Picking your starting value stream
The first decision is which value stream to start with. That choice dictates difficulty, who is involved, and how visible early wins will be. Choose wrong and you exhaust political capital before producing a result anyone can point at.
"We must pick our transformation projects carefully — when we're in trouble, we don't get very many shots. Therefore, we must carefully pick and then protect those improvement projects that will most improve the state of our organization."
// Michael Rembetsy — Director of Operations, Etsy, who helped lead Etsy's DevOps transformation in 2009.
Geoffrey A. Moore described how new ideas spread across a population. Inside any organization, attitudes toward new ideas span the same curve — and the same chasm sits between the early adopters and everyone else. Most DevOps transformations die here. The playbook is to start where the chasm doesn't matter yet.
Try anything. Build with you.
Bet on the idea, want the edge.
Need social proof.
Join when it's normal.
Fight to the end.
Find innovators & early adopters
Build critical mass
Identify the holdouts
"Little fish learn to be big fish in little ponds."
// Peter Drucker
Translation: choose carefully where you start, so you experiment and learn without jeopardizing the rest of the organization. Win in a small pond. Then expand. The point is not the size of the early win — it's the credibility it earns you to keep going.
"Leading change requires courage, especially in corporate environments where people are scared and fight you. But if you start small, you really have nothing to fear. Any leader needs to be brave enough to allocate teams to do some calculated risk-taking."
// Ron van Kemenade — CIO, ING. Helped transform ING into one of the most admired technology orgs.
After early wins, AA had to scale DevOps across the whole business. They focused on three attributes to scale the culture, not just the tooling.
A new vocabulary, used by Dev and Ops alike, instead of tribal jargon that excluded the other side.
Tracking systems both teams could see — incidents, tickets, deploys — in the same place.
Concrete improvement goals on a short cycle, instead of an open-ended "modernization" effort.
// they also rewrote vocabulary: "project" → "product", "release" → "deploy". sounds cosmetic. it changes how people think.
A CIO wants to launch a DevOps transformation. They identify the three teams most opposed to change and assign the transformation to them first, reasoning that 'if we convince the hardest, the rest will follow.' What's wrong with this approach?
// pick one to verify
Why did American Airlines rewrite vocabulary words like 'project' → 'product' and 'release' → 'deploy'?
// pick one to verify