Read a Book!

It's been a few years since I tried to pick up books to read, broadening perspective beyond that of daily work. With the shift to more cross team and company wide efforts the topics of engineering culture and leadership come to mind. Having jumped on the DevOps wagon in recent years I went for the following books:

Not only did these books outline timeless advice, they offer well put ways of performing trade-off analysis and swift decision making methods. Should you jump in and read these books you'll also notice that people make way too many assumtions which often cripple processes, let's dig in some more details on my learnings.

Faster vs. Safer

Working in our industry, you've likely encountered statements like "speed kills quality" quickly followed up by the logic of slowing down, enforce approval gates etc. It's this trap that the character of Bill Palmer fell into at the start of Phoenix Project. He's faced with a burning platform of outages, his instinct was to freeze changes. But as the story unfolds, and what the Accelerate book proves with hard data, that intuition is broken.

The Cultural Predictor

But what drives these metrics? Accelerate points to the Westrum Organizational Culture model as a top predictor of performance. It classifies organizations into three types:

• Pathological (Power-Oriented): Information is hidden, messengers are shot, and failure leads to scapegoating.
• Bureaucratic (Rule-Oriented): Information is ignored, and responsibilities are compartmentalized.
• Generative (Performance-Oriented): Information is shared, risks are shared, and failure leads to inquiry.

High performers are almost exclusively Generative. In your own org, ask yourself: When a deployment fails, do we ask "Who did it?" (Pathological) or "How did our system allow this?" (Generative)?

The Data: Speed Produces Stability

In Accelerate, having analyzed and categorized large amounts of data on performance in organizations, they found that high performers did not make a trade-off. They mastered both.

Utilizing the four key metrics from DORA to measure this:

• Speed: Lead Time for Changes & Deployment Frequency.
• Stability: Mean Time to Restore (MTTR) & Change Failure Rate.

Data outlined that high performers deploy on demand (multiple times a day) maintaining lowest change failure rates. This in contrast to low performers, deploying less frequent for the sake of safety, breaking things more often and taking much longer to fix them.

The Silent Killer: Unplanned Work

It still feels odd, doesn't it? How can slowing down backfire? The Phoenix Project illustrates this by categorizing work into four distinct types:

1. Business Projects: Direct value to the customer.
2. Internal IT Projects: Infrastructure and maintenance.
3. Changes: Updates and fixes.
4. Unplanned Work: Firefighting and emergency fixes.

The book argues that Unplanned Work is the most toxic because it steals capacity from the other three. When we delay releases and increase batch sizes, we end up with massive deployments. These are risky and inherently hard to debug. It's not if but when they break. When they do, the resulting tsunami of Unplanned Work displaces the roadmap, creating a death spiral where we never have time to fix the root causes.

The Architecture of Hope

With The Phoenix Project teaching us what disrupts flow, The Unicorn Project teaches us how to fix environments to enable flow.

The Ghost of 1975

The Mythical Man-Month offers timeless advice supported by sound logic. We're introduced early on to the fact that "adding manpower to a late software project makes it later." Adding people requires more communication, causing even more complexity, often feeling like an inescapable law of nature, much like gravity.

We attempted to solve this via "Waterfall" planning and tight coupling, the assumption being that if we just planned better, we could manage the complexity. Sadly, this assumption is wrong.

The Five Ideals

The Unicorn Project flips the script with "The Five Ideals," a set of principles to re-engineer the way we work. While all five are crucial—including Focus, Flow, and Joy and Psychological Safety—the first one is the structural key: Locality and Simplicity.

Our protagonist Maxine spends half the book fighting a monolithic architecture where changing one line of code requires coordination with five different teams. This is the modern manifestation of Brooks' Law.

The solution didn't lie in building up middle management to coordinate the teams; it was to decouple the architecture. Teams were set up to work independently—modifying, testing, and deploying without bureaucracy. Parts Unlimited broke the curse not by reducing people, but by reducing the necessity of communication between them.

The Human Operating System

We have the metrics (DORA) and the architecture (The Five Ideals), but there is one final piece of the puzzle: the people.

In a recent interview, Dr. Nicole Forsgren (author of Accelerate) introduced a concept that goes beyond just system performance: DevEx (Developer Experience). While DORA measures the system, we need a way to measure the human.

From DORA to SPACE

It's easy to fall into the trap of measuring "productivity" by lines of code or hours worked. But this is a vanity metric. To truly understand engineering health, we look to the SPACE Framework:

• Satisfaction
• Performance
• Activity
• Communication
• Efficiency & Flow

The AI Mirage

This focus on the human becomes even more critical in the age of AI. In a recent discussion on The Pragmatic Engineer, Laura Tacho (CTO at DX) warned against the new wave of vanity metrics: measuring AI success by "lines of code generated" or "acceptance rates."

If AI helps you generate 50% more code, but that code requires 200% more time to review and debug, you haven't gained speed—you've just created technical debt faster. Tacho points out a "Satisfaction Paradox": if AI automates the "fun" part (writing the initial logic) but leaves developers with the "toil" (fixing the subtle bugs the AI introduced), job satisfaction—and ultimately performance—will plummet.

We must apply the SPACE framework to AI, too. Don't just measure Activity (code generated); measure Efficiency (did the task actually get done faster?) and Satisfaction (did the developer enjoy the workflow more?).

The Feedback Loop of Joy

The core finding is simple but profound: Developer happiness is a leading indicator of software performance.

If a developer has to wait 20 minutes for a build to finish, they lose their "Flow State." Their satisfaction drops, their efficiency tanks, and eventually, the DORA metrics (like deployment frequency) suffer. By focusing on DevEx—reducing cognitive load, speeding up feedback loops, and removing friction—we don't just make developers happier. We make the business faster.

Conclusion: The Unified Theory

Looking back at these four books, a clear lineage emerges:

1. 1975: The Mythical Man-Month identified the cost of complexity.
2. 2013: The Phoenix Project showed us how to manage that complexity with culture.
3. 2018: Accelerate proved that speed and stability are correlated.
4. Today: The Unicorn Project and SPACE remind us that the heart of it all is the developer experience.

Whether you are battling the monoliths of 1975 or the AI mirages of 2025, the lesson remains the same: If you want to build a unicorn, don't just build a pipeline. Build an environment where developers can find their flow.