The 0.1x Manager

10x engineers won't help if there are multpliers in the other direction

People have talked about the 10x or 100x software engineer for decades. The skillset involved may have changed as technology has changed, but the basic concept remains the same. Some software engineers are more productive than others.

I've met a lot of people over the years who thought that all they needed to do to guarantee success was assemble a team of 10x engineers. There are lots of ways this can backfire, but the one I think is talked about the least is the 0.1x manager. It does not matter how good the engineers on your team are if you have a manager that will unnecessarily slow them down. There are too many ways this can manifest to list, but here are some of the bigger ones I've seen.

Headcount

The first is the headcount metric. A business should only care about ROI when it comes to engineering: total amount spent on engineering vs the total amount of value gained from engineering. The problem is that the latter is incredibly difficult to measure, even for engineers. It is compounded by the fact that the expense is immediate, but the value can take months or years to manifest.

Unfortunately, humans have a deep need to see progress in a measureable way. We are all susceptible to this. Your boss is susceptible. You're susceptible. I'm susceptible. If we are not careful, we will allow ourselves to prioritize an easy to measure metric as a proxy for our real metric. For many executives, this is headcount. It's not entirely unreasonable. A growing company will very likely need to grow its headcount. Therefore high headcount would correlate with success and a manager with a high headcount has been in a leadership position during that success.

The correlation is not perfect though. Incentives matter and many managers know this metric is used to measure their capabilities. That creates an incentive to create a higher headcount in their organization regardless of whether it makes sense. It almost certainly means that they will create a per-head budget in addition to their overall engineering budget so that they can fit more engineers into the overall budget.

Let's say you have a team of 10-20 engineers. You're about to reach a level of scale or go into a new domain that your team doesn't have expertise in. Developing that expertise will take months and result in software that will require more ongoing maintenance for years after that. An engineer who has that expertise could easily 10x the productivity of *all* 10-20 engineers. That engineer is likely to command a high salary.

Spelled out like that, you wouldn't think it possible that any manager would risk not hiring that expertise to save $20k on their salary. You'd be wrong. It is far rarer to find a manager who would make the necessary offer.

Blame avoidance

People are put into leadership positions to well... lead. That means making decisions. Leadership is tricky though. It's not like writing code where if you write X and give Y inputs, you should expect Z. The decisions managers have to make are not deterministic. The same decision that works one day could not work the next. The best that managers can do is maximize their odds of success, but they can rarely guarantee it.

Unfortunately, the performance reviews for managers rarely take that into account. They've either succeeded or failed. That creates a sense of fear.

One way that fear manifests is to make sub-optimal decisions that appear safe. Software engineer interviews are a perfect example of this. Most people know that leetcode interviews do not correlate with job performance. This has been talked about for over a decade. Why is it still used then?

Consider this: if you make a bad hire, but used a technique everyone else does, then it can be chalked up to bad luck. The technique is flawed, but it is the standard. You're expected to use it so the bad hire is not seen as a result of a poor decision you made.

If you took a risk on a novel way of interviewing and it resulted in a bad hire, only you could be responsible. Maybe if you had used the technique everyone else did, you would not have made that bad hire?

This isn't a conscious decision on the part of the person evaluating the manager either. It is the thought process that humans default to. It takes great effort to counter that thought and that effort is rarely spent. The result is "safe" decisions being made instead of good decisions.

As bad as that is, it is still better than the second way this fear can manifest: not making a decision at all. Trying to figure out whether to use AWS or GCP? Spent a month comparing the two? Why not spend another month, just to be safe?

Fiefdoms

Communication barriers are a huge hinderance to productivity. Early in my career, I cut three weeks off a project by talking to the product manager when the other engineers were just going to implement what the spec told them to implement. That experience stuck with me. Every time I took a new job and saw walls between people that needed to speak, I burst through those walls like the Kool-aid man.

Unfortunately, that habit has backfired on me. Barely a month into a new job, one of the directors calls in my manager and I to a meeting and screamed at us for 30 minutes. I didn't realize his problem until 15 minutes in. Apparently, I had developed the unhealthy habit of talking to people in his organization directly. He wanted me to go up through my reporting chain and across to him. He would decide what would reach his teams.

There's no practical reason for this. Unlike headcount, it doesn't make a resume look better. It doesn't ensure that director would get blame or credit for project results. All it really does is make him feel better by being in control. That was enough for him to reduce the productivity of roughly 60 people.

"I'm still an engineer!"

It's ironic for me to point this out because I've always identified myself as a software engineer regardless of my actual role. The engineers promoted to management roles tend to be high performing engineers. That high performance has given them a well earned sense of pride in their abilities. However, the performance of a manager is determined by the performance of their team, not their own invididual engineering contributions.

The obvious consequence of this is managers who force engineering decisions on their teams when there are engineers on the team with the expertise to make better decisions. The result is software that is harder to maintain as well as a demoralized team. Demoralized teams have lower productivity and higher turnover.

The less obvious problem is that even *if* the manager is the most capable engineer on the team, they should still prioritize letting their team make decisions. The only way to learn is to make choices and deal with the consequences of those choices. Making decisions for a team will cripple that team's ability to learn and grow. They start relying on the manager to make all decisions. Instead of moving forward on development, they will pause and wait for a manager's decision every time a roadblock appears.

---

Those are some of the worst ways I’ve seen managers destroy productivity. If you’ve experienced ones that aren’t on this list, I’d love to hear about it.