Throughout our productivity research at Uplevel, we’ve had a revelation: The best goals don’t focus on output, but instead, look upstream. We know that when we consider the conditions that support or block work in the first place—as opposed to looking at the work itself—we give engineers the chance to be their best.
How do you set impactful goals? Here are four upstream metrics worth tracking.
Time to Focus
We live in a distracted world of work—especially in 2020. We’re trying to create “offices” in our homes, our virtual calendars are full, and Slack sends notifications all day long. (Thanks to APIs and integrations, you can be notified about anything from the status of a Jira ticket to when lunch will be delivered.) Clearly, we need help to focus. A manager can help enable this in two ways: by serving as the shield so that the team receives fewer emails and attends fewer meetings, and by creating a culture where developers (or entire teams) feel empowered to block off time to focus.
How managers can help:
- Analyze your team’s calendars and look for open blocks of time. Effective engineers need uninterrupted time—at least two hours or more—to do Deep Work and focus on challenging problems.
- Consider that availability over a longer period of time. Is your team’s openness for Deep Work time trending up or down?
- Are there individuals on the team that rarely have time for Deep Work? Meet 1:1 to find out why and make a plan.
- Survey the team. Do people feel they have enough time to get their work done? You can create a team culture of Deep Work by scheduling the same time for everyone. Even better, you can collaborate with other managers in your org to establish meeting-free times, like Tuesday afternoons or every day from 9-10am, to avoid fire drills from other teams.
Meeting Volume and Distribution
Teams should meet when they need to, but no more than necessary. Meetings are helpful when 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 to have ineffective 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 they have optimal time for Deep Work before, after, and in between.
How managers can help:
- Analyze the attendee lists. Does everyone in each meeting truly need to be there? Consider appointing one or two people to represent the team and take notes, bringing those action items back to the rest of the group. (We’ve seen this tactic do wonders for our users.)
- Aim to group meetings together. Are meetings scheduled back-to-back or scattered throughout the day? Optimizing this could open larger periods of time for Deep Work.
- On the flip side, are there days with too many meetings in a row? Look for times when the team might appreciate a break, especially in regards to Zoom fatigue.
- Are there recurring meetings that just aren’t necessary? Assess any regularly recurring meetings to make sure they are still needed and not just taking up calendar space due to a repeating autoschedule.
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 present. Past and emerging research points to evidence that manager behavior shapes team behavior. That role modeling can lead to new habits, good or bad.
How managers can help:
- Look to your Uplevel dashboard to track your team’s multitasking behavior in meetings.
- Consider the long-term prevalence. If multitasking is trending upward this quarter, this is a good time to assess your meeting health. If everyone is multitasking in a meeting, how valuable is it, really?
- Set a goal as a leader to stop multitasking and analyze how it affects your team data.
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.
How managers can help:
- Analyze the load balance across the team, looking at the number of projects assigned to each team member, as well as how many cross-team dependencies those projects involve. Doing one solo project is a much different experience than working on a project that requires input from multiple teams.
- Analyze communication habits out of working hours. If Slack, email, and Jira activity is jumping during nights and weekends, your team might be at risk of burnout.
Each of these goals serves an important purpose in tracking and modifying your team’s workload to ensure a healthy culture. We’re not going to fix a heavy meeting and multitasking culture in one week, but we can be more aware of the upstream factors that impact everything downstream by staying current with data.