Morning friend ☕️

Welcome back to Project Heisenberg, Episode 2 of 5.

In Episode 1, Richard gave Anand two weeks to investigate a finished product change that was still waiting to reach customers. Richard had been making the case for a platform migration to exco. He wanted to know what delivery delays it would remove, what the product owner could do with the time, and what the company would give up to get there.

Two weeks have now passed in their story. Anand is back with feedback.

What are the answers to Richard’s questions?

Grab your coffee.

Let's chat!

Richard Vale is the CIO and Anand is the Head of Software Engineering in the fictional world of my Scary Management novel. Their project is a platform migration.

Yours might be a new system, a restructure or a change to an approval process. The hard part comes when you've already told people what the project will achieve, then find it will fix only part of the problem.

Anand spreads four sheets across Richard's table. The change Richard circled in Episode 1 is on top.

"Start with this one," Richard says.

"It passed its checks. But it had to go out with three other teams. One had a problem, so this team waited too."

Anand points to a date further down the sheet. The product owner's planning meeting, a week before the release.

"At that meeting she had to decide what the team would build next. She wanted to see how customers used this change first. It hadn't reached them."

"Would she have chosen differently?"

"I don't know."

Richard pulls the other sheets closer. "Same problem?"

"All four waited for a combined release. The second also waited for the weekly approval meeting, even though the checks were done. The third needed work from another team on a shared system."

"And the fourth?"

"It waited. I can't show that getting it out sooner would have changed anything."

"Leave it in."

Richard taps the proposal. "I've already called this a migration upstairs."

"Then we should be clear about what it buys. Letting one team release on its own might help the first change. Moving the meeting wouldn't."

"We can't just drop approval."

"I don't want to. The people responsible for customer safety, security and accurate records need to tell us which changes still need that meeting."

Richard looks at the delivery list. "What waits while we work on this?"

"Customer self-service might slip into next quarter. Support would keep taking those requests. The product owner hasn't agreed to that."

Richard closes the proposal and writes the name of one team on the cover.

"Bring me the cost of that team's work in the current system and through the migration. Work out the approval route with the people who own those checks. Bring her view too."

"And upstairs?"

"I'm going to tell them I asked for the wrong thing."

Anand starts gathering the sheets.

"Leave the fourth one out where I can see it."

In Episode 1, I wrote: "Stopping it is not mainly a technical job."

That sentence sounded balanced, which is probably why I let it through. Anand cannot untangle a combined release by improving a meeting. There is engineering work here, and it could be difficult. There are also decisions that a new platform will leave exactly where they are.

What I actually need, before I put a recommendation in front of my Engineering Head, is the specific wait the change would remove. "Technical" and "organisational" are the labels I reach for when I haven't done that work yet.

The hard part comes when you have already told people what a project will achieve, and then find it will fix only part of the problem. Richard is in that position, and he put himself there. It would be easier to keep the heading and let the investigation look like supporting evidence.

Anand gives him something more useful: a reason to change the scope, a constraint worth addressing, and a customer trade-off they have not settled. The fourth sheet stays on the table even though it doesn't help sell the benefit.

The question from last time still matters: what does the person receiving my recommendation have to answer for after I leave the room?

This time, Richard has to answer for which part of the problem the company is actually choosing to tackle.

Anand's four sheets are a crude version of something called a value-stream map: you follow one piece of work and write down every place it stopped. You don't need the formal version. Four sheets and a pen were enough here to change what Richard asks for.

What they showed is that the four waits were not the same kind of thing, and only one is the kind a new platform removes. The second change waited for a weekly approval meeting. That meeting exists because somebody decided that changes of a certain kind should be seen by the people accountable for customer safety, security and accurate records. A new platform does not change that decision. It moves it.

This is the part I find hardest to hold onto. Some waits are somebody's answer to a question that was asked once and never revisited. Removing one without finding out which question it answered is how a project creates the problem it gets blamed for later.

The question worth asking is what the step protects, and who decided it should. Those are two different people often enough to be worth checking.

Pick one thing that was called ready but hadn't reached the person waiting for it. Write down every place it stopped, and next to each one, what that stop is protecting.

If nobody can explain what a step protects, take that question to its owner before proposing to remove it.

Try finishing your recommendation like this:

This project would remove ___.

It would leave ___ exactly where it is.

Before we commit further, I need to hear from ___.

If nobody can explain what a step protects, take that question to its owner before proposing to remove it.

Every wait in a process is protecting something, or it used to be. Find out what, and who decided it, before you offer to remove it.

You can bring that much to a recommendation without having the authority to approve the project.

Until next time, friend!☕️

Vaugan