Recently, I finished reading The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data book.
Unlike my standard type of reviews (see my Technical and Non-Technical book reviews), where I list which chapters were most helpful, and provide my notes/highlights for each, this review will be nothing like that.
Previously, I’ve read The Phoenix Project and was excited to hear that this sequel was being released.
I would highly recommend everyone to read both The Phoenix Project and The Unicorn Project. As I read them, it made me want to do more DevOps-y things, like Infrastructure-as-Code (IaC), pipelines, builds, containers, APIs, and especially, collaborate and work together with everyone (to break down the silos).
Some of the best lines that I enjoyed in the book include:
- Punishing failure and “shooting the messenger” only cause people to hide their mistakes, and eventually, all desire to innovate is completely extinguished.
- I expect leaders to buffer their people from all the political and bureaucratic insanity, not throw them into it.
- Creating software should be a collaborative and conversational endeavor — individuals need to interact with each other to create new knowledge and value for the customer.
- Although long hours are sometimes glorified in popular culture, Maxine views them as a symptom of something going very wrong.
- She wonders what is happening: Too many promises to the market? Bad engineering leadership? Bad product leadership? Too much technical debt? Not enough focus on architectures and platforms that enable developers to be productive?
- When people can’t get their builds going consistently, disaster is usually right around the corner.
- Without constant feedback from a centralized build, integration, and test system, they really have no idea what will happen when all their work is merged with everyone else’s.
- 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.
- When engineers think of “the customer” in the abstract instead of as a real person, you rarely get the right outcomes.
- Everyone around here thinks features are important, because they can see them in their app, on the web page, or in the API. But no one seems to realize how important the build process is. Developers cannot be productive without a great build, integration, and test process.
- Developers need a system where they can get fast and continual feedback on the quality of their work. If you don’t find problems quickly, you end up finding them months later. By then, the problem is lost in all the other changes that every other developer made, so the link between cause and effect disappears without a trace. That’s no way to run any project.
- Maxine has seen how Dev and Ops interact around Phoenix. Instead of acting like an actual team, they act more like sovereign states on the brink of war, with diplomats trying to patch together an uneasy peace, complete with embassies, protocols, and official formalities. Even scheduling a meeting between these two groups requires a summit and lawyers present.
- Maxine isn’t usually a fan of rigid standardization, but she’s not a fan of everyone getting to choose whatever they fancy in the moment. Each decision is a commitment to support it for years or even decades — these are decisions that go far beyond just one team.
- Without automated testing, the more code we write, the more money it takes for us to test.
- Even though Maxine doesn’t believe in punishment or scapegoating, it’s doubly unfair that all the blame is being put on the technology organization, and no one from the business or product side is being held accountable.
- We’ve somehow created a system where hundreds of engineers are unable to get simple things done without an incredible amount of communication and coordination
- Watermelon projects? Green on the outside, but red on the inside?
- 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.
- Technical debt is what you feel the next time you want to make a change.
- Make it safe to talk about problems, because solving problems requires prevention, which requires honesty, and honesty requires the absence of fear.
- The 5 ideals:
- The First Ideal — Locality and Simplicity
- The Second Ideal — Focus, Flow, and Joy
- The Third Ideal — Improvement of Daily Work
- The Fourth Ideal — Psychological Safety
- The Fifth Ideal — Customer Focus
- The Fifth Ideal is Customer Focus, where we ruthlessly question whether something 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?
- It is ignorance that is the mother of all problems, and the only thing that can overcome it is learning.
- “You may have to change old rules that no longer apply, change how you organize your people and architect your systems,” he continues. “For the leader, it no longer means directing and controlling, but guiding, enabling, and removing obstacles.”
- No one will take risks, experiment, or innovate in a culture of fear, where people are afraid to tell the boss bad news
- When something goes wrong, we ask ‘what caused the problem,’ not ‘who.’ We commit to doing what it takes to make tomorrow better than today.
- Prevention requires honesty, and honesty requires the absence of fear.
- Maxine is excited that there is finally a career ladder for individual contributors and brilliant technologists without having to become managers.
- Who better to disrupt things for the benefit of customers than the organizations that already have a decades-long relationship with them?
Hopefully, these excerpts will inspire you to go read the book!