Morning friend ☕️

Someone asked me for a date. I didn't really have one. I had an estimate, a few assumptions, some confidence and some hope. But the meeting needed a date, so I gave them one.

A few conversations later, my estimate had become the delivery date. Then the committed delivery date. Then the date everyone was planning around. When it became obvious that we might miss it, I found myself wondering how everyone had turned my estimate into a commitment.

How indeed? A: I helped them.

Grab your coffee.
Let's chat!

Welcome back to Project Heisenberg, Episode 3 of 5. Richard Vale, the CIO, and Anand, Head of Engineering are characters in the fictional world of my Scary Management novel.

In Episode 2, before approving the overall platform migration, Richard asked Anand to conduct a short experiment to compare the costs, work through the approvals and get the product owner’s view.

Anand has brought those answers back. Richard now has to decide whether to proceed, and what he can tell executives the first release will prove.

“One team,” Richard says.

“One team, able to release its next product change without waiting for the other three.”

Richard looks through the proposal as Anand continued, “The product owner supports this team going first. Self-service work will wait, and Support will keep handling those requests while the team establishes the new route. The approval boundaries have been agreed. The existing release route remains available if the checks fail.”

Richard points to the date.

“Can I use this?”

“As an estimate for this team's first release, yes.”

Richard types it into the executive update beside Migration.

Anand watches the screen.

“They'll read that as the migration date.”

“I've already told them the migration will deliver less than I promised. Now I have to give them a date.”

“This is one team.”

Richard leaves his hands on the keyboard.

“What will I actually have on that date?”

“If the checks pass, a live change through this team's own release route. We'll be able to see what it does in production, check the customer feedback and support it.”

“If the checks don't pass?”

“We keep the existing route. We change the forecast.”

Richard scrolls back to the benefits section.

“Will we know how much faster the business can deliver? That is the whole point of the migration.”

“We'll know whether this team can release without the combined wait. We still need to see what the product owner can do with that. The other teams have different dependencies. There’s more discovery work before we can be clear on the whole migration”

“Approve the work for this team. Keep the checks in the plan. No second team until we've reviewed what happens with the first.”

Richard looks at the update again. Migration still sits beside the date.

“I said estimate for the first team,” Anand says.

“I heard you.”

Richard saves the update without changing the heading.

Anand gave Richard an estimate for one team. But his update makes it look like a date for the whole migration.

Richard needs to answer executives who want to know when the wider migration programme will deliver. He's already asked them to accept less than he originally proposed.

Anand needs the date to keep meaning one team's first release. Richard hears the warning and leaves the larger heading in place. His executive pressure is real; so is the expectation Anand may now have to answer for.

When this happened to me, my instinct was sometimes to complain: “That was never a commitment. I said it was an estimate.” Sometimes that was true. It wasn't the whole truth.

There were times when I knew someone wanted certainty and that the caveats would probably disappear once the date reached a slide, dashboard or executive update. I let it leave anyway. Sometimes I wanted to be helpful. Sometimes saying “I don't know yet” felt weak. Sometimes the person asking had to answer to someone more senior, and going back with a smaller answer felt politically harder than allowing a bigger interpretation to survive.

Once another team schedules its dependency or someone plans marketing around the number, correcting it can mean disrupting their work too. That's why I want to ask earlier what they think I've promised.

I've started finding it useful to be explicit about which kind of date I'm passing on:

These are the four labels I would use, rather than a guarantee that everyone uses them the same way. Calling something a deadline doesn't show that it is achievable.

For Anand, a successful first release would provide evidence that this team can operate safely through its own route and remove the combined-release wait. Whether that helps the product owner deliver value sooner still needs to be tested. The other teams' dependencies remain open. That is the scope Richard's heading leaves out.

Before passing a date on, name whether it is a target, forecast, commitment or external deadline. Attach the scope and what you expect to learn, so the next person can carry its meaning as well as its number.

Try it with one date you're putting into a slide, update or status report:

The date is a _____.

It covers _____. By then, we expect evidence of _____.

It still won't tell us _____. Our next decision will be _____.

The people relying on it are _____, and they understand it to mean _____.

If it's a commitment, that last line needs their agreement, not just your description.

I've been part of this before. I'm trying to get better at having that conversation before people build their plans around my number.

Richard has saved his update. When someone upstairs asks whether the migration is committed for that date, Anand's word “estimate” won't be beside it.

Until next time, friend ☕️

Vaugan