When we talk about metrics in software delivery, developers usually think of execution metrics – things like throughput, delivery, and number of deploys. These are often used to track team performance or determine efficiency, but in reality, these metrics don’t motivate anyone or provide a holistic picture of results – at least not without connecting them to a bigger picture.
When developers understand how their day-to-day work directly impacts the company’s goals and vision, they’re able to understand their impact and will want to do better. When they want to do better, they want metrics to get them there.
Here are four ways managers can motivate their developer teams to get behind metrics and find the right ones to track.
[ Want more on how to help your team members maximize their potential? Read also: 5 elements of servant leadership. ]
1. Clarify your goals
The first step to get developer teams excited about metrics is to define your goals as an organization and as a team. Then ensure that every team member understands them. From there, decide how your team will execute these goals and figure out the obstacles that stand in the way.
If your developers have clarity on the company’s mission and vision, they understand how their work directly impacts the customer and the success of the organization, which is highly motivating. When team members understand their role and value, they will be more motivated to improve their performance because they can see its direct impact.
Individual contributors will start asking for access to more information so they can diagnose their own problems and improve their work.
To help your team determine which metrics to track, consider these questions:
- Are we spending too much time on technical investment?
- Does it feel like we have too many incidents, issues, and escalations from customers?
- Are we far off on our estimates?
[ Read also: OKRs vs. KPIs: what's the difference? and How to explain OKRs in plain English. ]
2. Use intrinsic vs. extrinsic rewards
One of the challenging things about business outcomes is extrinsic motivation. You want to set stretch targets because people faced with stretch targets tend to push themselves to achieve the challenge.
For example, if your goal is to reduce your mean time to recovery from 55 minutes to 50 minutes and you can easily get to 50 minutes, you’re going to hit that number and be pretty satisfied. But if you set the goal at 45 minutes and the best you can do is 47 minutes, getting to 47 is still better than getting to 50. Even if you didn’t hit that stretch goal of 45, you’ve still achieved more by aiming for it.
Teams need the safety to be able to push themselves to those stretch goals, and that safety comes in part from the right approaches to motivation – the flexibility to fail.
3. Clearly connect impact to output
Finding a way to connect to the value you’re delivering to your users through the work you and your team are doing is incredibly important. Software practices such as DevOps and CI/CD are great ways to find that connection because they enable you to put something you built in front of users the same day it’s completed. You also become interested in a different form of metrics: whether users are adopting the features and products you build.
With CI/CD, teams are connected to what they’re doing for end users instead of building something so long ago that they don’t even remember it by the time it goes out to a customer. These practices allow teams to get that feedback from customers directly and truly realize their impact. That gets people excited.
[ Read also: 4 books to boost your data storytelling skills. ]
4. Avoid shortcuts
As a leader, you generally have context around the decisions being made and the goals being set. You may feel like it’s easier to just process that information and convey the results to your team rather than bringing them along on the journey. But that approach is unlikely to achieve alignment.
If you tell your team to hit their numbers because they should just trust you, that’s not going to work. Similarly, if you show up and say they need 27 percent allocation to bug fixes and 32 percent to new features because that’s your diagnosis of the problem from looking at the dashboard, your team may allocate their time that way, but you won’t see a benefit to the business.
But if you start with the reason and you end with the numbers, you’re on the right track. You’ll know you’re getting there because you’ll see the numbers moving, your team will be excited by that, and they’ll be motivated to do even better.
[ Get exercises and approaches that make disparate teams stronger. Read the digital transformation ebook: Transformation Takes Practice. ]
