The most common thing we hear when we first embed with a team that's struggling: "we need to fix the process." The second most common: "we have the wrong people." In our experience, the right answer is usually neither — and arriving at either conclusion too quickly makes things worse.
Getting the diagnosis right matters because the interventions are almost entirely different. Fixing a process problem with a people change is expensive and demoralising. Fixing a people problem with a new Jira workflow is a waste of everyone's time.
What a process problem actually looks like
Process problems have a specific signature. The work is getting done — eventually — but it moves in unpredictable ways. Tickets get stuck in review for days without clear ownership. Deployments are infrequent because the release process involves too many manual steps or too much risk. Engineers are capable but constantly waiting: for approval, for a decision, for someone to unblock them.
The clearest signal is that the same capable engineers who are slow in your environment move fast when they leave. If you're consistently losing good people to companies where they suddenly become prolific, the constraint is almost certainly structural, not personal.
Other reliable indicators:
- Incidents that repeat because the fix never made it to a post-mortem that anyone acted on
- Work that gets estimated accurately but delivered late because of handoff delays
- Engineers who stop raising blockers because past blockers weren't resolved
What a people problem actually looks like
People problems look different. The work moves unpredictably not because the system is slow but because individual output is inconsistent or misaligned. The same task takes wildly different amounts of time depending on who picks it up. Reviews are superficial. Technical decisions aren't reasoned through.
The harder version: a people problem is sometimes a hiring calibration problem, not a fault of the individuals involved. If you've been hiring engineers into a context that requires a skill set they were never assessed for, the gap is real but the cause isn't a character issue — it's a mismatch that compounds over time.
Be careful about diagnosing people problems under pressure. The engineers who look least productive during a crunch are often the ones maintaining the systems that let everyone else ship. Removing them tends to clarify this, expensively.
The diagnosis most teams miss: a leadership vacuum
In practice, the most common root cause isn't a broken process or the wrong people — it's the absence of consistent technical leadership at the right level.
When a team lacks someone with the authority and judgment to make architecture calls, set delivery expectations, and push back on scope, both symptoms appear simultaneously. Processes pile up as substitutes for judgment. Engineers start to underperform not because they're wrong for the role but because they don't have clear direction or adequate context.
This is the pattern we see most often in companies that have grown from six to twenty engineers without adding senior technical leadership to match. The founding engineer or CTO is still nominally in charge, but they're spread across too many concerns to provide the consistency the team needs.
A more useful diagnostic
Rather than starting with "process or people," start with a different set of questions:
Where does work actually stop? Map a recent piece of work from inception to production and identify every point where it waited. If it waited for a human decision, that's a leadership or clarity problem. If it waited for a system, that's a process problem.
What happens when a capable engineer hits a blocker? Watch what they do. Do they resolve it themselves, escalate it, or absorb it and slow down? The answer tells you a lot about whether the environment is giving them what they need.
Is the problem consistent or localised? If one team or one area of the codebase is consistently slow while others move fine, the issue is probably localised — either to the domain complexity, the team structure, or specific individuals. Treat it as a local problem before extrapolating.
What do your best engineers complain about? Senior engineers who are still engaged will tell you what's broken if you ask directly. The complaints of people who are about to leave you've already lost. The complaints of people who are still invested are worth taking seriously.
What to do about it
If you've identified a genuine process issue, the most effective interventions are almost always the boring ones: clearer ownership of decisions, shorter feedback loops on work in review, and deployment pipelines that make releasing safer. Introducing new frameworks or tools is rarely the answer.
If you've identified a genuine people issue — a specific mismatch between what a role requires and what an individual can provide — the kindest thing is to address it directly. Reorganising around the gap or adding process to compensate creates fragility and isn't fair to the person in the role.
If you've identified a leadership vacuum, that's the thing to fix first. Almost everything else will look like it's getting better once the right senior person is in place, making decisions, and giving the team consistent direction.
---
These are the kinds of diagnostics we run during our early embed weeks. If your team's velocity has stalled and you're not sure why, a short conversation is usually enough to identify where to look.