Is It the Tool, or the Team?

Every data operation eventually produces the same meeting. Output is below where it should be, quality is drifting, and someone says the team needs more training. It is a reasonable sentence and it is often wrong, and the reason it is wrong is that it skipped a step.

A system is designed, built and tested. You then expect people to use it in a particular way. When they do not, and they run into problems, you have a signal. What that signal means is a separate question, and answering it too quickly is how teams spend a month retraining their way through something that was never a knowledge gap.

The two failures look identical from a dashboard

From above, a workflow problem and a capability problem produce almost exactly the same evidence. Throughput below target. Inconsistency between individuals. Rework climbing. Some people managing fine and others not.

Every one of those is consistent with two completely different explanations. Either the people using the system do not yet know how to use it well, or the system is asking something of them that is harder than it needs to be. The metrics cannot separate those, because both produce the same numbers, and the default assumption fills the gap. In most organisations the default assumption is that the tool is fine, because the tool was signed off, and the people are new.

Check the technical side first, always

The rule I use is simple in order and unglamorous. Go to the technical side first. Establish whether the problem is already solved there. If it is not solved, solve it. Only once the technical side is genuinely clean do you move to the people side and look at where the work is inconsistent or lacking.

The order matters more than the rule. Investigating people first is not merely inefficient, it actively contaminates what you learn afterwards. Once a team knows their performance is under examination, behaviour changes, and you are now measuring a group that is being watched rather than a group doing the work. If the platform turns out to have been the cause, you have also spent your credibility telling capable people they were the issue, and you do not get that back easily.

Technical first is also cheaper to run. Checking whether a workflow has a slow step, an unclear interface, a validation rule that fires wrongly, or a step that forces avoidable manual effort is work you can do in a day without involving anyone. Training programmes take weeks and cannot be un-run.

A people problem is not the same as a people solution

Here is the part that catches out most managers, and it is a genuine trap rather than carelessness.

Suppose there is a platform intended for both your internal team and an external one. The work is not getting done. The purpose the platform exists for is not being served. That is correctly classified as a people issue, in the sense that the failure is appearing at the point where people meet the system.

But the correct response is frequently to change the platform. You go in and work out what needs to be different so that it is easier for people to use. The diagnosis and the remedy point in opposite directions, and the language misleads you because "people problem" sounds like it should be answered with a people intervention.

The practical test is whether the difficulty is something a competent person should reasonably be expected to absorb. Learning your labelling taxonomy is reasonable, it is domain knowledge and it has to live somewhere. Remembering that one specific field must be filled before another or the record silently fails is not reasonable. That is a design defect, and training people to work around it means paying for the defect every time you onboard someone new, indefinitely.

Reading the pattern in who is struggling

The distribution of the problem usually tells you which one you have, and it is the fastest read available.

If almost everyone is struggling in the same place, it is the system. Large groups of people do not independently develop the same knowledge gap at the same point in a workflow. When a whole team stalls at one step, that step is badly designed, however clearly it was documented.

If a few individuals are struggling while most are fine, it is more likely a capability or training issue, and it is worth being specific about which. Someone who was trained inadequately needs training. Someone who does not have the underlying domain understanding needs a different task. Those are different findings that both get filed as needs training.

And if the same people are fine on one project and struggling on another, look at what changed between the two, because it is almost never the people.

The same logic applies to your quality checks

This diagnostic extends past workflow into quality assurance, where the same mistake produces a quieter and more damaging version of itself.

When rejection rates climb, the reflex is again that the work has got worse. Sometimes it has. But an automated quality pipeline can reject correct data as easily as it can pass incorrect data, and over-rejection is much harder to notice than the reverse, because rejection looks like rigour and nobody questions a system for being strict.

The method is the same as everywhere else in this piece. Look for patterns where rejections are unusually heavy, take a small sample of the files being rejected most, and check them by hand. A small sample of heavily rejected files will normally tell you within an hour whether your rule is wrong or the data is. Often enough it is the rule, quietly discarding good work while every dashboard reports that quality control is functioning.

None of this is an argument that people are never the problem. Sometimes they are, and pretending otherwise is its own failure of management. It is an argument about sequence. Look at what you built before you look at who is using it, because that order is cheaper, faster, reversible, and it keeps you from solving a design defect with a training budget.