⚠️ 5 Signs Your Software Development Team Is Struggling

To effectively operate as a Tech Leader is to work in an ultra-competitive environment, where one's ability to ship products relies heavily on building and retaining a motivated and productive software development team. However, high business demands can stretch engineering teams thin and push them into a crisis state before you even notice warning signs.

‍

So what are the early warning signs to look out for that indicate that your software teams are struggling? I posed this question to Fractional Chief Technology Officer, Sven Poppelmann, here are his thoughts:

‍

Increase in bugs

An uptick in the rate of bugs in your software may be indicative that the team is rushing or cutting corners and may be feeling under pressure to deliver.

‍

Is throughput slowing?

Is it taking longer to approve pull requests? This may again be indicative that something in the team’s ways of working has changed and might need a bit of digging or investigating.

‍

Poor communication

Noticing when a team or its members are unusually quiet, or when they communicate in uncharacteristic ways may be a signal that the team isn't collaborating effectively.

‍

Working late

Consistent upticks in overtime hours can be a sign of unrealistic deadlines or underestimation of tasks and a trigger to investigate further.

‍

Absenteeism and churn

If members of a team start calling in sick more regularly, or in the most extreme cases, a spate of sudden resignations occurs, this is a strong indicator and it’s almost too late to do anything other than panic.

‍

None of these factors tell the full story of why the team might be struggling, but they can act as an early-warning system to start having some conversations. It is important to lead with genuine curiosity rather than weaponising things like metrics and unfairly pressuring engineers with them.

‍

Of course, whilst all of these are great indicators that something may be wrong, there is nothing that beats the power of regular feedback or one-to-ones with your team. I also like to measure team pulse weekly by having engineers self-report an “eNPS” score during check-ins with their managers (using a typical NPS 1-10 scale, 1-6 are detractors, 7-8 passives, and 9-10 promoters). 

‍

My engineers also report what might improve their score by +1 point. Aggregating these into rolling 6-week scores gives me sight of trends across the whole department and also irons out spiky weeks, whilst the score+1 report gives managers something specific and tangible to work on solving with the engineer during that week.

‍

Do you resonate with Sven’s points? What early signals do you watch for to know when to shift course? I welcome perspectives from Tech Leaders who have or are facing similar challenges.