I suggest there are only three measures leaders should examine when considering a team’s effectiveness. However, read to the end to understand the dangers of measuring team effectiveness.
- The team’s track record of delivering outcomes that addresses user/client/stakeholder needs. This is the ultimate arbiter of team effectiveness. Emphasis: Building the right thing
- The typical time it takes for the team to start working towards an outcome, to the point the outcome has been achieved. In other words the cycle-time. Emphasis: Building the thing fast
- Particularly if it’s a software team, their level of tech debt. This allows leaders to understand the team’s ability to maintain service and deliver further business outcomes. Emphasis: Building the thing right
Considering any more measurements will run the risk that leaders get blinded by proxy information, and risks them misjudging the team.
Of course, the team are at liberty to consider other information. However, this should just be for the team to interpret and make use of.
Even these three measures could lead to misjudgement. Therefore I suggest leaders spend time with the team to understand the insights and stories behind these measures, and be aware of how such measures can be misinterpreted.
Trading-off the emphasises
There’s a trade-off between the emphasises of building the right outcome, building it fast, and building the thing right. Leaders should work closely with the team to ensure these trade-offs are appropriately balanced.
The balance should reflect the current and future state of product/service/process development.
…..conversations and co-creation are better than managing by measurements
Consider what Einstein is attributed to have said:
Not everything that can be counted counts and not everything that counts can be counted
If leaders only use measurements to judge a team’s effectiveness, there’s a temptation to manage the team indirectly. There’s also a dangerous possibility of misjudging the team.
Ideally, the managers should create a structure and set of processes which allows leaders to have meaningful conversations with the team. Leaders should involve themselves with the team to co-create and co-discover the best outcomes for their customers/clients/stakeholders.
Such an environment will outcompete any alternative where the leaders manage indirectly, provide little direct support and manage by measurements alone.
If measurements are being considered, leaders and the team should discuss and agree on the intention behind for measurements. It’s likely unintended behaviours and incentives will emerge, so with the team, measurements and its impact should be reviewed periodically.
When it an outcome achieved?
Agendashift’s Definitions of Done helps teams focus, and gain support from their leaders, to deliver genuine business outcomes.
An outcome is not achieved if it’s at a stage before users/clients/stakeholders are demonstrably benefiting from it.
Further reading and thanks
- Henrik Kniberg’s Agile Product Ownership in a Nutshell – [15-minute video]
- Agendashift’s (Mike Burrows) Definitions of Done
- Thank you to Simon Powers for helping me improve this article
Feedback is welcome.