Somebody Is Paying for That Demo

An engineer once told me she'd lost trust in my judgment.

She was right, and it took me an embarrassingly long time to work out why.

I'd championed a rapid prototype. Built it fast, demoed it brilliantly, got the green light, and moved on to the next initiative with the satisfied feeling of a man who has just delivered something. She didn't move on. She spent the next six months maintaining a thing that was never designed to last that long, while her actual project work slid quietly behind, and her performance review at the end of that year didn't account for a single hour of it.

I had captured the upside. She was paying the mortgage. I hadn't even noticed there was one.

The cost doesn't disappear, it relocates

Here's the thing about the distance between a demo and a real product: it doesn't get absorbed by the organization in some diffuse, collective way. That's the comfortable fiction. It lands on a person.

Usually one person, and usually the most conscientious person available, because the work arrives without a ticket and only a certain kind of engineer picks up work that has no ticket. That's the cruel bit — the trait that makes someone absorb it is the same trait that made you want them on the team.

I call it the transfer. A decision made in one room produces an obligation in another, and because the two rooms have different attendees and different calendars, the cost is functionally invisible to everyone who authorized it. Nobody hid anything, and nobody had to.

And this is genuinely a clarity problem before it's a fairness problem. Your organization cannot make good portfolio decisions while a material cost of those decisions is unmeasured, unnamed, and sitting on somebody's evenings.

Costs you can't see don't stop existing. They just stop being yours.

Why your systems can't see it

Look at where work becomes visible in your company. Tickets, sprint boards, roadmaps, review cycles. Every one of them is designed to capture work that was planned, and the transfer is definitionally unplanned — that's what makes it a transfer rather than a project.

So it shows up in three places, none of which anybody reads as a cost signal.

It shows up as a person getting slower. Their throughput drops, they miss a deadline they'd have made a year ago, and the story the org tells itself is that they've plateaued.

It shows up as a project slipping for no discoverable reason. You go looking for the bottleneck and find nothing, because the bottleneck isn't in the project, it's in the person the project depends on.

And it shows up, eventually, in an exit interview.

Most leaders never get the conversation I got. The engineer doesn't tell you she's lost trust in your judgment, because that sentence is expensive to say and she has already run the arithmetic on whether saying it will change anything. She just leaves, and her departure gets logged against comp, or the market, or a competitor with a better remote policy.

Go and read your exit interviews

This is the diagnostic, and it costs you an hour.

Pull the last twelve months of exit interviews for your engineering and product functions. Read them for one phrase and its cousins: keeping the lights on. Also maintaining, supporting, nobody else knew how it worked, and the deceptively mild I wasn't working on what I was hired for.

Count them, because that count is the number of people who left over a transfer nobody priced, and I would be genuinely surprised if it came back zero.

Then do the second half, which is harder. For each one, find the initiative that created the obligation, and find the meeting where it got approved. Somebody in that meeting was delighted that day. That is not an accusation of anyone — it is the whole point. The delight and the resignation are separated by eighteen months and four floors, and nothing in your operating model connects them.

Marty Cagan writes about empowered teams as though empowerment were mostly about decision rights, and it largely is. But you cannot empower someone whose capacity you are quietly spending. Autonomy without protected capacity is just a nicer word for being on your own.

Name the carrier

The fix isn't a policy, and it certainly isn't a maintenance sprint.

Before an AI initiative gets its yes, name the carrier: the specific person who will hold this thing once the excitement is over. Say the name in the room. Then say the second part, which is the part that makes it real — what comes off that person's plate to make room.

If nothing comes off, you haven't named a carrier. You've named a victim and given them a title.

Three questions, asked in the room, before the yes:

Who carries this in six months? A name rather than a team, said out loud while everyone is still in the room.

What are they not doing instead? If the answer is "they'll fit it in," the transfer is happening and you've just watched it happen.

How would we know it's gone wrong? Not whether the product fails — whether the carrier is drowning. Their throughput on their other work is the signal, and it's already in your systems.

What to stop

Stop reading slowed-down people as a performance problem. Check what they're carrying before you check their goals.

Stop treating maintenance as an abstract category of work, when what it actually is is a specific person's week.

And stop assuming the silence means it's fine. The engineer who tells you is doing you an enormous favour, at real cost to herself. Most won't, and the ones who don't are already updating their CV while you're congratulating the team on shipping fast.

Do this before your next portfolio review

Read twelve months of exit interviews and count the phrase, which will take you about an hour and change what you think you know.

Then take one number into the review — not a complaint, not a plea for headcount, just the count and the phrase it came from. Say it once and let the room sit with it.

Whose name is on the thing you shipped fastest this year, and when did you last ask them how it's going?