Where I’d start
Look at whether useful changes reach customers, how reliably the software works and whether the team can keep improving it. Talk through real examples with the people doing the work before drawing conclusions about their performance.
- Agree what good work looks like in your business.
- Use measures to help you ask better questions about what’s happening.
Start with something a customer can use
Choose a few recent changes and ask who uses them. What problem were they meant to solve? Has anyone checked whether they helped? Sometimes the team builds exactly what was requested and the business still gets little value. That deserves a conversation about how work is chosen.
Include some work customers may never see directly. Improving recovery from failures or making a painful release process safer can be valuable. Ask the team to explain the problem and what has improved, in terms you can both understand.
Look at what happens after release
Ask about recent problems in production. How were they spotted? What did customers experience, and what did the team change afterwards? You’re looking for evidence that people can respond and learn.
Notice the effect on the next piece of work too. If every release produces days of repairs, the team may have very little uninterrupted time left. Discuss whether investing in tests or simplifying a fragile part of the system would help.
Understand the conditions people are working in
Ask developers what repeatedly gets in their way. Listen for unclear requests, priorities that change halfway through, slow decisions and knowledge held by one person. Check those accounts against recent examples.
Your own choices matter here. A developer waiting for a commercial decision can appear slow on a report. Someone quietly helping colleagues may close fewer tickets while making the whole team more effective.
If there’s a concern about an individual, discuss it privately with their manager, using specific examples and clear expectations. A dashboard alone gives you very little of the context needed for that conversation.
Use a small amount of evidence you understand
Useful questions include how long work waits, how often a release needs repair and whether customers use what was built. Keep definitions consistent so you can compare the team’s own work over time.
Ticket counts and lines of code can change simply because someone splits tasks differently or chooses a shorter solution. Ask what a number tells you and what it leaves out before using it to judge performance.
The SPACE research on developer productivity describes why several perspectives are needed, including satisfaction and collaboration. It’s useful background for the conversation. You can start with a few concrete examples before deciding which measures are worth maintaining.
Agree one improvement together
Choose a problem the team recognises and decide what you’ll try. That could mean fewer simultaneous priorities, faster access to a decision-maker or time to improve a troublesome release step.
Agree when you’ll look at it again and what would count as progress. Include quality and workload in that conversation. Faster delivery that leaves people exhausted or customers dealing with more failures needs another look.
If the team still struggles after the working conditions improve, examine whether you have the skills and leadership the work requires. Be specific about the gap before deciding whether to coach, hire or bring in outside help.