The Unicorn Project

Summary

The Unicorn Project is a book about organizational change and the improvement of working conditions within tech organizations. It's about strategies and ideas that engineers can employ to maximize their and their teams' contributions to the company.

The goal is to create a vibrant ecosystem of excellence that helps create value for the customer. But the learnings and ideas are wrapped in a well-written story, making the book really hard to put down.

The key takeaways for me were the following ideas:

1. The 5 Ideals of Work
2. The 3 Horizons of What a Company Does
3. The Focus on Context vs. Core Expenditures

The 5 Ideals

• locality and simplicity => a change should be done by a two-pizza team, if it needs cross-coordination between teams, something is off in the organizational structure.
• flow and joy during work => Work, as a heuristic, should be fun. Flow is a guiding compass, a result of also following the other 4 ideals and making sure that people have immediate feedback on whether or not the work they are doing is good or not. It's win/win because the employees and the company benefit from it.
• focus on improvement of daily work => This has to be done consistently, all the time, sometimes even over daily work itself, else one gets lost in a quagmire of technical debt and bad tooling, getting nothing done, ever.
• psychological safety => If somebody makes mistakes, they should be happy to tell everybody about it because mistakes are an opportunity to learn. Post-mortems should be done blamelessly, analyzing faults and putting automated systems in place, so that the same mistakes can't happen again.
• relentless customer focus => asking what does this work do for our clients, all the time. What value do we provide here, asking why this is necessary? What is the use case? Knowing how engineering work improves the business outcome or enables other people to improve the business outcome is important in prioritizing one piece of work over another.

The 3 Horizons

Companies have different sets of things that they have to work on and balance resources between. They can be broadly divided into three horizons. Horizon 1 is the "cash cow" of the business. It's already scaled up, and now it's about making it more efficient, increasing margins, and creating bureaucracy to not break existing systems. Horizon 1 is important but eventually, the world moves on and Horizon 1 will become obsolete. Hence Horizon 2 and 3 are necessary. They explore new opportunities and build them into new Horizon 1 business ventures. Horizon 2 is the stage of scale-out, of deploying resources in order to grow a business idea that has been validated and tested on a smaller scale before. Horizon 3 is rapid-fire testing, iteration, and innovation. It's about having novel ideas, that can explore new markets, new technology and other things like it. It's usually the thing that early-scale startups are doing (experimentation) in order to find something viable that can then be scaled with VC money. But crucially, big companies have to also invest resources into Horizon 3 or they'll become obsolete eventually. If Horizon 1, 2 and 3 are well implemented, this results in continuous innovation and relevance for a company, as well as growing financial results.

Context vs. Core

Some things are core to a business and other things are mere context: things that the company has to do but don't provide a unique decisive advantage. They are not core to what the company is really doing but necessary to keep every company running. HR, payroll, time-card systems, messaging, email, etc. fall into this category. Spending should be relentlessly focused on the Core. I.e. if there is an expense that goes to context, but there is a tool, outside the company that costs less than doing this same work in-house, then there is no reason not to use it and pipe the saved costs into things that are more relevant to the business.

Detailed Notes

The detailed notes below are packed with quotes from the book as well as people and book recommendations that keep popping up in the book.

Chapter 1

Blaming someone for a payroll outage is a strange way of appreciating someone.

I expect leaders to buffer their people from all the political and bureaucratic insanity, not throw them into it.

Although long hours are sometimes glorified in popular culture, Maxine views them as a symptom of something going very wrong.

Chapter 2

Paper Recommendation: Papers We Love Series

Words to Look Up - Non-Referential Transparency, Strangler Pattern.

Trying to get a Phoenix build going is like playing Legend of Zelda, if it were written by a sadist, forcing her to adventure far and wide to find hidden keys scattered across the kingdom and given only measly clues from uncaring NPCs. But when you finally finish the level, you can't actually play the next level—you have to mail paper coupons to the manufacturer and wait weeks to get the activation codes.

Companies have two modes of operations: peacetime and wartime. Peacetime is when things are going well. This is when we are growing as a company and continue business as usual. During these times, the CEO is often also the board chairman. However, wartime is when the company is in crisis, when it is shrinking or at risk of disappearing. [...] During wartime, it's about finding ways to avoid extinction. And during wartime, the board will often split the roles of CEO and chairman.

Chapter 3

A great day is when she's solving an important business problem. Time flies because she's so focused and loving the work. She's in a state of flow, to the point where it doesn't feel like work at all. A bad day is spent banging her head against a monitor, scouring the Internet for things she doesn't even want to learn but needs to in order to solve the problem at hand.

Just because she felt busy doesn't mean that she actually did anything meaningful.

None of the meetings on her calendar seem interesting anymore. It's just people complaining about waiting. Waiting for something. Waiting for someone. Everyone is just waiting. And she wants no part of it right now.

The joy of teaching people something they want to learn is awesome.

Maxine knows that agility is never free.

When you have customers, change is a fact of life.

Chapter 4

There is nothing so rewarding as providing something to someone who really needs your help.

Chapter 5

We're figuring out how to engineer our way there.

Chapter 6

The first thing she would have done right away is write some automated tests to ensure that all input files are correctly formed before they allow them to corrupt their production database, and that the correct number of rows are actually in the file.

Technology failures cascade through the organization, like water flooding through a sinking submarine.

He turns back to work on his piece of the puzzle, not caring that none of the pieces actually fit together. Or that the entire puzzle has caught on fire over the weekend, along with the house and the entire neighborhood.

Chapter 7

Complect means to turn something simple into something complex.

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 hundred, or even a thousand, areas of the code. And even the smallest change can cause wildly unpredictable effects in distant parts of the system, maybe in something you've never even heard of.

Sensei's in the Book: Rich Hickey

Sensei's in the Book: Dr. Nicole Forsgren

Sensei's in the Book: Jez Humble

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.

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.

Sensei's in the Book: Ward Cunningham

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.

The Five Ideals:

• Locality and Simplicity
• Focus, Flow and Joy
• Improvement of Daily Work
• Psychological Safety
• Customer Focus

Chapter 8

Maxine loves Byzantine processes like pediatricians love sick children.

It may not be the most elegant piece of software she's seen, but things that have been in production for twenty years rarely are. Software is like a city, constantly undergoing change, needing renovations and repair.

Race conditions are one of the toughest categories of problems in all of distributed systems and software engineering.

Multi-threading errors are at the very limits of what humans can reason about.

It is most impossible to predict how a program will behave if any other part of the program can change data that you're depending on at any time.

Functional programming principles are better tools to think with.

Fixing the code especially for features is just a fraction of the entire job. It's not done until that customer can use what they've written. 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.

Technical debt is a fact of life, like deadliness. Business people understand deadlines, but often are completely oblivious that technical debt even exists.

Sensei's in the book: Risto Siilasmaa

Business people can see features or apps, so getting finding 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.

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.

TWWADI - the way we've always done it

[If] the distance from where decisions are made and where work is performed keeps growing, the quality of our outcomes diminish.

Sensei's of the book: W. Edwards Deming

When something goes wrong we ask "what caused the problem", not "who".

Sensei's of the book: John Allspaw

Safety is a pre-condition of work.

Sensei's of the book: Paul O'Neill

Chapter 9

The last thing a QA person wants to hear from a developer they just met is their ideas on how to automate their job away.

Chapter 10

Code merges are never anyone's idea of a fun time.

We don't even need guards anymore. We love being prisoners so much, we just think the bars are there to keep us safe.

Instead of improving the processes we work within we blindly follow them.

Chapter 11

IT is the nerve center of the entire organization. [...] But for whatever reason, businesses have allowed their nervous systems to become degraded, like multiple sclerosis disrupting the flow of information within the brain and between the brain and the body.

Immutability is another concept from functional programming that is making the world a more predictable and safer place.

Chapter 12

Bash is the disease you die with, but not of. – Jeffrey Snover

Working with designers fascinates Maxine. Early in her career, the ratio of UX and designers to developers was 1:70. These days great teams doing consumer-oriented products have ratios of 1:6 because it's that important to create products that people love.

Chapter 13

Every time we have an outage, we'll be conducting a blameless post-mortem, like this one. 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.

How tenuous and fleeting the conditions that enable psychological safety can be. It depends on the behavior of leaders, one's peers, their moods, their sense of self-worth, wounds from their pasts... Given all this, it's amazing that psychological safety can be created at all.

In order to speak clearly, you need to be able to think clearly. And to think clearly, you usually need to be able to write it clearly.

Chapter 14

Tuckman phases of teams: form, storm, norm, perform

Whenever you have a team of people who are passionately committed to achieving a mission and who have the right skills and abilities, it's dangerous to bet against them, because they'll move heaven and earth to make it happen.

Data is the lifeblood of the company.

Chapter 15

When everyone knows what the goals are, teams will self-organize to best achieve those goals.

The future requires creating a dynamic, learning organization where experimentation and learning are a part of everyone's daily work.

Chapter 16

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.

For every winning idea, there are many losing ideas. [...] 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.

Sensei's in the book: Dr. Geoffrey Moore

Book Recommendation: Crossing the Chasm - Dr. Geoffrey Moore

Horizons 1, 2 and 3

Customer adoption is a Gaussian distribution curve, naming them the innovators, early adopters, early majority, late majority, and laggards.

Horizon 1 is the cash cow. But it attracts competitors.

Horizon 2 is about exploring adjacent markets, finding new customers, and different business models. As such it is not profitable but has higher growth. They turn into the next Horizon 1 cash cows after being developed for long enough.

Horizon 3 efforts are targeted at answering 3 key questions: market risk, technical risk, and business model risk.

Does the idea solve a real customer need? Is it technically feasible? And is there a financially feasible engine of growth? If the answer is no to any of them, it's time to pivot or kill the idea.

Horizon 3 successes turn into Horizon 2 business opportunities.

Horizon 1 thrives on process and consistency, on rules and compliance, and on bureaucracies, which create extraordinary resilience. These are the mechanisms that allow greatness to be consistently delivered over decades. In contrast, in Horizon 3, you must go fast, you must be constantly experimenting, and you must be allowed to break all the rules and processes governing Horizon 1.

Sensei's in the book: Dr. Steven Spear

Lead time from idea to market offering matters.

Manage to Value vs. Manage for Growth is about businesses focusing on Horizon 1 vs. Horizons 2 and 3.

Chapter 17

The Hoare principle:

There are two ways to write code: write code so simple there are obviously no bugs in it, or write code so complex that there are no obvious bugs in it.

Having the head of HR in a meeting is never a good thing.

As a company, we must show that we can create value in ways besides just cutting costs.

If you're not growing you're slowly dying.

Context vs. Core - what are the core competencies that a company needs to do themselves? Which things like payroll or email or HR can be outsourced or bought as a solution from somebody who is better at providing it, also at a cheaper cost? Where to spend money to do things in-house, and where not? Companies die when they spend too much on context and not enough on core.

Sensei's in the book: Clay Christiansen

Chapter 18

If there's anything I've learned managing salespeople, it's that you never want to bring opinions when you're playing a game that needs facts.

Chapter 19

Our future depends on innovation. That doesn't come from process. It comes from people.

The most valuable thing you can do is mentor or learn from your peers. [...] Learning is for everyone, and it is from there that we will create competitive advantage.

Leaders must model the behaviors they want.

Thing to look up: Wardley Maps

Epilogue

Small doesn't beat big. Instead fast beats slow. And fast and big will win almost every time.