Recently I listened to the audiobook of The Unicorn Project by Gene Kim. In the past, I’ve recommended its predecessor, The Phoenix Project, to multiple people, albeit reluctantly and tinged with embarrassed explanations about the format—the “business novel.” The author, Gene Kim, presents his thesis as a fictional narrative constructed solely to serve that end. The Ur-book in this genre is The Goal, which lives on more than one list of the best business books. (Both Phoenix and Unicorn specifically reference The Goal.)
I found The Unicorn Project to be slow to start but ultimately covering a lot of valuable ground. It’s most useful as a DevOps introduction for junior software engineers and for those who have only ever worked in dysfunctional organizations. It’s a great illustration of the power of continuous delivery and DevOps practices—continuous integration, developers working directly with the business, replicable builds, etc.—in a way that some people may find more powerful and digestible than a traditional exposition. Stories can be more powerful than facts.
But if you’re already aware of the concepts, you’ll spend a lot of time saying, “I know, I get it, dev environments need to be easy to set up and reproducible, I get it.” Some of the story sounds over the top—and it is—but having been on calls with big organizations trying to release software, it’s unfortunately very, very accurate.
The following are the concepts I found most useful:
- The three horizons
- The five ideals
- Core and context
- Complection
The three horizons
The three horizons is the concept that I find myself coming back to most. I am not sure how accurate it is as a top-level classification of businesses, but I have found it useful as a model.
Geoffery Moore created the three horizons to explain and categorize different types of businesses (or business units):
- Horizon 1 is the legacy core business that generates the bulk of a company’s revenue and profitability. It’s predictable and is where process can and should be applied to drive incremental improvements and change. On the downside, it is where bureaucracy thrives and can resist needed change. It’s a gravity well that left unchecked will consume most of the company’s resources—after all, it’s where the bulk of revenue comes from. While you can reduce costs and maximize profitability in the short/medium term, any Horizon 1 business will eventually fade, since any profitable businesses invites competition that inevitably erodes profitability.
- Horizon 2 is a smaller, emerging business that represents a possible future of the company. These businesses aren’t necessarily profitable—certainly not at first—but represent informed bets the company is making to find higher growth areas. The objective for a Horizon 2 business is to grow up into a Horizon 1 business.
- Horizon 3 businesses are the true experiments. They require a culture of learning, and a willingness to prototype and iterate quickly to evaluate (1) market risk (does it solve a customer need), (2) technical risk (is it technically feasible), and (3) business model risk (is it a financially viable engine of growth). Many of these will fail. The most promising of these graduate into Horizion 2 efforts.
Horizon 2 and 3 are about learning-R&D, experiments, new markets, new customers, new businesses. Horizon 1 is about process and compliance. These will by nature clash.
I am by nature somewhat of a process person, so this model has been useful to remind me to try to ensure our team spends enough time in both Horizon 2 and Horizon 3. This requires (1) protecting people’s time, and (2) having a tolerance for certain teams not following established process for organizing our creation of software. But the risk of over-optimizing for the existing business is slow death.
The five ideals
You can argue the whole book is an elaborate mechanism for Kim to propose and illustrate his the five ideals for leading a technology business:
- The First Ideal: Locality and Simplicity. In your software architecture, ideally introducing a new feature only requires changing a small amount of code in a single codebase, as opposed to many changes in many codebases. Complexity makes everything harder, and slows you down. The simpler your code, systems, and organization, the better off you will be. You don’t have locality and simplicity, making changes can be tied up in cascading, unknown dependencies. Or it requires the coordination of many different teams. This ideal directly leads to the goal of product-aligned, cross-functional teams that can deploy their own software to production.
- The Second Ideal: Focus, Flow, and Joy. How does work feel? How it feels doesn’t matter for its own sake, but it is a leading indicator of the effectiveness and efficiency of how work gets done. Developers do their best work when they can focus on a single, difficult problem, and when their tools work with them rather than against them. Can developers work on one thing at a time, get fast feedback on their work, and quickly push their work to production? The way I think about this is that this ideal is about maximizing the amount of time a developer spends effectively thinking about and working on problems, and minimizing the amount of time lost on friction—waiting for others, waiting for builds, struggling against tooling, etc. This ideal also points to working in small batches—Theory of Constraints—both because it’s more efficient, and because it’s more enjoyable.
- The Third Ideal: Improvement of Daily Work. In other words, continuous improvement. It’s essential to prioritize time to improve workflows and pay down technical debt, since incremental investments can pay off big over time.
- The Fourth Ideal: Psychological Safety. Psychological safety is one of the top predictors of team performance. People need to feel safe to take risks and experiment and empowered to tell the boss something she doesn’t want to hear. A key example of this is a blameless postmortem. When there is a major customer-impacting outage, everyone should feel safe enough to raise their hand and say, “I might have caused this” and talk through tough issues with an eye for discovering the truth—not for assigning blame or ridicule. Without this, learning and improvement are impossible.
- The Fifth Ideal: Customer Focus. Ensure that developers (and development teams) are focused outward towards the wider world, and not inward towards itself, turf, internal company concerns, or shiny technology for its own sake. A business needs to deliver value to customers to stay in business, and relentless focus on that leads to better decisions about technology and product. Ask yourself: does this actually matter to customers—i.e., are they willing to pay for it? One way to think about this is core vs. context, which I discuss below.
None of these ideas are novel to this book. But the categorization is useful for thinking about these concepts and seeing them in the world. That sounds like faint praise, but it’s not. These are essential concepts, succinctly captured.
Complection
Complect: To intertwine, or interweave, or to turn something simple into something complex.
The idea here is that software systems become complected over time, as different areas become more tightly coupled. It becomes harder (or impossible) to work on a single system because of unpredictable effects elsewhere. This is the inverse of encapsulation, although Kim uses the term “locality.”
… ‘Think of four strands of yarn that hang independently—that’s a simple system. Now take those same four strands of yarn and braid them together. Now you’ve complected them.’ Both configurations of yarn could fulfill the same engineering goal, but one is dramatically easier to change than the other. In the simple system, you can change one string independently without having to touch the others. Which is very good. However, in the complected system, when you want to make a change to one strand of yarn, you are forced to change the other three strands too. In fact, for many things you may want to do, you simply cannot, because everything is so knotted together.
Is this term useful? Maybe. I’ve always talked using words like “encapsulation” or “avoiding cross-dependencies” or “loosely-coupled” which has always gotten my points across.
Core and context
The purpose of a business is to produce a thing to sell to customers.
Core activities are those that customers are willing to pay for. Context is everything else, i.e., all of the activities that support the business but customers don’t care about and don’t create a competitive advantage—payroll systems, email, bug trackers, etc.
The point is to minimize the amount of money and effort going into context activities, and maximize the amount of time going into core. Your product should be world-class. Your email system simply needs to work. This is a great rule of thumb for deciding whether to build or buy.
One thing that The Unicorn Project does well is showing how, as time passes, what was once core can become context. Late in the book, the protagonists, forced to cut costs, struggle to decide what they should stop doing and outsource. Decades ago, they built a first-in-class ERP system, which proved a huge competitive advantage. But now there are off-the-shelf solutions that are just as good. It’s no longer a competitive advantage; it’s a distraction.
It’s important to periodically evaluate what you are working on to ensure you are spending the most time possible on investing in producing and improving the things that people actually want to buy.
Conclusion
The Unicorn Project is an interesting artifact of a book. The concepts are powerful and powerfully stated. But you have to wade through a lot of words to get to them, which I found frustrating at times. (I “read” it as an audiobook, which is probably the best way to tackle it). I think for many people, this is an ideal introduction to these DevOps concepts. The stories that a team tells about itself create a shared sense of purpose and reality—and this book can jumpstart that. You can steal these stories as a shorthand for the work that you need to do.