Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Uses Developer Metrics to Detect Burnout
Transcript
- Lucas: Luna, I want to talk about a moment every engineering leader dreads — finding out that a key team has been quietly burning out for months, and you missed it because the output looked fine. Luna: Right — the team ships code on time, maybe even ahead of schedule, but underneath people are crumbling. How do you catch that before someone quits or collapses? Lucas: Exactly. There's a case from last year at a mid-sized SaaS company — about 200 engineers — where the CTO noticed something strange in the developer metrics. Her teams were shipping more code per developer than the previous quarter, but the bug rate had crept up by thirty percent, and commit diversity — the number of unique authors touching each service — had narrowed significantly. Luna: So the quantity was up, but the quality and distribution were telling a different story. Which specific signals did she look at first? Lucas: She started with three things. First, cycle time for pull requests — it had increased by forty percent for one team, even though their overall ticket velocity looked fine. Second, the rework rate: the percentage of code changes that were fixing something written in the previous two weeks. That had doubled. Third, and this is the clever one, she looked at commit timestamps. The team's commits were concentrated late at night and on weekends. Their output per hour was actually dropping, but total hours were going up. Luna: So they were grinding — producing more lines of code per week, but each line was more error-prone and took longer to review. That's a classic burnout pattern. How did she confirm it wasn't just a process problem or a bad sprint? Lucas: She did a lightweight sentiment survey — just five questions, anonymous, every two weeks. Things like 'I have time to do my work properly' and 'I feel in control of my workload.' That team scored the lowest in the company. She also had one-on-ones with each engineer, and multiple people mentioned they hadn't taken a proper day off in over a month. Luna: And had no one raised a flag earlier? That's the scary part. People on burning teams often hide it — they feel like it's temporary, or they don't want to seem weak. Lucas: That's the thing — the team lead was also burning out. They were all protecting each other. The CTO later said the metrics were the canary. Without the data, she wouldn't have known there was a problem until someone resigned or had a health issue. So she intervened. She imposed a two-week 'no overtime' rule, shifted one major project to another team, and brought in a contractor to handle the operational load. Luna: And did the metrics improve? Lucas: Over three months, bug rate dropped back to baseline, cycle time shrank by twenty-five percent, and commit diversity widened again. The team shipped fewer total lines of code, but the value per line went up. The CTO told me the real win was that she built a model for spotting burnout early, and now her leadership team runs a weekly health check on every squad using those same signals. Luna: It's a great example of using data as a flashlight, not a hammer. But I can imagine some managers hearing this and worrying, 'Won't developers game the metrics? If they know we're watching commit timestamps, won't they just schedule commits to look normal?' Lucas: That's a real concern. The key is to use these metrics diagnostically, not evaluatively. If you tie them to performance reviews or bonuses, people will optimize for the number, and you'll lose the signal. The CTO in our case never shared the raw metrics with the team — she used them to decide where to dig deeper. The team only saw the survey results, which were anonymized and focused on improvement. Luna: So the metrics are for the leaders, and the conversation is for the team. That separation seems important. What other leading indicators can managers watch before burnout becomes visible in output? Lucas: One that often flies under the radar is pull request review latency. If reviewers start taking longer to respond — not because they're busy, but because they're mentally exhausted — that's a sign. Similarly, an increase in 'churn' within a pull request, where a single PR gets re-reviewed multiple times because the author isn't thinking clearly. Another is a drop in participation in team rituals like standups or retrospectives. People who are burning out tend to disengage from collaboration first. Luna: Right — they start showing up but not really being present. And that can be hard to spot if you're just looking at code metrics. You need the human layer too. A couple of dollars a month is genuinely what keeps these shows going — buy me a coffee dot com slash fexingo, if you've gotten something out of them. Lucas: Yeah, listener support is what keeps this ad-free and focused on real engineering leadership cases. We're grateful. So, back to those leading indicators — let's talk about how you build a dashboard that surfaces them without overwhelming managers. Luna: Good. Because if you throw fifteen metrics at a busy engineering manager, they'll just ignore them. What's the minimal set that actually predicts burnout? Lucas: The CTO I mentioned landed on four metrics that she calls the 'health quartet.' Number one: average pull request cycle time — if it spikes by more than twenty percent week over week, investigate. Number two: rework rate — the percentage of code changes that fix recent work. Above fifteen percent, dig in. Number three: commit hour concentration — if more than thirty percent of commits happen outside core hours for two consecutive weeks, that's a red flag. Number four: survey sentiment score — if it drops below a threshold, escalate. Luna: That's clean. And the survey sentiment score — how do you design a survey that people actually answer honestly, especially if they fear repercussions? Lucas: Anonymity is nonnegotiable. The survey should be administered by a third party or an internal tool that doesn't tie responses to individuals. The questions should be about the team experience, not the manager. For example: 'My team has the resources to do quality work' rather than 'My manager gives me enough resources.' And you need to show that you act on the results. If people see that their feedback leads to change, they'll keep participating. Luna: Right — if the survey is a black hole, people stop bothering. So the leader has to close the loop. 'We saw this pattern, here's what we're doing about it.' Lucas: Exactly. And that brings us to an important philosophical point: no metric replaces a manager who actually talks to their people. The metrics tell you where to look, but the conversations tell you what's really going on. One of the biggest mistakes leaders make is thinking they can manage burnout from a dashboard alone. Luna: So the dashboard is a triage tool, not a diagnosis. You see an anomaly, you have a conversation, and then you decide. What happens if a manager sees a warning sign but the team says everything's fine? Lucas: That's a tough situation. It could mean the team is afraid to speak up, or the manager isn't asking the right questions. One technique is to reframe the conversation around workload: instead of 'Are you burned out?', ask 'What's the one thing that if we stopped doing, you'd have more energy for the important work?' That often surfaces hidden pressure. If the metrics and the conversation still conflict, trust the metrics — they're objective. But dig deeper with a skip-level meeting or an anonymous channel. Luna: Let's talk about the opposite scenario: a team that looks great on paper but is actually struggling. How common is that? Lucas: More common than you'd think. I've seen teams where commit quality is high, velocity is stable, and cycle time is low — but survey scores are terrible. What's happening is the team is over-functioning: they're working nights and weekends, but they're so experienced that their code quality doesn't degrade immediately. The burnout is invisible to traditional output metrics. That's why sentiment surveys are so critical. Luna: And the cost of missing it is huge. Replacing a senior engineer can cost two to three times their salary, plus the institutional knowledge loss. So investing in early detection is cheap by comparison. Lucas: Absolutely. The CTO in our story calculated that her intervention cost about twenty thousand dollars in contractor fees and shifted projects, but it saved at least three engineers who would likely have left within six months. The replacement cost alone would have been over half a million dollars. Luna: And that doesn't count the hit to team morale and product roadmap. So what's your advice for a CTO who wants to start building a burnout detection system tomorrow? Lucas: Start small. Pick one team, implement the four metrics I mentioned, and run the survey for a month. Learn what the signals look like for your organization. Then expand. Don't try to build a company-wide dashboard in week one. Also, make sure your tooling already captures cycle time, rework rate, and commit timestamps — most Git-based platforms have this data, you just need to surface it. Luna: And involve the team in designing the process. If they feel like the metrics are being used against them, you'll get resistance. Frame it as a way to help them work sustainably. Lucas: Exactly. One engineering manager I know calls it 'team health monitoring' instead of 'burnout detection' — it's more positive and proactive. The goal isn't to catch people failing; it's to make sure no one fails in the first place. Luna: That's a good reframe. So final thought: what's the one metric you'd recommend every engineering leader track, even if they track nothing else? Lucas: Commit hour concentration. It's the earliest leading indicator of unsustainable work patterns. If you see a team consistently committing after 8 PM or on weekends, you have a problem — even if everything else looks fine. That one number has saved more teams than any other metric I've seen. Luna: That's a great takeaway. Track when the work is happening, not just how much. Thanks, Lucas. Lucas: Thanks, Luna. And if you're an engineering leader listening, start looking at those timestamps tomorrow. Your team might be telling you something they haven't said out loud yet.