Morning friend ☕️

Welcome to Project Heisenberg, Episode 4 of 5. If you've joined me recently, I'm glad you're here. You can start with today's decision.

Richard Vale, the Chief Information Officer, and Anand, his Head of Software Engineering, belong to the fictional world of my Scary Management novel. Their project is already underway: help one software team release changes without waiting for three other teams. Richard has approved the work and given executives a date.

Now he wants to know whether AI can help them deliver sooner. It's a reasonable question.

In Episode 3, I admitted that I'd given or capitulated to estimated, even made-up dates that later became hard deadlines with executives. Richard now has to decide whether this experiment is worth changing the date he's already passed on.

Grab your coffee. Let's chat!

Richard opens the executive update. Anand's date was a forecast for one team's first release. Richard has put it beside Migration, making it look like a date for the whole project.

“Can AI bring the release forward?” Richard asks.

“We can test it. But that takes engineers away from the release work,” Anand says.

“I've already given them a date,” Richard says. “‘We're trying AI’ won't buy me more time.”

“How would you try it?” Richard asks.

“We can try it for drafting the tests we already need to check the system's behaviour,” Anand says. “The engineers would check them against the system, correct them and run them.”

“How much time could that save?”

“We don't know yet,” Anand says.

Richard turns the laptop towards him.

“Then find out. I need a better answer than the same date.”

Anand puts the first-team plan beside it. He points to the work needed before the release checks.

“Preparing the comparison and checking the result still take time. If we do it now, the first release moves.”

Richard looks down the plan.

“Self-service is already waiting.”

“Customers still need Support to handle those requests,” Anand says. “The product team's work to let customers do it themselves waits for our release.”

“What are my options?”

“Keep the release plan and evaluate afterwards. Or test now on one part of the work, and revise the forecast to make room. The release checks stay.”

“Your recommendation?”

“Test one part now,” Anand says. “We're preparing these tests anyway, so we can compare the effort on real work before deciding how to approach the work that follows.”

“Worth moving the release for?” Richard asks.

“I think so. Count the setup, review and correction. Stop if it takes more effort or we can't trust the coverage.”

“And if it helps?”

“Use it for that kind of work. Review again before widening it. It won't give us a new date for the whole migration.”

Richard looks again at the date beside Migration.

“Move the first-team forecast. Put the evaluation in the plan. Tell the product owner what changes before they plan around it.”

“They may want to keep the earlier release,” Anand says.

“Bring that back to me. Don't leave them to absorb it.”

Richard adds a line for First team's release — forecast to be revised. The wider Migration heading remains above it.

“No acceleration in this update,” Anand says.

Richard deletes the words AI saving from the benefits note.

“Bring me the result.”

When I wrote about the Crew in my own AI workshop, it was seven text files with different job descriptions, helping me work on the book. One looked after story, another continuity, another the reader experience. It sounded grander than it was.

I also wrote: “Sometimes seven roles produce seven longer versions of roughly the same answer.”

More output can leave you with more to read and the same decision to make. I still decide what belongs in the book. Anand needs evidence from his own work: how much effort does it take to get tests the engineers can accept, including setup, checking and correction?

NIST's AI Risk Management Framework connects risk measurement to the context of use and people with relevant expertise. Here, the engineers judge whether the tests are usable. The release checks and fallback route stay.

The trade-off question in Michael Porter's strategy work is useful here: what will they choose not to do? Richard is taking time from the release plan to find out whether AI helps. That time has to be available before any saving exists.

The result may justify using AI for the tested work, adapting the approach within an agreed allowance, or stopping. It still won't tell them whether the whole migration will finish sooner or customers will receive value earlier.

If a new priority is landing on your existing plan, start with the commitment it would change:

I recommend _____. To make room, _____ would need to move. That affects _____. Who needs to approve that trade-off?

You may not own the decision. This gives whoever does own it something concrete to weigh against the current plan.

A recommendation for a new priority needs to name the commitment it changes and the people who bear the consequence, so the decision owner can weigh it against keeping the current plan. Any AI saving remains a hypothesis until the relevant work has been evaluated.

What would have to wait in your plan, and who needs to hear that from you?

Until next time, friend ☕️

Vaugan