Greg Hoy
The diagnosis is pretty simple. If the same problem keeps showing up with different people doing the work, it’s a process problem. If the problem follows one specific person from project to project like my dog following me around with a plate of bacon, it’s a people problem. Most agencies assume the second and are actually living the first, which is convenient, because for some, firing someone is easier than admitting your process is flawed. It’s also predictable: the person diagnosing the problem is usually the person who built the process, so the diagnosis reliably comes back “people.”
What the two terms mean
A process problem is when something goes wrong with how the work happens. Stuff gets dropped at handoff. Approvals go to the wrong person, or to three people, none of whom think it’s their call. Estimates are based on gut feeling or guesses. “Done” means something different depending on who you ask, if they ask at all. Perfectly smart people are involved, and the outcome is bad anyway, because bad outcomes are what the structure was inadvertently built to produce.
A people problem is when something goes wrong with a person. Wrong skillset for the role. Work ethic stinks. A personality that makes every meeting feel like a hostage negotiation or gives attendees a dead person face. Swap out the process around these folks and the issue comes right along with them.
Why does this matter? Because the fixes are completely different. You can’t train or will someone out of a bad workflow. You can’t restructure around someone who shouldn’t be in the role. Diagnose it wrong and you’ll spend months painstakingly repairing the thing that wasn’t broken.
What the research says
W. Edwards Deming, the statistician whose work shaped modern quality management, put a number on this in Out of the Crisis. In his experience, 94% of problems belong to the system and 6% to special causes, meaning individual people or one-off events. Deming was talking about manufacturing, and the figure is his estimate rather than a measured result, but decades of process improvement work have backed up the general idea: when things go wrong, the system is the far more likely suspect. Yeah, he never had to deal with a client who wanted the logo bigger, but the principle holds.
Gallup’s research pulls in a different direction, and it’s worth holding both in your head at once. In its State of the American Manager report, Gallup found that managers account for at least 70% of the variance in engagement across business units. That’s a people finding. One role, the manager, explains most of the difference between a team that’s engaged and a team that’s mentally clocked out by Tuesday.
Google’s Project Aristotle landed in between. After studying 180 of its own teams, researchers found that who was on the team mattered less than how the team worked together. The strongest predictor of effectiveness was psychological safety: whether people felt they could raise a problem without getting punished for it. That’s not purely a process finding, since safety is a cultural condition, but it isn’t about individual talent either.
Read together, the three point at the same conclusion: individual capability matters a lot less than most agency owners assume, and the conditions people work inside matter a lot more. The exception is management. One bad manager can make a whole team look like it has a process problem.
The litmus test
When a project goes sideways, the first thing I ask is whether this exact failure has happened before with different people involved. Not a similar failure. This one. A project that blew its estimate by 40% because discovery uncovered scope nobody priced. A deliverable that went to the client without a review because everyone assumed someone else was the someone. An invoice that went out six weeks late because the person tracking billable hours was also the person running the project, and also the person putting out the fire that started when the invoice went out six weeks late.
If the answer is yes (and it almost always is), you don’t have a people problem. You have a process that’s producing the same reliable failure, and the people are just the ones standing nearest to it when it goes off.
The same test runs in reverse. When the process changes and the failure doesn’t, look at who was there every time.
When it really is the person
Process problems get most of the blame here, but people problems are real, and pretending otherwise is its own kind of mistake. Usually an expensive one.
The clearest sign is portability. If someone struggles on every project, with every team, under every process you’ve tried, the common denominator isn’t the process. If clients keep asking not to work with a specific person, and the reason isn’t “they told us something true we didn’t want to hear,” that’s a signal. If a team’s morale visibly improves the week a particular manager goes on vacation, that’s not a coincidence. That’s data.
I’ve watched this happen from the inside. One manager, one team, a steady stream of departures, and the same explanation every time: they weren’t getting it, they weren’t a fit. No other team in the company was turning over anything close to that rate. Every individual explanation was plausible on its own. The pattern wasn’t.
What was actually happening was simpler. The manager was buried in their own work and never had time to onboard anyone properly. New hires were expected to read minds from the first week, and when they couldn’t, that became proof they weren’t cut out for it. The company had vetted and hired every one of those people. It then accepted, over and over, that the hiring had been wrong and the manager had been right. That cost real money in recruiting and ramp-up time, and more in the work that didn’t get done while each new person quietly failed at a job nobody had set them up to do. The turnover never stopped, because the one thing every departure had in common never changed.
Management is where the two categories blur. A manager who can’t give clear direction, can’t make decisions, or punishes people for surfacing problems is a people problem, but the damage shows up as process failures: missed handoffs, unclear ownership, a team that stops flagging risks because the last person who flagged one is no longer employed. Gallup’s 70% number is really about this. You can’t fix it with a better workflow, and you’ll waste a lot of time trying.
Where this advice doesn’t apply
Very small teams are the main exception. At three or four people, the process and the people are pretty much the same thing, because every process runs through the same two or three humans. There’s no system to diagnose separately from the individuals in it. Below that size, the honest answer to “people or process” is “you don’t have enough of either for the question to mean anything yet.” Come back when you’ve hired someone you can blame.
The other exception is a genuine capability gap. If your agency took on work it has never done before, and it’s going badly, that’s not a people problem or a process problem. It’s a scope problem. Nobody’s workflow was designed for it and nobody was hired for it. You said yes to something you’d never done because the number was big. I’ve done it too. Everyone has. Just don’t diagnose it as something else afterward.
What to do with the diagnosis
If it’s process, write down how work actually gets done—not how the org chart says it should. Those are two very different documents, and one of them is pure fiction. Look for where things keep breaking down and fix that specific step. This is most of what I do with agencies: map out the real workflow, spot the handoffs dropping the ball, and rebuild them so success doesn’t depend on someone just remembering to do it. You can read more about this on my services page under Documentation & Process Handoff and Business Process Optimization.
If it’s people, the answer is a direct conversation and a real decision, made faster than feels comfortable. Agencies routinely wait a year longer than they should on this. I have personally waited a year longer than I should have on this. The process work can’t start until it’s resolved, because you’ll be building a system around a problem that isn’t going to stay put.
If you’re not sure which it is, that’s usually the sign that you’re too close to it. Remember who built the process. An outside read of how the work actually flows, done by someone who doesn’t have lunch with anyone involved, tends to settle the question in a couple of weeks.