“ A novel about developers, digital disruption, and thriving in the age of data ”

by Gene Kim

Book Cover

This is the follow-up to the Phoenix Project. The business-novel format is interesting in that it lets you reflect on the lessons rather than have them ready for consumption.

Lots of these notes are more related to things I thought of while reading rather than things I read in there.

Summary

Small doesn’t beat big. Fast beats slow.

~ Gene Kim, The Unicorn Project

Work needs to be enjoyable. Developers need to be close to their output. Things need to improve, and to do so you must not be afraid of failing. Get rid of what does not matter for the customer.

Reading notes

ideals

  1. Locality and simplicity
  2. Focus, Flow and joy
  3. Improvement of daily work
  4. Psychological safety
  5. Customer focus

locality

Development needs to be done locally (builds amd runs on machine)

Teams should be able to create value for customers in autonomy. That means initiating work, building it, testing and pushing to prod, and operating it.

Involving other teams to make changes should be the exception, not the rule.

The waiting place is a symptom of non-locality

focus flow and joy

Over-administration killed the joy

Challenge is a source of joy

improvement of daily work

Practice the andon cord- stop work, celebrate feedback

a bad system will beat a good person every time.

~ W. Edwards Deming

psychological safety

Slips easily, model, coach and reinforce every day

ask ‘what caused the problem,’ not ‘who.’

~ Gene Kim, The Unicorn Project

Blameless retros is a way of creating psychological safety. No hindsight

Assemble a timeline

customer focus

Consider as part of daily work if the customer would pay for it, and if it wouldn’t then maybe you shouldn’t do it.

Core and context. Core is what customers want to pay for, like manufacturing, or the service itself. Context is everything else, like infrastructure, supply, etc. Focus on core: what your customers want. Context needs to be driven down or commoditized - you don’t have any business driving core.

self organization

Networking matters - give more than you receive

Keep a work journal. Reflect on your days. Did you do anything useful? Drop things to investigate there.

During peacetime ceo and chairman are often the same. During wartime they are often different for accountability

Papers we love

Don’t go down the rabbit hole. Don’t go to the dreaded waiting place

The optimal number of changes to introduce at a time is 1

processes

Inhuman processes, like tickets, don’t foster friendship

Dont lose 1000 to spare 500

Agility is never free. Software has to be rewritten in a way that allows it, and refactored to allow change

Changing software should be easy

Once the why is accepted, strategy is mostly useful in tactical discussions (define how) for validation.

Components of a system should be understandable in isolation, else things are too entangled.

Best thing a manager can do for its team members is shield them from noise. Let the rest of the organization scream all they want, as long as the team can work, all is good. (#focus on my scope of action)

“Bill told me that he can’t fire the business unit executives or tell them what to do. He said that the only thing he can do is ensure that I’m not wasting time on those things. He said to tell anyone trying to reach me that I’ll be fired if I call them back.”

~ Gene Kim, The Unicorn project

Something painful sometimes needs to be done more often (reduce batch size or force automation) to get better

Processes with too much steps and dependencies are like tightly coupled systems.

Engineers should be writing code, not filling forms

Think about theory of constraints : what is the constraint preventing you from releasing faster?

Get rid of the clutter. Cycle time matters. Measure it, measure each steps, know what need improvement.

Don’t get stuck on the plan, do what matters for the business

Future proofing is as much the obvious dependencies as it is the small things im the critical path.

org

Throwing more people at the problem and distributing responsibility only adds to the complexity

People should be able to go on holidays without a pager

Setup mythology around teams. Tell stories. Place projects in a scheme of things. “the red shirts”, the rebellion, …

Master schedule and high project management/coordination cost is sign of high coupling

Complexity of making a simple change is a sign of too much coupling. Cross cutting concerns should be in a single place (make the change in one place by one team to make it everywhere)

Software is like a city, constantly undergoing change, needing renovations and repair.

~ Dan Kim – the unicorn project

Be a customer advocate, push for what is good for the customer

Collocation. Team of teams. Product managers seat with developers, not marketing managers.

Managers need to remove organizational barriers. Networking matters. Reciprocating favors as well.

Clear goals is what let teams self-organize

When everyone knows what the goals are, teams will self-organize to best achieve those goals.

~ Dan Kim – the unicorn project

Shadowing is an effective way of generating empathy

Bureaucracy brings resilience

Making devs more efficient everyday pays of in spades

Manage important internal systems like products, not projects

business

Horizon 1, 2, 3- 1 is current cash cow. 2 is future but existing. 3 is fast innovation and validation of market, tech and business model.

H1 and h3 are in conflict, H1 will cannibalize resources on the ground of profit but h3 is needed for growth


About Reading Notes

These are my takes on this book. See other reading notes. Most of the time I stop taking notes on books I don't enjoy, and these end up not being in the list. This is why average ratings tend to be high.