Four Metrics Every Engineering Manager Needs to Monitor for Success

Engineering managers and leaders are charged with a challenging task every day: How do they support engineers to do their best work, and how do they know if their engineers are doing their best work? 

The former is easier than the latter. To enable an engineer’s best work, you’ll want to make sure they are clear on their goals, focused on the right priorities and have the information they need to do their work. A critical role of the manager is to eliminate any blocks that get in the way, too.

Yet, despite those efforts, engineering managers struggle to identify if their engineers are actually doing their best work. Should they measure how many items they complete? Or how much code they write? Or the quality of their work?

All of these are relevant puzzle pieces, yet they’re hard to objectively measure, and don’t indicate the full picture of an engineer’s work.

One revelation from our productivity research at Uplevel is this: Instead of focusing on output, managers can find more success in focusing upstream. When we consider the conditions that support or block work in the first place, we give engineering teams the best chance to do their best work.

Here are four upstream metrics worth tracking.

Time to Focus

While it seems pretty straightforward to focus, we live in a distracted world of work. Office layouts are open, calendars get filled, Slack sends notifications all day long (and thanks to APIs and integrations, you can be notified about anything from the status of a Jira ticket to when lunch will be delivered). Effective engineers need uninterrupted blocks of time—at least two hours or more—to do deep work and focus on challenging problems. A manager can help enable this in two ways: by serving as the shield so that the team is in fewer meetings, and by creating a culture where developers feel empowered to block off focus time, either individually or as a team.

Meeting Volume and Distribution

Managers can ensure that their teams meet when they need to, but no more than that. These meetings are needed so that people can collaborate, problem-solve and follow engineering-related rituals in the world of agile development. However, it is easily possible to have too many meetings, or ineffectively run meetings. When occurring at inconvenient times, just two meetings a day can take up most—if not all—of a developer’s deep work time. Monitor your team’s meeting levels and distribution so that there’s optimal time for deep work before, after or in between.

Avoid Multitasking

If your developers are going to be in a meeting, it’s important that they are focused on the goals of that meeting—and not multitasking. Managers can lead by example and keep laptops closed, unless they need to share or present. Past and emerging research points to evidence that manager behavior shapes individual contributor behavior. That role modeling can lead to new habits, good or bad.

Too Much Context Switching

Are your developers focused on a small number of high priorities? Or are they jumping across epics, project phases, focus areas and code bases? Keeping each developer focused on just a few areas helps reduce context switching—a costly obstacle to effectiveness. Every context switch—like, say, shifting focus from a 10-minute standup, to a cluttered inbox, to a fire-drill Jira ticket—requires time to switch out of the first context, into the new context and back to what they were working on in the first place.

— David Youssefnia