Productivity systems mistakes: six fixes that made teams slower, not faster

These are not failures of discipline. Each one below is a sensible improvement, correctly implemented, that made the operation worse, and in every case the mechanism is the same shape: something was made faster in one place and the effect landed somewhere else.

That shape is worth learning, because it is invisible from inside the step being improved. The step really did get faster. The measure really did move.

What to take away

One: the team got faster at the first step

What was done. Intake was streamlined. Requests that used to take a day to be logged and routed were being handled in an hour.

What happened. Total time from request to completion got longer. The queue in front of the second step doubled, and items now sat there instead of sitting in intake.

The mechanism. Intake was never the constraint. Making it faster changed where the work waited without changing when it finished. It also made things worse in a second way: the larger queue meant more time spent looking through the queue.

What would have worked. Find the step where work waits longest and improve that, or cap intake so the second step is not flooded. The general framing for this, the idea that a system's output is set by one place rather than by everywhere, is the theory of constraints.

Two: everybody was given more to work on

What was done. People reported waiting on others, so each person was given several items to work on in parallel so they would always have something to do.

What happened. Utilization rose to near full and everything took longer. Nothing was idle and nothing finished.

The mechanism. Time to finish an item rises with the number of items in progress, for a fixed completion rate. Adding parallel work spreads the same capacity over more things, so every one of them takes longer, and each switch between them costs setup time that nobody counts.

What would have worked. Fix the waiting rather than filling it. Idle time is a symptom of a dependency, and covering it with more parallel work hides the dependency permanently.

Three: the review step was removed to save time

What was done. A check before release was cut, on the reasonable grounds that it rarely found anything.

What happened. Nothing for eleven weeks. Then a run of problems that took much longer to fix than the check had ever taken to perform.

The mechanism. A check that rarely fires looks like waste, and the cost of removing it is delayed and lands elsewhere. Cost of correction rises the later a problem is found, so the arithmetic that made the check look expensive was measured entirely on the cheap side.

What would have worked. Measure what the check catches before removing it, and if it genuinely catches nothing, ask why. Often the answer is that the check has been changing behavior upstream, which stops the moment it goes.

Four: work was batched to reduce switching

What was done. Similar items were grouped and done together, weekly, to cut the cost of switching between types.

What happened. Average completion time rose by roughly half a week for everything, and urgent items now had to break the batch, which cost more switching than had been saved.

The mechanism. Batching trades waiting for efficiency. It is the right trade when setup costs are large and volume is low, and the wrong one when items arrive continuously and someone is waiting for each. The waiting is real time and it is paid by somebody outside the team, which is why it does not appear in the team's own measure.

What would have worked. Batch the setup, not the work. Or reduce the switching cost directly, which is usually possible and is where the real gain was.

Five: a dashboard was built so everyone could see the numbers

What was done. A live view of throughput per person, visible to the team.

What happened. Throughput rose and the work got smaller. People split items to close more of them, took the easy ones first, and stopped picking up anything ambiguous.

The mechanism. A measure that is visible and attached to individuals becomes a target, and behavior reorganizes around the target rather than the goal. The effect is reliable enough to be a rule of thumb rather than a risk, and it is the one named by Goodhart's law.

What would have worked. Show the team's queue and its aging rather than each person's count. Team-level and case-level views produce conversations about the work; per-person counts produce conversations about people, and the version of this argument that applies to individuals is in team management metrics.

Six: the meeting was made shorter

What was done. A weekly hour was cut to thirty minutes to give people back time.

What happened. Two new recurring meetings appeared within a month, and the decisions that used to be made in the hour started being made in messages over several days.

The mechanism. The meeting was doing work, not just consuming time. Cutting the container without removing the work relocates it somewhere less visible and usually less efficient.

What would have worked. Take items out of the meeting first and see what the hour is still needed for. Shortening a meeting is a decision about the agenda, and making it without touching the agenda is a decision about nothing.

The check that catches all six

Before making any improvement, answer two questions in writing.

Where does the work wait longest right now? If your change is not aimed there, it will move the waiting rather than remove it.

What will get worse, and where will that show up? Every one of the six above had a predictable cost that landed outside the measure being improved. Naming it in advance is not pessimism; it is the difference between a change and an experiment.

Neither question needs data you do not have. Both can be answered in an hour by counting what sits where; the method is in operating processes metrics.

For how personal and team systems interact, and why team throughput is not the sum of individual effort, see productivity systems. If a fix like these changes daily work, its sequencing belongs in change management.

Common questions

Is any of this an argument against improving things?

No. It is an argument for improving the right thing and for predicting the cost. Five of the six above would have been fine changes if made somewhere else in the system.

How do I find where work waits longest without a system?

Count what is sitting in front of each step, at the same time on the same day, for two weeks. The step with the pile is your answer, and the count takes minutes.

What if the constraint is a person rather than a step?

Same logic, different responses. Take work off them that does not need their judgment, change when they enter the process, and only then add capacity. Speed is not the lever, and asking for it is the one response that reliably makes things worse.

We already made one of these changes. Reverse it?

Not automatically. Find out where the cost landed first, since sometimes the trade was worth it and nobody had noticed either side of it. A reversal made as blindly as the original change is not an improvement.