Recently, I gave an emphatic recommendation for all IT people to read The Unicorn Project by Gene Kim immediately. This post is a summary of the main points raised in the book. They are grouped by topic and reordered into a coherent argument.
(It’s a longer post than I intended – sorry, not sorry – but that is a function of just how many key takeaways Gene raises.)
The Five Ideals
- The First Ideal: Locality and Simplicity
- The Second Ideal: Focus, Flow, and Joy
- The Third Ideal: Improvement of Daily Work
- The Fourth Ideal: Psychological Safety
- The Fifth Ideal: Customer Focus
On Locality and Simplicity…
“…design things so that we have locality in our systems and the organizations that build them … we need simplicity in everything we do. The last place we want complexity is internally, whether it’s in our code, in our organization, or in our processes. The external world is complex enough, so it would be intolerable if we allow it in things we can actually control! We must make it easy to do our work.”
“…Absolutely no one can get anything done if they have to work with eight other teams all the time…”
On Focus, Flow, and Joy…
“…all about how our daily work feels. Is our work marked by boredom and waiting for other people to get things done on our behalf? Do we blindly work on small pieces of the whole, only seeing the outcomes of our work during a deployment when everything blows up, leading to firefighting, punishment, and burnout? Or do we work in small batches, ideally single-piece flow, getting fast and continual feedback on our work? These are the conditions that allow for focus and flow, challenge, learning, discovery, mastering our domain, and even joy.
On Improvement of Daily Work…
“…we must elevate improvement of daily work over daily work itself…”
Before you start making lunch, a prudent move is to wash the breakfast utensils.
“…It is the dynamic that allows us to change and improve how we work, informed by learning.”
On Psychological Safety…
“…where we make it safe to talk about problems, because solving problems requires prevention, which requires honesty, and honesty requires the absence of fear. In manufacturing, psychological safety is just as important as physical safety.”
On Customer Focus…
“…where we ruthlessly question whether something actually matters to our customers, as in, are they willing to pay us for it or is it only of value to our functional silo?”
“…relentless focus on understanding the customer…”
“…where you are truly striving for what is best for them, instead of the more parochial goals that they don’t care about, whether it’s your internal plans of record or how your functional silos are measured … Instead we ask whether our daily actions truly improve the lives of our customer, create value for them, and whether they’d pay for it. And if they don’t, maybe we shouldn’t be doing it at all.
On Employee Engagement…
“…my job is to ensure that we fulfil our obligations to our employees, who make the daily work of this organization possible. Without [them], we would not be able to serve our customers…”
It is the job of every employee.
“…If [x] is the most important and strategic project for the company, don’t the teams who work on it deserve a better building?”
“…in most organizations, corporate IT is rarely loved and is often parked in the least attractive properties.”
“…corporate IT is usually viewed as ranks of nameless faces whom you call when there’s something wrong with your laptop or when you can’t print something.”
“…technology teams [should] work side-by-side with the business operations people. [They should be] viewed as partners. They work together, eat together, complain together, and drink together.”
“…It’s been true for hundreds of years and probably thousands more: employee engagement and customer satisfaction are the only things that matter. If we do that right, and manage cash effectively, every other financial target will take care of itself.”
“…If all our employees are excited to come to work each day, and if we’re delighting our customers through constant innovation and great service, cash flow will take care of itself.”
“…better customer service enables more sales…”
As Richard Branson says, “Take care of your employees and they’ll take care of your business.”
“…when willing developers are prevented from contributing.”
“…Our future depends on innovation … That doesn’t come from process. It comes from people.”
“…[implement] a career ladder for individual contributors and brilliant technologists without having to become managers.”
You have a valuable company asset not being leveraged to its full potential.
“…Creating software should be a collaborative and conversational endeavor – individuals need to interact with each other to create new knowledge and value for the customer.”
“…[it is important] to have a great network, able to find people who can help get important things done.”
“…this is what an effective network is all about – when you can assemble a group of motivated people to solve a big problem, even though the team looks nothing like the official org chart.”
“…How can you create anything of value if you don’t have feedback on how it’s used?”
“…There is nothing so rewarding as providing something to someone who really needs your help.”
“…bring back the days when a developer could actually create value for someone who cares, easily and quickly … build and maintain something for the long haul…”
“…one of the most rewarding and fun things I’ve ever done…”
“…everyone’s energy is high…everyone is having fun.”
When was the last time you woke up in the morning and couldn’t wait to get into work?
“…always on the lookout for places [to] help. It’s a great way to make friends and find potential new [collaborators]…”
“…It’s always easier to make new friends when you bring tasty treats.”
“…It’s not done until that customer can use [the feature]. And even then, it’s probably still a work in progress, because we can always learn more about how to help that customer best achieve their goals.”
“…great teams doing consumer-oriented products have ratios of 1: 6 because it’s that important to create products that people love. Every consumer these days knows what a professional app feels like. Apps that don’t have great designers are often ridiculed as enterprisey.”
“…assigned a team that included developers to explore the idea and build a solution together.”
“…amazing to see how people are acting and reacting to each other, especially when compared to … two months ago. People across different disciplines – Dev, QA, Ops, Security, and now even Data and Analytics – are working together daily as fellow teammates instead of adversaries. They are working toward a common goal. They realize that they are on a journey of learning and exploration, and that making mistakes is inevitable. Creating ever-safer systems and continual improvement is now viewed as part of daily work.”
“…We’ve shown what an incredible business and technology team working together can do, and we’ve got to elevate the dreams, goals, and aspirations of our business leadership.”
“…we all took a bunch of risks to get here, and I think we’ve all learned so much in this journey. I can’t believe how much we’ve gotten done…”
“…Although long hours are sometimes glorified in popular culture, [they are] a symptom of something going very wrong.”
“…No one can sustain those insanely long working hours. Who wouldn’t start making mistakes if you can’t even sleep anymore?”
“…How do we keep our people healthy enough so they can actually do their jobs? And how do we keep them happy enough so they don’t quit?”
“…It can be fun to be at the center of everything, but it’s certainly not sustainable. Down that road, only chronic wakeup calls, exhaustion, cynicism, and burnout await.”
“…Breaking the rules is the only way anyone can get anything done around here…”
“…a bad system will beat a good person every time.”
“…important to have a sustainable work pace and to limit our work in process to make sure that work keeps moving…”
“…developers who are nowhere near as productive as they should be, struggling to perform routine builds, spending too much time in meetings, or waiting for things they need.”
“…Instead of acting like an actual team, they act more like sovereign states on the brink of war, with diplomats trying to patch together an uneasy peace, complete with embassies, protocols, and official formalities. Even scheduling a meeting between these two groups requires a summit and lawyers present.”
“…These are people from Dev, QA, Security, and Ops – a very unlikely group of people to be socializing, let alone working together.”
But they ought to be; day in, day out! It should be the norm, not the edge case.
“…lack of trust and too much information flowing around [causes] things to go slower and slower.”
“…Most people aren’t brave enough to say what they think or to do the right thing. They just say ‘yes’ whether they agree or not.”
“…No one will take risks, experiment, or innovate in a culture of fear, where people are afraid to tell the boss bad news.”
“…Watermelon projects? Green on the outside, but red on the inside?…”
“…psychological safety [is] one of the most important factors of great teams: where there was confidence that the team would not embarrass, reject, or punish someone for speaking up. When something goes wrong, we ask ‘what caused the problem,’ not ‘who.’ We commit to doing what it takes to make tomorrow better than today. …every incident is a learning opportunity, an unplanned investment that was made without our consent.”
“…mistakes and entropy are a fact of life … Punishing failure and shooting the messenger only cause people to hide their mistakes, and eventually, all desire to innovate is completely extinguished.”
“…mitigate the HIPPO effect (or Highest Paid Person’s Opinion), … people’s unhealthy tendency to only care what the highest-level decision-maker thought.”
“…It’s so easy for leaders to talk about the platitudes of creating psychological safety, empowering and giving a voice to the front-line worker … But repeating platitudes isn’t enough. The leader must constantly model and coach and positively reinforce these desired behaviors every day. Psychological safety slips away so easily, like when the leader micromanages, can’t say ‘I don’t know,’ or acts like a know-it-all, pompous jackass. And it’s not just leaders, it’s also how one’s peers behave.”
“…Everyone must be responsible for their own safety and the safety of their teammates. If you see something that could hurt someone, you must fix it as quickly as possible.”
“…leaders [should] buffer their people from all the political and bureaucratic insanity, not throw them into it.”
“…the only way they could have achieved what they had was by creating a culture where people felt safe to experiment, to learn and make mistakes, and where people make time for discovery, innovation, and learning.
“…build a world-class technology organization and create an engineering culture.”
“…Startups have lots of ability to do things … but they’re always lacking the resources to do them. This is not a story about small beating large; it’s fast beats slow.”
“…Small doesn’t beat big … fast beats slow. And fast and big will win almost every time.”
On Tools & Techniques…
“…Everyone … thinks features are important, because they can see them in their app, on the web page, or in the API. But no one seems to realize how important the build process is. Developers cannot be productive without a great build, integration, and test process.”
“…making developers more productive is always super important…”
“…when people can’t get their builds going consistently, disaster is usually right around the corner.”
“…Without constant feedback from a centralized build, integration, and test system, they really have no idea what will happen when all their work is merged with everyone else’s.”
“…there’s something even more important than code: the systems that enable developers to be productive, so that they can write high-quality code quickly and safely, freeing themselves from all the things that prevent them from solving important business problems.”
“…developers need a system where they can get fast and continual feedback on the quality of their work. If you don’t find problems quickly, you end up finding them months later. By then, the problem is lost in all the other changes that every other developer made, so the link between cause and effect disappears without a trace.”
“…having a great build process is key to having a good code deployment and release process.”
“…if we all want our developers to be productive, they need to be able to perform builds on Day One. Ideally, they should be writing code in a production-like environment so they can get fast feedback on whether the code they write works with the system as a whole.”
“…we need an automated way to create environments and perform code builds … We need some way to automate those tests and some automated way to get those builds deployed into production. We need builds so that developers can actually do their work.”
“…getting builds going again is one of the most urgent and important engineering practices … Once we get continuous builds going, we enable automated testing. We get automated testing, we can make changes quicker, with more confidence, and without having to depend on hundreds of hours of manual testing. And that, I believe, is the critical first step for how we can deliver better value, safer, faster, and happier.”
“…The importance of lead times in software delivery is tantamount … Code deployment lead time, code deployment frequency, and time to resolve problems are predictive of software delivery, operational performance, and organizational performance, and they correlate with burnout, employee engagement, and so much more … Simplicity is important because it enables locality. Locality in our code is what keeps systems loosely coupled, enabling us to deliver features faster. Teams can quickly and independently develop, test, and deploy value to customers…”
“…putting cross-cutting concerns in one place is so great, like logging, security, or retry policies. You change it there, and you’ve changed it everywhere…”
“…Being able to test and push code to production is more productive, makes for happier customers, creates accountability of code quality to the people who write it, and also makes the work more joyful and rewarding.”
“…brainstorm ways to dramatically improve developer productivity…”
“…We need developers to be able to focus their best energies on building features, not trying to get builds to work.”
“…Business people can see features or apps, so getting funding for those is easy … But they don’t see the vast architectures underneath that support them, connecting systems, teams, and data to each other. And underneath that is something extraordinarily important: the systems that developers use in their daily work to be productive.”
“…tech giants assign their very best engineers to that bottom layer, so that every developer can benefit.”
“…Every developer uses a common build environment. Every developer is supported by a continuous build and integration system. Everyone can run their code in production-like environments. Automated test suites are built to replace manual testing, liberating QA people to do higher value work. Architecture is decoupled to liberate feature teams, so developers can deliver value independently.”
“…it’s about how … requirements change so often, which almost always requires urgent code changes. This reduces the time available for testing, resulting in poorer quality…”
“…automated tests would be run every time a developer checks in code, giving fast and immediate feedback … They could find mistakes right away and not make the same mistake day after day, week after week.”
“…It hurts because the merge sizes are so large. To make it hurt less, they need to do it more frequently, so that the merges are small and create fewer conflicts.”
“…developers will eventually be responsible for testing their own code, with QA taking a more strategic role, coaching and consulting. It means all the automated tests they’re writing will soon run with every check-in once they get their centralized build and continuous integration (CI) server going.”
“…because tests are being checked in with the code themselves, it’s easy for the developer to quickly reproduce and fix the problem.”
“…automate the production deployments … enable fast and safe deployments into production, and … do it using the same environments across Dev, Test, and Production.”
“…code is … promoted into production multiple times per day, smoothly, quickly, and mostly without incident, with any issues being resolved quickly and without blame or undue crisis.”
“…Purchasing says we can only order twice per year to get the best quantity discounts with our vendors.”
“…Because it takes so long for Ops to get anything to us, people always ask for way more than they need. And that makes Ops’ job harder and lengthens the lead times for everyone else, making the shortages even worse!”
“…centralized Ops are merely the people on the other side of a ticket. They’re the people everyone is always complaining about.”
“…the bureaucracy and silos have taken over. You can’t do anything without first convincing a bunch of steering committees and architects or having to fill out a bunch of forms or work with three or four different teams who each have their own priorities. Everything is by committee. No one can make decisions, and implementing even the smallest thing seems to require consensus from everyone.”
“…Product Requirements Documents … made sense decades ago, when you wanted written justification before you wasted a bunch of developers’ time. But now you can prototype most features in the time it takes to even write one page of a PRD. One team can now build things that used to require hundreds of people.”
“…They did it to reduce costs, but … in the end, it was more expensive for everyone all around … it took everyone longer to do their work, with everyone having to communicate, coordinate, get approvals, with project managers shuffling and deconflicting all the work.”
“…you’ve trapped yourself in a system of work where you can no longer solve real business problems easily anymore – instead, you’re forced to merely solve puzzles all day, trying to figure out how to make your small change, obstructed by your complected system every step of the way. You must schedule meetings with other teams, try to convince them to change something for you, escalate it to their managers, maybe all the way up the chain.”
“…you complected their value streams, all now having dependencies on each other that didn’t exist before. They must constantly communicate, coordinate, schedule, marshal, sequence, and deconflict their work. They now have an extremely high cost of coordination, which has lengthened lead times, decreased quality…”
“…Simplicity is important because it enables locality … Locality in our organizations allows teams to make decisions without having to communicate and coordinate with people outside the team, potentially having to get approvals from distant authorities or committees so far removed from the work that they have no relevant basis to make good decisions…”
“…change old rules that no longer apply, change how you organize your people and architect your systems…”
On Continuous Improvement…
“…The joy of teaching people something that they want to learn is awesome.”
“…win by innovating and understanding our customers…”
“…Innovation and learning occur at the edges, not the core. Problems must be solved on the front-lines, where daily work is performed by the world’s foremost experts who confront those problems most often.”
“…For every winning idea, there are many losing ideas. And some of the winners seemed outright crazy and never would have been approved by the typical middle-manager or committee. The literature suggests that in general, only one out of every three strategic ideas has a positive result, and only a third actually move the needle in a material way.”
“…It is ignorance that is the mother of all problems, and the only thing that can overcome it is learning…”
“…For the leader, it no longer means directing and controlling, but guiding, enabling, and removing obstacles…”
“…When something goes wrong, we ask ‘what caused the problem,’ not ‘who.’ We commit to doing what it takes to make tomorrow better than today … every incident is a learning opportunity, an unplanned investment that was made without our consent.”
“…[conduct] a blameless post-mortem … The spirit and intent of these sessions are to learn from them, chronicling what happened before memories fade. Prevention requires honesty, and honesty requires the absence of fear … Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand … The only rule is that you can’t say ‘I should have done X’ or ‘If I had known about that, I would have done Y.’ Hindsight is always perfect. In crises, we never actually know what’s really going on, and we need to prepare for a future where we have an equally imperfect understanding of the world.”
“…these blameless post-mortems…now [have]] a reputation for being the fastest way to learn about the most innovative and exciting things in the company.”
“…continuously performing experiments…”
“…mildly irritated that these details were caught so late in the launch process. But on the other hand, that’s what rehearsals are for and why everyone is assembled in the war room. Everyone needed to make these types of last-minute calls are in the room and everyone agreed that it made sense…”
“…proud of how well her teams did, handling every crisis that was thrown their way, quickly adapting and learning. And absolutely everyone knows that all this adversity is a great thing…”
“…the future requires creating a dynamic, learning organization where experimentation and learning are a part of everyone’s daily work.
“…hundreds of plant worker suggestions were put into production to improve safety, to reduce toil, to increase quality, and to increase flow. That too is also a form of continual experimentation. You now need it at a much larger level, liberated from the tyranny of project management and functional silos.”
“…it’s an extremely experimental process, an exercise of exploration and learning. Not every idea is a winner…”
“…For feature promotions, A/ B tests, or algorithmic testing, you may be thrilled to even have five percent of tests work. We need a group that is dedicated and empowered to explore a broad range of business ideas that take advantage of our unique position in the marketplace, to quickly make bets, and then explore and validate them, she says. We need to have some way to quickly shut down bets that don’t pan out and to double-down on the winners.”
“…We all have this ideal of small teams working independently, but who manages the teams of teams? It’s your middle managers. Some call them derisively the ‘frozen middle,’ but you’ll find that properly developing this layer of people is critical to execute strategy.”
“…oversee a massive reskilling of the workforce … investments to make sure every worker could survive and thrive in a new era where everyone was being paid not to just use their hands but also their heads … one of the most fulfilling and rewarding things…”
“…long-term training where we create the next generation of leaders and engineers we need for the long-term survival of the company. We pay them to get the skills they need.”
“…explore the viability of the idea, investigating market risk, technical risk, and business model risk, and hopefully achieving some fantastic agreed-upon business outcomes.”
“…The most valuable thing you can do is mentor or learn from your peers.”
“…adult learners often hide the fact that they’re trying to acquire a new skill, whether it’s learning a new language, swimming, or even taking golf lessons. It usually comes from embarrassment or being afraid of being seen doing something that they’re not good at.”
“…ensure that the entire company can ship the best ideas, wherever they come from, quickly, safely, and securely.”
“…Ops is quickly turning into a platform team and internal consultants, with the goal of providing developers the infrastructure they need, complete with a vast army of experts who are there to help, looking for ways to make developers productive.”
On Technical Debt…
“…For those of you not in technology, ‘technical debt’ is what creates hardship, toil, and reduces the agility of our software engineers … technical debt is what you feel the next time you want to make a change. There are many things that people call technical debt, but it usually refers to things we need to clean up, or where we need to create or restore simplicity, so that that we can quickly, confidently, and safely make changes to the system…”
“…agility is never free. Over time, without this type of investment, software often becomes more and more difficult to change.”
“…even more impressive is your ruthless eradication of technical debt as a part of your daily work.”
“…In tightly coupled and complected systems, it’s nearly impossible to change anything, because you can’t just change one area of the code, you must change one hundred, or even a thousand, areas of the code. And even the smallest changes can cause wildly unpredictable effects in distant parts of the system, maybe in something you’ve never even heard of.”
“…achieving this greatness is never free. It requires focus and elevation of improvement of daily work, even over daily work itself. Without this ruthless focus, every simple system degrades over time, increasingly buried under a tundra of technical debt.”
“…Sometimes it’s when decision-making processes or the organizational structure loses locality, forcing even small decisions to be escalated – your infamous ‘Square.’”
“…You can choose to build new features or you can choose to pay down complexity debt. When a fool spends all their time on features, the inevitable outcome is that even easy tasks become difficult and take longer to execute. And no matter how hard you try or how many people you have, it eventually collapses under its own weight , forcing you to start over from scratch.”
“…Your teams are able to add features at a rate that [everyone] should envy. And that is only possible because you pay down technical debt as a part of daily work.”
“…Every tech giant has nearly been killed by technical debt … they became so encumbered by technical debt they could no longer deliver what their customers demanded … The consequences would have been fatal – and for every survivor, there are [others] who fell from the loftiest heights, killed by technical debt.”
“…Technical debt is a fact of life, like deadlines. Business people understand deadlines, but often are completely oblivious that technical debt even exists. Technical debt is inherently neither good nor bad – it happens because in our daily work, we are always making trade-off decisions … To make the date, sometimes we take shortcuts, or skip writing our automated tests, or hard-code something for a very specific case, knowing that it won’t work in the long-term. Sometimes we tolerate daily workarounds, like manually creating an environment or manually performing a deployment. We make a grave mistake when we don’t realize how much this impacts our future productivity … All the tech giants, at some point in their history, have used the feature freeze to massively rearchitect their systems … famous internal memo … stating that if a developer has to choose between implementing a feature or improving security, they must choose security, because nothing less than the survival of the company was at stake … Interestingly … still has a culture that if a developer ever has a choice between working on a feature or developer productivity, they should always choose developer productivity.”
“…real problem: technical debt in the form of an architecture where developers could not be productive.”
“…Context and Core. There are services we should get out of the business of operating … challenge … the technology team to think deeply about … areas of Context that you can unload, freeing yourself from decades of technical debt, things that have been shackling you for years or maybe even decades. Imagine what you can get done without all those things dragging you down. Even though it may be more painful in the short term, you will find some unexpected and critical dividends long term…”
“…Imagine what it could feel like to deliberately and carefully choose what to leave behind and where you could spend your time and energy instead …simplicity enables effectiveness, and that complexity conspires against it. How much of getting business done here is impeded by your internal systems and processes?”
On [Business] Change Management…
“…goes to extraordinary lengths to describe the business outcomes that need to be achieved and the grave consequences of not doing so.”
“…it looks so much like the same drill that everyone in Ops deals with all the time. Do more with less. Outsource this. Outsource that. In the past, this has led to some incredibly unwise decisions, and people like us are left cleaning up the mess afterward for years. And when everyone’s realized that we crapped the bed, we often have to bring everything back in-house. There’s nothing fun about that.”
“…production deployments are some of the most complex activities of any technology organization, because they require so much coordination between so many different parts of the organization.”
“…By the book, there’s two extremes for how to run companies, which affects how you plan and how the investment community perceives you. On one extreme,you have … creating value, which is just by cutting costs. You squeeze every bit of margin you can out of the operation. Some companies thrive at this, and some manage to malinger for decades, but most eventually fade and disappear … But when you’re in this mode, you’re often just playing financial engineering games … In order to stem our losses, we’ve had to do a couple of asset sales to generate cash. But this can be like selling the furniture to pay the mortgage bill. Eventually, you run out of things to sell and you can no longer fund daily operations, which means more layoffs.”
“…On the other end of the spectrum, you can choose to build the company for growth … if you’re not growing, you’re slowly dying … we can actually grow: by creating new offerings that customers want, by taking market share away from our competitors, by doing things that great companies do … And when we grow revenue, we eventually grow profits too. And we earn the ability to innovate and place more bets in the marketplace, which accelerates growth and ensures our relevance in the future. Investors reward growth … And in time, they may value us much higher, as someone who is defining and leading, and maybe even disrupting our market.”
“…Islands of technologies, which served us well for decades, but we’ve drifted so far from where the entire industry has gone that we haven’t been able to benefit from all the things the industry vendors have created. Maybe it’s time to build a bridge back to the mainland … or maybe vacate the island completely.”
“…A healthy software system is one that you can change at the speed you need, where people can contribute easily, without jumping through hoops.”
“…charter is to help create a culture of engineering excellence across the entire company. She’ll meet regularly with the top company leadership to understand their goals and strategize on how technology can be used to achieve those goals, which of course helps the company win in the marketplace.
“…fund more teams to explore the most promising business ideas, to find the next winner…”
“…The power to disrupt the customer experience is [now] … within reach of almost any organization that wants to disrupt the market. And who better to disrupt things for the benefit of customers than the organizations that already have a decades-long relationship with them?”
“…Companies … already have the customer relationships, the supply chains, the understanding of the customer’s wants and needs as they progress through their own life journey. Compared to startups, the modern enterprise has more resources and expertise. What’s needed is focus and urgency, and the modern methods of managing the value creation process.”
“…We are at the dawn of the Age of Software and Data … [think about] what data is most important to the long-term success of the company, exploring ways of buying data from our customers and even potentially acquiring strategic data sources.”
“…In order to remain relevant, people need to view us as a market leader creating new business models…”
“…Cores are the central competencies of the organization. These are things that customers are willing to pay for and what investors reward … Context is everything else. It’s the cafeterias, shuttles between buildings, and the thousands of things companies must do to operate. They’re often mission-critical, such as HR, payroll, and email. But our customers do not pay us for the great payroll services we provide to our employees.”
“…how much of the [technology budget] spending is Core, actively building competitive advantage, and how much of it is Context, which is important and maybe even mission-critical, but still needs to be standardized, managed down, and maybe even outsourced entirely? … of the applications and services that you manage, which of them are customers willing to pay you for? Which ones truly enhance competitive advantage? And which can you rely on vendors for?”
“…compliance is not just a moral obligation or a set of contractual obligations … it’s also the law.”
“…everyone is the custodian of company data. It’s not just the job of one department.”
“…You build it, you run it.”
Heads-up: there’s a strobing effect which I think is caused by shooting at 60FPS in a area lit by LED lights
I put together a set of potential questions to use when interviewing people for DevOps roles. I’m sharing them here so that others may benefit from using them. Alternatively, feel free to comment so that we all, interviewers & candidates alike, can improve on the hiring experience.
They are clustered into topics such that if I think a candidate has answered an initial question or questions really well (or indeed not at all), I’ll skip to the next cluster; there’s little point asking about related areas under different guises.
Conversely, if the candidate has struggled, I’ll probe deeper. It might be that my phrasing of the question is the cause of the misunderstanding.
- What can you tell me about yourself that isn’t on your CV?
- What is your greatest achievement/accomplishment?
The point here is to get the candidate relaxed and talking more freely.
- Discuss your experience building bridges between various separate groups?
- Can you give an example of where you’ve been able to use your leadership and communication skills?
- Can you describe a situation where you endured adversity?
I’m looking for STAR responses here – Situation, Task, Action, & Results
- What are the advantages of Pair Programming?
- What do you know about DevOps?
- Is there a difference between Agile and DevOps? Please explain your answer
Starting to get under the skin of what the candidate really knows.
- Why has DevOps gained prominence in recent times?
- What is the most important thing DevOps helps us achieve?
- What are the key components of DevOps?
- What is Devops with respect to Cloud Computing?
- How would you explain the concept of Infrastructure-as-Code?
- How might IaC be implemented?
- Why are configuration management processes and tools important?
Has the candidate got a genuine understanding? Or have they researched the topic the previous night in prep. for this moment?
- What is meant by Continuous Integration?
- Why do you need a Continuous Integration of Dev & Testing?
- What are the success factors for Continuous Integration?
- What are Design Patterns?
- What testing is necessary to ensure that a new service is ready for production?
- What is functional testing and non-functional testing?
- Which testing tool are you comfortable with and what are the benefits of that tool?
- What is continuous testing?
- What is test automation?
- What are the benefits of test automation?
- How to automate testing in DevOps lifecycle?
- Why is continuous testing important for DevOps?
How are the candidate’s development skills?
- Why is continuous monitoring necessary?
- Are you a team player?
- Explain your understanding and expertise on both the software development side and the technical operations side of an organization you have worked with in the past.
Some candidates have focused far too heavily on the Dev aspect, neglecting the Ops element; these questions are intended to bring that side to the fore of candidates’ answers.
- What is your approach to learning new skills?
- What was the last book/article you read?
I treat these as gateway questions in that the candidate may well be able to teach me something new here. Depending on their initial response, I will ask unrehearsed, follow-up questions in a more conversational style.
- Why is this job the right fit for your career?
- Do you have any questions for us?
While the last question might be thought of as obligatory, cliche even, in combination with its predecessor, it still provides an valuable indicator of the buy-in by the candidate. I don’t mind helping anyone practice their interview skills; it’s also practice for me as an interviewer, with zero lost-opportunity impact. What I don’t want is to offer/appoint a candidate who is only biding their time, looking for something better whilst in role. In the meantime, I may have missed out on the perfect appointee.
I recently completed interviewing a number of candidates for a new team. It was the first time I had prepared and set the criteria. All the interviews I participated in previously were based on someone else’s script. The following is what I learned from the exercise…
- Look for people who have endured adversity
- How did they rise to the challenge? (Look for examples of demonstrating resillience)
- What did they learn from the experience? (Do they have a growth mindset)
- Ask questions designed to identify people who are…
- Humble, e.g. quick to admit their mistakes, willing to roll their sleeves up & get stuck in wherever needed? (I need team players, not lone wolves)
- Hungry, i.e. they’ll go above & beyond (results/goal oriented)
- Smart – more EQ-related than IQ, e.g. genuinely interested in other people, or using common sense in dealing with people-related issues (good culture fit)
- Get the interviewee away from the formal interview setting, the more radical, the better
- How rounded (as a person) are they, e.g. away from the workplace? Would you still want to hire them after a long, 1-on-1 road-trip?
- How adaptable (to context) & accepting of change are they? (The future is unpredictable)
- Look for the imperfect fit
- Don’t hire someone who has done the job already; they will get bored quickly
- Look for potential to grow into the role; a 70% fit, with a balance of skills & drive, is a good threshold, The candidate can make the remaining 30% their own in terms of stretch goals
- Ask them, if appointed, how will they help…
- …the team achieve their goals & objectives?
- …me with my short, medium, & long term goals & objectives, etc.?
The primary rationale for all of the above is this…
A poor fit, cultural or otherwise, will always gravitate towards the low performer group.
Footnote: I’m not sure on the radical-interview-setting point. I think it potentially opens up an avenue of criticism targeting unfair recruitment practices. I’d be happy to hear any thoughts on this because I can absolutely see the benefits but only if it can be done legitimately.
I’ve had some spare time recently so I’ve been through this material as a revision exercise.
This is a log of the online content I’ve been through during this revision exercise.
Connor’s had a balance bike for ages but this is only a brief clip of what he managed on his 2nd go on a push bike. All told, he did laps of the skate park for about 20 minutes.
Full disclosure, he did come off early on but fair play, straight back on and away again.
He’s also been going to Clip n’ Climb Ilkley on and off for a while where they do a full on safety briefing, proper harness, and auto belaying. He rocks up to this climbing frame…
My fix was to reset the device’s network settings (but I fear it may not work for all hardware versions).
After upgrading and reconnecting to WiFi after the mandatory reboot, all my Apple devices insisted on using the WEP protocol – whose security has been broken for some time.
Lots of things I tried didn’t work…
- Turning WiFi off and on again – off-&-on-again isn’t always the answer; who knew?
- Airplane mode;
- Forgetting the network; &
- Hard reboots – of both devices and router.
Eventually, I twigged that under Settings -> General -> Reset, there’s a Reset Network Settings option. You are prompted for confirmation and your PIN. The device will reboot and, once restarted, you’ll need to select your WiFi SSID re-enter your password.
A small price to pay for privacy!