The Unicorn Project - Gene Kim
'Is this book about my ex-employer?'
This was my first thought while reading The Unicorn Project's plot. The Unicorn Project, a novel set within a large organization's IT department, strikes a common chord with everybody who has closely interacted with large IT departments. If you are a software developer, the book's plot also echoes the pain you have felt on the job.
At its heart, The Unicorn Project aims to unpack a paradox that is common in large IT orgs.
By its very nature, software development is a pursuit in creative problem solving. Every software
problem is a puzzle to be solved - one that can potentially fill a developer's workday with
focus, flow, and joy. This is what developers sign up for. Yet, when you visit the
IT department of a traditional business, you are directed to a sordid, windowless office space tucked away
in an old and seedy office building. You are greeted by sulking developers and stubborn system admins
who are constantly at each other's throats. You gingerly approach this bunch and ask them to automate
your business critical process. Without getting up from his desk, one of them hands you 25 forms and
asks you to come back next quarter. Oh, you want that process automated in 2 weeks? The developers and
sys-admins set aside their differences to laugh you out of the building.
How did we end up here?
Something there is that doesn't love efficient IT. And given how every business today is a software business, this evil force poses an existential risk to businesses everywhere. Most businesses struggle to keep pace with the rapid rate at which their IT landscape changes, which leaves them vulnerable to competition - a tech giant in most cases. The Unicorn Project delves into the heart of this problem in a manner that makes it just as relevant for managers as it is for its core audience - software developers.
The book itself is a novel about a brick-and-mortar organization that is unable to cope with e-commerce disruption, mainly due to its dysfunctional IT department. Through its storyline, the book gets at the heart of whatever renders an IT organization dysfunctional.
Is your IT org dysfunctional? That depends on how emphatically you answer the following questions with a 'yes':
- Does changing your IT systems involve long approval chains?
- Does building and deploying a feature involve a larger-than-2-pizza-team? (about 9 people)
- Does building and deploying a feature involve more than 1 team?
- Do executives wish to always be on top of bad news?
- Are fingers pointed and scapegoats made in case of failures?
The key to resolving dysfunction within IT orgs is DevOps - a cultural paradigm that is hard to define and is often misunderstood. The term 'DevOps' itself hints at reconciling the long-standing feud in IT orgs between the 'Dev' and the 'Ops' specialists. However, its principles, based on the Lean Manufacturing movement, have grown to attain a much larger scope that spans an entire organization - sales, marketing, HR, production and so on. Afterall, every company today is a software company, and everything is interconnected. The root cause of organizational dysfunction is a failure to recognize this interconnectedness.
The crowning glory of this novel is that its plot serves as great lubricant for the reader to get a 'feeling' for what DevOps is. Despite having a fast paced and interesting plot, it is interspersed with with drops of wisdom that cause you to put the book down and think. The books nuggets of corporate wisdom move seamlessly across various organizational levels. It starts with engineering wisdom...
‘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.
‘Without automated testing, the more code we write, the more money it takes for us to test.’
... moves onto organizational structure ...
You’d think we have thirty teams of ten people, with each team able to get things done independently. But at times, it’s like we have only one team of three hundred people … Or maybe three hundred teams of one. In either case, something is very wrong.
There must be two hundred people responsible for some portion of the release, but for most of them, it’s only about five minutes of work. So, they have to wait around for hours to perform their little part in this excruciatingly long, complex, and dangerous operation. The rest of their time is spent watching and … waiting.
... and finally melds into corporate strategy.
As Sensei Clay Christiansen once stated, one keeps what is ‘not good enough’ and outsources what is ‘more than good enough.
Innovation and learning occur at the edges, not the core.
The book doesn't offer readymade solutions - there are no silver bullets for the problems it outlines. Instead, it gives you a good basis to identify their symptoms, understand where they originate and treat the underlying disease that causes them.
What I also loved about the book's writing style was Gene Kim's masterful ability to weave some deep rooted programming concepts into the plot, all the while connecting them with the big picture to ensure that a non-technical reader does not get left behind.
Despite its several merits, one drawback worth pointing out is the book's length. The book mentions how an organization's strategy ought to focus on its core, ensuring that contextual functions don't distract from this focus. Ironically, the book disregards its own advice here - the core message of the book is delivered in about 35 pages, with its contextual plot occupying the remaining 320 pages. The book could have been half as long with a good-enough plot and fewer characters. After all, people don't read a book like The Unicorn Project for its plot.
Nevertheless, reading The Unicorn Project has given me a new pair of eyes for looking at how organizations create and ship software. If you, as a developer or a manager, have ever been frustrated with the 'ground realities' of how an IT business works, this book will help you understand the ways in which the underlying system is broken.
a bad system will beat a good person every time.