How to Tell If an Engineer Is Struggling

TL;DR: Engineers almost never announce that they're struggling; the culture trains them not to. The signs show up in the work first: branches that won't converge, PR scope shrinking, questions drying up, a person going quiet. Every sign has innocent explanations, so the move is never a verdict. It's an early, private, concrete offer of help: shrink the task, assign a pairing partner, make asking cheap. Struggle caught in week two is coaching; struggle discovered in month four is a resignation or a review problem you built yourself.

There's a specific silence that experienced managers learn to hear: the engineer whose updates got shorter, whose PRs got smaller, who stopped asking questions three weeks ago. Not slacking. Working hard, often late, on something that isn't converging, and hiding it because that feels safer than admitting it. Your job is to see it before it compounds.

Signs an engineer is struggling (visible in the work)

None of these is proof. Each is a hypothesis that, sustained for a few weeks, deserves a kind and private conversation:

• Branches that live too long. Work that stays open for weeks, rebased repeatedly, never quite ready. The classic signature of a task that's too big or a problem that isn't yielding.
• Shrinking scope. Someone who used to ship features now ships typo fixes and config tweaks. Retreating to safe, small changes is what low confidence looks like in a diff.
• Stretching cycle time, on their items only. If the whole team slowed down, you have a system problem. If one person's tasks quietly doubled in duration while the team's stayed flat, that person is fighting something.
• Questions drying up. Counterintuitive but reliable: struggling people often ask fewer questions, not more, because each question feels like evidence against them. In the 2024 Stack Overflow survey, 61 percent of developers reported spending over 30 minutes a day searching for answers. Searching alone is what asking-feels-expensive looks like at scale.
• Withdrawal from review. They stop commenting on others' PRs, their own PR descriptions shrink, they approve without discussion. Review is where confusion becomes visible, so it's the first place people hide.
• Vague standups. "Still working on the migration" for the third week, with no named blocker. A named blocker is a request for help; vagueness is its absence.

Struggling, slacking, or burning out? The triage

Three patterns get confused because they all read as "less output," and the responses are completely different:

• Struggling - effort is high, progress is low, confidence is dropping. Usually situational: wrong-sized task, unfamiliar terrain, missing context. Response: support, scope, pairing. This article.
• "Slacking" - the suspicion managers reach for first and the data supports least. Before you go there, read why engineering data can't detect slacking: the low-output engineer is usually blocked, overloaded, isolated, or ramping.
• Burnout - energy depletion, cynicism, reduced efficacy, sustained over months, with a rhythm that lost its off switch. Different signals, different urgency: developer burnout warning signs covers what it looks like, and the prevention playbook covers what to change. Struggle that goes unsupported for long enough becomes burnout.

The triage question that separates them, asked in a 1:1: "Walk me through what a day on this task actually looks like." Struggle sounds like effort hitting a wall. Burnout sounds like effort losing its point.

Why engineers hide struggle

Because the profession punishes visible confusion, and everyone learns it early. Seniors believe they're paid to already know. New hires fear confirming a bad-hire suspicion. And remote work removed the cheap rescue channels: nobody sees you frowning at your screen, so nobody wanders over. Microsoft's study of 267 new hires onboarding remotely (Rodeghero et al., ICSE 2021) found that building a strong social connection with the team was a key struggle, and asking for help is a social act. No connection, no asking; no asking, no visible struggle until it's big.

There's a structural angle too: at Google, the large-scale study of ~9M code reviews found review functions as an education and context-sharing channel, not just a defect filter. If your review culture is thin (rubber stamps, no discussion) you've disabled the main legitimate channel where a struggling engineer gets teaching without having to announce they need it.

How to help (the part that matters)

1. Shrink the task until it's finishable this week. Struggle feeds on scope. Cut the migration into a slice that can merge in days. Momentum is the treatment; a merged PR is the dose.
2. Assign pairing - don't offer it. "Let me know if you need help" is a politeness, not a plan; a struggling person will never redeem it. "Spend tomorrow morning on this with Sam" is a plan.
3. Make asking cheap, as a team norm. The rule that works: stuck for 30 minutes means you post the question in the team channel, for everyone, seniors included. It converts asking from a confession into a procedure.
4. Fix the terrain, not just the person. If they're stuck in an area only one other person understands, the problem is a knowledge silo wearing a person costume. Docs, pairing rotations, and spreading ownership fix it for the next person too.
5. Say the normalizing sentence out loud. "That part of the codebase confuses everyone; it took me three weeks to touch it safely." Thirty seconds of manager vulnerability buys more honesty than any survey.

What good looks like after 30 days: their branches merge in days, not weeks; questions reappear in channels and reviews; scope grows back; the standup has named blockers again. If none of that moved despite real support, then you're allowed to consider it a performance conversation, with a clear conscience, because you fixed the system first.

Where Busfactor fits, honestly

Busfactor can't read confidence or see effort, and won't pretend to. What it can surface are the work-level traces this article describes, as hypotheses with receipts: work that isn't converging, a collaboration footprint that shrank, someone operating alone in an area with no other knowledgeable people, a ramping engineer in unfamiliar terrain. It frames them as "worth a caring conversation," never as a score: no rankings, no verdicts, and nothing that punishes the person for being seen. The goal is that the quiet three weeks stop being invisible.