Plato

Login to Plato


This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Don't have an account? 

Securing Buy-In for New Metrics

Team processes
Productivity

23 February, 2021

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

Acting Quickly To Resolve an Incident
9 April

Leo Torres, Engineering Manager at Carta, speaks of his prompt response to a recent incident and how acting quickly allowed him to make a customer happy.

Team processes
Collaboration
Leadership
Leo Torres

Leo Torres

Engineering Manager at Carta

Pausing for Innovation
31 March

Arjita Ghosh, Director of Engineering at Quizlet, shares how intentional pausing can instigate innovation and boost productivity.

Team processes
Productivity
Arjita Ghosh

Arjita Ghosh

Director of Engineering at Quizlet

Shipping Products Faster with Confidence
26 March

Ian Logan, VP of Engineering at Rose Rocket, explains why the speed of execution is critical for finding a product-market fit and highlights how to build confidence when shipping fast.

Dev Processes
Team processes
Ian Logan

Ian Logan

VP Engineering at Rose Rocket

Leading Post-Acquisition
26 March

Ian Logan, VP of Engineering at Rose Rocket, shares what it takes to make a successful acquisition of engineering organizations.

Leadership
Changing company
Team processes
Ian Logan

Ian Logan

VP Engineering at Rose Rocket

How to Balance the Continual Proliferation of Ideas With Limited Resources
26 March

Jérôme Basdevant, CTO and Co-founder of Datamaran, talks of his efforts to balance his continual proliferation of new ideas with his startup’s limited resources.

Team processes
Jérôme Basdevant

Jérôme Basdevant

CTO and Cofounder at Datamaran

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.