TWH#49: The Metrics of Fear
What the obsession with individual performance can teach us about ourselves.
Engineering leadership coach Laura Tacho recently published an article that starts with a question she often gets:
“What metrics should leaders use to measure the individual performance of developers on their teams?”
As far as I’m concerned, Laura does a masterful job of answering this question. But as she points out towards the end:
“If you’ve read this far, hoping for a list of metrics that you can grab and start using on your teams, you won’t find one. There’s no shortcut here.”
Laura’s level-headed analysis of the dangers of individual tracking, and what to do about it, fully resonated with me. However, I suspect it will leave a lot of people dissatisfied precisely because it provides no list of metrics ready to be tracked to finally bust those pesky, underperforming developers.
Laura focused on the “what” and the “how”. I can’t possibly do a better job than she did, so please make sure you read it, re-read it, take notes, and discuss with your peers. What I’m really, really curious about is the “why”. Why is this question so often asked? When you dig into it, what do you find? And what can we learn from it?
That’s what I intend to explore with this week’s post.
If you’re an engineering (middle) manager, or considering the opportunity to become one, this week’s post is for you. And if you’re a senior leader in a tech startup, particularly if you’re non-technical and in charge as a founder and CEO, then this post is definitely for you.
Trust
If there’s one ingredient missing in an insane number of organizations is trust. Sadly, it’s the one that’s needed the most. Whatever trust there is by default gets eroded when performance is off the mark, goals are not met, and simplistic explanations—usually focused on individuals as scapegoats—are used. This in turn leads to reduced trust, which impairs collaboration, preventing better ideas and risks from being surfaced. All of this leads to worse results which further erode trust. And so it goes.
Naturally, the lack of trust goes both ways. Senior management mistrusts their people (“Why does it always take so long? Why are there so many issues?”), and people mistrust their leaders (“Why do they change their priorities all the time? They don’t understand what we do.”) As companies grow in size, the distance between senior management and the “shop floor” increases, making it increasingly more difficult to build shared context and understanding.
Part of the reason why senior management is usually so keen on individual performance metrics stems from this absence of trust:
Towards individual contributors. Without truly understanding what’s going on, the verdict is inevitably some combination of people not working hard enough, not caring enough, or simply not being good enough at their jobs—especially at estimating how long things will take (also known as “futurology”).
Towards engineering managers. Again in the absence of real understanding, the simple explanation is that engineering managers aren’t being “tough enough”, allowing underperformance to go on because they’re avoiding conflict and being “too nice”.
Combine these with being used to living inside spreadsheets and counting things, it’s no wonder senior management has an irresistible pull towards individual performance metrics. Cut the middle men and give me the data. After all, who wants to be paying top dollar for people who are coasting and just having a good time at their expense?
And you know what? All of the above has a kernel of truth. Some people do coast. Some people aren’t very good at what they do. Some managers do struggle to have difficult conversations, and to set and manage clear expectations.
But throwing the baby out with the bath water? No bueno.
It really doesn’t have to be this way. In fact, even if some results are there working in this way, it’s not fun and, more importantly, it has a steep cost: falling well short of the true potential of the organization and in the mental health of all involved—including senior management in the long run.
Doing The Same Thing Over And Over Again
As a leadership coach, I get some serious exposure to all sorts of challenges multiple times a day, on a daily basis. Together with my own years of experience as an engineer and engineering leader, I have little doubt that:
99.9% of people want to do the right thing.
Most challenges ultimately stem from a lack of theoretical knowledge and the respective practical applications.
In other words, most of us are winging it, to different degrees. And when you dig into some fundamentals, it’s really no wonder so few organizations are satisfied with their people, and so few people are truly satisfied with their organizations.
One glaring example is how “performance” and “productivity” in product & engineering teams continues to be regarded as being about the individuals above all else. Someone (almost always a product manager or someone else outside of engineering) decides what the team should work on. Developers get “tickets” assigned to them. Standups, then, are about status updates about where everyone is at with their respective tasks. Performance is about cranking out these tasks, the more the merrier.
This “factory model” has obvious limitations because whereas factory work is predictable, with very low variability and whatever dependencies are mapped out in advance, software development is nothing but. One developer may code a particular feature, but it requires code review, some testing, and somehow getting it deployed to a production environment. All those are handoffs and dependencies.1 No to mention that there’s infinite possibilities on how to get anything done. There’s no “best practice”.2
The more work-in-progress (WIP), the more the negative effects of this way of working are felt. And, unsurprisingly, most teams have a whole lot of WIP thanks to a combination of ambition, naïveté, resignation with the status quo, and an immense stakeholder push to get as much done as possible—for which teams usually have no vocabulary to respond to.
The result?
Estimates are rarely, if ever, met.3
Everyone is busy beyond belief—all the time.
Most people are stressed—most of the time.
It’s not fun.
Little value is delivered.
Teams are not living anywhere close to their real potential.
Burnout
Churn.
Also a result: CEOs lamenting that “we used to deliver a lot more when we were only 5 people.”
Again, none of the above is the real issue. Startups must hire junior people. Founders must once be first-time founders who can’t possibly know better. Engineering managers will struggle to have conversations they were never taught how to have.
And people will simply be people. Period.
The real issue is that most teams simply don’t learn. They are stuck with doing the same thing over and over (and over) again expecting different results.
(Very) High WIP == No Learning
As I already hinted above, I believe the tragedy of the commons, particularly in scaled startups, is the sheer amount of work in progress. I call it a tragedy of the commons because often it doesn’t have a single culprit. As Cal Newport points out in A World Without Email, we have made communication so easy (through email and especially things like Slack) that interrupting other people with what we need became simply too cheap. So we do a whole lot of it.
Seen individually, it doesn’t amount to much. As a whole, it’s a mess of context switch, lack of focus, and ultimately lost value.
More important than all that for me are the lost opportunities for learning. Whereas every situation can (and should) be an opportunity to learn something valuable, most people are so frazzled from having their attention bouncing around like a pinball, that they count themselves lucky just to get to the end of the day. Exhausted.
What could happen if we talked as much about “learning” as we do about “productivity”, “efficiency”, and “performance”? Where do all of those things come from? Why do we expect ourselves and everyone else to come pre-packaged with all the required skills, with all the experience already?
What if leaders were accountable to their people learning and getting better at their work?
Here’s a vision. Imagine that you have a few engineers who are not only great developers, but they are great mentors, too. Imagine that this allows you to significantly expand your hiring pool because now you’re in play for all the inexperienced, junior developers who are curious, humble, insatiable learning machines. You pay them well, instead of exploiting them, because you know they will soon be extremely competent, grateful and loyal for the opportunities they got, and soon great mentors themselves.
That’s a competitive advantage if I have ever seen one.
Instead, what we have are insane bureaucracy machines, where engineering managers are well over their capacity (and unable to increase it), stuck in roadmap meetings, OKR updates, calibrations and performance reviews. The list goes on, leaving no space to simply getting better what they do. It certainly disables them from spinning what I call the “coaching flywheel”:
If you can do one thing, and one thing only, let it be this: actively reduce the amount of work in progress inside teams and inside the organization as a whole. No good comes from high WIP. It’s no more, no less than an illusion. It’s a guarantee of underperformance and burnout predicated on the idea that great work is hard work, and that busyness means business.4
Fear
If only it was so easy, right?
“I can’t reduce WIP, all of this stuff is critically important! And urgent!”
That’s fear talking. Fear (and anger) give bad advice.
Fear that we won’t work hard enough, that we won’t care enough, that we won’t get enough done, that we will not be enough.
Founders live in fear that their baby won’t make it.
CEOs live in fear of their board, and that the forecast won’t be met.
Senior management lives in fear of their CEO and of their performance targets.
Middle managers live in fear of their bosses, and of their teams’ expectations.
Individual contributors live in fear of the next performance review, and not meeting the sprint goals.
Maybe it’s not exactly like this, but close enough to ring true.
The problem is that learning can’t happen when we’re in fear. When we’re in distress. When we’re annoyed, frustrated, or angered. The problem is also that our responses where we’re in fear are more controls, more rules and regulations, less trust. Which only exacerbates the problem.
What would it take to step out of the fear a little bit and start learning?
For one, it takes (real) leadership.
Leadership
Leadership is not just having a collection of tools and frameworks. Leadership is not just dashboards and spreadsheets. Leadership is not just having the gift of the gab. Leadership is not just “strategy docs”. Leadership is not being loud or pontificating. Leadership is not looking good. Leadership is not even just about the results.
Leadership is about how you look at yourself, how you look at others, and then how you show up. It’s about realizing that a leader can’t lead alone, but rather bring others along. Leadership is glue. Leadership is about gifting the best of us. Leadership is doing what it takes for the whole to be bigger than the sum of the parts.
Leadership is having the humility to ask better questions when all the answers we have are about other people not being good enough. Leadership is having the humility to change ourselves before we demand others to change.
Leadership is courage.
Leadership matters.
Thanks for reading. If you enjoyed this post, please consider hitting the ❤️ button, and sharing it using the button below.
Also — I have a couple of openings for executive and leadership coaching. If you’d like to explore working with me, drop me a message on LinkedIn or Twitter.
Until next week, have a good one! 🙏
One reason why many teams’ standups take forever is precisely because of the underlying dependencies between different individuals’s work.
Highly recommend Johanna Rothman’s “Cost of Delay” series on this topic.
Such a great post, Paulo!
It’s so much easier to follow the same pattern over and over. It’s expected. No wonder why most teams end up facing the same problems.
Your focus on learning instead of performance alone looks simple, but it’s a huge paradigm shift!