4 takeaways from The Unicorn Project

The Phoenix Project was probably the first IT-related book I read immediately after finishing my bachelor. Something about the way it was written in a novel-like style made it much quicker to read and much easier to retain the information, compared to traditional IT manuals. I've read many books over the years, but nothing caught my attention and interest quite like that book.

The years have passed and I've moved from an intern position to Head of R&D in an international company with a small, but very dedicated, team under my wing comprised of a few engineers, a QA, a data scientist and a designer.

So you can imagine my excitement when I heard that a new book was coming out, written in the same style but instead of being “A Novel About IT, DevOps, and Helping Your Business Win” it's specifically “A Novel about Developers, Digital Disruption, and Thriving in the Age of Data”. I bought it ASAP and started reading. The Unicorn Project became such an enticing book for me, the same way The Phoenix did before it, by being so realistic in the way it portrays issues.

It goes without saying that I definitely recommend you buying the book. Spoilers ahead.

The Ideals

1. The First Ideal - Locality and Simplicity
2. The Second Ideal - Focus, Flow, and Joy
3. The Third Ideal - Improvement of Daily Work
4. The Fourth Ideal - Psychological Safety
5. The Fifth Ideal - Customer Focus

1. Blocking factors and Organizational Issues

The first noteworthy point is the importance it gives to dev tools.

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.

This might seem obvious to you if you are a software engineer, but the more you climb the corporate ladder the easier it is to become distant from what provides value on a daily basis.

Developers cannot be productive without a great build, integration, and test process.

It is not a purposefully done mistake, but the balance between long and short term benefit sometimes becomes hard to execute. This is portrayed in the book by using Star Trek references such as “the bridge” and “the redshirts”, which I have to admit, never seeing Star Trek before, it worked the other way around, I now know what those mean because they were associated with Parts Unlimited employees (the fictional company in the book).

Being disconnected from daily work makes good managers very unhelpful and bad managers perceived as the enemy.

There is also another extremely realistic scenario pointed out, that I dare say occurs on a daily basis on any organization regardless of its size, which is the myth that engineers are psychics. Which is a skill we have yet to obtain.

(...) we don’t really know what the implications of shutting these systems down are and what it takes to transition. We need time to work with our teams to figure out what’s even possible and come up with a realistic timeline.

There are so many benefits of not using deadlines and yet it seems the world of Software Engineering still spins around the “guessing game” unnecessarily and without view of the consequences of doing so, completely ignoring: the stress produced, the quality of code diminished and the lower motivation that come from it.

It's very simple.

Trust > Control Spotify knows this since before 2014 (which was 6 years ago). Even Sun-tzu said something that can be interpreted as such 2500 years ago:

A ruler might bring misfortune upon an army (...) by attempting to govern an army in the same way as he administers a kingdom, being ignorant of the conditions which obtain in an army.

It really is as simple as that, you need to trust your team to succeed. Control is merely a DRM ready to be cracked by untrustworthy employees as soon as the conditions dictate (i.e. required WFH in a pandemic state).

2. Teamwork

Companies don't always feel like a team.

Why does the ticketing system here feel so awful? (...) Why does everything feel like I’m dealing with a government bureaucracy or an uncaring vendor? (...) Maybe it’s because when friends do favors for friends, we don’t require them to open a ticket first.

Processes in place are necessary for any up-and-coming organization, but don't underestimate the value of side-talks, favors and friends inside an organization. Those are the only things that sometimes makes clients want to stay, critical issues to be heard and fixed in under eight hours and teams to be happy.

Community > Structure

Again, Gene Kim, Sun-tzu and Spotify's engineers all say the same in a different way. But in short: community is more important than structure. And as Sun-tzu put it: “He will win whose army is animated by the same spirit throughout all its ranks.”

I believe this to be so important, that I was able to convene two ideals from it:

• The Second Ideal - Focus, Flow, and Joy
• The Fourth Ideal - Psychological Safety

3. Technical Debt

This is an extremely hard to summarize chapter with many, MANY great quotes from the book. Examples are given surrounding the many companies that had their downfall due to technical debt (such as Nokia) and others that did great investments as to not suffer the same fate (as Amazon and Microsoft).

There are two quotes though, that complement each other, and are on my top favorite from the book.

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, (...) hard-code something for a very specific case, knowing that it won’t work in the long-term.

But then comes the “pay-day”.

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.

4. Experimentation and Data

Experimentation and data are unquestionably the present and future of the industry. A mockup and a PoC don't take nearly as much time to build as they might have twenty or even ten years ago.

As it's said once again in The Unicorn Project: “If we can't experiment, we can't learn.”

There are two mindsets that have to be understood and implemented throughout the organization for this to work:

1. A fail-friendly environment (The Fourth Ideal - Psychological Safety)
2. Data is everything.

Postmortem - Throw out what’s bad, keep what’s good

As Sensei Clay Christiansen once stated, one keeps what is ‘not good enough’ and outsources what is ‘more than good enough’.

The Not Invented Here (NIH) stance only makes bad worse. There's no need to re-invent the wheel, and sometimes, an already existing working tool saves months or years of development and maintenance, even if it was NIH.

To have balance within an organization's innovation vs stability and predictability, Gene Kim reminds us of the Three Horizons, defined by Geoffrey Moore in his book “Crossing the Chasm”.

The three horizons

1. Successful cash cow business

The business where the customer, business and operational models are well-known and predictable. This is where corporate giants get stuck and a culture of bureaucratic stagnation is developed. Teams get so ingrained in their processes that they can’t seem to think outside the box, and when they do, the processes they are required to follow drags them down and prevents any risk taking.

2. New lines of business that represent the future of the company

New lines of business may introduce the company to new customers and new capabilities. They are still not well formed processes for efficiency and thus may not be profitable, but they show significant growth. They will transform into a Horizon 1 business as they mature and become profitable.

3. Velocity of learning and having a broad pool of ideas

This is where startups thrive. They prototype and validate ideas with the market quickly, change accordingly and move forward fast. The idea is to fail fast and adapt as quickly as possible. Teams must be light, nimble and empowered to take risks that may fail.

These three “horizons” also remind me of a talk from Jan Bosch on the conference: GOTO 2019 called Why Aren't You A Data-Driven AI Company Yet?.

Which also emphasizes that “Data is everything.”