“Our analysis is clear: in today’s fast-moving and competitive world, the best thing you can do for your products, your company, and your people is institute a culture of experimentation and learning, and invest in the technical and management capabilities that enable it.” – Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate. After finishing the book, many engineering leaders are determined to build a high-performance team. Readers go to the ends of the internet looking for the right tools and processes to facilitate speed and stability. Accelerate Lucky for us, to summarize every area that can be improved and move the needle, the authors put together this simple flowchart: Just kidding. It’s not simple at all. The tl;dr of the chart above is that changes to behaviors, processes, and culture influence several outcomes, such as burnout, deployment pain, or overall organizational performance. So while the book gives you a comprehensive explanation of everything that be done, it doesn’t answer the most important question can : if I want to improve how my team works, where do I start? Metrics != Strategy Ever since we built an , many engineering leaders have come to us and asked: “What metrics should I track in ?” And more recently: “How do I track metrics within Velocity?” engineering analytics product Velocity Accelerate The metrics, specifically, are valuable in giving engineering executives an understanding of where their organization stands, compared to the rest of the industry. They’re not: Accelerate Specific to the problem you’re trying to solve. Diagnostic to indicate when you should take action. While engineering teams track Accelerate metrics in Velocity (along with 40+ other metrics), we always advise leaders to first take a step back and consider what they’re trying to improve. Quantitative measures are a powerful tool to measure progress toward objectives—but these objectives can vary drastically between organizations or even between teams. Measuring metrics with no end goal in mind can lead to poor decision-making and a focus on the wrong priorities. can Instead, we recommend starting by determining your team’s objectives and then pairing them with the appropriate metrics. Then you can use metrics as a means to an end: measuring progress toward a clear direction. This will ensure your metrics are more actionable in the short term and will be received more favorably by the team. Specific: Start with the Pain We always recommend that engineering leaders begin with research. Prioritize conversations before looking at quantitative measures to work through the most immediate and painful issues. qualitative Through stand-ups, retrospectives, and 1:1s, work to understand what feels broken to the engineers. To avoid , collaborate with peers in management or lead engineers to gather this data to find repeat points of friction. exposure or recency bias Based on your team’s observations, record your hypothesis: Our code review process is often painful. I’ve heard that some reviewers “always approve PRs,” and often overlook defects. Other team members complain that specific individuals consistently ask for multiple rounds of changes, regardless of the magnitude of the change. Try to include concrete details to make sure you’ve completely and accurately captured your team’s shared sentiment. Once you’ve worked to understand the day-to-day friction, only then should you begin to look at quantitative measures. The example above might call for the following metrics: How quickly do reviewers pick up PRs? Code Review Speed: Once a PR is opened, how long does it take to merge? Time to Merge: How many times, on average, does a PR go back and forth between its author and reviewer? Review Cycles: How is Code Review distributed among Reviewers? Code Review Involvement: How often do reviews lead to a change in the code or a response? (e.g., How valuable are these reviews?) Code Review Influence: Look at these metrics historically to see whether they’ve been increasing or decreasing. You can also look at them in tandem with overall Cycle Time (time between the earliest commit and when a PR is merged to master) to see which have the biggest impact on the team’s speed. Diagnostic: Distinguish Drivers from Outcomes A common mistake leaders make when first implementing metrics is looking at outcome metrics and then making assumptions about their Drivers. Often, however, an output metric, such as Cycle Time, is spiking due to an upstream issue. Unclear technical direction, big batch sizes, or a single nit-picky reviewer can all contribute to a high Cycle Time. Drivers are typically indicators. They’re the first quantitative sign that something is going the right direction, and they will, in turn, affect your outcome metrics, which are your indicators. Your leading indicator is representative of an activity or behavior, whereas your lagging indicator is usually a count or a speed, which is the result of that behavior. leading lagging In the example we’re using for the piece, here’s how you would split up your metrics: Leading Indicator (Driver): Review Cycles, Code Review Involvement, Code Review Influence Lagging Indicator (Outcome): Time to Merge While you diagnose your issue, you’ll want to look at both the Drivers and Outcomes. Over time, you may discern certain patterns. You might notice that as Code Review Involvement goes up, Code Review Influence goes down. From those data points, you may want to investigate whether overburdening a reviewer leads to undesirable results. Alternatively, you might want to look into teams whose Review Cycles are much higher than others’ (with seemingly no difference in outcome). Once your team has improved, you can step back from looking at Drivers. Outcomes for your team will serve as at-a-glance indicators for whenever a team or individual is stuck and may warrant your support as a manager. The Path to High-Performance The research found in suggests that quantitative measures are important—but it also argues that the most successful leaders take a thoughtful and deliberate approach to improving how their organizations work: Accelerate “Remember: you can’t buy or copy high performance. You will need to develop your own capabilities as you pursue a path that fits your particular context and goals. Doing so will take sustained effort, investment, focus, time. However, our research is unequivocal. The results are worth it.” – Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate. If you’d like to examine your own team’s metrics and consult our engineering data specialists, sign up for a Velocity demo . We regularly coach engineering teams through improving upon the Accelerate Key metrics.

Velocity

Engineering Management, Reimagined

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

So, You Read Accelerate. Now What?

Too Long; Didn't Read

Company Mentioned

Code Climate

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

So, You Read Accelerate. Now What?

Too Long; Didn't Read

Company Mentioned

Code Climate

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES