There is a point in most growing teams where the process that worked at ten people stops working at twenty-five. It is not a sudden break. It is a slow accumulation of workarounds, informal tools, and decisions that used to be obvious and now need to be explained. By the time it becomes a crisis, the team has usually been compensating for months.
How to tell if you need a redesign or a patch ¶
A patch is appropriate when one specific step is broken and the rest of the workflow is sound. A redesign is appropriate when the workarounds have become load-bearing: when removing them would break things, when new people cannot learn the process from the documentation because the documentation does not reflect reality, or when the same type of error keeps appearing in different parts of the workflow. If you are patching the same area for the third time, it is probably time to redesign.
Start with the handoffs, not the tasks ¶
Individual tasks are usually fine. The problems are almost always in the handoffs between tasks, between people, or between teams. In a workflow redesign, we spend the first workshop mapping every handoff: what triggers it, who owns it, what format the work arrives in, and what happens when it is late or incomplete. This map is usually more useful than any task-level analysis.
Involve the people who will live in the new workflow ¶
A workflow spec written without input from the people who will use it is a guess. It may be an educated guess, but it will have gaps that only become visible in practice. We run workshops with the people doing the work, not just the managers overseeing it. The goal is not consensus on every decision. It is making sure the people who know the edge cases have had a chance to describe them.
Write the spec for the person starting next month ¶
The test of a good workflow spec is whether someone joining the team next month could read it and understand what they are supposed to do, in what order, and what to do when something goes wrong. If the spec requires tribal knowledge to interpret, it will not survive the next round of turnover. Write it for the new person, not for the people who already know.
Plan for the transition, not just the destination ¶
The new workflow has to be adopted by a team that is currently running on the old one. The transition plan is as important as the spec. Who changes first? What happens to work that is mid-flight when the switch happens? What is the rollback plan if something breaks in week one? These questions are easier to answer before the transition than during it.
A workflow redesign is not a one-time fix. It is a new base to build from. Get the base level and the next round of growth will be easier to handle.