How to measure teams’ performance & success?
I find discussions about measuring anything in a working environment so difficult and often counterproductive that I decided to sum up some of my thoughts and learnings.
Hope you’ll find this article helpful if you’re dealing with this topic too — either setting up new goals with your team/company or changing existing ones as they’re not useful to you.
Performance doesn’t mean success.
My main take away from the years is to focus on measuring outcome over output. Might seem obvious but oh god how many times have I dealt with situations like — Let’s measure how many lines of code does each programmer write, the analysis produced, tasks moved to done, meetings conducted, hours spent at work, story points/man-days delivered. And my guess is you spotted these too, or maybe proposed such metrics in your teams. Let’s talk about why it’s a bad idea to measure output and what metrics could bring better value to your environment.
Let’s start with what you want to achieve by measuring something — you likely want that metric to improve and for that, make decisions based on these metrics to help your company grow.
Imagine a situation where your metric is lines of code produced (traditional anti-pattern but trust me, still existing). Probably, what will happen is, that your developers will focus on how many lines they wrote, and when implementing a new feature the thoughts will be on how many lines should it have. And now tell what value to the company and customers will such thoughts bring. If you intend to keep your teams busy with non-valuable work, this might help, but mostly, we want to create something useful, something people like, and the company makes a profit from it. So let’s make a few examples of what metrics can help you focus on the important:
Outcomes create successful teams.
First of all, focus on the outcomes — what does the company want to achieve, how can the team help, and what added value they create for the customer? Metrics will deeply depend on the industry you’re in but the characteristics should be the same:
- helping to progress towards company goals — company OKRs, KPIs, strategic bets
- customer focus (internal or external) — net promoter score (NPS), customer feedback, retention, active base
- team focus — ability to sustain, learn, innovate and grow
- teams happiness — employee NPS, employee retention
Focusing on such goals will help you being busy with the right things, delivering value and thus satisfying your customer and motivating your team.
Here is an example of well-defined team goal:
- 1 million daily active users in our app (company goal)
- 4.8 app store rating (company goal, customer focus)
- NPS 87 (company goal, customer focus)
- the average score of 3.9 on a teams skills matrix (team focus — learning)
- feature lead time under 5 days (team focus — sustainability)
- employee NPS 90 (team happiness)
- 1 team improvement implemented per month (team focus — innovation)
If it’s the teams’ metric, let the team create it.
Setting the metrics on your own might be super easy but the question is if anybody will be interested in working on them. Take some extra time with your team and come up with the metrics together, as a team and decide where to put your focus.
Also, think beyond your team’s borders. You probably need more teams in your company to achieve your goals. The best outcomes come when teams are collaborating, not competing with each other over different goals. Try to involve teams and stakeholders you work the most with and create common metrics.
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Agile manifesto
Nice number, and what’s next?
Now after having a set of metrics you want to measure the key part is to make them visible, review and take action regularly, otherwise you’ll end up with a bunch of useless numbers. Create an online/offline dashboard and decide what team session will be dedicated to the metrics review and discussion. For the session to be effective, agree on who will be responsible for the correctness of the data and will have a better insight into what caused movements (IMO this shouldn’t be one person but rather the team should split responsibility for the updates).
The key to making any metric useful is to make decisions based on it. Constantly inspect and adapt. Learn what works and what doesn’t. Be consistent in your review & action routine and team involvement and I’m sure this will bring a positive impact on your environment.