Fix the Process First Is a Decision, Not a Deferral

The hiring request reaches the budget review with its evidence attached. The backlog has grown for three months, the team is working evenings, and the manager has costed one more person. Someone in the room, often the COO or the finance lead, has looked at the queue and seen rework rather than volume. The question gets asked in the form it is usually typed later into a search bar: should we hire or fix the process first. The answer is fix the process first. It sounds disciplined, the request is declined, and the meeting moves on.

A sound answer with no terms

On substance the answer is often right. The case for it is made in add headcount for volume, fix the process for rework: a hire adds capacity to a loop without changing what the loop does. What the room rarely does is turn the answer into a decision, with someone who owns the fix, a date it is due, and a consequence if it slips. Without those terms, fix the process first is a hiring freeze with better manners.

What follows is the case pattern as we have seen it recur in operations and commercial teams across digital banking and payments, composited and stripped of anything identifying, and then the terms that keep the answer honest.

The sequence is consistent enough to describe in order:

• the hiring request is declined in favour of a process fix, and the fix is assigned to no one in particular
• the fix lands in the backlog of a team that does not feel the strain, and waits behind that team's own priorities
• the strained team absorbs the gap with overtime and workarounds until someone it cannot afford to lose resigns
• the company then hires in a hurry, often more people than were first requested, into the process that was never fixed

The fix has no home

The cause of rework rarely sits inside the team that does the rework. At a payments company onboarding merchants, the risk operations team spends much of its week chasing ownership documents that applications arrive without, because the form the sales team uses does not require them. In a B2B sales organisation, legal is buried in contract amendments because the quoting tool lets reps offer terms that legal then has to rewrite. In both cases the fix belongs to a team that was not in the budget review, has its own roadmap, and has never felt the queue.

So the fix becomes a ticket. It is real, it is prioritised against everything else the owning team was already doing, and it loses, because nothing that team is measured on improves when it ships. Nobody decided to leave it undone. Nobody decided to do it either.

The team pays twice

Meanwhile the strained team does what strained teams do. The workarounds harden into process of their own: a shared inbox for incomplete files, a tracking spreadsheet, a senior person who checks every case before it goes out. Each one makes the eventual fix larger, because it now has to replace something people rely on. Then the person who held the workarounds together leaves. By the time the hire is approved, the company is hiring to replace knowledge it lost, not to add the capacity it needed.

The hiring that follows is fast, larger than the original request, and less selective. It goes into the same loop, which now has more steps than it had six months earlier. The outcome is the worst of both answers: the hire came later and bigger, and the process is still unfixed.

The remedy is not to stop saying fix the process first. It is to attach terms that the same meeting can set in a few minutes. Where we have seen fix-first work, four were present:

• an owner for the fix in the team that owns the cause, with time released for it, rather than in the team that feels the strain
• a date by which the fix is live, close enough to sit within what the strained team can absorb
• a reading agreed in advance: which count should fall, such as files returned for missing documents, and how much volume is expected to remain once it does
• a fallback: if the date passes without the fix, the hire is approved without a second hearing

The fallback carries the weight

The fallback is the term most often refused, and the one that does most of the work. It changes the position of the owning team, which now knows its delay has a price the company will pay in headcount. It also protects the strained team from the third stage, because the worst case has a date on it. A fix with no fallback asks the strained team to carry the risk of another team's backlog.

Without those terms, fix the process first is a hiring freeze with better manners.

The reading matters for the same reason a kill criterion has to be readable the day it is set. If nobody agrees beforehand what the fix should change, its success becomes a matter of opinion at the next review, and the hiring case is argued again from the beginning.

Interim capacity belongs in the same minute

Temporary capacity, a contractor or a person borrowed from an adjacent team, should be agreed alongside the fix and sized to the gap until the fix date. It should end on that date as well. Interim help with no end date tends to become the permanent hire by default, made without the reading that was supposed to size it.

Part of the pattern is a question addressed to the wrong person. Should we hire or fix the process first is usually put to the manager who asked for the hire. That manager can answer half of it. They can show the backlog and cost the person. They cannot commit another team's roadmap, so whatever they say about the fix is a hope.

The forum that answers has to be one that can order the fix as well as decline the hire: the leadership team, the COO, or whoever sits above both teams. That is a decision architecture point more than a hiring one. The right to say fix the process first should sit only with someone who can also make the fix happen.

When the honest answer is to hire

Sometimes the reading shows mostly volume, and the honest answer is to hire now. Sometimes the cause is real but its owner cannot take it on within any date the strained team could survive, and the honest answer is still to hire, with the fix recorded separately and the new role written so it can change once the fix lands. Choosing to hire first is defensible; choosing to fix first and leaving the fix unowned is not. And where a team has already hired twice into the same strain, the cause may not be inside any one loop at all, but in a shared constraint that headcount cannot grow.

We are most often called in at the third stage, when the workarounds are visible and a resignation has made the backlog impossible to ignore. Our consulting work under growth discipline reads a month of the team's real cases, locates the cause and its owner, and puts a cost on the fix next to the cost of the hire.

The output is one page the leadership team can decide on in a single sitting: the fix, its owner, its date, its reading, and the hire that follows if it slips. Where the managers who write hiring cases want to run the same test themselves, we take it up as training for the planning cycle.