Measuring Manager Effectiveness -- Can You Even Quantify It?

Dev Leader Weekly 138

May 04, 2026

TL; DR:

Manager effectiveness is multidimensional -- technical, project, and people
You can’t perfectly quantify it, but you can measure signals that matter
Balancing delivery with people management is the real challenge
I’m on-call this week -- no live stream. Sorry!

Can You Actually Quantify How Good a Manager Is?

A viewer recently asked me about how quantifiable manager skills are, and I think it’s a genuinely fascinating question. We can all think of managers we’ve worked with and immediately categorize them -- “that person was incredible” or “that person was a nightmare.” But putting numbers on why is a completely different challenge.

I wanted to break this down because I think it matters -- not just for evaluating managers, but for managers themselves who want to understand where they’re doing well and where they need to invest more time.

You can check out my full thoughts on this in the video below:

First, Set the Expectations

Before we can measure anything, we need to level-set on what’s actually expected of a manager. And this varies massively -- across companies, team sizes, and seniority levels.

My advice for level-setting expectations applies to managers too. If you’re thinking of moving into management or you’re a new manager, work with your own manager to understand what’s expected of you. That baseline matters because without it, you’re measuring against a target you can’t even see.

The biggest variance I see comes down to how much time you spend as a hybrid IC. At smaller companies or on smaller teams, there’s often more of an expectation that you’re hands-on in the code. It almost wouldn’t make sense to sit back and wait if you have a small surface area of people and technology. But as your scope grows -- more people, more product areas -- the balance shifts. You stop being the person fixing bugs and start being the person planning how work gets delivered and making sure the right skills are applied to the right problems.

I’ve lived this shift personally. Early in my career I managed a bunch of people at a startup on a single product, and I could code in any area because I’d been there since the beginning. Then at Microsoft, I moved into a deployment team -- a more focused scope, a codebase older than some team members -- and many of my hands-on strengths just didn’t apply the same way. The same thing happened when I moved over to the M365 routine plane -- and that’s not a failure. It’s what happens when your role gets more strategic.

The Three Dimensions of Manager Effectiveness

I think about manager effectiveness across three major areas, and the measurability of each is very different.

1. Technical Ability

This one is nuanced. It’s different to have domain knowledge of the codebase versus having system design expertise. I can tell you from experience -- there are potentially junior engineers on my current team who can find and fix a specific bug faster than I can, because they’re working in that code every day. But if you need help designing a system from scratch? That’s where broader engineering experience kicks in.

The measure isn’t “can you out-code your team.” It’s more like: can you take on ambiguous, complex technical challenges and deliver at a level comparable to senior ICs on your team? For some managers, the answer is yes. For others -- especially those managing larger or more diverse surface areas -- the answer is no, and that’s completely okay if other dimensions are covered.

Actionable Tip: If you’re a manager who’s lost touch with hands-on code, lean into AI tools. I’ve found that AI makes it much faster to get up to speed on unfamiliar codebases when you need to jump in. It doesn’t replace daily hands-on experience, but it dramatically shortens the ramp-up time.

Thanks for reading Dev Leader Weekly! This post is public so feel free to share it.

2. Project Management

This covers prioritization, tracking progress, managing roadblocks, handling dependencies with partner teams, and making sure work is properly staffed. And not “staffed” in the gross “people as resources” sense -- I mean making sure you have the right mix of skills and experience applied to each problem.

Can you measure this? Sort of. You could look at whether deadlines are consistently hit, missed by a little, or missed by a lot. If you’re always off by 2x on a six-month project, something’s wrong. If you’re off by a week or two? That might be totally reasonable.

But the real signal is less about hitting exact dates and more about what you do when things are off track. The best managers I’ve seen raise awareness at the right time, engage the right stakeholders, and either adjust scope or adjust timelines -- so things still get delivered on an agreed-upon plan even if it’s been shifted. That’s incredibly hard to put a number on.

3. People Management

This is the one most engineers underestimate when they move into management. And honestly, from my experience working with other engineering managers, many still don’t realize this is fundamentally a people management job. That’s alarming to me.

Here’s what falls under this:

Career growth -- are you helping people advance? Is there a reasonable promotion cadence on your team? Not everyone promoted every cycle, but also not nobody ever.
Team composition -- do you have the right balance of levels, backgrounds, and strengths? You can’t build a team where everyone has maxed-out stats. That’s not real.
Single points of failure -- if only one person knows a critical system, you need a plan. That’s the lottery effect (or if you prefer the darker version, the bus effect).
Engagement -- are people actually interested in their work? Do they feel supported?

That last point is critical. If you’re hyper-optimizing for delivery by always slotting your best person into the next highest-priority task, you’re probably ignoring whether your team is burning out. That person keeps getting siloed. Maybe they don’t even want to do that work anymore. Maybe other people on the team want the opportunity. You can’t ignore the people side just because the delivery side looks efficient on paper.

Actionable Tip: If you think supporting your employees detracts from delivery, you’ve got it backwards. A team full of people thinking “screw this place, no one cares about me” is not going to deliver great work regardless of how cleverly you assign tasks.

So How Do You Actually Measure This?

Here’s my honest answer: there is no single tool or system that gives you a clean numeric value across all of this. But there are signals you can look at.

Promotion cadence -- are people progressing at a reasonable rate? If it’s zero or 100%, something’s off.
Employee satisfaction surveys -- at Microsoft we have a signals survey with a “thriving score.” It’s not perfect science, but it gives you a quantitative read on whether your team is engaged.
Deadline accuracy -- not whether you hit every deadline perfectly, but whether the variance is reasonable and whether you course-correct effectively.
Technical contribution -- if you’re still expected to be hands-on, can you handle complex work at a level that matches your most senior ICs?
Team resilience -- do you have the right mix of experience levels and no single points of failure?

The important thing is that you’re not measuring to game a target. You’re measuring to understand where you need to invest time. If nobody’s getting promoted, that’s a signal. If everyone is but your delivery is suffering, that’s also a signal.

It’s Going to Look Different for Everyone

Is it possible to come up with some type of assessment for manager effectiveness? Sure, I think so. But it’s going to look different depending on your seniority, your team composition, the lifecycle of your product, and a dozen other factors.

And that’s actually fine. The point isn’t to come up with a universal manager score. The point is to be aware of the different dimensions, check your signals, and course-correct where things are off.

These are my opinions from 13+ years of frontline engineering management. Your experience might tell you something different, and I think that’s a valuable perspective -- so leave me a comment to let me know!

Dev Leader Weekly

Discussion about this post

Ready for more?