"Can't Code! Not inclined to Hire?" - Why Engineering Managers Don't Need to be Great Coders

An explanation of why managers do not need to code, and probably shouldn't.

Wales. This is basically what all of Wales looked like.

I hope you're all having a lovely week! Welcome to the intro portion of my article in italics, where I write whatever I feel like.

We're in the midst of spring break with our kids. I remember as a kid being flabbergasted when I realized that my parents didn't have a Christmas or Spring or Summer break. The idea of working year round blew my mind. Funny what you can get used to.

Also amusing this week, we watched half of Jumanji 2 yesterday with our 8-year-old (we'll be finishing today). She thinks Jack Black is hilarious. She has good taste.

Amazon expects their engineering managers to run projects, mentor employees, design systems, architect platforms, manage operations, communicate with customers, and evolve products. But they don't expect them to code.

However, that's not true of many companies. When I interviewed at Facebook / Meta years ago, I had to take a coding test as a part of the hiring process.

I remember talking to the recruiter about it.

Me, "So I won't code in the job?"

Recruiter, "Oh no, I'm sure you wouldn't have time."

Me, "But I still need to take a coding test?"

Recruiter, "Yes, they want all their managers to be able to code."

Thankfully, my rusty coding skills didn't stop me from getting hired.

Once I was working there, there was a pervasive idea & attitude that coding was a necessary skill for managers. Other managers (particularly junior ones) insisted that Facebook couldn't hire managers with poor coding skills.

I literally heard this quote from another manager:

"How could you earn the respect of your team if you weren't the best coder on the team?"

I hope you also find that idea nonsense. The idea that engineers can only respect their manager if they're the best on the team seems crazy.

However, many people (such as Twitter's owner) still believe that coding is a key skill for managers.

These people argue that as a manager, ensuring your team does the right thing is crucial, and since coding is vital for engineering teams, managers should be able to code. Often not only capable of coding, but active and skilled at coding.

My perspective is that engineering managers should be technical enough to understand the key challenges their team is confronting. They should understand the process of coding, such as an understanding of build processes, unit tests, and source control.

However, I disagree with any requirement that a manager be able to currently code. And I certainly disagree with a manager actively coding at work.

The main point I'll discuss is that although coding is crucial for engineering team productivity, it's among the least important things for a manager to stick their nose into.

How you build something is rarely how you fail.

The most common argument for why managers need to be deep into the details is that they have to watch for potential failure from their team. The worry is that things will "go off the rails" if the manager is not closely monitoring the code the team is writing.

"You need to be reading code reviews regularly to make certain code quality is at the right level."

I think that's crazy talk. I've seen hundreds of projects at Amazon. What are the most common 2 reasons they fail?

1. They have a poor understanding of customer need. This is mostly a product problem, although the engineering manager should certainly be in the discussion.

2. They fall drastically behind schedule. I'll talk more about this one.

I don't think coding issues are in the top 10. Why? Because no one's poorly formatted loop code caused a major project to fail.

What causes projects to fall behind schedule?

• The schedule wasn't built well in the first place - The project manager or engineering manager's mistake.

• The technical design wasn't finished before estimating - The engineering manager's mistake.

• Scope creep or poorly defined scope - The product manager or software manager's mistake.

"But what about estimates? We sometimes see horrific estimates causing project failure. That's why the dev manager needs to be a great engineer. They need to be able to double-check on the estimates."

Even the best engineers make mistakes with their estimates. There are unknowns in every system, and they make estimates a guess at best. Even if/when the manager was in the details, they'd likely make the same mistakes.

What's the fix for poor estimates? Because I'll give you a hint. It's not "estimate better."

You need to build your project management processes to give early warning of a project slipping.

"Hey PM team. Looks like we're 3 weeks into the project, and we're already a week behind. I want you to be aware, so we can talk about contingency plans."

And you need to learn from your mistakes.

"Hey folks. Every sprint, it's taken longer than expected to make these mobile app changes. What's the pattern? Anyone want to guess why this consistently takes longer than expected?"

And you need to be bold and quickly adjust dates.

"Now that we've taken a closer look at the difficulty of building these features into our mobile app, everything is taking around 25% longer than expected. Our new expected launch date is X."

In the end, engineering managers have a significant impact on project success, but very little of project success has anything to do with coding or implementation details. Execution can be handled by the team.

Your job as an engineering manager is to avoid project failure. Failure comes from poor scope, poor schedule, poor communication, or poor project management. You don't have time to manage the execution details, you have a team to run.

Managers must grow their team members.

How do software engineers grow?

They move from doing what others say, to directing how engineering should be done. You can't do this as an engineer if your manager is leading engineering personally.

You can only grow when there is a void in leadership. When someone takes a step back and says that it's your turn.

What types of leadership do engineers need to do? Here are some examples:

• Setting high standards - "Yes, I know that might work, but this other way is better in the long run."

• Designing solutions - "If we hook these two services together, and store the results in this third service, we could solve for that requirement."

• Gathering consensus - "Ok, you'd like to add the feature to X service, but you'd like to add the feature to Y service. Why would either one be better?"

If the manager is doing the engineering leadership, what do the senior engineers on the team lead? How do they grow? They can continue to write code, but engineers aren't meant to be code monkeys their entire career.

As a manager, you don't want your Director micromanaging your daily work. The same as engineers don't want their manager micromanaging their daily work.

Micromanagement is practically a swear word in engineering. And leading coding as a manager is a form of micromanagement. It prevents leadership growth for the rest of your team.