Team Health is the most important KPI for dev leads. Monitor these vital signs during your iteration to identify problems early and prevent developer burnout.
Many of us in software are working longer and harder than ever before. Being at home all day, every day, is blurring the lines between work and home life. On one hand, this work from home experience is wholesome and humanizing. Seeing your boss holding a newborn or wrestling with a curious five year old during product strategy meetings adds a new perception and understanding to the workplace. Something that was often not found in the workplace. Unfortunately the same coin has another side.
As family life blends into worklife, the opposite is happening as well. It’s all too easy to get pinged on slack after dinner and say “I’ll just send that over real quick.” No one wants to be the blocker afterall. This type of always-on mentality is something that many companies are learning to combat because it is unhealthy and a leading indicator of bigger issues down the road.
Keeping the teams pulse at your fingertips is one of the necessary challenges of the team lead.
In a lot of ways the team’s pulse is something that is felt, an intuition if you will. In other ways it is something that can be measured, like work output changes. Great leaders work hard to combine their intuition with quantitative data, providing them with powerful insights into their teams.
I’m not sure I can help you feel the pulse of your team, but I can share the quantitative data I watch at a team and individual level that helps me identify unhealthy behaviors before they become larger issues.
Top Development Team Health Indicators to Watch:
- Consecutive Days Worked
- Number of Open Tasks per Team Member
- Unfocused Work
- High levels of Rework
- Number of bugs/fire drills per Iteration
- Team Members Acting Out of Character
Consecutive Days Works
At LinearB we run 2 week sprint cycles, meaning my team has 10 good working days to accomplish our sprint goals. At larger companies with hundreds of developers, seeing developers log on 11 out of the 14 days might be the norm. This includes being on-call during a sunday night merge or answering a quick slack message on a Saturday.
At smaller companies who employ only a handful of developers, all of which are all at home all day, it’s much more regular to see 12, 13, 14 days logged in per sprint. This is okay during some sprints, big launch weeks for example, but when my lead developer is working at least some of every day for multiple sprints, that is unhealthy.
Linearb retrospective view
Consecutive days worked is a leading indicator of team member health. It is the job of the team lead to step in and be the responsible people manager. It’s like putting a 7 year old to bed, they are tired, you know they are tired, but they fight it anyways. If tomorrow is going to be a good day, we need to disconnect, mentally and physically. If you see your people working consecutively, if you find yourself working consecutively, start enforcing mandatory downtime.
Number of Open Tasks Per Team Member
Work balance across development teams has gotten much better over the years. As a team lead myself, I take an active role in knowing what everyone is working on and making sure our more experienced developers aren’t taking on more than they should be.
On the LinearB development team we flag anyone who has more than six tasks open at any one time. What does the flag mean? It means I need to take some time to listen.
There may be a good reason why Oriel has 6 active branches right now, or it might mean that I haven’t provided Miki with the right priorities. Either way, knowing the number of open tasks everyone is working on allows me to open a dialogue and keep my team balanced.
To keep your team members healthy, stop using individual velocity as a KPI, focus instead on providing the right priorities and keeping the work balanced across your whole team.
Unfocused Work
Similar to having too many open tasks, team members who aren’t focusing their efforts on solving one problem before another is a leading indicator of developer burnout. If we take Oriel as the example again, we can see that he is spread across 4 different open tasks and 4 completely different areas of focus. It’s going to be hard for him to immerse himself in any of those problems if he is constantly switching contexts.
Linearb team pulse view
Another way to identify unfocused inefficient work is to look at the type of output coming from developers who are spread thin. If someone like Oriel, who is often providing several PR reviews a week, hasn’t participated in any reviews during this sprint, I can infer that his time is being taken up in other areas – meetings, support tickets, bugs, etc. While day-to-day operations like these are important, it’s also crucial to make sure your team members have enough time to block out the business and zone in on solving a single problem.
Identifying people on your team who are spread across several focus areas is an excellent way to prevent developer burnout. Help your people by communicating their priorities and asking what they need so they can focus without switching context.
High Levels of Rework
Frustration is a keen emotion felt by everyone. It often reminds me of fire. It can build up and explode. Or it can be so subtle you don’t even recognize it until it’s a bigger issue. And the best antidote for both is to identify it early and snuff it out. High levels of rework during your sprint is a leading indicator of team frustration. Frustration within your team is scary, because like fire, it can spread very quickly.
A high level of rework during your sprint is often a symptom of misalignment between product and development. It’s an age old story, product says A, development starts working, and three days later, product makes changes to the requirements. Rework due to vague or changing requirements causes frustration for whoever is trying to build the feature.
Another way to check for misalignment between product and your dev team is to look at the time between when requirements are finished and the first commit. If that is a short time span, you can infer that your team members trust the product team because the product team has provided enough context for developers to understand why something is being built.
Healthy development teams have a transparent relationship with their product manager.
Number of Bugs/fire drills per Iteration
Working on new stuff is fun. You get to explore, discover, and accomplish something different. Working on bugs, fire drills, and support tickets might be seen as less exciting, especially by younger developers. Teams who are working on bugs and support more than 80% of the time tend to get bored and envious of other teams, leading again to our fiery friend frustration.
It’s good to keep an eye on the amount of new work vs refactoring vs bugs during your team’s iteration, and at an individual level. Too much of the latter can be a symptom of much larger code quality issues or headaches that cause stress among the team. Team health is optimized when refactor, bug, and new work is balanced throughout the team.
Another way to combat a high amount of bug work is to ask your developers what else they are interested in and try to give them time throughout the sprint to explore the idea. People produce their best work when they are interested in what they are doing.
Acting Out of Character
Our final top dev team health indicator to watch is more subjective. People management is hard, and only harder now with everyone distributed. Our 2d world leaves out a lot of the context we as humans have become accustomed to when interacting with each other. But as a team leader, I have to try.
Acting out of character can take a lot of different forms, and it’s the job of the team lead to identify when it’s happening. If someone who normally speaks a lot is all of a sudden quiet during stand up, or the type of work someone usually does has changed significantly, are a couple examples I’ve seen. If you can identify a behavior change, my best advice is to engage that person directly and ask what’s up. Maybe it’s frustration, or home life, or conflict within the team. Whatever the reason, it is the team leader’s responsibility to listen, understand, and lend your resources where you can.
Tips for Mitigating Dev Team Health Risks
1. Give People Tactical Time To Explore
I like to ask my team members directly what they are interested in working on. What has been triggered in their brain lately. So other teams I know give an 8 hour allotment per sprint to each dev to work on something they are interested in. However you go about doing it, giving people some freedom to explore and discover on their own will almost assuredly make your team happier.
2. Use Tools That Track Team Vital Signs
While team leaders most assuredly keep track of their team’s health, it is always helpful to apply tools, automation, and data to provide early identifiers. LinearB plugs into your project management tool and Git repository to provide visibility into your overall sprint as well as individual team health. Tools like LinearB give team leads the early indicators they need to run a healthy team.
3. Communicate Priorities Often
Everyone knows how challenging it can be to work on a team whose priorities are vague or constantly shifting. Communicating the teams priorities throughout the sprint, not just during planning, helps team members focus on solving one problem at a time. It also helps to give individual contributors the freedom to prioritize their own time during the day (e.g. cancel meetings, schedule focused time blocks, push off weekly business discussions). Teams are healthiest when team members know exactly what they should be working on and when they’ll have time to focus. Providing clear priorities throughout the sprint is an easy way to prevent constant context switches and team frustration.
Are you ready to stop burnout?
Discover which of your devs are most at risk of burnout and how you can help improve your team health in LinearB. It’s free for dev teams up to 8. Click here to start your free account.
