Many managers agree that digging into engineering workflow data may feel invasive. At the same time, many engineers are naturally skeptical towards metrics, misinterpreting them as a way to monitor or micromanage output. In most cases, it’s usually because the data itself is being misinterpreted or mishandled, or the type of data is simply not shedding light on the truth as a whole. The key to maintaining your team’s trust and fostering a greater sense of autonomy lies not in whether you have access to data, but in how you use it.
Measuring a complex human process is not easy, nor consistently accurate. Still, with thoughtful application and the right tools, engineering leaders can use engineering metrics to improve efficiency, build a positive work culture, and set clear priorities. This data can provide a concrete foundation for productive conversations, and help engineering teams maximize their impact.
Here are some best practices for using data transparently and constructively.
1. Better Metrics Are Just the Start
Good metrics are based on objective measurements. They can accurately assess your team’s baseline, measure progress across teams and projects, and track process health over time. They also allow you to set actionable goals for software developers and drive high performance on your team.
“Objective” is not the same as “good,” however. Lines of Code (LOC) is an objective metric. It’s also an awful way to quantify developer contributions, measuring volume instead of quality or impact.
In addition, not all objective metrics are equally helpful for every team and situation. Leaders looking to boost efficiency may want to track a speed metric like Cycle Time. In contrast, those looking to optimize collaboration might look at code review metrics like Review Speed or Review Cycles. It can also be helpful to look at complementary metrics together — measures of speed and quality, for example, to ensure that one doesn’t suffer as you try to improve the other.
2. Use Data Responsibly
When leveraging data, it is important to be transparent, open, and constructive. Your team should understand what you are measuring and why, as well as who can see what data. You want to involve your team in discussions about what to measure and what goals to aim for.
If data does not meet expectations or otherwise raises concerns, it is important to work with your team to understand the pain points, address them, and create positive outcomes. Data should never be used as the basis for punitive action. It is essential that team members feel safe dissecting and learning from issues rather than be worried that they’ll be punished if they don’t meet some arbitrary number.
3. Always Add Context
Measurements only tell part of the story, and all data should always be placed in context. If a given metric is trending in a concerning direction, it’s critical to speak to your team and determine exactly why. There may be a good reason, and if not, understanding the root cause will make it easier to troubleshoot.
For example, one of our team leads noticed that her remote developers had a far higher Cycle Time than their in-person peers. Looking at only that metric, it would be easy to assume the remote developers needed to catch up or improve. With more context, however, a very different truth emerged. During 1:1 coaching sessions, she learned that unusually large pull requests were the real issue. The remote developers weren’t stuck or working less: they had just fallen out of alignment with the team’s best practices on PR size.
4. Leave blame behind
Metrics give you insight into the work, not the developers themselves. An engineer moving slowly through a project could be struggling, but they could also be working through a tricky problem that requires careful consideration. Leading indicators are a signal flare: they let engineering leaders know when there’s a risk or something worthy of investigation. This kind of data can be used to drive conversations and decisions, allowing leaders to give meaningful and actionable feedback with a fact-based understanding of what’s happening.
Engineering data can reveal a lot about the health and efficiency of your software development processes. It can help you coach your team, assess progress, and intervene before small issues become big disruptions. But to reap the benefits of engineering data, you must use it responsibly. As a leader, your success is not measured by your individual output but by the health of your team and its collaboration. Data wins happen when they can augment or address the team’s needs. Choose to use data to empower, motivate, and inspire professional growth.