u/Upstairs-Stretch-662

At one of my clients we had a pilot team moving a lot faster than the rest of the org, and finance got pulled in because everyone was making claims about savings.

The first comparison was kind of ridiculous: around 10x more features a month from the pilot team versus the traditional teams. Cost per feature looked like roughly $40k versus $340k. I don't trust feature counts across different teams, but even after pushing on the assumptions the gap stayed big.

The more useful part was separating the costs. We counted time waiting for approvals, work delayed, rework caused by the delay, and the operational overhead around all of it. The annual estimate came out at more then $100m across all teams.

What changed was finance stopped asking only how much technology cost and started asking what customer value actually came out. Faster wasn't automatically better. A team had to show impact. But delay was no longer treated as free.

What metrics have you used that finance actually trusted without turning them into targets people gamed?

How do you count cost of delay and rework without inventing a giant attribution model?

Has outcome-based funding changed real decisions anywhere, or did it eventually turn back into annual budget allocation?

Picture this: A bank runs a transformation pilot. The skeptic on the team - the engineer who's survived every failed initiative, who complains about frameworks for a living - decides to prove the new model wrong using the company's own data.

He pulls up deployment stats, incident logs, approval chains, recovery times. He runs the numbers through an AI engine that doesn't know org charts or politics - it just sees patterns.

And the pattern it finds makes him angry.

Not code complexity. Not number of deployments. Not the age of the tech stack. The single strongest predictor of how bad an incident gets is decision latency - how long it takes someone with authority to say yes or no.

He digs deeper:

- Before the pilot, a payments incident took 43 hours from detection to authorized rollback. Six managers and three committees were in the path.

- After aligning around the new approach, a comparable incident was resolved in 18 minutes. The team handled it using pre-approved guardrails. No escalation chain.

He re-ran the correlation six times. The pattern held every time.

Then one governance committee caught his eye: it handled less than 5% of total changes but was responsible for 30% of all decision latency. Nobody had noticed because nobody had ever measured the cost of waiting.

What finally tipped leadership? Not the consultant's slides. The skeptic stood up in front of the executive team and said: "For fifteen years I've watched every transformation fail the same way. This is the first time I've seen the system react differently - and measurably."

The CFO's response: "If he's putting his name on it, I'll fund the next phase."

I've been thinking about this a lot:

1. Have you ever seen decision latency measured as an operational risk metric - not just "how long approvals take" but the actual correlation between slow decisions and incident impact?

2. When an organization has governance bottlenecks that touch a tiny fraction of work but create a massive fraction of delay, what's actually worked to fix them - without just removing controls entirely?

3. The skeptic was more convincing than the consultant precisely because he didn't want to believe it. When has a reluctant convert been more persuasive than an enthusiastic champion in your experience?

I've been thinking about what happens when change management processes meet a live outage — and how the rules designed to protect you become the thing that makes it worse.

Picture this: payments gateway is down at a bank. Customers are minutes from losing access to their money. The backup instance hasn't been properly tested in years. Fraud detection has fallen back to a rules engine from 2012.

And the emergency protocol says: wait for Change Advisory Board approval before anyone touches production.

The compliance guy — let's call him Dave — isn't wrong. He's watched audits destroy careers. He's seen what happens when you touch production without a paper trail in a regulated industry. His fear is earned.

But the system he's protecting is the same system that caused the outage. And every minute he blocks the fix, the blast radius grows.

Eventually someone senior enough makes the call: break the protocol. The system stabilizes. And then everyone in the room has to sit with the fact that they only survived by ignoring their own rules.

So what changes after that? Usually nothing. The postmortem blames the incident, not the process. The CAB adds another checkbox. And next time, Dave is even more afraid to let anyone touch production.

For anyone who's been in a regulated environment:

1. Has a crisis ever forced you to bypass your own change process? What happened after — did anything actually change, or did the process just get heavier?
2. Ever sat through a "blameless" postmortem that turned out to be anything but?
3. Has anyone actually built a change process that survives contact with a live incident without getting thrown out? What does it look like?

I’m publishing a business novel chapter by chapter. It’s called The Horizon Problem, and it explores why so many "agile" and "DevOps" transformations become theater instead of real change.

Here’s the opening scene from Chapter 1. I’d love honest reactions.

---

Alex Meyer stood at the back of the auditorium, watching Horizon Bank’s quarterly PI Planning session unfold like a Broadway musical with a predictable script.

This wasn’t agility. This was choreography.

Hundreds of people filled the room and overflowed into the hallway. Colored sticky notes, oversized printed dependencies, and giant SAFe boards decorated the walls. But despite all the "agile theater," the atmosphere felt stale. Heavy. As if the entire organization was collectively pretending.

On stage, a product manager nervously clicked through a deck titled:

"PI Objectives – Q3 Alignment Review."

Forty-eight slides. Zero working software.

Alex rubbed his temple. PI Planning… the most expensive three-month waterfall cycle ever invented.

A tiny notification flickered on his phone — Sofia’s anomaly trend summary:

• Deployment frequency: 4.2 times per quarter (goal: daily)
• Environment wait times: 31.4 days average (SLA: 3 days)
• Customer complaints: +23% vs. last quarter
• Competitor feature releases: 8x faster than Horizon

He stared at the numbers for a moment.

The Flow Layer was bleeding. Work wasn’t moving through the system — it was drowning in queues, approvals, and silence.

He dismissed the notification. He didn’t need it to know what today would show. The room itself was a diagnostic tool.

The product manager cleared his throat.

"For Feature 12 — which was committed last PI — we weren’t able to complete the dependencies with Platform DevOps. The environment request is still pending."

A VP immediately pounced.

"But we planned the dependency last quarter! Why isn’t it resolved?"

The PM swallowed hard.

"We submitted the environment request six weeks ago. It’s still in the DevOps queue."

A few executives chuckled — the resigned, hopeless laugh people make when something has been broken so long it becomes comedy.

Alex leaned closer. "DevOps queue?" he murmured.

Dave Ortega, the long-tenured Head of Delivery, overheard. "Yeah," he said proudly. "Our DevOps team manages deployments and environment provisioning."

Alex raised an eyebrow. "You mean your operations team."

Dave stiffened, shoulders rising defensively. "No. We rebranded. They’re DevOps now."

Alex turned back to the stage, biting back the instinct to comment.

Rebranding the team didn’t change the system. And the system was designed not to flow.

---

If this resonates (or if you disagree), I’d really value your perspective:

1. Where have you seen "agile cosplay"?
2. What’s your real environment wait time in your org?
3. Is your DevOps function actually DevOps, or "Ops with guilt"?

Full Chapter 1 on Substack