November 29, 2022
Executives everywhere are hearing the siren call to become more data-driven in their engineering organizations, and more software teams are bringing engineering metrics into their workflows. When leaders sense the wrong things are being prioritized, or that engineering isn’t moving fast enough, they like to turn to data to understand and track what’s happening. We believe most of these leaders have good intentions: they want to be informed, they want to make sound decisions with better information, and they want to grow and improve their teams and their work. They might want to use data to remove team bottlenecks, drive operational efficiencies, and ultimately get the other executives off their team’s back so they can go back to doing their best work. Data-driven decision making at its best enables and empowers leaders, managers, and individual contributors with additional context to make the right decisions daily.
But many developers have seen this story before, and they know these intentions don’t always lead to those desired outcomes. In certain circumstances, metrics can exacerbate the most damaging aspects of our work cultures. No one wants to work for an organization when they feel like just a cog in the machine, or a number on a page. And if not implemented correctly, this is the exact feeling numeric goals without context can elicit. While the engineering teams often suffer first, leaders do too when morale and engagement go down, attrition goes up, and their best talent walks out the door. In short, metrics can drive team engagement, growth, and success in the right environment. They’re a force multiplier of your leadership and the culture: for good or ill. In this post, let’s talk about my experiences with oversight, how metrics can go wrong, and how you can be thoughtful about introducing them well.
Storytime: My first experience with metric oversight
First, a quick story.
One day, in my early years as an engineering manager, long before Jellyfish, my boss and CEO came out of a board meeting that had taken place in the glass conference room next to where I was working. He asked me whether we as a team were spending too much time on Slack. I knew he was aware of how interruptions can break from developer flow time… but then he dropped the underlying reason for his question.
From where he was sitting in the board meeting, he had been able to see me working. He observed that I had spent a good portion of my afternoon on Slack. And at that moment my amygdala (where the flight or flight response within the body resides) and defense mechanisms went haywire. Sure, I was on Slack all day, for good reason! I was helping one of my direct reports with a stressful fire drill and talking through solutions with them. My team was distributed, and keeping in the loop with them often required a lot of DMs and conversation threads. I knew that I was doing good work, and here I was feeling the need to defend my actions. If I hadn’t been in Slack all day, he probably would have heard about the fire drill and asked me why I wasn’t taking care of it. I was in a no-win scenario.
What about engineering metrics feels threatening?
So why did everything about that situation feel so wrong? Let’s start with the idea that being “watched” without realizing it, or in a way you hadn’t fully considered, never feels good. It makes you feel like you aren’t prepared and are more susceptible to being judged unfairly, without the necessary context. We can be painted in an inaccurate light when observed from afar. Like in my story, managers and leaders are susceptible to missing important context if they’re not actively seeking it out or asking the right questions. We, as employees and humans, feel much better prepared when we are aware of when and how we are being observed. Many of us would love to be active participants in deciding if and when oversight takes place and be allowed the opportunity to provide the right context for actions. Without these things, oversight is intrusive and uncomfortable.
All of these points from my example can be applied to rolling out engineering metrics too. Having open conversations and thinking through how we gather and interpret engineering metrics is an important way to work through how threatening they can feel. We need to encourage talking about metrics. We at Jellyfish have seen firsthand the positive impact of engineering metrics when they’re paired with leaders using that data as input for thoughtful human processes that support people and their results.
We can all do better and grow. We need to talk about how we think about our teams’ growth, and demonstrate care about the qualitative aspects of each engineering story that cannot be measured. We need to ensure that our teams and cultures are introduced to metrics in a way that feels safe, fair, and actionable. In my next post, we’ll discuss a framework I like for ensuring engineers’ needs are met when rolling out metrics plans with teams.
