May 28, 2024
One of the most common things an engineering leader will hear from their team is, “I don’t understand how my work actually matters.”
And that lack of clarity leads to dissatisfaction — individual contributors struggle to connect their work to the broader goals of the business, leading to a poor developer experience and increased employee churn.
But that isn’t even the worst possible outcome. In the worst-case scenario, an engineer might come up with their own narrative around the work they’re doing.
“The only reason I have to do this is because the sales team wants it.”
“This project doesn’t matter, it’s not innovative.”
“This is a beta, it’s just an experiment.”
When you hear comments like this, it means the engineers are missing context. They aren’t being told how their work fits into the bigger picture and why it matters to the company’s success. This isn’t just a problem for morale; it can also make engineering work less efficient. If an engineer doesn’t understand why they’re being asked to build a certain feature, they might end up building the wrong code for the job.
Engineering leaders can foster two-way communication with their teams, explaining the why behind certain decisions and using specific metrics to show how the team is executing against business goals. By opening things up to a conversation, engineers are open to ask questions, offer ideas, and in general feel more ownership of what they’re building.
When engineers understand how their work aligns with business goals, they’re in a much better position to make trade-off decisions. If an engineer knows the team is aiming to allocate 60% of its work to new features, they might not jump immediately on every bug that comes in. Without that clarity, they may spend too much valuable time fixing problems that pose less of a problem to the organization as a whole.
Discussing engineering metrics can feel like opening Pandora’s box, but it doesn’t have to be that way. The right set of measurements can help keep teams on track without feeling like they’re in a straitjacket or being micromanaged. Engineering is an art as much as it is a science. When we commission an artist for a painting, we don’t judge them by the number of brush strokes; we ask them to paint a picture, provide a few points of guidance, and then assess the quality of the result.
See the forest for the trees
When it comes to measuring engineering teams — and even more so when measuring individual performance — the questions are harder than the answers. Knowing how to fix something is easy. Knowing where to look and what to measure when you have a team with dozens of engineers? That’s hard.
Instead of getting bogged down in granular detail, engineering leaders should focus on high-level indicators. The goal isn’t to “optimize” performance. The goal is to give engineers freedom to operate, and to gather information that helps leaders ask better questions.
Engineering leaders should be asking questions related to allocations and quality, and using straightforward metrics to answer those questions. “What percentage of time is being spent on feature work, keeping the lights on, and support?” You don’t need to establish hard lines for those allocations, but you should have a general idea of what you’re aiming for. Engineering leaders can then identify when their team is deviating from the planned allocations and start looking into the reason why.
Engineering teams could use hundreds of different metrics to measure quality, but there are benefits here to keeping things simple. Instead of measuring quality in terms of the number of escaped defects, measure the amount of time engineers are spending fixing bugs. If you release a bug into production that can be fixed in under a minute, that’s not significant to the team’s overall performance; but if the team is spending 25% of its time on bugs and support work, that’s a shining indicator that quality isn’t where it needs to be.
Freedom and focus
Just as engineering leaders should focus on high-level indicators rather than granular details, they should also keep things simple when it comes to reporting and making improvements. Instead of trying to optimize ten things at once, choose one or two areas where you want your engineers to focus their efforts. Engineers need space and freedom to create: the best way to help them is by removing bottlenecks, rather than using engineering activity as a proxy for engineering effectiveness.
These metrics provide engineering teams with useful reference points to organize their work and improve performance without micromanaging:
- On-time delivery: This is fundamental. At a business level, at a team level, at an individual level, are we able to do what we say we’re going to do? This is also an opportunity to encourage engineers to “think macro” about the business. When you explain how engineering work builds up to broader business goals, you can also demonstrate clearly how on-time delivery shapes the work of other business units. Improving on-time delivery percentage increases the trust other business units have in engineering — that’s worth striving for as a team.
- Epic cycle time: Engineering teams will commonly measure their work according to issue cycle time, but that can lead teams to lose sight of the big picture. Measuring epic cycle time allows you to organize your work in a bigger context, and this can in turn help to keep engineers focused and positive. If you’re dealing with a difficult task, you don’t want to be measured on issue cycle time and have managers breathing down your neck. If you’re measuring the broader context with epic cycle time, you know that the more painful issues aren’t going to impact your overall performance.
- Work in progress: Engineering teams should also be tracking how much they’re working on in a given moment. We’re human — we can only carry so much at a given time. When engineering leaders measure how much their team is working on, they often find a long tail of smaller assignments that are distracting from larger priorities. Set expectations for how much an individual should be working on, then use those expectations to protect their time — this will keep the most important initiatives moving forward and simultaneously improve on-time delivery.
What do all of these metrics have in common? They’re high-level, easy to understand, easy to work against, and easy to compare among teams. These metrics allow engineers to operate freely and focus on the work that matters. Engineering leaders should never report on metrics like story points or issues, which are too granular and too variable to provide useful information. A story point doesn’t correlate with time, nor is it consistent from one team to another. Focus on the larger trends and you’ll gain a much more valuable perspective on what’s happening and how to adjust it.
Maximizing value from metrics
There’s a natural tendency when it comes to engineering management and metrics — we want more information. The more detail we have into individual performance, the more control we feel we have over the situation. If everything is measured in fine detail, you’re less likely to miss mistakes and anomalies, right?
The reality is that too much information can make it harder to see what’s actually happening. Alert fatigue can cause engineers to miss the most important signals in the bigger picture. For every metric you’re tracking with your engineering team, ask yourself this: what are we doing with this information? You might be getting down into the weeds with PR cycle time, but how does that metric inform your broader decision-making?
To maximize the value you derive from your metrics, take a step back and look at the bigger picture. Are we making the right decisions? Are we using our resources wisely? Are we focusing on the work that matters to the business?
Your metrics don’t have to be complicated. With the right combination of communication and common sense, you can keep things simple and steer your team towards improved efficiency and stronger results.
Want to learn more about how Jellyfish can help engineering teams track their performance and communicate across the business? Check out these recent blog posts:
– Goodhart’s Law in Software Engineering and How to Avoid Gaming Your Metrics
– CTO Toolbox: 22 Resources For Building Great Engineering Teams
