As an engineering leader, I have experience in introducing the idea of implementing metrics to my software teams. Quite often, it is met with a groan and reluctance, followed by a conversation about how it just "isn't going to be useful for us".
Having talked with engineering leaders from software companies of all different sizes, I have noticed the management team are often the ones who define what parts of the software development process are being measured. These leaders know they should be measuring something, but are not necessarily sure what that thing should be and what would be most effective.
I have been in this situation myself - you listen to what has been working for other companies, because surely the same metrics would be useful in our environment. This can be problematic, and I empathise with engineers as to why they greet metrics with such suspicion.
What I am talking about in this article is how we can change our approach as engineering leaders, and break away from the top down leadership style. I like to refer to this approach as 'empathy driven metrics', because the definition of empathy is 'having the ability to understand the needs of others'. However it is ultimately a way of using metrics effectively and empowering teams to improve themselves.
This approach is less about finding the most useful metric for us as a leadership team, but more about supporting your teams in their quest for what is the most important measurement for them - empowering teams to own their own insights and use them for the benefit of tracking what matters to them in the present. Allowing teams to drive change for themselves, to have conversations when problems arise and to encourage proactive improvement to process.
Transparency, always.
It is worth mentioning at this stage that any process change or metric adoption should be approached with complete transparency. This is our first empathetic approach. Understanding that introducing metrics to an engineering team may cause suspicion and being able to find an effective way of doing this comes with its challenges.
We understand from Paloma Medina's BICEPS model - that one of our core needs in the workplace is predictability. Our peers and employees seek consistency in the work environment, and to maintain consistency it is an effective idea to communicate early any changes that are going to be made to the working environment, in this case the introduction of engineering metrics.
As leaders we have a responsibility to share exactly why and how we are going to be implementing a new process, and to give our teams the opportunity to digest the change as well as leave feedback and share their thoughts. The 'why' is crucial to get right, and we should be asking ourselves this. Why are we introducing metrics? What do I, as a senior staff of engineering, hope to get from these metrics?
Writing a public proposal can be a fantastic way of sharing this news so it is less of a surprise to the teams it involves. Allowing comments and feedback at this stage gives people the permission to feel as though they are also part of the process and that they have been able to raise any concerns they may have at this point. It undeniably allows the construction of a better process, because your teams are behind it, curating it and driving it forward.
What to measure?
The debate on 'what metrics should we be measuring' is an old one in software engineering companies, but it is often an argument over the wrong question. It simply doesn't make sense to be measuring something unless you know why you are measuring it!
We need to stop viewing the perfect metric as something that exists out there to be discovered, and once uncovered it will gift you +10 productivity and +15 efficiency. The perfect metric is the one (or several) that your team needs at any given time and the one that makes most sense in the present. The couple of indicators that work wonders for a team one quarter, might be (and should be if improvements have been made) absolutely irrelevant the next.
Back at the start of the article, I mentioned that teams should be the owners of their metrics and therefore they should provide the reasoning for what they want to be improving and measuring. We pass the responsibility on to the people we are part of our teams. This is our second empathetic approach.
Maybe your team wants to focus on quick experimentation to validate the best market fit, but want to ensure they are delivering value to customers at a quick enough pace - a release frequency indicator would be the most useful metric in this scenario.
Another team could want to focus on ensuring that their pull requests are prompt and small, because as a collective team they decided this was an area that could be improved. Small pull requests ultimately mean that there is greater ability to mitigate an issue quickly if it were present in production, which in turn means less risk. The various metrics that shine insight upon pull request size and frequency would give the team a clearer understanding as to where the hold ups are.
It makes perfect sense in this case, to allow your teams access and ownership to a metric dashboard, where they can visualise and choose from insights taken from right across your development process, from planning to release. Whether the metrics are taken from the start of the cycle - understanding the average time between a developers first commit the opening of an associated Pull Request, for instance - or the end a cycle, like gaining insight over the length of the deployment process. Having a range of metrics allows teams to pick the areas that matter most to them.
It could be the case that after one iteration the team discovers that they are performing better than they had previously discovered and they can re-examine and look to improve another area. Allowing your teams and team leads to be the ones to say what they want measuring, and empowering them to control and view these metrics is effective. Not only because they have the day to day context that management don't, but it allows them to improve autonomously without leadership intervention and therefore improve quicker.
How our teams come up with these areas of improvement is ultimately down to them. Whether it be through a retrospective, health check or another ritual - each is equally as effective as surfacing potential focus points. These metrics should enable your team to have healthy discussions about blockers as well as learning and improvement.
Conclusion: Empowering Teams
Building a metric driven culture, by empowering teams to own their own problems and be in charge of their own improvement, is a much more scalable, simple and effective way of introducing and working with metrics than a top down approach.
As engineering leaders, we often don't have the clarity of the context that surrounds these situations our teams want to be measuring. We trust our employees to be focusing and improving the most vital and impactful process'. Trusting teams to uncover what metrics are going to have a positive affect and understanding the importance of allowing the team to own that process is what empathy driven metrics is all about, rather than defining metrics based off of what has worked well for another engineering team in another company.
Going back to the original definition of empathy, 'having the ability to understand the needs of others', in this case means allowing your engineering teams to understand their own needs. Metrics and insights is a way that they can gain access to these needs. This process will undoubtedly take time and practice, but an empathetic approach to a culture of data-driven teams will yield higher productivity, greater engagement and allow continuous and autonomous improvement.
