The Phoenix Project was a novel on the DevOps transformation of an imaginary company from the perspective of the new VP of IT Operations. The The Unicorn Project is a novel about the same transformation from a developer perspective.
If you had a feeling while reading The Phoenix Project that Bill Palmer was kind of alone and he acted as a messiah, you'll understand from The Unicorn Project that it was hardly the case. Other people already got fed up both from dev, ops and QA. They didn't only complain, they had ideas and acted upon them.
But what got on their nerves?
Lack of environments, shaky or even impossible builds, always pushing for features while you can't even test anything locally and you have to wait weeks for having some test results from your QA department. Does that sound familiar to you?
The first half of the book is quite depressing as it hits some nerves. But this is not a Greek tragedy where everyone dies. There is a happy end to this story.
I won't go through the story, I don't want to completely spoil your read.
I want to share some aspects of the book and some concepts from it.
A culture of overtime
People, in general, can be extremely motivated to improve things around themselves. Anything. To me, this is one of the main messages of the book.
At the same time, it feels a bit too much what the book suggests.
People barely go home. They work long hours, then they go to the bar and drink. Though they come to work by their own cars, yet somehow they still manage to go home. I hope they don't drive drunk... They work on weekends, during vacations periods, etc.
Is that realistic?
Maybe it's because I spent most of my career in France and I have a life, I have goals outside the virtual walls of my office, but this part of the book is complete nonsense to me.
I would understand such an exaggeration from the author if he spoke up against this culture of overtime in the book.
But he rarely does. Yes, constant calls ruined the Brent family's vacation in Disneyland, but so what?
They still keep working for company goals and people barely consider changing for another job where they don't work long - most probably unpaid - hours of overtime.
As the author is a CIO and a founder himself, in my opinion, he has responsibilities in setting the right culture. Not to speak up and challenge such long days and weeks doesn't help to fulfil those responsibilities.
This is probably the only negative point, I have about the book. Now let's see some concepts that the mysterious barman and prospective board member - Erik - explained.
The five ideals
The below ideals are about making a productive workplace - not only for developers -, where work is not misery, where changes are easy to make, improvements are welcome and the centre of attention is the customer.
Let's have a look at them one by one.
As most of you visiting this page is in IT, let's stick with software development.
The First Ideal: Locality and Simplicity
We have to design software, processes, organizations in a way that we have locality. In other words, decisions are made close to the parts affected by people who are knowledgeable.
At the same time, both in software and processes we should strive for simplicity. There are only a few things we control and the code we write, the processes we create are definitely among those few. We cannot let the complexity of the outer world in them. Otherwise, it's really difficult to achieve the second ideal.
The second ideal: Focus, Flow and Joy
It's about our daily work.
Are we bored while you're waiting for others to get things done for us?
Do we understand how our work affects the whole system?
Do our working conditions let us focus and reach a flow state?
Do we get continuous and timely feedback on our work?
After all, do we enjoy our work?
The Third Ideal: Improvement of Daily Work
Think about Toyota who introduced continuous improvement, "kaizen", in their processes a long time ago.
We should explore on a day-to-day basis what can we do better in our jobs, what can we improve. What are the barriers slowing us down or even prevent us from reaching the ideal?
Of course, we won't always have the right answer, it will take a couple of iterations to get the right solution. This requires experimenting which requires the next ideal.
The Fourth Ideal: Psychological Safety
We can only experiment if we're not punished for failure. We can only improve if we can safely talk about problems if we can talk with full honesty. Honesty requires the absence of fear.
In our job, this psychological safety is probably even more important than physical safety - due to the nature of our work.
The Fifth Ideal: Customer Focus
Whatever we do, whatever we deliver we should ruthlessly question whether that 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?
I tend to ask that question for my refactorings too. Do I achieve refactor code that is being used? Do I refactor code that we revisit frequently and therefore I make it considerably cheaper to maintain or is it just l'art pour l'art?
Do we plan features that will solve real problems or are they only for chasing a Bonus Driven Development scheme?
The Three Horizons
The Three Horizons were introduced by Geoffrey Moore. Most companies don't only have one product or service, but a portfolio of them.
Depending on where the different businesses are in their lifecycle, they require different management.
Horizon 1 represents those offerings that are generating money right now. Their business and operational models are well-known and predictable.
No business is meant to last forever, therefore you have to keep thinking about the future.
The businesses of Horizon 2 are important because they represent the next generation of high-growth opportunities. They may bring in new customers, or they might enter some new adjacent markets and they potentially introduce new business models.
They might or might not be profitable but they are are definitely in high-growth areas. They are the "adolescents of the business world". They already show potential, but they need more maturing, they need more experience before they can live on their own and become the new cash-cows of the company.
Among the Horizon 3 projects, you'll find all the not-yet developed and fully experimented ideas. It should contain a broad pool of ideas to explore and with those projects, velocity is important. You must go fast, experiment continually and not be constrained by too many processes that are necessary for Horizon 1.
Most of the Horizon 3 projects will fail and that's fine. Many ideas have to be explored to find some that can be promoted to Horizon 2 and only very few will make it to Horizon 1.
By managing the different projects differently you give them the most chance to reach a profitable state and you let the non-viable ones die as soon as possible.
Conclusion
The Unicorn Project is another great book by Gene Kim. A book that once again shares significant knowledge about DevOps, about business management in an enjoyable form. He chose a novel as a platform with sometimes controversial people who you can root for or who you can dislike. Of course, this is not a crime story and if you already read The Phoenix Project, you won't be surprised by the outcome.
I think that at the end of the book the author didn't have enough time, space or will, I found it a bit too fast, but it doesn't devalue the whole.
If you like novels and you want to learn about how to organize better an IT organization, this book is a must-read.
Happy reading!
Connect deeper
If you liked this article, please
- hit on the like button,
- subscribe to my newsletter
- and let's connect on Twitter!
Top comments (0)