The bakery window

A reader asked me a question on When your team gets called a blocker that I've been thinking about ever since: did we track why work was waiting, or was the time it spent waiting enough?

The honest answer is that at first we didn't track it at all. And that was the problem.

Finished, but not done

Every team has some version of this. You finish your part, but the job isn't done until someone else does theirs.

My husband is a plumbing foreman, so here's his version. He works nights remodeling grocery stores that stay open all day: new bathrooms, new sinks, the plumbing for new fridges and freezers. His crew can run every pipe on schedule, and the job still isn't done. The parts have to arrive, and they have to be the right ones. Another crew has to put in the fridges. And nothing gets closed up until the inspector signs off. On his schedule, the plumbing is done. In the store, the new aisle still isn't open.

And every night the job waits on someone else, the store runs half-working. A bathroom stays roped off. A section stays taped off. Staff and shoppers work around it all day. The wait doesn't just cost the crew. It costs everyone living with the half-finished job.

My team builds and changes the business systems that sales and other teams run on. We plan our work in sprints, two-week blocks. A piece of work goes like this: it waits to get into a sprint, we build it, the people who asked for it test it (we call that step UAT, user acceptance testing), and then it goes live.

The building part was the part we were good at. The trouble started after.

Work would land in testing and sit. The person who asked for it was busy. Testing wasn't anyone's priority that week. So at the end of the sprint, the work wasn't done, and we'd push it into the next sprint and carry it along.

Do that for a few sprints and you end up with a sprint full of tiny leftover items. And when I looked closely, most of that sprint, I'd guess around 70%, was fluff: work that was built, checked by us, and simply waiting. Getting stale in the window.

The lie we told ourselves

So we did what a lot of teams do. We changed the rule. "Handed over for testing" now counted as done.

It helped morale, and I understand why. The team had built the thing. Carrying it sprint after sprint felt like being punished for someone else's delay.

But it was a lie we told ourselves.

The moment "handed over" counted as done, the stuck work disappeared. It wasn't on our plan anymore, so nobody saw it. It was still stuck. We just stopped looking.

And it wasn't free. The effort we planned for covered getting the work to testing. Everything after that, the approvals, the release, chasing down the person who asked for it, was hidden work nobody planned for. The longer something sat, the more that hidden work grew. Sometimes getting it the last step took as much effort as building it.

Think of those pipes again. The longer a job sits half-finished, the more goes wrong: other crews bump your lines, the plans change, and by the time the inspector shows up, you're redoing work you already finished.

Meanwhile, the numbers people saw looked fantastic. Look at everything this team finished! Look how much they can do!

The numbers said one thing. The reality said another. We were drowning in unfinished work, approvals and releases, and chasing people who, by then, didn't remember what they'd asked for. And the business was living in a half-working store: the fix they'd asked for existed, but they were still using the workaround.

We looked productive, but nothing moved.

The bakery window

The picture I kept coming back to was a bakery.

You bake the bread. It comes out perfect. You put it in the window. And it sits there. Day after day it gets harder, and by the time someone finally comes to pick it up, nobody wants it anymore.

That's what was happening to our work. We built it, it was good, and it sat in the window until it went stale. What people needed drifted. The person who fought for it moved on to something else. The system underneath it changed. What had been finished turned into a small project of its own just to get out the door.

Counting the bread you baked isn't the same as counting the bread you sold.

Why the bread sat there

It would be easy to blame the people who weren't testing. That's not what was going on.

Years earlier, a big change to the sales systems had landed badly. Really badly. The people who used those systems lived through it, and they built workarounds to survive it. Some of the patches from back then are still waiting to be fixed properly today.

Picture a homeowner who's had a leaky pipe for years. There's a bucket under it, and they know exactly when to empty it. Then a new plumber shows up wanting to cut into the wall. The bucket isn't great, but they trust the bucket. They know how it fails.

That was our business. When new work showed up for testing, they weren't just checking a feature. They were deciding whether to trust us again. The system they had was broken, but they knew how it was broken, and they had a workaround for every crack. The evil you know beats the one you don't. They had to feel good about a change before they'd let it near the thing they depended on.

It didn't help that, from their side, there wasn't much to feel good about. Requests were often a one-line title and not much else. Everything was urgent, so everything ran on heroics. Requests came in faster than anyone was willing to say no to them, and the people building were burning out.

And the business wasn't one voice. Several teams shared the same system, and they didn't agree on how it should work. One team wanted X. Another wanted Y. Neither knew the other had asked, and neither knew their change would mean more manual work for the other, or stop them cold. It's like one crew moving a drain without telling the crew putting in the fridges, and everyone finding out at 2 a.m. when nothing lines up. Nobody sat at the same table.

Then there was the calendar. This was sales work, and sales lives by month-end and quarter-end. In those weeks, the people who needed to test were heads-down closing deals, and rightly so. If our work was ready during that window, it waited another sprint, sometimes more. We were working on our clock. They were living on theirs. Nobody had lined the two up.

My husband's crews get this better than most. The store has to stay open for customers, so the work happens at night, when the store can spare the aisle. Nobody had planned our work around when the business could spare its people.

No wonder the bread sat in the window. Nobody was sure they wanted to eat it.

Making the window visible again

For a long time, I knew the window was full. I could feel it every sprint. But "I can feel it" isn't something you can take to a leadership meeting.

The first fix was simple: we made a separate board just for work that was built but not live. The stuck work was visible again, in one place, without cluttering the team's plan.

Then I wanted numbers. I had hunches about where things got stuck and what kind of work got stuck most often, but a hunch is easy to argue with. I wanted data that would either back up my theories or kill them, so we could fix the bottleneck instead of hiding it.

It took me until late 2024 to get them. Nothing we had tracked what I needed, so I started changing how we worked until the data existed, and built the automation to pull it out myself. I knew the story was there. I needed a way to tell it.

I looked at three clocks for each piece of work:

1. Waiting to start. How long from the ask until we started on it.
2. Building. How long it actually took to build. Not what we estimated, the real time.
3. Waiting to finish. How long from built to actually live.

It was fascinating. The building clock was the one we'd been watching all along, and it was the one that looked fine. The other two told the real story.

Across a full year of work, about 8 in 10 pieces of work were built and handed over within a single sprint. Building was never the problem. Finishing was: only about one in five went live within a week of being handed over, and a few sat waiting for more than a year.

My hunches about what got stuck held up, and then moved. At first it was always the sales systems, the work closest to that old launch. By the time I had a year of data, it was maintenance, the patch-and-repair work: about half of it sat waiting more than a month, compared with about a quarter of the big, exciting projects. Nobody fights to get maintenance work started, so nobody shows up to finish it either.

A new deal with the business

The numbers made a conversation possible that we'd needed for a long time.

Before, it was easy to look at everything the team finished and assume everything was flowing. With three clocks on the table, it was clear the bottleneck wasn't building. It was everything after.

So we changed the deal. When we started on someone's work, we told them, and we set the expectation up front: when this is ready, we'll need you to try it, quickly, so it can go live.

This was work they wanted. They had fought to get it started ahead of other work. If it was important enough to fight for at the start, it's important enough to help get out the door. It's booking the inspection when you start the job, not when you finish it.

Agreeing on what's important was only half of it. The business also had to agree to show up at the end.

The other half is the table. I still see it today: teams asking for changes to a shared system without knowing what it does to the team next to them. A change that saves one team ten minutes can cost another team an hour of manual work, or stop them cold. The numbers can show you where the work is stuck. Only getting those teams in the same conversation keeps it from getting stuck again.

The window isn't something you empty once. It's something you keep watching. I'm still at it. And honestly, I haven't had time to run the numbers yet this year, which is its own lesson: the work of seeing the work needs time set aside too.

Why we haven't moved done back

Part of why I wanted the numbers was to make a case to my own team: change our rule back, so work only counts as done when it's live.

The numbers said we could. We'd worked that way before, and it had worked fine.

The team still didn't want to. And I get it. They remember the pain: sprint after sprint of carried work, doing everything in our control and still missing the goal because of something that wasn't. Right now, on paper, they're winning. Every sprint closes clean.

But it's the same feeling as a doom scroll. You come away feeling like you did something. You took in a lot. You watched other people go places. You didn't actually go anywhere.

A clean sprint that hides stuck work is the quick win chosen over the long fix. It's skipping maintenance on the truck because nothing's broken yet. The brakes don't care how good the dashboard looks. Waiting almost never makes a problem smaller. It just makes us comfortable living with it.

Numbers can show a team it's ready. They can't make the fear go away. That part is trust too, and it's the work I'm still doing.

If your window is full

If your team finishes a lot of work but people keep asking where things are, you might have a bakery window too. Here's where I'd start, in any kind of shop:

• Don't call it done until it's in use. If you count "my part's finished" as done to keep spirits up, track what's still waiting somewhere everyone can see it.
• Give stuck work its own list. Visible, but not cluttering today's plan.
• Measure three clocks, not one. Waiting to start, doing the work, waiting to finish. The one you already watch is probably the one that looks fine.
• Test your hunches. Look at which kinds of work get stuck most. You might be right. You might be surprised.
• Ask for the finish line at the start. When the work begins, get the commitment from whoever has to sign off at the end.
• Plan around their calendar, not just yours. If the people you need disappear at certain times of the month or year, don't finish work then. Plan it to land before, or after.
• Look for the trust problem under the process problem. If people won't sign off, ask what happened the last time they did.
• Expect the fear. Data can prove a team is ready for a change. It doesn't make anyone feel safe making it. Give that part time.
• Put everyone who shares the system at one table. Every change should come with the question: who else does this touch?

The work you finish isn't the measure. The work that's in use, that someone's actually living with, is.