How to Tell If an Engineer Is Slacking (Honest Answer)

TL;DR: You can't detect slacking from engineering data, and any tool that says otherwise is selling you commit counting with a dashboard on top. Activity metrics measure visibility. The low-output engineer you're worried about is far more often blocked, overloaded, isolated, or ramping than lazy. Those four are diagnosable from data, they're usually system problems, and fixing them is your actual job. The better question isn't "is this person slacking?" It's "what's in this person's way?"

You typed that question because something feels off: someone's output looks thin, the standup updates are vague, and you're starting to wonder. Fair. It's a real management situation and it deserves a real answer. Here it is, without the surveillance-tool sales pitch.

Can you detect slacking from commit data?

No. Not with commits, not with PR counts, not with lines of code, not with "active days." This isn't a philosophical objection; it's mechanical:

• Hard problems produce small diffs. Three days inside a race condition can end in a four-line fix. The diff is the receipt of the work, not the work.
• The most valuable work is often invisible in git. Code review, mentoring, incident response, design discussion, unblocking three teammates. A week of glue work can be the highest-leverage week on the team and produce zero commits under the person's name.
• Activity is gameable in one afternoon. Split commits, open cosmetic PRs, push work-in-progress hourly. The moment activity becomes the score, you're measuring who read the scoring rules, and your best people learn that visibility beats outcomes.
• The research is settled. The SPACE framework (Forsgren, Storey, et al.) states flatly that developer productivity "cannot be measured by a single metric or dimension." Activity is one of five dimensions, and the paper warns specifically against using it alone.

So the direct answer to the query: engineering data cannot tell you someone is slacking. Anyone claiming their product detects slackers is either measuring the wrong thing or lying about what they measure. We've written before about why individual output metrics fail as performance measures; this is the same failure with a suspicion attached.

What low output actually means, most of the time

Here's what makes the honest answer useful rather than just principled: low visible output is a real signal. It's just a signal about the system around the person far more often than about the person. Four patterns cover most cases, and each one is checkable:

1. Blocked. They finish work and then wait. PRs sit in review queues for days, a dependency on another team stalls, the staging environment is broken again. Check: how long do their PRs wait for pickup? What are they waiting on right now? A person who is blocked looks identical to a person who is idle - from the outside.

2. Overloaded, with the wrong kind of work. They're the go-to reviewer, the onboarding buddy, the one who answers every "quick question." Their calendar is confetti. The Parnin & Rugaber research on 10,000+ real programming sessions found only about 10 percent of interrupted sessions get back to editing code within a minute of resuming, and roughly 30 percent take over half an hour. An interrupt-shredded week produces almost no visible output while being completely full. Check their review load and meeting density before you check their commits.

3. Isolated. They're stuck in a part of the system nobody else knows, with nobody to ask. In the 2024 Stack Overflow survey, 61 percent of developers reported spending more than 30 minutes every day just searching for answers, and 30 percent said knowledge silos hit their productivity ten or more times a week. Knowledge silos manufacture slow-looking engineers at industrial scale.

4. Ramping. New to the team, the codebase, or the domain, where time to productivity is measured in months rather than sprints. Someone six weeks into an unfamiliar legacy area should look slow. That's what learning looks like in a git log.

Notice what these four have in common: every one of them is your problem to fix, and every one of them gets worse if your response to it is monitoring. There's also a fifth possibility worth naming: the person is struggling and hiding it, which deserves help, not detection.

The better question: what's in this person's way?

Swap the question and the whole investigation changes shape. "Is X slacking?" leads to watching. "What's in X's way?" leads to looking at queues, load, and context, things you can actually see in the data and actually fix. Concretely, before the next 1:1, spend ten minutes checking:

1. Their wait time. How long did their last five PRs sit before first review?
2. Their interrupt load. Review requests, meetings, support pings - is their week actually available for the work you're judging them on?
3. Their terrain. Are they working in a well-trodden area or somewhere with one other knowledgeable person - or zero?
4. The team's load overall. If several people look slow at once, you don't have a slacker. You have an overloaded team or a broken delivery pipeline.

Then ask, in private, questions that assume good faith: "What are you waiting on right now?" "What was the most frustrating part of last week?" "If you could delete one recurring obligation, which one?" People blocked by the system will tell you exactly where it hurts, usually with relief that someone finally asked.

When it really is a performance problem

Sometimes it is. Honesty cuts both ways. Once you've cleared the blockers, balanced the load, and given context and a fair ramp, if the output still isn't there, you have a real performance conversation to have. Have it like a professional: clear expectations, specific examples, a time-bound plan, delivered through a proper review process, not through commit graphs presented as evidence.

What you should refuse, permanently, is the shortcut: ranking people by activity to find the "bottom." Microsoft ran exactly that experiment with stack ranking and killed it in November 2013; HBR's account ties the forced curve to the company's "lost decade": managers rating team members from excellent to poor even when the whole team performed excellently. Surveillance and ranking don't find slackers. They manufacture distrust, reward theater, and hand your best engineers a reason to interview elsewhere.

How Busfactor fits (and where it refuses to)

Busfactor does not have a slacking detector. That's not a gap in the roadmap. It's a refused feature, permanent, because the data can't support it and the attempt poisons teams. What it does show is the system around each person, with receipts: who's waiting on reviews and for how long, whose week is being eaten by review load and glue work, which areas have one knowledgeable person, who's ramping in unfamiliar territory. Blocked, overloaded, isolated, ramping - diagnosed at the system level, so the 1:1 starts with "I saw you waited three days on that review" instead of "your numbers are down." No stack ranks, no activity leaderboards, no firing signals. Ever.