You may have inadvertently discovered a metric for measuring apathy. Here's a thought: since engineers are analytically minded, any system designed to measure our performance is going to analysed and mitigated. When management started using #failing regtests to beat engineers over the head, guess what - tests that are known to fail get removed from the weekly run. The hilarious end-state in my workplace is that due to compute farm time-cost metrics, this has also become official enough to be automated in the infrastructure that runs the tests.
Even though your objective is actually to look after the well-being of your team, the data-gathering may be sending a message of "here's another manager who will use incomplete data to make decisions that increase process and adversely affect my job satisfaction".
Overall - and yes this is an engineer's perspective - it is more helpful if team members have the freedom to be completely open with you in conversation, and young engineers are actively encouraged to be open like this. Questions like looming burnout can be addressed indirectly by asking about activities outside work ("did anything fun last weekend?").
That does place a burden on you the manager, to amass and filter circumstantial evidence, but I think team leadership works best when based on large amounts of low quality info, than systematic gathering & analysis of data that are incomplete or liable to manipulation.
But... at the end the day an engineer like me is expecting my manager to develop people skills so that I don't have to!
"Metric for measuring apathy" is a better title than mine. I might steal that.
Two things. I'm not using health checks to evaluate performance. I'm using them to detect when someone is drowning before they quit. If the system reads "everything is fine" while someone is burning out, it failed its only purpose.
Your point about informal conversation over formal data is what I did for years. It works until you have 10+ people across three time zones. You physically can't have a real conversation with everyone every week. Once a month if you're lucky. The forms exist because the conversations don't scale.
And your last line is my entire article in one sentence. "I'm expecting my manager to develop people skills so that I don't have to." Writing a real number into a form instead of zero is not a people skill. It's a two-second decision most people refuse to make.
You have a big challenge there! You have probably been through this mill youeself, but one of the moving parts of looming bunrout is a sense of shame that one cannot keep on delivering at the current level. If there’s a normal rhythm to the development cycle, i.e. a delivery crunch followed by decompression while figuring out what to do in the next phase of the project, that risk doesn’t turn into burnout. My own experience of early burnout was a desire to keep on pushing, to get to the decompression phase. During these times I would absolutely “mask” and not admit to losing energy. Why whinge when relief is just around the corner? Thinking back to your article, perhaps you can observe masking in the form of super-consistent numbers or numbers that don’t reflect the current level of project pressure.
The masking point is sharp. "Why whinge when relief is just around the corner" explains my data better than I did. That's exactly what super-consistent numbers look like: 20 out of 21 weeks of "normal week" from someone whose stress field says otherwise. Not laziness, not apathy. Just someone pushing through because admitting they're struggling feels like admitting they can't handle the job.
That makes it harder to detect, not easier. At least apathy has a pattern you can spot. Masking looks identical to actually being fine.
Another thing about burnout is the way it creeps up on one gradually, then all at once. So it's possible that week by week the descent into burnout doesn't feel much different - "normal" is being redefined. However it may be that more ups and downs in an individual's reported sense of well-being indicates a healthy mental state... because really there are good weeks, and bad weeks, and good-bad weeks. But if your data are flatlined from day 1 then even checking fo "healthy noise" won't help.
Five questions once a week. Two minutes. That's what I'm asking from the rank and file. If that's exhausting, we have a different problem.
"They didn't see it actioned correctly" is fair and I addressed it in the article. But the reverse is also true: if people stop reporting because they didn't see results in three weeks, they're confusing "I haven't seen the change" with "nobody listened." Sometimes the fix takes months. Sometimes it's already in motion and they don't know. Silence guarantees nothing changes. The form at least gives it a chance.
There is a big difference between informal and formal communication.
Say a dev tells you "Tyson is being a dick" in a 1:1. You can have a casual chat about it and from the devs perspective it is ephemeral and they aren't responsible for anything.
If they deliver that to you in writing it is a completely different story. They will want to make sure they add all the context. They will feel responsible for actions you take. They will worry that in the future their statements will be taken out of context. They will worry about their feedback getting straight back to Tyson.
So when putting something in a formal system the average dev will be trying to weigh up all of these tradeoffs.
Here's the actual form. Nine questions. "How many hours of meetings did you have this week." "How many context switches occurred." "What is your sprint completion rate." These are numbers about your own week. There's no "Tyson is being a dick" in this form. No interpersonal risk. No statements that can be taken out of context. Just: how many hours, how many switches, how much fuel left in the tank. That's what people fill with identical answers for 18 straight weeks.
Four weeks of health checks plus PM and product feedback give me a foundation for a real 1:1. And in that 1:1, face to face, the engineer can absolutely tell me that Tyson is being a dick. That's what the conversation is for. The form collects the data. The 1:1 handles the human part.
I'm glad a colleague sent this one along for me to read. Your framing of complaining as a closed loop and logging as an open ticket is one of the cleaner distinctions I've read on this dynamic.
For me, it's about the neuroscience underneath it. When someone vents in a team meeting, three chemicals light up quickly: dopamine from the validation and recognition in the room, cortisol released as stress exits their system, and oxytocin from the social bonding that comes from sharing frustration. That's a powerful cocktail. Logging a number into a scorecard offers none of that. No reward, no release, no connection. Just an open ticket and "deferred accountability".
So the gap or the problem you're describing is really three-fold: 1) a courage problem; 2) a culture problem, and 3) a design problem. The verbal channel is neurologically rewarding right now. The written channel? Well, that just asks people to delay gratification for an outcome they may not trust will come.
The culture piece you raised near the end is where I think the real work lives, and one in which systems do not create it. Leaders who understand why the meeting feels good can start designing environments where the documentation feels worth it, too.
The neuroscience framing is sharp, and I genuinely hadn't thought about the dopamine angle. But I want to push back on the conclusion. "Leaders should design environments where documentation feels worth it" puts the responsibility back on the manager. That's the same pattern I'm describing in the article. Everyone agrees something should change. Everyone points at someone else to change it.
Writing a number into a form doesn't need to feel rewarding. It needs to feel like your job. The two-second decision to log a real number instead of zero isn't a design problem or a dopamine problem. It's an adult choosing accountability over comfort. I don't think I need to compete with the dopamine hit of venting. I think I need people who do the right thing even when it doesn't feel good.
Also sewage (and company culture) always roll downhill. Fought many battles to turn around an apathatic team with the mindset you described perfectly, only to find senior management are locked in their ways, and created the culture, pushing the team to apathy in order to protecti themselves, and survive without burnout.
I've also seen senior management take those anonymous metrics and feedback, that aren't anonymous, and then make plans to remove the vocal people who were encouraged to pluck up the courage and be vocal.
Being open honest has a very high cost both at work and socially. The Black Box Thinking book describes and compares it perfectly between the Aerospace and US Medical industries.
Don't chain humans to machine systems. Chain machine systems to humans. Turn off that survey everyone lies on. Keep the meeting where everyone talks openly. Have an AI note taker like fathom listen in and summarize the complaints. Use another automated tool to count the complaints in each week's meeting minutes. Tell people why youre doing that change. Basically just let the computers serve humanity rather than the reverse.
Interesting idea but it breaks the one channel that still works. People talk openly in meetings precisely because it's verbal and disappears. The moment they know an AI is transcribing and counting their complaints, they'll stop complaining there too. Now you have zero honest channels instead of one.
The problem isn't capturing the data. The problem is that people treat verbal and written differently on purpose. Automating the conversion doesn't fix that. It just makes people stop talking.
I recognize a lot of what you say. And I think many companies suffer from it. But it doesn't have to be that way. It is like trying to live a healthy life. It requires discipline, resilience and perseverance. There is no free lunch, no easy way. Although there is an easier way. Once you get the hang of it, it will get easier. As long as you can maintain the discipline. And if you are smart, you feed the energy of the eventual success into that discipline. Once you reach a sustainable flow, your chances of reaching great success will absolutely increase. This is also about leadership. If you put in the effort show the results, be an example, hold yourself accountable, people will respect you holding them accountable. What is also very important is core values and how those influence your hiring approach. Make sure you find your companies core values. They are not what the CEO suggests, they are the average positive values shared by every single employee.
I once worked for a company who relentlessly managed their core values. By surveying their employees, what they thought were the core values. By encouraging everybody to act according those values, by asking what was wrong, by communicating improvements. By hiring people that were aligned with those core values. Over time, the company begins to literally breathe those core values. In management meeting quotes would be explicitly matches against core values. Anyway this was the only 3000+ company I ever worked for that exercised this approach diligently and successfully. And it has always been an inspiration. For me as a manager. And I try to live by it. And if the board of my company does not practice their own values, I should not work there. But we do not always have that choice, but it is healthy to always try to have that baseline
Back to the topic at hand: core values, you cannot make that change from one day to the other, you have to build and it start with leadership. But once they are convinced and want to live and work accordingly. It is possible. Never said it was easy, if it were, we'd all do it. Know however that it is precisely that fact that offers you a possibility to stand out. Because not everybody has the discipline, will or proper context to pull it off. But if you manage, it can be highly fulfilling.
Because the job changed. Five years ago a good engineer could get away with just being a good engineer. Write code, ship features, go home. In 2026 you're reviewing AI-generated code you didn't write, catching mistakes a machine made confidently, and explaining to a PM why the "working" prototype will collapse in production. Pushback, feedback, and communication aren't soft skills anymore. They're the job. If you can't write a real number into a form or tell a colleague directly that their task spec is unclear, you're not doing the job. Not the 2026 version of it.
That's not what I said. I'm not trying to make it work for the average dev. I'm trying to push the average dev to be slightly better than average, one week at a time. If out of 10-15 people, 2 or 3 start owning their environment, that changes the dynamic for the entire team. Those 2-3 set the standard. The rest follow or at least stop actively resisting. That's not a system design problem. That's patience and repetition. Water wears down stone.
Standups, at least in my experience, are nearly useless. My CEO, who had a software background, forced me to have daily standups with my accounting team.
One sweet young woman one day said: ALL I DO EVERY DAY IS ENTER PAYABLES! I WILL NOT EVER HAVE ANYTHING NEW TO SAY!,
I found it worked better when I kept an open door, collected questions or comments or complaints, and let the team address specifics once a week. They became part of the solution, and without going on the record as complaining.
Daily standups for an accounting team is a different problem. That's a software CEO forcing engineering rituals on a department where they don't fit. The payables story proves it. Weekly health checks aren't standups though. They're not about status updates. They're about catching someone drowning before they go silent.
You may have inadvertently discovered a metric for measuring apathy. Here's a thought: since engineers are analytically minded, any system designed to measure our performance is going to analysed and mitigated. When management started using #failing regtests to beat engineers over the head, guess what - tests that are known to fail get removed from the weekly run. The hilarious end-state in my workplace is that due to compute farm time-cost metrics, this has also become official enough to be automated in the infrastructure that runs the tests.
Even though your objective is actually to look after the well-being of your team, the data-gathering may be sending a message of "here's another manager who will use incomplete data to make decisions that increase process and adversely affect my job satisfaction".
Overall - and yes this is an engineer's perspective - it is more helpful if team members have the freedom to be completely open with you in conversation, and young engineers are actively encouraged to be open like this. Questions like looming burnout can be addressed indirectly by asking about activities outside work ("did anything fun last weekend?").
That does place a burden on you the manager, to amass and filter circumstantial evidence, but I think team leadership works best when based on large amounts of low quality info, than systematic gathering & analysis of data that are incomplete or liable to manipulation.
But... at the end the day an engineer like me is expecting my manager to develop people skills so that I don't have to!
"Metric for measuring apathy" is a better title than mine. I might steal that.
Two things. I'm not using health checks to evaluate performance. I'm using them to detect when someone is drowning before they quit. If the system reads "everything is fine" while someone is burning out, it failed its only purpose.
Your point about informal conversation over formal data is what I did for years. It works until you have 10+ people across three time zones. You physically can't have a real conversation with everyone every week. Once a month if you're lucky. The forms exist because the conversations don't scale.
And your last line is my entire article in one sentence. "I'm expecting my manager to develop people skills so that I don't have to." Writing a real number into a form instead of zero is not a people skill. It's a two-second decision most people refuse to make.
You have a big challenge there! You have probably been through this mill youeself, but one of the moving parts of looming bunrout is a sense of shame that one cannot keep on delivering at the current level. If there’s a normal rhythm to the development cycle, i.e. a delivery crunch followed by decompression while figuring out what to do in the next phase of the project, that risk doesn’t turn into burnout. My own experience of early burnout was a desire to keep on pushing, to get to the decompression phase. During these times I would absolutely “mask” and not admit to losing energy. Why whinge when relief is just around the corner? Thinking back to your article, perhaps you can observe masking in the form of super-consistent numbers or numbers that don’t reflect the current level of project pressure.
The masking point is sharp. "Why whinge when relief is just around the corner" explains my data better than I did. That's exactly what super-consistent numbers look like: 20 out of 21 weeks of "normal week" from someone whose stress field says otherwise. Not laziness, not apathy. Just someone pushing through because admitting they're struggling feels like admitting they can't handle the job.
That makes it harder to detect, not easier. At least apathy has a pattern you can spot. Masking looks identical to actually being fine.
Another thing about burnout is the way it creeps up on one gradually, then all at once. So it's possible that week by week the descent into burnout doesn't feel much different - "normal" is being redefined. However it may be that more ups and downs in an individual's reported sense of well-being indicates a healthy mental state... because really there are good weeks, and bad weeks, and good-bad weeks. But if your data are flatlined from day 1 then even checking fo "healthy noise" won't help.
> It's a two-second decision most people refuse to make.
As a leader you fundamentally misunderstand what you are asking from the rank and file.
We used something similar (teammood) for a while and the devs found it exhausting. Even more so when they didn't see it actioned correctly.
Five questions once a week. Two minutes. That's what I'm asking from the rank and file. If that's exhausting, we have a different problem.
"They didn't see it actioned correctly" is fair and I addressed it in the article. But the reverse is also true: if people stop reporting because they didn't see results in three weeks, they're confusing "I haven't seen the change" with "nobody listened." Sometimes the fix takes months. Sometimes it's already in motion and they don't know. Silence guarantees nothing changes. The form at least gives it a chance.
Is it ever just two minutes?
There is a big difference between informal and formal communication.
Say a dev tells you "Tyson is being a dick" in a 1:1. You can have a casual chat about it and from the devs perspective it is ephemeral and they aren't responsible for anything.
If they deliver that to you in writing it is a completely different story. They will want to make sure they add all the context. They will feel responsible for actions you take. They will worry that in the future their statements will be taken out of context. They will worry about their feedback getting straight back to Tyson.
So when putting something in a formal system the average dev will be trying to weigh up all of these tradeoffs.
Here's the actual form. Nine questions. "How many hours of meetings did you have this week." "How many context switches occurred." "What is your sprint completion rate." These are numbers about your own week. There's no "Tyson is being a dick" in this form. No interpersonal risk. No statements that can be taken out of context. Just: how many hours, how many switches, how much fuel left in the tank. That's what people fill with identical answers for 18 straight weeks.
Four weeks of health checks plus PM and product feedback give me a foundation for a real 1:1. And in that 1:1, face to face, the engineer can absolutely tell me that Tyson is being a dick. That's what the conversation is for. The form collects the data. The 1:1 handles the human part.
I'm glad a colleague sent this one along for me to read. Your framing of complaining as a closed loop and logging as an open ticket is one of the cleaner distinctions I've read on this dynamic.
For me, it's about the neuroscience underneath it. When someone vents in a team meeting, three chemicals light up quickly: dopamine from the validation and recognition in the room, cortisol released as stress exits their system, and oxytocin from the social bonding that comes from sharing frustration. That's a powerful cocktail. Logging a number into a scorecard offers none of that. No reward, no release, no connection. Just an open ticket and "deferred accountability".
So the gap or the problem you're describing is really three-fold: 1) a courage problem; 2) a culture problem, and 3) a design problem. The verbal channel is neurologically rewarding right now. The written channel? Well, that just asks people to delay gratification for an outcome they may not trust will come.
The culture piece you raised near the end is where I think the real work lives, and one in which systems do not create it. Leaders who understand why the meeting feels good can start designing environments where the documentation feels worth it, too.
Great piece. Genuinely.
The neuroscience framing is sharp, and I genuinely hadn't thought about the dopamine angle. But I want to push back on the conclusion. "Leaders should design environments where documentation feels worth it" puts the responsibility back on the manager. That's the same pattern I'm describing in the article. Everyone agrees something should change. Everyone points at someone else to change it.
Writing a number into a form doesn't need to feel rewarding. It needs to feel like your job. The two-second decision to log a real number instead of zero isn't a design problem or a dopamine problem. It's an adult choosing accountability over comfort. I don't think I need to compete with the dopamine hit of venting. I think I need people who do the right thing even when it doesn't feel good.
Love it. I agree. Keep up the great leadership content!
Apathy breeds apathy.
Also sewage (and company culture) always roll downhill. Fought many battles to turn around an apathatic team with the mindset you described perfectly, only to find senior management are locked in their ways, and created the culture, pushing the team to apathy in order to protecti themselves, and survive without burnout.
I've also seen senior management take those anonymous metrics and feedback, that aren't anonymous, and then make plans to remove the vocal people who were encouraged to pluck up the courage and be vocal.
Being open honest has a very high cost both at work and socially. The Black Box Thinking book describes and compares it perfectly between the Aerospace and US Medical industries.
As I said I am too stubborn to give up
Don't chain humans to machine systems. Chain machine systems to humans. Turn off that survey everyone lies on. Keep the meeting where everyone talks openly. Have an AI note taker like fathom listen in and summarize the complaints. Use another automated tool to count the complaints in each week's meeting minutes. Tell people why youre doing that change. Basically just let the computers serve humanity rather than the reverse.
Interesting idea but it breaks the one channel that still works. People talk openly in meetings precisely because it's verbal and disappears. The moment they know an AI is transcribing and counting their complaints, they'll stop complaining there too. Now you have zero honest channels instead of one.
The problem isn't capturing the data. The problem is that people treat verbal and written differently on purpose. Automating the conversion doesn't fix that. It just makes people stop talking.
Completely fair.
I recognize a lot of what you say. And I think many companies suffer from it. But it doesn't have to be that way. It is like trying to live a healthy life. It requires discipline, resilience and perseverance. There is no free lunch, no easy way. Although there is an easier way. Once you get the hang of it, it will get easier. As long as you can maintain the discipline. And if you are smart, you feed the energy of the eventual success into that discipline. Once you reach a sustainable flow, your chances of reaching great success will absolutely increase. This is also about leadership. If you put in the effort show the results, be an example, hold yourself accountable, people will respect you holding them accountable. What is also very important is core values and how those influence your hiring approach. Make sure you find your companies core values. They are not what the CEO suggests, they are the average positive values shared by every single employee.
I once worked for a company who relentlessly managed their core values. By surveying their employees, what they thought were the core values. By encouraging everybody to act according those values, by asking what was wrong, by communicating improvements. By hiring people that were aligned with those core values. Over time, the company begins to literally breathe those core values. In management meeting quotes would be explicitly matches against core values. Anyway this was the only 3000+ company I ever worked for that exercised this approach diligently and successfully. And it has always been an inspiration. For me as a manager. And I try to live by it. And if the board of my company does not practice their own values, I should not work there. But we do not always have that choice, but it is healthy to always try to have that baseline
Back to the topic at hand: core values, you cannot make that change from one day to the other, you have to build and it start with leadership. But once they are convinced and want to live and work accordingly. It is possible. Never said it was easy, if it were, we'd all do it. Know however that it is precisely that fact that offers you a possibility to stand out. Because not everybody has the discipline, will or proper context to pull it off. But if you manage, it can be highly fulfilling.
Appreciate your thoughts! Will try to do my best
Honest feedback causes trouble.
> This is a leadership problem at the individual level. Not management leadership.
Most people are not leaders and will never be leaders. Expecting them to be leaders is a management problem.
So why have you setup the system to work this way?
Because the job changed. Five years ago a good engineer could get away with just being a good engineer. Write code, ship features, go home. In 2026 you're reviewing AI-generated code you didn't write, catching mistakes a machine made confidently, and explaining to a PM why the "working" prototype will collapse in production. Pushback, feedback, and communication aren't soft skills anymore. They're the job. If you can't write a real number into a form or tell a colleague directly that their task spec is unclear, you're not doing the job. Not the 2026 version of it.
I'm reading your response as basically "I don't know how to set it up so it works for the average dev".
And that's ok - we are going through a rapid change in the way we work.
Maybe 90% will be left behind but more likely we will figure out new workflows etc to make it work for the average dev.
That's not what I said. I'm not trying to make it work for the average dev. I'm trying to push the average dev to be slightly better than average, one week at a time. If out of 10-15 people, 2 or 3 start owning their environment, that changes the dynamic for the entire team. Those 2-3 set the standard. The rest follow or at least stop actively resisting. That's not a system design problem. That's patience and repetition. Water wears down stone.
Standups, at least in my experience, are nearly useless. My CEO, who had a software background, forced me to have daily standups with my accounting team.
One sweet young woman one day said: ALL I DO EVERY DAY IS ENTER PAYABLES! I WILL NOT EVER HAVE ANYTHING NEW TO SAY!,
I found it worked better when I kept an open door, collected questions or comments or complaints, and let the team address specifics once a week. They became part of the solution, and without going on the record as complaining.
Daily standups for an accounting team is a different problem. That's a software CEO forcing engineering rituals on a department where they don't fit. The payables story proves it. Weekly health checks aren't standups though. They're not about status updates. They're about catching someone drowning before they go silent.