I run a CTO-as-a-service company. Every engagement starts the same way: we walk into an engineering department we've never seen, and we have days to understand it. Before I look at any metric, I look for one thing — the person whose curve went flat.
In every department I've inherited, the person who scared me wasn't the loud one. It was the one who used to ask questions in reviews and stopped. The questions stop about three months before the resignation letter arrives.
What "quiet" looks like in tracker data
Commits drop. PR comments dry up. Issues move slower. Standup answers get shorter. Reviews go from thoughtful one-liners to "LGTM".
None of these trip a single alarm, and that's the problem. Each signal on its own has an innocent explanation. Commits drop — maybe they're in meetings. Comments dry up — maybe the work is straightforward. It's the flat curve across all of them, at once, that you can't explain away. And by the time it's obvious in delivery, you're already a quarter behind on doing something about it.
Why nobody sees it
Here's the part that took me years to internalize: the data was never hidden. It's just split.
The drop is visible in GitHub. The cause is sitting in Jira — they got moved off the interesting work three sprints ago. The context is in the review threads — someone's been crushing their PRs for months. Three exports, three tools, three people who each see one innocent-looking slice. Nobody joins the dots, because joining them requires the GitHub data and the Jira data and the review history to sit in one place where one person can see the whole curve.
That's not a dashboard feature. That's the actual argument for one board over all four trackers — Jira, GitHub, GitLab, Azure DevOps in one view. We built it for exactly this kind of question, and it's the first thing I open in a new company, before any DORA number.
The management trap
The moment you build per-engineer data, someone in the room will want a leaderboard. Don't give them one.
A ranking is the fastest way to make your quiet people quieter — it teaches everyone that the data is being used against them, and the first thing people optimize after that is visibility, not delivery. The guardrail I'd put in writing before rolling any of this out: team-level views by default, individual drill-down only when there's a reason, and the reason is always "someone needs help", never "someone's at the bottom".
The first time you show per-engineer numbers to a team, someone will ask for a ranking. Have your answer ready before that meeting, not during it.
The close
Burnout isn't a wellness metric. It's a leading indicator of delivery risk — the resignation, the handover, the three months of knowledge that walks out the door. The data to see it early has been in your trackers the whole time, waiting for someone to look at it as one picture.
We ended up open-sourcing the board we use for this. Repo: https://github.com/Codpal-Limited/deckgauge — self-hosted, so the per-engineer data never leaves your infrastructure either (if you're going to look at people's curves, the least you can do is keep them on your own server). There's a live demo at https://demo.deckgauge.com with a fictional 25-person org if you want to see what a flat curve looks like before it becomes a resignation.
I'm Yaniv — fractional CTO, ex-IronFX, now building Deckgauge in public. If this post makes you look at one person's curve today, it did its job.
Top comments (0)