Back to resources

Securing Buy-In for New Metrics

Productivity
Team Processes

23 February, 2021

Cody Kurz
Cody Kurz

Director of Engineering at 7shifts: Restaurant Scheduling

Cody Kurz, Director of Engineering at 7shifts, details how he managed to secure buy-in for new metrics from a team that was largely skeptical and distrusted the management.

Problem

After considerable deliberation, we decided to start collecting the data about our key processes that managers could use to identify strengths and weaknesses across different teams. Though we were very transparent about the data we were collecting, many of our employees became anxious and assumed that we would use them to fire people who were not performing up to the standards. We had to keep re-emphasizing that these metrics were not intended to fire/demote anyone and that poor metrics wouldn’t imply that someone was a poor-performing employee. We extensively communicated what was the goal of the metrics -- to analyze what things, not people, were broken and why.

Actions taken

We decided to mainly focus on pull request flows and measure the times from pull requests being open and interacted with to being completed and merged. Each of those steps gave a lot of insight into where the team was being held up. It became apparent that teams would focus on their own work and were not helping the rest of the organization with pull requests. People were expecting someone else to take care of it, and because it was a prevalent mentality, it took a long time for pull requests to be dealt with.

As we were emphasizing specific metrics, we noticed that the team cohesion strengthened and that the team started to operate more like a team as opposed to a loose group of individuals. They could see what the things we cared about were and that we were concerned about how the team was performing rather than how particular individuals were doing. Also, the team soon realized that some of those metrics could help them grow in the direction we cared about.

However, things didn’t go as smoothly as we hoped for. Initially, the team assumed that the goal was to use metrics for individual performance assessments, and they were largely skeptical. They falsely understood metrics as something that would get them in trouble and would impact if they would get raises or not. But, as they started to improve their performance due to the metrics we introduced, they also realized that those metrics provided them with more ammunition when it came to performance assessment and salary reviews. The metrics provided them data-based arguments to discuss their performance with their managers instead of having to take their managers’ subjective assessment for granted. Moreover, the same could be applied to managers, who had some solid data to corroborate their arguments.

Even when things were not going well and the stats were poor, the sheer numbers could become a great starting point for discussing what they could improve and shed light on some aspects of their performance they were not aware of. That also meant that they could much faster fix their weaknesses because metrics would spare them thinking if their manager liked them or not. They will have an opportunity to assess their own numbers, compare them with the company’s average and track their own progress.

Lessons learned

  • Communication is everything. Make sure that you communicate clearly why you want to introduce new metrics and how you intend to use them. That is essentially important for securing buy-in and enforcing more data-driven culture.
  • Some people will merely assume the worst intentions. Keep re-emphasizing what your intentions are, and that will hopefully help them overcome their own negative thoughts.
  • Introducing cycle time metrics around reviews, pull requests, and bug meantime to resolution proved hugely successful. Some of the metrics like bug meantime to resolution helped connect engineers with our customers and showed them that fixing the bugs is something we value greatly.
  • We also found a significant value in introducing metrics around the amount of time spent on a story combined with its estimate, which should disclose how accurate people’s estimates are. A lot of people shy away from framing it as a goal, but our intent was to show the team whether they were doing it consistently or not and to establish if a one-point story is -- most of the time, at least -- half of a two-point story.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

"You don't care about quality" A story of single metric bias

3 February

This was not a high point in my career. It's a story of single metric bias, how I let one measure become a 'source of truth', failed to manage up and ended up yelling at one of the most respected engineers in my team.

Product Team
Productivity
Team Reaction
Alex Shaw

Alex Shaw

Chief Technology and Product Officer at Hive Learning

Myth Busting

10 December

Supporting principles on why being data led (not driven) helps with the story telling.

Alignment
Managing Expectations
Building A Team
Leadership
Collaboration
Productivity
Feedback
Psychological Safety
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

The Not-So-Easy Guide on How to grow and develop an Amazing A-Team

5 December

Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Alignment
Building A Team
Company Culture
Sharing The Vision
Embracing Failures
Team Processes
Jaroslav Pantsjoha

Jaroslav Pantsjoha

Google Cloud Practice lead at Contino

How to measure Engineering Productivity?

30 November

When you grow fast, its normal to focus on Value delivery aka "Feature Releases". Too many releases too soon will inevitably lead to piling tech debts and before you know, inefficiencies creep in, performances goes down, and ultimately any new release takes too long. Sounds familiar? Then read on..

Productivity
Prioritization
Performance
Ramkumar Sundarakalatharan

Ramkumar Sundarakalatharan

VP - Engineering at ITILITE Technologies

How to improve engagement and retention in remote engineering teams?

25 October

Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.

Remote
Company Culture
Collaboration
Motivation
Team Processes
Mrunal Kapade

Mrunal Kapade

Director of Engineering at Inspire Energy