The Unicorn Project
“ A novel about developers, digital disruption, and thriving in the age of data ”
by Gene Kim
- Goodreads
- Rating: 4.5 / 5
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
- Locality and simplicity
- Focus, Flow and joy
- Improvement of daily work
- Psychological safety
- 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