Skip to content

Insights

Is it a process problem or a people problem?

Eleven 186 ·

Key takeaways

  • A process problem, a people problem, and a system or incentive problem can all look identical from the outside.
  • A process problem means the steps required are unclear, missing, or work against a good outcome.
  • A people problem is narrower than most owners assume: the process is clear and workable, and this specific person still cannot or will not perform it.
  • If the same failure recurs across more than one person in the role, it is probably not one person's problem.
  • Replacing the person without fixing the process or system rarely removes the failure for long.

Most performance problems get blamed on the person doing the work, and most of the time that's the wrong diagnosis. A process problem, a people problem, and a system or incentive problem all produce the same symptom, which is someone not doing the thing they're supposed to do, but they call for completely different fixes, and treating one as another wastes months.

The blame lands on the person first because a person is easy to see and a system isn't. A missing step in a workflow, or a commission structure that rewards the wrong outcome, sits quietly in the background while the person following it absorbs the visible consequence. Telling them apart before you act is the whole point of the tests below.

Getting this wrong is expensive in a specific way. Treat a process problem as a people problem and you replace someone, absorb the cost and disruption of hiring, and watch the new person hit the same wall within weeks. Treat a people problem as a process problem and you rewrite documentation nobody needed rewritten while the actual performance gap carries on. And treat a system problem as either of the other two and the fix never touches the cause, so the same failure resurfaces every few months under a different name.

Three tests, run in order

The Swap Test. Put a different, reasonably competent person into the same role, following the same process, for the same stretch of time. If the outcome improves meaningfully, you probably had a people problem. But if the new person struggles in the same specific way, in the same specific place, you probably have a process problem, because something in the steps themselves is the obstacle rather than the person running them.

The Instruction Test. Ask the person to explain, in their own words and without looking anything up, the correct way to do the task. If they can't describe a correct process, then either it was never documented or it doesn't exist in a usable form, and that's a process problem. And if they can describe it accurately and still aren't doing it, run the third test before you conclude it's a people problem.

The Incentive Test. Ask what happens to that specific person if they do the task correctly, versus if they skip it, take a shortcut, or do it late. If the honest answer is that nothing different happens either way, or worse, that doing it properly is slower and less rewarded than the workaround, then you have a system or incentive problem. No amount of retraining or replacing people fixes a structure that rewards the wrong behavior.

Run the three in that order and stop as soon as one gives you a clear answer. Most cases resolve at the Swap Test or the Instruction Test. The Incentive Test matters most precisely because it's the one people are least willing to run, since it asks whether the business itself, rather than the employee, built the failure into the role.

A worked example

A regional service company noticed that follow-up calls to new leads were slow, sometimes by days, and the salespeople pointed to a heavy caseload. The owner assumed a people problem and started performance conversations with two reps.

The Swap Test told a different story. A newly hired rep, given the same lead list and the same tools, was just as slow within two weeks. The Instruction Test showed that every rep could describe the correct follow-up window accurately, so nobody was confused about the standard. The Incentive Test found the actual cause: commissions were paid on closed deals only, with no distinction between a lead followed up within an hour and one followed up three days later, and the CRM didn't flag an overdue follow-up to anyone, not even the manager. Nothing in the system rewarded speed.

If the owner had carried on with the original assumption, the next step would probably have been a round of coaching or replacing the slowest-looking rep, and neither one touches the commission structure or the missing alert. Once follow-up speed was tracked and tied to a small piece of the commission, response times improved within a month with the same people in the same roles. The fix cost a change to a spreadsheet and a CRM setting, whereas the alternative would have cost a hiring cycle and produced the same result six months later.

Questions to ask before you conclude which one you have

  • Has more than one person, in more than one period, produced the same failure in the same role? If yes, it probably isn't one person's problem.
  • Can the person describe the correct process accurately, unprompted? If no, fix the process or the documentation before you touch anything else.
  • What does this person's manager actually check or measure day to day? If the honest answer is nothing related to the failure, then the system isn't built to catch or reward the behavior you want.
  • If you replaced this person tomorrow with someone equally capable, would the same failure likely recur within a quarter? If yes, don't spend the effort on a personnel change.

When to get help

Most process problems, and a fair number of incentive problems, can be worked out internally once someone runs these three tests honestly, which is harder than it sounds when the person doing the diagnosis has a stake in a particular answer. Outside help tends to earn its cost in two situations: when the person closest to the problem is also the person whose incentive structure is the actual cause, which makes an honest internal diagnosis unlikely, or when the failure spans more than one department and each side has a reasonable case for blaming the other. Neither is unusual, and both are worth naming before you spend another quarter on the wrong fix.

Get the next one

One short note when we publish something worth reading. No sequence, no pitch.