Morning friend ☕️

Welcome to Episode 1 of Project Heisenberg.

Today we're looking at what a company is actually buying when it commits to a big project.

The project in this series is a platform migration. Yours might be a restructure, a new system, a move to a different building, or a hire you've been asked to justify. The question underneath is the same one, and it's harder to answer well than it looks: what does this buy us, and why now?

In the trailer, Richard Vale, the CIO, and Anand, the Head of Software Engineering, had a case for modernising the platform. These are characters from the fictional world of my Scary Management novel, alongside Thandi. This week, they need to explain the value of the change, and why it deserves attention now.

There's a lot to like about what they're proposing. But what would it actually change for the business?

How much of today's waiting would disappear? And what would we have to put on hold to make room for it?

Grab your coffee.

Let's chat!

Richard puts the existing delivery commitments beside the migration proposal.

"If we leave the platform alone, these teams stay on what we've already promised."

Anand turns the release plan towards him.

"This team's change is ready. It passed its own checks two weeks ago. It goes out with changes from three other teams, and one of them is still working through an issue."

"That sounds like one team having a bad month."

"It's the fourth time this quarter."

"Can we release it separately?"

"Not the way this part of the platform is put together. The combined release has to be ready."

Richard follows the line across the page. "So keeping them on product work doesn't mean that work reaches customers."

"Correct. They can start something else. This still waits."

"Explain what the migration changes."

"A product team could build, test and release changes in its own area without routinely waiting for unrelated teams to finish theirs."

"On its own timetable?"

"Within the shared standards. Quality, security, how the parts work together. Changes that depend on shared services would still need coordination."

Richard looks at the delivery list again.

"Then the product owner gets an improvement to customers when it's useful, without waiting for everyone else's launch."

"And when customers respond, the team makes the next change without joining the same queue."

"How much sooner does a change reach a customer?"

"I can't give you that number yet."

"You're asking me to fund it."

"I'm asking you to let me find out. What I have today is the waiting. I'd have to separate the time the work spends being done from the time it spends waiting to be released, then establish how much of that waiting this removes."

"How confident are you?"

Anand doesn't answer straight away.

"I'm confident the constraint is real. I've watched it for a year. The size of the gain I'd be guessing at, and you'd hold me to the guess."

"I'm held to it either way."

Richard lets that sit.

"And while we migrate?"

"The existing platform still needs support. Teams need time to move, learn the new way of releasing, and take responsibility for operating their part." Anand looks at the delivery list. "Some of them are on that page."

"Which promises can I still make?"

"Fewer than you made last quarter. I can't tell you which ones until I've been through it with the product owners."

Richard circles the ready change.

"Two weeks. Show me the waiting, what the new platform removes, and what the product owner does with the time. Then show me what we give up to get there."

Anand gathers the two plans together.

"And if the waiting turns out to be small?"

"Then you've saved me a migration."

In our earlier visit with Heisenberg, I wrote: “Standing still is the riskiest move of all.”

Too blunt for this decision. Sometimes waiting protects something you'd be sorry to lose, and starting has its own bill. This migration costs Anand people he has already promised to someone else.

The moment I keep going back to is Anand refusing to give the number. He has a real constraint and no measurement of it, and he knows a guess would follow him into every conversation after this one. Richard's answer (that he's held to it either way) is the part I'd have missed a few years ago.

There's an answer to "why now" in that scene, and it isn't urgency. Nothing is on fire. Anand has watched the same thing happen four times this quarter, which is long enough to stop calling it bad luck.

I'm working through this in my own role too, trying to support my Engineering Head more usefully. The question I keep coming back to is:

What does the person receiving my recommendation have to answer for after I leave the room?

The proposal is for a platform. What Richard is actually being asked to buy is the removal of something the company already pays for: a delay, a handover, a piece of rework, a conversation that has to happen four times before anything moves.

In Richard and Anand's case, what stops is one team waiting on another team's schedule. Stopping it is not mainly a technical job. It needs someone who owns the outcome, standards people actually work to, and a dependable way of checking that the separate pieces still hold together. DORA's research on independent teams reaches the same conclusion: the technology and the way the organisation is arranged have to change together. A restructure or a new approval process runs into the same wall.

This is why finishing the project would be an incomplete measure of success. Delivering the thing is not the same as collecting the benefit, and if you've been near a big project before, you've probably watched a company do the first and quietly skip the second.

How much that waiting is worth is not the same in every case. Some of it is an inconvenience. Some of it is the reason a customer went somewhere else. The people closest to the work usually know which is which.

But, they are not often asked before the business case is written.

You don't need a platform migration to use this. Any project you've been asked to support, justify or deliver will do.

Before your next update, try filling in these three lines:

The waiting I've actually seen is ___.

Removing it would let us ___ sooner.

Before I recommend it, I'd have to verify ___.

The waiting is something you have watched happen: finished work sitting behind somebody else's sign-off, an approval that takes a fortnight, a team that can't start until another one finishes. Keep it separate from the improvement you're hoping for.

And if the last line is the one you can't fill, say so. That's where Anand ended up, and he was right to stay there.

Then go back to the question above and fill the blanks for the person you're handing this to, not for yourself. They're the one who still has to answer for it next quarter.

A proposal names what gets built. The business case is a claim about what stops happening: the waiting, the handover, the queue that disappears. Until somebody measures that, nobody in the room knows what the company is being asked to pay for.

Richard still hasn't approved the migration. He's approved two weeks of finding out. That is his answer to why now: the waiting has happened often enough to be worth counting. Anand has to come back with something he can defend, which is a harder position than the one he walked in with.

I'd still say standing still is risky. I'd just be slower to say it with a delivery list sitting in front of me.

Until next time, friend!☕️

Vaugan