A Week for a Five-Minute Change

A team can close a lot of tickets while making very little progress. Split the same change into more tickets, hold more planning sessions, and suddenly the board looks healthier. The person who needed the change may still be waiting for exactly the same thing.

I understand why activity is attractive to measure. It is visible, countable, and conveniently available from systems we already use. The trouble starts when the report becomes our definition of useful work.

Imagine a routine configuration change that needs contributions from three teams. The configuration edit itself might take five minutes. That does not mean testing, access checks and a safe rollout should take five minutes too. There is legitimate work around the edit.

But it is entirely possible to spend a week getting it done without spending most of that week doing any of that work.

The time between the tickets

In this hypothetical week, the application team opens the request on Monday. The platform team picks it up on Tuesday and discovers that the destination is missing. The answer arrives on Wednesday. Someone then needs to confirm the access requirement. By Friday, the change can finally be tested and applied.

Each team might have dealt with its own ticket promptly. Nobody has to be lazy, dishonest or bad at their job for this to happen. The request can move between reasonable people whose queues, responsibilities and working hours do not line up.

Now look at the weekly report. The application team completed a request. Platform completed a configuration task. Another team completed an access review. There may be a separate deployment ticket as well. We have several completed items, and each one has a sensible comment explaining what happened.

What the person waiting experienced was one change that took a week.

Closing the local task is a useful event. It does not tell us how long the whole request spent waiting between those events. If nobody follows the request across the handoffs, that part of the week can disappear from the conversation.

This is also why automating the workflow around an unclear decision can produce such a disappointing result. A webhook can move the ticket immediately. It cannot supply a destination nobody recorded or decide who has enough information to approve the access.

Choose where the clock starts

Before arguing about the number, I want to know what it includes.

A report might measure how long an assigned ticket stays open. Another might start when the first commit appears. Another might measure only the deployment. Those can all be useful measurements. They cover different parts of the work.

DORA defines change lead time from a change being committed to version control through its deployment in production. That gives us a way to examine the delivery path. A request that waits three days before anyone can write the change needs another view as well.

I would keep that distinction visible. When was the request understood well enough to act on? When did somebody begin the change? When could the person who requested it actually use the result? What was happening in the gaps?

That does not require tracking every minute of an engineer's day. Start with the transitions that help explain a real delay. Waiting for the required destination is different from actively testing the change, even if both currently appear as In Progress.

If we shorten the part we measure while the unmeasured queue gets longer, the report can improve without making anyone's experience better. We need to know enough about the boundary to notice that.

Read the numbers beside the work

A pull request count needs the same kind of context.

Ten small, well-scoped changes can be a good sign. So can taking the time to review a difficult migration properly. Comparing those situations through the count alone tells us very little about whether either team made a sensible decision.

The SPACE research on developer productivity makes the broader point that productivity cannot be captured by a single metric or dimension. Activity is one part of the picture. It needs to sit beside evidence about the result and the conditions in which people did the work.

For our configuration request, I would want the elapsed time, the missing information, the outcome of the change and whether anyone had to repair it afterward. I would also ask the people involved what kept interrupting them. A fast completion time becomes less impressive if it leaves another team with a broken service.

I would use that information to improve this delivery path over time. A ranking of unrelated teams would mostly start an argument about whose work was harder.

There is still a place for judgment. Someone needs to explain why a particular change mattered, what made it difficult and what became easier afterward. Having data available should make that discussion more precise. It should not make an explanation unnecessary.

Make the removed work visible

Some of the best operational work reduces the amount of activity there is to report.

Fix a recurring failure and the recovery tickets stop arriving. Retire an unnecessary service and there are fewer deployments, patches and access requests. Remove a duplicated check and somebody no longer has to produce evidence for it every week.

If recognition depends mostly on visible ticket throughput, the person removing that work has a problem. The recoveries used to generate a regular sequence of completed tasks. The durable fix may produce one task and then a quieter queue.

I want the report to show what changed. Which recurring intervention disappeared? Which service was retired, and what work went away with it? Has the improvement held up long enough to be useful?

That is particularly relevant when one team's feature delivery creates another team's operating workload. Looking only at the feature team's completed items leaves out part of the cost. Looking only at the responders' closed tickets can make permanent cleanup look like a productive operating model.

Be careful with estimates here. If someone says a fix will save ten hours a week, call it an estimate until there is evidence. Once the change is in place, check whether the interruptions actually fell. Do not make people inflate a savings calculation just to justify giving them time to fix a known problem.

And I would not turn deleted services or eliminated tickets into the next quota. Removing a control that protects something real can create more work than it saves. The question remains what improved and how we know.

Start with one request

I do not think the answer is another large measurement project before anyone is allowed to change the process.

Take one recently completed request. Follow it from the original need through the usable result, including the time before the first engineering task and the handoffs after the last one. Sit with the people who handled it and work out where the time went.

Some of that time will have been necessary. Testing may uncover a dependency. An access review may prevent a mistake. Keep those decisions visible too, so the next attempt to make the process faster does not remove the part that made it safe.

For the hypothetical configuration change, perhaps the useful improvement is a request template that asks for the destination up front, a named person who can decide the access requirement, or a tested change path that removes a repeated manual handoff. Pick the actual constraint and see whether the next comparable request gets through with less waiting and rework.

Then bring that result to the weekly review. Explain what changed, what still needs attention and what the numbers can reasonably tell us. A team should be able to remove unnecessary work and have that show up as progress, even when there are fewer completed tickets to put on the slide.