Sarthak Garg

Leading indicators of burnout and drift

Detectable weeks before attrition: meeting load, tone shift, response latency.

·8 min read·

An engineer hands in their notice on a Tuesday, and you did not see it coming. They were hitting their numbers, and they were fine in last week's standup. Then you look back over the past six weeks, and it was all there: the review comments that used to run a paragraph had shrunk to "lgtm," the replies that used to come within the hour were taking a day, the camera that used to be on was off. None of it was loud, but it was all in plain sight.

The signs were there for six weeks, but the two tools most teams reach for cannot catch them that early. The standard burnout survey scores three things: how exhausted you are, how cynical you have become, and whether you still believe your work matters. As a definition that is fine, but it only registers burnout after it has set in, and only when the person will admit it on a form. The other tool, the activity dashboard, has the opposite problem: it tracks commit times and pull-request counts all day, none of which tells you how the person is doing.

Catching it early takes something duller and harder to automate: a manager who has watched this person every week for months and notices when they start showing up differently. The engineer who is about to quit was showing it weeks before they resigned. Doing that well comes down to a few things: compare the person to their own past rather than a team average; tell burnout apart from drift, because they need opposite fixes; check what you see in a real conversation without sliding into surveillance; and change what is wearing the person down rather than handing the problem back. Spotting weak signals in general is its own skill; this is the burnout case.

Compare them to their own past

The first mistake is to look for an absolute level. There is no response time that means trouble and no meeting count that means overload, because everyone runs at a different baseline. The colleague who has always answered the next day is consistent. The one who used to reply within the hour and now takes until tomorrow has changed, and that change is what you are looking for. Compare each person to their own past, because a team-wide threshold flags the wrong people, the ones who work heads-down and the introverts, and misses a sharp drop in someone who started high.

No single sign is worth much on its own, either; anyone can have a quiet week. What you are watching for is several of them moving the same way over a few weeks:

  • the calendar filling up until there is no open time left
  • the writing turning terse or sarcastic where it used to be generous
  • the slow replies and the dropped threads
  • pulling back from anything optional: camera off, clipped answers in standup, no more side jokes

One of them is noise, but three or four moving the same way over several weeks means something.

The clearest version runs over about three weeks. The review comments go first: a paragraph of real engagement on a pull request drops to "lgtm." Then the replies stretch from within the hour to the next day, and the person who used to start threads stops starting them. Any one of these you would explain away. Put them together, against who this person was a month ago, and the pattern is clear.

Tell burnout from drift

Once you are sure the decline is real, you have to name which kind it is, because the two look alike on the surface and need opposite responses.

Burnout is depletion in someone who is still delivering. The work stays good while the person wears down, and that is what makes it dangerous: the numbers look fine right up until they break or quit. The newer name for it is "quiet cracking," and it fits, because the cracking is quiet. Drift is the opposite: the person has checked out from boredom or lost meaning rather than overload. They do the minimum, and it shows in the work.

What fixes one makes the other worse. Burnout needs less: cut the load, protect time to recover. Drift needs more: more ownership, a harder problem, a reason the work matters, which is a subject of its own. Get the diagnosis backwards and you do real harm. Give a burning-out engineer a big, visible project as a vote of confidence and you bury them. Cut a bored engineer's workload to protect them and you make the boredom worse. The question that sorts them is easy to ask and hard to answer honestly: is this person exhausted but still trying, or checked out and coasting?

The case that teaches this best looks healthy the whole way through. A strong engineer hits every commitment, stays pleasant in standup, ships on time, and then quits, and the team is blindsided because the dashboard showed nothing wrong. The delivery was real, and so was the exhaustion underneath it; the steady delivery had been hiding it.

Check it in the one-on-one

What you see is a guess until you check it in the 1:1, and that check goes nowhere if you open with "how are you," because the healthy and the exhausted both say "good, busy." The question has to be specific enough that the autopilot answer does not fit. Ask what drained them this week, and what they did not get to that is still nagging at them. Ask which part of the work they would drop if they could.

None of this means watching in silence and never asking. It means the 1:1 is a real conversation about what you have already noticed. Run it like a status update or an interrogation and you teach the person to say "fine," which shuts the one door you had. The 1:1 is where this comes out, and running it well is a craft of its own.

Watch without surveilling

If the signs are behavioral, why not track them automatically? There are tools that score after-hours commits, count keystrokes, and guess from someone's messages who is about to quit. The pitch is early warning for the whole team at once, but what you actually get is surveillance, and it ruins the very thing it set out to measure.

There is a real line here. Noticing what is already in front of everyone is fine: the tone of a code review, how full a shared calendar is, how fast threads get answered. That is just what working together looks like. Going after private data the person never showed you, when they commit, how fast they type, is a different thing entirely.

It is easy to predict how this goes wrong: a model flags a loyal senior as a quitting risk because of his late-night commits. Nothing was wrong; he likes the quiet after his kids are asleep. But now he knows the clock is being watched, so he shifts his commits to daytime and goes quiet everywhere else. His score went up while he got harder to figure out. The tool taught him to hide, and it cost you the openness you had been relying on.

Once people know something is being scored, they stop being honest about it, so keep your attention on what the work already shows. What you refuse to measure is a real part of the job, and designing measures that resist gaming is the bigger discipline.

Change the work itself

Catching it early is worthless if you then get the response wrong, and the usual response is wrong in a specific way. You confirm someone is burning out, and you tell them some version of "set better boundaries" or "you should really take your time off." It sounds caring, but you have handed the problem back. You have taken a workload you control and turned it into their personal wellness task, which they hear as blame and which usually speeds up the exit instead of preventing it.

Your job is to change what is wearing the person down:

For drift, you change the work itself: more ownership, or a harder problem. And do not reach for a performance plan; the repair loop is built to fix underperformance, and putting an exhausted person through it treats exhaustion like incompetence.

The wrong answer looks like kindness: a manager notices someone is fried and tells him to take a long weekend, meaning it well. He takes it, comes back rested on Monday, and the workload is exactly where he left it: same meetings, same scope, same pager. A month later he quits. The weekend treated the symptom and left the cause untouched.

Check your own state first

All of this depends on the person doing the watching, which is you. A worn-out manager gets the team wrong in both directions. In a brutal quarter, you either miss the changes because you have nothing left to spend on anyone, or you see burnout everywhere because you are projecting your own. Before I judge anyone else's week, I check my own, and the weeks I get people most wrong are the ones where I am closest to empty.

Picture a manager in a crunch quarter who becomes sure half the team is about to crack, calls a round of emergency one-on-ones, starts pulling scope, and slowly works out that the only person who had really changed was themselves.

Checking your own state is the same skill turned inward, and it is its own essay, along with the finite week you are spending that attention out of. The engineer who quit on Tuesday was already showing it in June; whether you caught it came down to whether you were in any shape to look.