Background
I have been an avid reader since about 2016. A friend of mine at work introduced me into the world of non-fiction books. And I got hooked. Since then I have read more than a 100 books. I mean do have a life and a full time job, so I think it is pretty good that I manage to read at least 10 books a years, but 2018 was probably the year I read a lot more than the others.
Anyway, I thought there was value in summarising and giving my review of the books I read. Who knows, it might help someone make a decision to buy a book. And I’m surprised I hadn’t done this yet.
So expect more in 2023 and beyond.
This is a summary of The Unicorn Project by Gene Kim.
The Author - Gene Kim
If you have heard this name, then you certainly have seen some of his other books like:
- Accelerate
- The Phoenix Project
- The Devops Handbook and so on
Two of Gene’s books that I really enjoyed were the Phoenix Project and the Unicorn project.
They are written in the form of a novel that takes you through the journey of someone who works in the Information Technology department of a company that is not so great with tech and how they work bit by bit to move the organisation from viewing tech as only a department to using tech as the medium to push their boundaries.
Anyone who has been in a similar role, can relate to the challenges faced by the protagonists in the novels. Some parts of the book made me feel like someone came and worked with me. Trust me, there are characters in this novel that you’ll say “I know that one”. And that’s exactly why I enjoyed The Unicorn project so much. It was a fun and easy read. I might have finished it in less than a week, covering it during my commute and after dinner, before bed etc.
What is it about?
The Unicorn project follows the story of Maxine, a lead developer and architect who was moved from one project to the Phoenix Project as a punishment! The company had a payroll outage which was not her fault, but she ended up getting the punishment.
Since joining the Phoenix project, Maxine had to battle endless bureaucracy and unnecessary procedures and processes that prevented her from making any meaningful contributions for a very long time. Starting with setting up her workstation, getting the source code to compile, then to run, then debug, etc. She saw that she was not alone. This was happening all around her, contractors were also facing the same issue, unable to push their changes for weeks.
In her battle, she comes across a group of geeks, also engineers working for the same Parts Unlimited company who had an ambition. They wanted to change the bad practices and make the IT department a better place to work in every possible way. They called themselves The Rebellion. And the story goes on to show how building trust and breaking down barriers might take time but is totally worth the effort. It also demonstrates a lot of important things like
- In order to build trust in a low trust environment, you might have to go the extra mile, burn the midnight oil sometimes
- The wrong team topology can slow you down and ruin your software architecture - a bit of Conway’s Law here.
The author then presents his philosophy for building a great IT organisation as 5 ideals. This I believe, is the main takeaway from the book.
The five ideals
The First
Locality and simplicity
Design systems so that we have locality in the systems and organizations that build them. Create loosely coupled systems that do not unnecessarily interact with things outside it.
In other words, a team owns everything that they need to deliver their software, from design, to development to deployment and maintenance and operations. If the cognitive load gets too high, create another team. The importance of DevOps cannot be stressed here.
The Second
Focus, Flow and Joy
Make daily work enjoyable. Reduce waiting for others and boredom. If your team is going through tedious, time-consuming processes to get things done, then it is time to engineer those process into better ones, or eliminate them entirely. You hired bright engineers to solve business problems. So if you want to retain them, then you better make your work environment as less bureaucratic as possible.
You do not want your engineers spending their precious time on things that could have been standardized and done just once. Examples: tabs or spaces, curly braces in the beginning of the line, or end of line, how to write yaml or a makefile, etc. These are things that can be automated and must be at all costs.
Work on small batches of deliverables or features that allow the team to get continuous feedback. This enables fast learning, discovery and mastering the domain.
The Third
Improvement of daily work
Continuous focus on small tiny bits of improvement to the ways of working than just working on the daily work items. Embrace trunk based development like your life depends on it. Commit and merge non-breaking changes daily or even more frequently. Resist the urge of working on branches that live for weeks.
Learn, reflect and adapt at regular intervals to ensure you are able to improve the processes around.
Don’t just improve what you build. Improve how you build too.
The Fourth
Psychological safety
I cannot stress the importance of this ideal. Software development is creative work, more often than not trying things you had never done before. Mistakes are bound to happen. We must take steps to prevent disasters, but there will always be things that slip through. It is important to have a culture where team members feel safe admitting their mistakes and being upfront about what might not be the right thing to do.
This requires honesty and in turn requires absence of fear. Create an environment where blame is absent.
The fifth ideal
Customer focus
When creating or working on something, always question whether what you are doing matters to your customers. Ensuring if they are willing to pay for it or whether you are just creating value for your organisational silo. You were hired by your company to deliver their product in optimal time. Not for you to build something that you liked or wanted. So when implementing changes, think from your customers’ perspective - not just your employers’. You add value to your employer by creating products that their customers love using.
That’s all folks
I hope this summary gives you a little sneak peak into the book and makes you curious enough to go have a full read.
The links to the book on Amazon on this page help support my blog, so if you hadn’t bought the book already please use the affiliate links on this website to make your purchase.