I didn't notice our team was burning out. The commit history did.
It started as an idle observation — I was scrolling through a repo's activity graph looking for something unrelated, and noticed a pattern I hadn't consciously clocked before: commits at 11 PM. Then 1 AM. Then a Sunday afternoon that was supposed to be nobody's problem but somehow was. Not from one person. From most of the team.
Nobody had said anything was wrong. Standups were normal. Sprint velocity looked fine, maybe even good. But the timestamps didn't lie, and once I saw the pattern, I couldn't unsee it.
The Illusion of "Fine"
Here's the thing about remote engineering teams: the signals that used to tell you someone was struggling just don't exist anymore. In an office, you'd notice if someone was still at their desk at 8 PM, or if the usual joker in standup had gone quiet for a week. Remotely, all you get is output — PRs merged, tickets closed, Slack messages sent at reasonable-looking hours (timezone permitting).
Output can look completely healthy while the person producing it is not.
This is the trap that's specific to engineering work in particular: flow state is genuinely good, until it isn't. Deep, uninterrupted focus is the thing every dev wants more of. It's also exactly the state that makes it easiest to lose track of time, skip breaks, and quietly work three extra hours without registering it as "extra." A senior engineer who's deep in a gnarly bug at 6 PM doesn't think "I should stop." They think "I'm so close." That instinct is a virtue right up until it becomes the reason they're still debugging at midnight, three nights in a row.
Why "Just Ask People How They're Doing" Doesn't Work
The standard advice for catching burnout early is to check in with people. I don't think that advice is wrong, exactly — it's just insufficient on its own, especially with engineers.
A few reasons:
- Devs tend to underreport their own state. "I'm fine" is the default answer to "how are you doing," even from people who are visibly not fine, because admitting otherwise can feel like admitting you can't handle the workload.
**- The people most likely to burn out are often your best performers. **They're the ones who won't drop a commitment, who'll quietly absorb scope creep instead of pushing back, who see "I need to slow down" as a personal failure instead of a normal signal.
- By the time it's visible in a 1:1, it's often already advanced. Burnout doesn't show up as "I'm stressed" in week one. It shows up as cynicism, disengagement, or a sudden resignation that blindsides everyone, months in.
You can't fix a lagging indicator with a conversation that only happens once a week, or once a sprint.
What Actually Caught It (Eventually)
What actually made the pattern visible wasn't a heart-to-heart. It was data I wasn't looking for on purpose — a byproduct of version control, not a monitoring tool designed to surface it. That's a problem, because it means the signal only exists if someone happens to go looking, and most of the time nobody does.
That gap is exactly what got me interested in tools built to surface this kind of pattern on purpose instead of by accident. Not surveillance-style keystroke logging — nobody on an engineering team wants that, and it wouldn't tell you anything useful anyway; deep debugging looks identical to idle scrolling in a raw activity log. What actually helps is something closer to a rolling burnout signal: work patterns trending in a direction that's worth a human conversation, flagged early enough that the conversation can still be preventive instead of a resignation debrief.
That's the underlying idea behind products like TrackDots — using activity patterns over time (not moment-to-moment surveillance) to flag things like sustained after-hours work or workload creep, before it turns into an engineer quietly deciding they're done. I'm not going to pretend every monitoring tool gets this right — a lot of them are built around exactly the kind of "gotcha" surveillance that developers correctly hate. But the instinct behind building one with transparency and pattern-detection instead of screenshots and keystroke counts is the same instinct that made those commit timestamps worth paying attention to in the first place.
What I'd Tell Past Me
If I could go back, I wouldn't tell myself to work less — that advice never lands when you're the one deep in flow state at 11 PM feeling productive. I'd tell myself to build in the visibility on purpose, before I needed a repo's commit graph to accidentally reveal a pattern that had already been running for weeks.
Burnout on a remote engineering team doesn't announce itself. It just quietly writes itself into the timestamps, waiting for someone to scroll back far enough to notice.
