BOTTOM LINE: Would you be surprised if your organization spent less than 20% of engineering capacity creating customer value? You’re stuck here because your org has so many handoffs it looks like an Olympic marathon relay. Value stream mapping reveals the same number told two ways: value density (aspirational metric that makes boards feel hopeful) or waste density (emotional metric that makes boards demand change). Same data. Different emotions. Choose based on whether you need inspiration or urgency. Implementation: 60 days.
THE RETRO
Stephen sits in the back of the Zoom call, camera off, watching the Sprint Retrospective. He’s the SVP of Engineering—he shouldn’t be here, but the SVP of Transformation (who has the CEO’s ear for reasons nobody understands) strongly suggested leadership “observe the team ceremonies to understand our transformation maturity.”
The Scrum Master—pleasant, earnest, and as far as Stephen can determine, has never written production code—asks: “What blockers are preventing us from achieving our sprint commitments?”
Silence.
“Let’s go around. Sarah, any blockers?”
“Waiting on Platform team to provision the database.”
“I’ll follow up with them. Marcus?”
“Security review is scheduled for next week, so we’re blocked.”
“I’ll escalate. Priya?”
“Blocked on API changes from the Services team.”
Stephen knows nobody takes these retros seriously. The real work happens in Slack DMs between engineers who’ve figured out how to route around the organizational chart. These ceremonies exist because the SVP of Transformation believes in them, and the SVP of Transformation has the CEO’s ear, so nobody challenges them.
But Stephen also knows his friend—the former CIO who hired him—was walked out ninety days ago for failing to answer one question: “What does a feature cost us to build?”
The new guard isn’t asking anything unreasonable. They’re asking what any functional organization should know. His friend was fired not because the question was wrong, but because this organization spent a decade building processes that make the answer unknowable—then systematically resisting change.
Stephen needs an answer. Fast.
THE PHONE CALL
Stephen calls Maria. She works with big tech companies—the ones that ship features in days and actually know what things cost.
“I need help,” Stephen says. “The new CEO wants to know what features cost. I’ve got nothing.”
“Good,” Maria says. “Walk me through your last feature.”
Stephen describes the checkout flow. Six months. Twelve teams. One hundred people touched it. The actual code changes took two weeks.
“Let me guess,” Maria says. “It looks like an Olympic marathon relay. The work passes from Product to Architecture to Platform to Services to Frontend to Security to Operations, and at each handoff, someone waits while someone else finishes their leg of the race?”
Stephen goes silent. That’s exactly what it looks like.
“You’ve got the relay problem,” Maria continues. “And you can’t measure what features cost because no single runner owns the full race. Everyone just knows their leg. Value stream map it—every step from ‘we should build this’ to ‘it’s in production.’ Every handoff. Every wait state. Every approval. Then categorize: Does this create customer value, or does this manage organizational complexity?”
THE VALUE STREAM MAP
They spend three days mapping the checkout feature. The relay becomes visible:
Leg 1 – Product (3 weeks): Requirements documentation, stakeholder alignment
Handoff, wait 1 week
Leg 2 – Architecture (2 weeks): Design reviews, approval boards
Handoff, wait 2 weeks
Leg 3 – Platform (3 weeks): Database provisioning, infrastructure setup
Handoff, wait 1 week
Leg 4 – Services (2 weeks): API development
Handoff, wait 1 week
Leg 5 – Frontend (2 weeks): UI implementation
Handoff, wait 1 week
Leg 6 – Security (2 weeks): Reviews, remediation
Handoff, wait 1 week
Leg 7 – Operations (1 week): Deployment, monitoring setup
Twenty-four weeks. Fifteen weeks of actual work spread across seven teams. Nine weeks of waiting for handoffs.
Then they categorize the work:
Customer value creation: 14% (code that differentiates the product, design that improves experience)
Organizational overhead: 38% (ceremonies, coordination, waiting for other teams, approvals)
Rework: 22% (contradictory feedback, requirement changes, incident fixes)
Compliance theater: 16% (documentation nobody reads, post-hoc reviews, checkbox exercises)
Waste in queue: 10% (work sitting “ready” while teams work other priorities)
“Fourteen percent value density,” Maria says. “Or if you prefer, eighty-six percent waste density. Same number. Different emotional impact.”
Stephen stares at the spreadsheet. $1.1 million total cost. $154,000 created customer value. $946,000 was organizational friction.
“Which metric do I show the board?” Stephen asks.
“Depends on the emotion you need,” Maria says. “Value density is aspirational—it makes boards feel hopeful about improvement. Waste density is visceral—it makes boards demand immediate change. You’re at 14% value density or 86% waste density. Same truth. Different reaction.”
THE EMOTIONAL CHOICE
Maria explains the psychology:
Tell them “14% value density” and they hear: “We’re creating some value, we could create more.” It feels like an opportunity. Room for improvement. Let’s optimize what we have.
Tell them “86% waste density” and they hear: “We’re burning $45 million annually on organizational dysfunction.” It feels like a crisis. Unacceptable. Burn it down and rebuild.
“The companies I work with usually start with waste density,” Maria says. “You need the board emotionally activated to support radical change. Once they’re activated, you switch to value density to show progress. You go from ‘86% waste’ at the start to ‘60% value creation’ six months later. Same improvement, but the framing controls the narrative.”
Stephen sees it. His friend, the old CIO, tried to explain why features took six months using technical complexity arguments. The board heard excuses. If he’d shown them “86% waste density,” the board would’ve heard a burning platform.
“So I’m leading with waste density,” Stephen says.
“Unless your board responds better to optimism than urgency,” Maria replies. “You know them. I don’t. But in my experience, when someone gets fired for not knowing what things cost, the board wants urgency, not aspiration.”
THE RELAY PROBLEM
“Here’s why you’re stuck,” Maria continues. “You’ve architected your organization like an Olympic marathon relay race. Seven specialized teams, each optimized for their leg. Platform runs the platform leg perfectly. Services runs the services leg perfectly. But nobody owns the full race.”
She explains the relay problem:
In an Olympic relay: Four runners. Clear handoffs. Everyone watching. Total race time matters more than individual leg times. You optimize the system. Runners run one race at a time.
In your organization: Seven teams. Unclear handoffs. Nobody watching end-to-end. Each team optimizes their leg time while ignoring total race time. You’ve sub-optimized the parts while destroying the whole. Runners are not only running this race, but another race, doing the pole vault, and on a good day ice dancing training which is a winter Olympic’s sport.
“The checkout feature took twenty-four weeks because it crossed seven organizational boundaries,” Maria says. “Each boundary adds coordination overhead, wait time, and rework risk. You’ve got world-class sprinters running a marathon relay, and you’re wondering why it takes six months.”
“What do the companies who’ve solved this do?” Stephen asks.
“They stop running relays,” Maria says. “They give one team the entire race.”
THE SOLUTION: SELF-CONTAINED FEATURES
“Self-contained features means one team owns end-to-end,” Maria explains. “No relay. No handoffs. No waiting for Platform to provision infrastructure or Services to update APIs. The team that conceives the feature builds it, deploys it, operates it, measures it.”
Marie continued
“This is also a major organizational change, which leaves some current leaders on the outside looking in – you need to think about this approach, carefully. It’s the way a startup would operate, but can you survive this change?”
This eliminates the relay: No handoffs between teams (38% of waste). No waiting in queue (10% of waste). No rework from misaligned handoffs (most of the 22%). No post-hoc compliance reviews (most of the 16%).
“But how do you actually measure costs?” Stephen asks.
“Two patterns. Pattern A: Sequential features. Teams work on one feature at a time, beginning to end. When it ships, you know what it cost—that team did nothing else. Pattern B: Billing hours against features. Engineers allocate their time to specific features. They’ll hate timesheets. They’ll complain. They won’t quit—not in this market. Within six weeks, you’ll know what every feature costs.”
Stephen sees it. “Pattern A maximizes value density. Pattern B maximizes visibility.”
“Start with Pattern B to build your measurement baseline,” Maria says. “Then shift to Pattern A once leadership believes the data.”
THE BOARD PRESENTATION
Stephen presents to the board. He leads with waste density—the emotional metric:
“Eighty-six percent waste density. We spent $52 million on engineering last year. Eighty-six percent was organizational overhead, rework, and compliance theater. That’s $44.7 million in waste.”
The CFO’s face changes. “Forty-four million dollars?”
“Yes,” Stephen says. “And this is why we couldn’t calculate AI ROI. We deployed AI agents ninety days ago to accelerate development. They probably improve coding speed by 30%. But coding is 14% of what engineers do. We optimized 14% of our operation by 30%. That’s a 4.2% total system improvement.”
He clicks to the next slide: the relay diagram. Seven teams. Seven legs. Nine weeks of handoff waiting.
“Our organization looks like an Olympic marathon relay,” Stephen says. “Each team runs their leg perfectly, but the total race takes twenty-four weeks. Each runner is running this race and others, and in fact some are training for the winter Olympics while running their leg. The checkout feature touched seven teams. One hundred people involved. The actual value-creating work? Two weeks. The other twenty-two weeks? Organizational handoffs.”
The CEO leans forward: “Show me how to fix it.”
Week 1-2: Value stream map five recent features. Calculate waste density for each. Show the relay diagram—how many handoffs, how much wait time. Present to executive leadership.
Week 3-4: Reorganize around self-contained features. No more relay races. Features are self-contained: one team owns it end-to-end. If you can’t make it self-contained, don’t build it—the handoff cost destroys ROI.
Week 5-6: Implement billing hours against features. Engineers will hate it. They won’t leave. Within six weeks, you’ll have cost data for every feature. Kill the bottom 40% of your roadmap with negative ROI.
Week 7-8: Kill the ceremonies consuming 38% of capacity. No sprint retros with Scrum Masters who’ve never shipped code. No dependency syncs across seven teams. No three-meeting architecture approvals. Keep three things: daily standups (blockers only), weekly demos (working software only), monthly architecture reviews (technical decisions only).
Week 9: The Next Board Meeting. We’ll use the data to design the new org, if this works.
“Once we go from 86% waste density to 40% waste density—or to frame it positively, from 14% value density to 60% value density—AI agents don’t optimize productivity,” Stephen says. “They multiply value. That’s your 10x.”
The CEO looks at the SVP of Transformation.
“Your reaction?”
Long pause.
“The value stream map is clear. If we’re spending $45 million on coordination overhead, we need change. But you’re proposing we eliminate guardrails that prevent disasters.”
“We automate the guardrails,” Stephen says. “The ceremonies exist because we don’t trust our deployment process. Fix the deployment process. Automated testing. Observability. Feature flags. Progressive rollouts. Technical risk has dropped 90% in a decade. We’re using 2015 governance for 2025 reality.”
THE DECISION
The CEO decides: “Sixty days. Value stream map five features. Reorganize around self-contained features. Implement billing hours. Show me improvement from 86% waste density to 50% waste density. If it works, we scale it.”
Stephen knows it will work. The new guard isn’t asking anything unreasonable. They’re asking: Can you measure what creates value and eliminate what doesn’t?
His friend couldn’t answer because the organization was designed to make it unanswerable. Seven kingdoms—each optimizing locally, each destroying enterprise value at the boundaries. Every feature a relay race. Every handoff a waste multiplier.
The solution isn’t better relay runners. It’s eliminating the relay entirely.
Self-contained features. End-to-end ownership. Measure the costs. Kill the handoffs.
Then deploy AI agents to multiply what’s left.
EPILOGUE: 90 DAYS LATER
The numbers: 57% value density. Or to use the emotional framing: 43% waste density.
The relay is gone. Teams own complete features. The checkout feature that took twenty-four weeks? A self-contained team rebuilt it in eleven days.
Stephen presents the results to the board using value density this time—the aspirational metric: “We’ve gone from 14% value density to 57% value density. We’re spending 57 cents of every engineering dollar creating customer value instead of 14 cents.”
The CFO smiles. Same improvement as “86% to 43% waste density,” but it feels like winning instead of fixing.
The billing hours data revealed uncomfortable truths: 35% of the roadmap had negative ROI even at zero implementation cost. The opportunity cost made them value-destructive. They were killed.
Engineering didn’t quit over timesheets. When you show people that 86% of their time was organizational friction, they want visibility.
The SVP of Transformation left the company. Nobody knows why. The CEO never explained.
Stephen occasionally observes retrospectives now. When the Scrum Master asks for blockers: “None. We own the whole feature. If something blocks us, we fix it.”
The work happens in self-contained teams shipping self-contained features, measured by value stream maps, framed as either waste density or value density depending on the emotion required.
That’s how you know what a feature costs.
That’s how you manage your board’s emotions.
That’s how you win.
FRAMEWORK FOR YOUR ORGANIZATION
Your organization probably looks like an Olympic marathon relay: specialized teams, multiple handoffs, nobody owning the full race. The result? Less than 20% value density.
Run the value stream map. Count the handoffs.
Then choose your metric based on the emotion you need:
Waste density (86% waste) = visceral urgency, demands immediate change
Value density (14% value) = aspirational opportunity, suggests optimization
Same number. Different emotion. Both true.
Then ask: What would it take to eliminate the relay and let one team own the entire race?
That’s not an AI question. That’s an organizational design question.
Stop running relay races. Then AI agents multiply what’s left.
Engineering leader who still writes code every day. I work with executives across healthcare, finance, retail, and tech to navigate the shift to AI-native software development. After two decades building and leading engineering teams, I focus on the human side of AI transformation: how leaders adapt, how teams evolve, and how companies avoid the common pitfalls of AI adoption. All opinions expressed here are my own.