Technology Leadership Isn't About Technology

If you've designed the hiring plan, been in a debrief, or simply been in a meeting about what makes a successful people leader for your engineering team, I'm guessing technical experience found its way to the top of at least one person's list.

It sounds natural, obvious even, to expect a new leader in your organization to come stocked up with tech skills. We're leading teams that need to produce, well, technology, after all. Your new director, new manager, new vice president should be an expert at it. Right? I'd like to answer that question with two questions of my own.

First: What exactly do you mean by technical expertise when it comes to a people manager?

Second: Was your answer to the above similar to how you'd define a Principal Engineer or Architect?

Okay, one more question: Does that really sound right to you?

How It Goes Wrong

Your teams are struggling to scale systems at the same pace as your business. Perhaps outages are escalating and teams can't get ahead of them. It's possible teams simply aren't executing, struggling to scope work and missing deadlines. Maybe you need to pivot your tech stack, or decompose a monolith into something more service-oriented. Whatever the problem or problems you're seeing, they're definitely technical problems.

You start the search for who needs to fill a leadership gap in your team. Let's say it's a Director you're missing, and that's who you try to find. You know they're struggling to execute technically – that much is obvious – and you suspect it's due to a lack of that technical knowledge within the team itself. You create a hiring plan, lay out the steps and questions to make sure you're getting someone with the skills you need, and you're off to the races.

The time to interview comes, and you focus your questions where it matters: How would you architect a service-oriented system to solve this problem? How would you scale an application to this many users? Would you choose GraphQL for this problem, or stay with a REST interface? You get signal on who has had the closest and most in-depth contact with hard technical choices, and what specific types of choices they'd make.

In the debrief, you narrow in on the best candidate. Their technical skills are sharp. Architect sharp. Hell, they could fill in for an architect if you don't have one. They're passionate about technical choices, in fact, so excited that they can't wait to join the team and push them forward. You make the offer, they accept, and you've landed your leader.

What do you think a candidate who rose to the top of that process is going to focus on? More specifically, what actions do you think they'll take to solve the team's problems? Are they most likely to observe why a team is making choices the way they are? To determine who on the team knows what's next but is struggling to influence, who is leading without bringing people along with them, who just needs the mentorship to make the next step? Or: is it more likely that they're going to hop onto the technical problems themselves, start pushing for specific designs and approaches, and solve the problem by being the team's architect?

If it's the latter – and I promise you, it will be – there's an obvious question you should ask next.

Who, exactly, is managing the team?

What Is a Manager?

If you ask the same people prioritizing technical expertise above all else what a manager is responsible for, the list will be full of non-technical responsibilities. You'll hear things like hiring and growing direct reports and retaining talent and influencing and aligning partners. There might be some knowing what to prioritize and knowing the right risks to take in there as well. And yes, you will hear technical skills – because tech is a part of the job! – but that's one area of competency surrounded five or six others.

Management, of course, isn't first and foremost about solving technical problems, because a manager has a team full of people with that as their primary responsibility. A manager has a role to play in helping a team get to the best technical solution, but there's a key difference between that responsibility and what a senior engineer might do. Managers need to work through their team, not in place of them.

Even if a manager's intention is to focus on technology, they can't escape all of the other demands on their time and attention, because unlike a team's technical choices, there's no one else to handle them. If a manager or director wants to be a primary technical influencer on their team, they're going to be forced to make a decision whether they want to or not: do a mediocre job as an architect, or leave all of those other responsibilities to simply... not get done.

If you're hanging up on this, and feeling cranky about what I'm saying, flip it around and think about it from the other angle. What does a successful principal engineer or architect's day look like? How do they know what the right decisions to make are? What conversations do they need to be having, and what work should they be doing to keep enough context to do their jobs? When it comes time to design, how do you see that working? What is the process for aligning the team around the idea, and then keeping them aligned during execution? How much time are they spending on just those duties?

Does it sound like a schedule that leaves time for 1 on 1s, recruiting, hiring, planning team design with product, and building growth plans for each of their reports?

(If your answer is yes, you're working too many hours a week and you're about to burn out. Please stop reading this and take a nap.)

My point is whatever your philosophy about the necessary technical competency of your managers, the schedule math simply does not work if you're hoping those skills will become the primary input into a team's decision-making. That's the case for team-level managers, and the math is even more dire as you think about your directors and vice presidents.

So, if a manager isn't able to be a team's principal engineer, if a director can't be the team's architect, how do they ensure their teams are making the right technical decisions?

The Art of Building a Team

Let's strip away the things a manager does, and think about how they know what to do.

If a manager needs to grow their direct reports, how do they know what growth, and how best to achieve it? They have to understand what that engineer is strong at, what's more of a struggle for them, and what their personal career goals are.

If a manager needs to hire, how do they know who to hire? They have to know what the team's current skills are, what they're already strong at, and what kind of skills would best complement and improve everyone else's.

If a manager has to retain people on their team, to keep them satisfied and invested, how do they know when that's a risk? They have to understand how their team members feel, what they aren't getting that they could decide to get elsewhere, and what options they have to address that.

If a manager is responsible for the team making the best technical decisions, how do they ensure that happens when they aren't able to make those choices themselves? They have to know which engineers are most capable in which domains, who might need help or mentorship when leading something new to them, and when there's a gap on the team that no one currently on it can solve.

Behind every one of a manager's duties is a vital core competency, and it isn't technology. It's assessment. A manager, first and foremost, has to be aware of the dynamics on their team, both at the group level and for every individual. Managing is about watching and seeing, listening and hearing, and using what they've seen and heard to know what their team needs to be successful. That ability to assess includes self-assessment, and this is where we can finally get to exactly why it's not important that your people leaders also be senior, top-level technologists.

A manager is just like anyone else on the team. There are things they'll be great at, stuff they can do if they work harder than they normally want to, and areas where they're weaker than even early career engineers. That means, when a manager is building a team, they aren't only looking for people to complement the skills of the people they manage. They need to balance their own strengths and weaknesses.

A great manager who's weak as a systems architect will know that, understand that their ability to help their team with those choices are limited, and hire the right person to be the technology leader the team needs. A manager needs to know enough to understand that gap exists, and enough to ask the right questions of everyone to ensure they're aligned with expectations. Beyond that, the best thing they can do for the team is set them up for success by building the right team for the job.

Wrapping It All Up

You're back to interviewing, looking for the next manager or director to join your engineering organization. As you speak to candidates, you find that some are stronger in technology than others. You know that technical skills alone aren't what you're looking for, but you do need to know if they'll make the right decisions for the team. How do you do that?

Go back to the core competency of assessment. Ask questions that tell you how aware they are of their own strengths, their own opportunities. Dig into times when they didn't know the answer themselves, and had to use their teams to get to the solution. Learn how they know a team is missing the right people to be successful, and how they fill those gaps when they find them.

A candidate that's fine, but not great, as a technologist, but knows their limitations and has a history of building and leading teams that balance them? They just might be the candidate with the potential to do the same at your organization.

If you're hiring a manager, you don't need an architect. You need someone who will know the team needs one before the team itself does, and understands how to find the right architect when the time comes. A great manager isn't just solving the problems the team is working on today, but keeping ahead of the problems they'll need to solve tomorrow. If you're hiring a manager, hire a manager, and set them up for success by helping them grow the right team around them.