Picture this: A talented senior engineer who shipped features rapidly at their previous company now takes three weeks for simple changes. The CTO assumes it’s a hiring mistake. Six months and one expensive severance later, the replacement has identical problems. The engineer wasn’t the issue—the 47-step deployment process was.
This scenario plays out in engineering organisations across the globe, costing companies six figures in unnecessary turnover whilst the real problems remain untouched. Technical leaders routinely attribute team underperformance to people problems—wrong hires, cultural misalignment, lack of motivation—when the actual culprit is invisible process dysfunction. This misdiagnosis leads to expensive hiring mistakes, damaged team morale, and performance issues that persist regardless of personnel changes.
The consequences extend far beyond recruitment costs. You’re potentially dismissing capable engineers, destroying team trust, and wasting months on hiring cycles whilst systemic issues continue strangling your team’s potential. The pressure from executive leadership to improve velocity quickly often pushes you towards reactive decisions that feel actionable but miss the mark entirely.
This article provides a diagnostic framework to distinguish between genuine engineering team dysfunction and process-induced performance problems, potentially saving you from six-figure hiring mistakes and months of unnecessary organisational disruption. You’ll learn the five process failures most commonly mistaken for people problems, specific diagnostic signals for each, and a practical three-week audit process to identify systemic issues before making personnel decisions.
The Attribution Error That Costs Engineering Leaders Six Figures
Why We Blame People When Processes Fail
You’ve seen it before: talented engineers underperform, and your immediate instinct points to the individual rather than the environment. This isn’t a personal failing—it’s the fundamental attribution error in action. Psychologists have documented for decades how humans naturally attribute failures to character rather than circumstances. When someone else struggles, we assume it’s who they are; when we struggle, we recognise the situational constraints.
For engineering leaders, this bias compounds because process dysfunction remains largely invisible to you. Unless you’re writing code daily, you won’t experience the friction your engineers face. That 47-step deployment process? You approved it in a meeting where it seemed reasonable. The architect, lead developer, and director all reviewing architectural decisions? That feels like appropriate rigour. But from the individual contributor’s perspective, these processes create constant friction that transforms capable engineers into apparently slow performers.
There’s also a darker truth: replacing people feels more actionable than systemic process redesign. You can make a hiring decision in weeks. Overhauling engineering team processes requires months of effort, political capital, and the admission that current systems aren’t working. The illusion of control that comes with personnel changes is seductive, especially under pressure.
Once you’ve mentally labelled someone as “the problem,” confirmation bias takes over. Every missed deadline confirms your diagnosis. Every communication misstep reinforces the narrative. You stop seeing the eleven approval gates that delayed their work and only see the late delivery.
Consider the engineer who joined your team from Amazon. At their previous company, they shipped features weekly. Now, six months in, they’ve delivered two significant changes. Your conclusion: they weren’t as good as their CV suggested, or perhaps the Amazon environment inflated their capabilities. The reality? Amazon’s deployment infrastructure allowed ten deployments daily with automated testing and rollback. Your infrastructure requires manual QA approval, a change advisory board review, and deployment windows on Tuesday and Thursday evenings. The engineer hasn’t changed—the environment has.
The Real Cost of Misdiagnosis
Let’s talk numbers, because this misdiagnosis isn’t just philosophically problematic—it’s financially devastating. The direct costs of replacing an engineer typically run between 1.5 to 3 times their annual salary, according to research from the Society for Human Resource Management. For a senior engineer on £90,000, you’re looking at £135,000 to £270,000 in direct costs.
This includes recruitment fees (typically 20-30% of salary), the severance package, lost productivity during the notice period, time your team spends interviewing candidates, and the ramp-up period for the new hire. Engineering hiring cycles average four to six months from opening the requisition to productive contribution, meaning half a year of underperformance costs regardless of your decision.
The indirect costs compound the damage. Team morale deteriorates when colleagues see someone dismissed for problems they all experience. Your remaining engineers start wondering if they’re next. The best performers—those with options—begin updating their CVs. You’ve inadvertently created a climate of fear where people spend energy on political safety rather than technical problems.
Institutional knowledge walks out the door with each termination. That engineer who seemed slow? They understood the legacy authentication system nobody else wanted to touch. Their replacement will take months to acquire that same knowledge, if they ever do.
Then there’s the opportunity cost: six to nine months focused on hiring activities instead of addressing the systemic issues strangling your team’s output. Your leadership capacity—arguably your scarcest resource—gets consumed by job descriptions, interviews, and onboarding instead of process improvement.
The death spiral begins when new hires experience identical engineering team performance problems. After cycling through two or three engineers in the same role with consistent underperformance, you might conclude you have “bad hiring luck” or that “quality engineers are impossible to find.” The actual problem—your 47-step deployment process—remains undiagnosed and unfixed, continuing to undermine whoever fills the role.
I’ve watched one company cycle through three engineering managers in eighteen months, each time convinced the individual wasn’t up to the role. The actual issue? Their sprint planning process required managers to attend seven different meetings weekly to gather requirements, with no documented decision-making framework for prioritisation. No manager could succeed in that environment, but it took the fourth hire—who explicitly diagnosed the process problems before accepting the role—for leadership to recognise the pattern.
5 Process Failures That Look Like People Problems
1. Deployment Bottlenecks Disguised as ‘Slow Developers’
You review velocity metrics and see developers completing fewer story points than expected. Your conclusion: they’re not working efficiently. But before you judge individual performance, examine what happens after code completion.
The diagnostic signals are specific: work sits in pull request review for three to seven days, multiple approval gates exist before production deployment, manual QA queues create bottlenecks, and deployment windows restrict when code can ship. You might have a security review requirement, a technical architecture approval process, and a change advisory board that meets weekly. Each gate adds days or weeks.
Why it looks like a people problem: Your velocity metrics only show completed work in production. If deployment infrastructure creates a ten-day lag between “code complete” and “deployed,” individual developers appear to complete one story every two weeks when they’re actually writing code in three days. From your dashboard perspective, they look unproductive.
The process reality: The coding happens quickly, but deployment infrastructure creates artificial constraints. Your engineers spend Tuesday writing code, Wednesday through next Tuesday waiting for reviews and approvals, and the following Wednesday deploying. The actual engineering work takes 20% of the calendar time; the deployment process consumes 80%.
Quick diagnostic test: Track “code complete” to “in production” time separately from actual development time. Shadow a feature from assignment to deployment, documenting each stage. If deployment cycle time exceeds development time by 3x or more, you have a process bottleneck, not a people problem.
Here’s a real scenario: A developer at a financial services company wrote a simple API endpoint modification in four hours. The code then spent three days in peer review (team members were in meetings), five days waiting for the security team’s approval slot, four days in the QA queue, and another three days waiting for the next deployment window. Total calendar time: 15 days. The developer appeared to need three weeks for a simple change, tanking their velocity metrics and raising performance concerns from leadership. The actual development work represented 4% of the elapsed time.
2. Unclear Decision Rights Creating ‘Leadership Vacuum’
You’re frustrated that your team can’t make decisions independently. Every technical choice becomes a protracted discussion. Engineers seem unable to take ownership. You conclude they lack initiative or senior-level judgement.
The diagnostic signals: Technical decisions require multiple meetings with different stakeholders, work stalls pending unclear approvals, engineers repeatedly ask “who should decide this?”, and leaders complain about lack of initiative whilst team members complain about overstepping boundaries.
Why it looks like a people problem: From your perspective, capable senior engineers should make technical decisions autonomously. When they don’t, you interpret it as insufficient experience, lack of confidence, or inability to lead. You hired them to reduce your decision load, but they keep escalating to you.
The process reality: No documented decision-making framework exists. The architect, tech lead, and engineering director all have overlapping authorities with unclear boundaries. An engineer who makes a significant architectural decision independently might get praised for initiative or reprimanded for not consulting stakeholders—and they can’t predict which. Fear of overstepping boundaries creates paralysis masquerading as indecisiveness.
Quick diagnostic test: Ask three different team members separately who decides specific categories of technical choices—database selection, API design patterns, third-party service adoption, refactoring priorities. If their answers differ significantly, you have process ambiguity, not a leadership vacuum.
Consider the architectural decision that ping-ponged between architect, lead, and director for three weeks. The lead engineer proposed moving from REST to GraphQL for a new service. The tech lead supported it, but wanted the architect’s review. The architect approved the pattern but suggested the director should sign off given cost implications. The director sent it back to the tech lead to “build consensus” with the team. No documented DRI (Directly Responsible Individual) existed for architectural decisions, so the choice cycled indefinitely whilst the engineer appeared unable to make progress.
The same engineer, in a previous role with clear decision rights, had successfully driven multiple architectural transitions. The capability existed; the process clarity didn’t.
3. Meeting Overload Masking as ‘Low Output’
Your engineers’ pull request activity has declined. Completed work volume drops quarter over quarter. You see talented people who produced impressive work during interviews somehow delivering less now. You begin questioning their motivation or work ethic.
The diagnostic signals: Engineers attend 20 or more hours of meetings weekly, calendars fragment into 30-minute blocks with no four-hour uninterrupted stretches, PR activity clusters on evenings and weekends, and engineers mention feeling “busy but unproductive” in one-on-ones.
Why it looks like a people problem: The volume of completed work is measurable and declining. From your perspective, engineers have the same 40-hour weeks but less output. Without examining how those hours fragment, you conclude decreased motivation, capability issues, or poor time management.
The process reality: Engineering work requires extended focus periods. Research from the University of California, Irvine shows that after an interruption, it takes an average of 23 minutes to return to the original task with full concentration. If your engineers’ calendars fragment into one or two-hour blocks between meetings, they never achieve the deep focus state necessary for complex technical work.
Your meeting culture optimised for coordination over creation. As the team grew, you added standups, planning sessions, architectural reviews, cross-functional syncs, and stakeholder updates. Each individual meeting seems reasonable. Collectively, they’ve eliminated maker time.
Quick diagnostic test: Audit one engineer’s calendar for a typical week. Count uninterrupted blocks of four or more hours. If they have fewer than 15 hours of contiguous focus time weekly, you have a meeting problem, not an output problem.
Here’s what this looks like in practice: A senior engineer’s calendar shows Monday starting with standup at 9:00, a planning session at 10:00, architectural review at 11:30, lunch, stakeholder sync at 13:30, cross-team collaboration meeting at 14:30, and an incident retrospective at 16:00. Tuesday follows a similar pattern. The longest uninterrupted block across the entire week is two hours. Actual coding happens in 45-minute fragments or during evening hours after meetings end.
The engineer appears to have low output during business hours because they literally don’t have business hours available for focused work. When you compare their productivity to their previous role—where they had “no meeting Wednesdays” and mornings blocked for maker time—the individual hasn’t changed. The environment destroyed their capacity for deep work.
4. Inadequate Tooling Appearing as ‘Technical Incompetence’
New hires struggle for months to reach productivity. Your team’s velocity seems inexplicably low despite talent. Engineers who were productive at previous companies appear less capable in your environment. You begin questioning your hiring assessment process.
The diagnostic signals: Manual repetitive tasks consume significant time, local environment setup takes multiple days, debugging requires tribal knowledge that isn’t documented, tests run slowly locally, and new engineers frequently need help from specific team members to complete basic tasks.
Why it looks like a people problem: New hires with impressive backgrounds take three to six months to reach full productivity. From your perspective, this suggests hiring mismatches or overestimated capabilities. You compare their current performance to the promises made during interviews and feel disappointed.
The process reality: Technical debt in developer experience compounds over time. Your team built systems when it was five engineers; it’s now thirty. Those initial shortcuts—manual deployment scripts, undocumented configuration, local environment setup requiring specific versions of twelve dependencies—created manageable friction at small scale. At current scale, they’re productivity killers.
Your engineers spend 30% of their time on activities that should be automated: manually deploying to staging environments, running test suites that take 45 minutes locally, configuring development environments, and debugging issues that stem from inadequate observability tooling.
Quick diagnostic test: Time a new engineer from laptop arrival to first meaningful commit to production. If it exceeds two days, tooling is a significant constraint. Survey your team about what activities they’d automate if given a week—if multiple people cite the same manual processes, you have systemic tooling gaps.
Consider the team blamed for slow delivery when running their test suite locally took 45 minutes per run. Engineers would start tests, context-switch to other tasks during the wait, and lose momentum. They ran tests less frequently, leading to more bugs reaching production, which led to demands for more thorough local testing, which further slowed development. The death spiral continued until leadership finally invested in CI/CD infrastructure that ran tests in seven minutes.
The same engineers, with proper tooling, tripled their velocity in six weeks. Their technical competence never changed—their tools did.
5. Missing Feedback Loops Creating ‘Persistent Issues’
The same bugs resurface. Incidents repeat. Quality issues persist despite “conversations” with team members. You conclude individuals aren’t learning from mistakes or are ignoring feedback. Performance improvement plans feel necessary.
The diagnostic signals: Incidents occur without post-mortems, or post-mortems happen without action items, or action items exist without tracking to completion. The same categories of bugs appear repeatedly. Quality issues persist at individual level but also team level. “We talked about this before” becomes a common refrain.
Why it looks like a people problem: You see patterns of repeated mistakes at the individual level. You’ve had conversations about code quality, incident response, or testing rigour. When issues persist, you interpret it as the individual not taking feedback seriously, being unwilling to improve, or lacking the capability to learn.
The process reality: No systematic feedback capture exists. Learning happens individually and inconsistently, not organisationally. You might conduct post-incident reviews, but without closed-loop verification that improvements were implemented, insights die in meeting notes. You lack processes to transform individual mistakes into organisational learning.
Individual engineers may want to improve but don’t have clear mechanisms to verify their changes were effective. You give feedback in one-on-ones, but without structured follow-up, both you and the engineer move on to new priorities and never verify improvement.
Quick diagnostic test: Review your last five incident post-mortems. Check if action items were documented, assigned to specific owners, tracked in your project management system, and verified as complete. If this closed loop doesn’t exist systematically, your feedback loops are broken. Ask engineers how they know if they’ve successfully addressed previous concerns—if answers are vague, feedback isn’t systematically closing loops.
One team faced recurring database performance incidents over six months. Leadership blamed individual engineers for not learning from previous incidents. Investigation revealed that post-mortems identified root causes, but recommended improvements—database query optimisation reviews, adding monitoring for slow queries, creating performance testing gates—never made it into sprint planning. No process existed to prioritise post-incident improvements alongside feature work. Action items lived in meeting notes, not backlogs.
Without systematic implementation and verification, the engineers couldn’t improve the situation even if they wanted to. The process failure created the illusion of individuals who wouldn’t learn.
The 3-Week Process Audit: Diagnose Before You Decide
Before making costly personnel decisions, invest three weeks in systematic process diagnosis. This framework identifies whether performance issues stem from systemic problems or genuine individual limitations.
Week 1: Shadow and Measure
Stop relying on second-hand metrics and dashboards. Observe actual workflows directly.
Shadow three to five engineers through their complete workflow for half a day each. Don’t just observe meetings—watch them code, deploy, debug, and collaborate. You’ll discover friction points invisible from leadership dashboards. Pay particular attention to waiting periods, handoffs, and context switching.
Track time from “task assigned” through each workflow stage to “deployed.” Create a simple spreadsheet documenting every stage: requirement clarification, design, implementation, code review, testing, approval gates, deployment. For each stage, record time spent actively working versus waiting. You’re building a flow efficiency map.
Document every handoff, approval gate, and waiting period. When work passes from one person or system to another, bottlenecks emerge. These handoffs feel reasonable individually but compound systemically. Note who owns each gate and what triggers progression to the next stage.
Collect quantitative data:
- Total meeting hours per engineer per week
- Pull request submission to approval time (average and median)
- Deployment frequency (daily, weekly, monthly)
- Uninterrupted work blocks (count four-hour minimum stretches)
- Time from “code complete” to “in production”
Here’s what this reveals: When one software company conducted this audit, they discovered a “simple” feature request took twelve days from assignment to production, but actual coding time was eight hours. The workflow map showed three days waiting for requirements clarification, one day for implementation, four days in code review (reviewers were overloaded), two days in QA queue, and two days waiting for deployment window. The engineering team processes created artificial delays exceeding development time by 14x.
This data transforms the conversation from “why is this engineer slow?” to “why does our process add twelve days to eight hours of work?”
Week 2: Anonymous Team Input
Your engineers know where processes break. Create safe channels to surface this knowledge.
Run an anonymous survey with specific questions about process friction points. Generic satisfaction surveys don’t help. Ask targeted questions:
- “What takes more time than it should in your workflow?”
- “What information do you regularly need but can’t easily access?”
- “What approvals or reviews create the longest delays?”
- “What tools slow you down or require workarounds?”
- “What meetings could be emails, and what emails should be documentation?”
Conduct confidential one-on-ones using this framework: “If you could change three processes tomorrow with no political constraints, what would they be and why?” This hypothetical framing gives engineers permission to identify systemic issues without fear of seeming negative.
Look for pattern recognition. If one engineer cites deployment bottlenecks as their primary frustration, that might be individual preference. If seven engineers independently cite deployment processes, it’s systemic. Patterns indicate process problems; outliers might indicate people problems.
Document specific examples. Don’t accept vague complaints like “too many meetings.” Push for specificity: “Which meetings? What makes them unproductive? What decisions or information comes from them that justifies the time?” Specific examples enable targeted improvements.
The pattern recognition matters critically. At one company, anonymous feedback revealed that eleven of fourteen engineers cited “unclear decision authority” as their top frustration, specifically around architectural choices. This wasn’t about any individual’s decision-making capability—it revealed a systemic lack of decision-making framework.
Week 3: Cost-Benefit Analysis
Transform your diagnostic data into business cases for process improvement versus personnel changes.
Calculate the actual cost of identified process problems using time-waste data from Week 1. If deployment bottlenecks add ten days to every feature and you ship thirty features quarterly, that’s 300 days of delayed value delivery. At an average engineer salary of £90,000 (approximately £450/day), that’s £135,000 in delayed productivity quarterly.
Compare process improvement cost versus hiring replacement cost. Improving your deployment process might require two engineers spending three weeks building automation, documenting procedures, and eliminating approval gates. Cost: approximately £15,000 in engineering time. Replacing an engineer costs £135,000-£270,000 in direct expenses, plus six months of disruption. The process improvement costs 6-11% of the personnel change whilst potentially solving the actual problem.
Prioritise fixes by:
- Impact on performance (how much improvement would this create?)
- Implementation difficulty (how much effort to fix?)
- Team morale benefit (what would most improve daily experience?)
- Risk if unchanged (what happens if we don’t address this?)
Create a 30-60-90 day process improvement roadmap. Within 30 days: eliminate obvious bottlenecks, clarify decision rights, reduce meeting load. Within 60 days: implement tooling improvements, establish feedback loops. Within 90 days: measure improvement and iterate.
Here’s a real calculation: One engineering organisation discovered their deployment process consumed £45,000 quarterly in delayed productivity. Improving it required £12,000 in engineering time and £3,000 in tooling costs. They were simultaneously considering replacing two “underperforming” engineers at a combined cost of £200,000+. They chose process improvement first. Within sixty days, those same engineers’ productivity increased 40%. The personnel changes weren’t necessary—the process improvements unlocked existing capability.
Critical principle: Create this roadmap before making any personnel decisions. If process improvements solve 70% of performance issues, remaining people problems become obvious and credible to address.
When It Actually Is a People Problem (And How to Know)
Process problems explain most engineering team performance issues, but not all. You need clear criteria to distinguish between systemic and individual problems.
Genuine Performance Issues Have These Characteristics
Individual performs below peers in identical process constraints. This is the critical test. If one engineer struggles whilst teammates in the same broken process succeed relatively, you’re seeing individual capability gaps rather than systemic issues. The environment is equally challenging for everyone, but outcomes differ.
Specific skill gaps persist despite training and support. You’ve provided mentoring, training resources, and pairing opportunities. Other engineers have grown through similar support. This individual hasn’t closed gaps despite genuine effort and investment. At some point, capability limitations become clear.
Process improvements help everyone except this individual. You fix deployment bottlenecks, and velocity increases across the team—except for one engineer whose output remains unchanged. You clarify decision rights, and engineers start moving faster—except one who still escalates everything. This differential response indicates the problem isn’t primarily environmental.
Pattern of behavioural issues independent of workflow. Reliability problems (missing meetings, not responding to time-sensitive issues), collaboration difficulties (conflict with multiple teammates, inability to accept feedback), or communication breakdowns that occur regardless of process quality signal individual issues.
Clear, documented performance feedback with insufficient improvement over a reasonable timeframe. You’ve had specific conversations, documented expectations, set measurable goals, and provided adequate time (typically 60-90 days) for improvement. Despite this, performance gaps persist.
Here’s how to distinguish: An engineer struggles with unclear requirements (process problem). You fix the requirements process—user stories now include acceptance criteria, designs, and technical specifications. Every engineer’s productivity improves except one, who still produces work that doesn’t meet requirements despite clear specifications. Now you’re seeing an individual comprehension or attention issue, not a process problem.
Conversely, an engineer seems unable to write functional code. Investigation reveals they’re working in a legacy codebase with no documentation, no local development environment setup, and no onboarding support. After you implement proper onboarding, documentation, and tooling, their code quality matches the team. That was a process problem masquerading as individual incompetence.
The Both/And Reality
Most situations involve both process and people elements. A broken process might affect everyone negatively whilst also revealing that one individual struggles more than others in challenging environments.
Fix processes first. This solves approximately 70% of issues in my experience and makes remaining people problems obvious. You can’t accurately evaluate individual performance in broken processes. If someone runs a marathon in deep sand and completes it slower than expected, you haven’t learned much about their running capability—you’ve learned about sand.
Process improvements give remaining personnel decisions credibility and fairness. If you fix systemic issues first and performance gaps persist for specific individuals, you can address those gaps with confidence that you’ve eliminated environmental factors. This protects you legally and ethically whilst being fair to the individual.
Create evaluation periods after process improvements. Implement your 30-60-90 day process roadmap, then evaluate individual performance in the improved environment. Those who thrive validate that processes were the constraint. Those who continue struggling despite systemic improvements need individual performance plans or role changes.
One company fixed their deployment process, clarified decision-making frameworks, and reduced meeting load. Three engineers immediately accelerated to expected senior engineer productivity. One engineer’s output remained below expectations despite identical environmental improvements. Only then could leadership credibly address the individual performance issue, having eliminated process variables.
The engineer in question ultimately transitioned to a role better suited to their strengths. The decision came after systemic improvements, was based on differential performance in an improved environment, and was received as fair by both the individual and the team.
Your Processes Probably Need Fixing, Not Your People
Before you restructure, replace, or write off team members as “not the right fit,” invest three weeks in systematic process diagnosis. Research from the State of DevOps Report consistently shows that elite-performing teams differ primarily in their processes and tooling—deployment frequency, lead time, and change failure rate—not in the inherent talent of individual engineers.
The majority of engineering team dysfunction stems from invisible systemic issues that persist regardless of personnel changes. That talented engineer from Amazon, Google, or another high-performing environment isn’t suddenly incompetent—they’re constrained by processes that don’t support their working style. Your team that performed brilliantly at twenty people isn’t suddenly dysfunctional at sixty—your processes haven’t scaled.
By distinguishing between process and people problems using the diagnostic framework outlined here, you’ll make better decisions, save significant money (potentially six figures per avoided bad hire), preserve team morale, and build the diagnostic capabilities that prevent these issues in the future.
Your engineering team probably isn’t broken. Your engineering team processes are. Fix the environment first, then evaluate the people within it.
Next Steps
Start your process audit this week. Shadow one engineer through a complete feature cycle from assignment to production deployment. Document every stage, handoff, and waiting period. You’ll discover friction points you didn’t know existed.
If you’re facing urgent performance decisions and need experienced guidance to distinguish between process and people issues in your specific situation, examining your engineering team processes systematically before making costly personnel changes could save you months of disruption and significant expense. The diagnostic frameworks here provide a starting point, but complex situations benefit from experienced external perspective.
Your next engineering leadership decision should be informed by data, not assumptions. Make process diagnosis your default before personnel decisions.