Why Developer Managers Should Be Technical — And What Happens When We Aren’t
Should an Engineering Manager be technical?
I’ve personally managed 50+ developers — and overseen 450+ developers. That said:
I have never written code in any meaningful way My background is agile Technical Project/Program Management But am I technical? I tell people no.
Why? Because people often use “ technical” to communicate:
- This person has had a hands-on engineering role
- This person can provide meaningful technical feedback to experts
- This person has direct experience in the work they are overseeing
But what does being “technical” mean?
Will Larson wrote an exceptional article, Do Engineering Managers Need to be Technical? He writes about the challenges of defining the word “technical.”
He created a simple framework of questions to address concerns if a person might not be technical enough for a role:
- Is there a relevant/critical technology that they are not familiar with?
- Were they perceived as uncomfortable, or did they lack confidence when describing a solution or when in a technical discussion?
- Would I care about them knowing a detail if I didn’t personally know it?
- Given their role in and relation to their work, is the work’s success dependent on them knowing these details?
Even when manager is technical enough, there can be challenges when compared to a manager who has a developer/technical background.
Challenges for a manager who can’t code
You are not autonomous: I can’t fix bugs in Production. I can’t write new features. My ability to assist my team with their technical work has meaningful limits. With my current team of 16, this hasn’t been an issue. When I ran a team of two, it was a nightmare.
Why was it a nightmare?
- I couldn’t be on rotation for our team’s 24x7 on-call support
- Our team’s work was highly specialized, and I couldn’t autonomously assist with bug triage, writing specs, or prioritization for almost a year
- I couldn’t provide feedback through code reviews or by observing them
You won’t perceive critical technical implications. A manager who is not technical — or hasn’t been an engineer — will need help understanding technical implications of decisions. In some teams this might be unacceptable, as you could be facing engineering challenges that are unique or novel somehow.
You have to grow your managerial and technical skills at the same time. This might sound easy, but in reality, it is incredibly challenging. Growing technical skills often requires hours of uninterrupted time. And in my average day I have 5+ hours of meetings, not counting constant fires to put out.
As Charity Majors, CTO of Honeycomb, points out in a great article, The Engineer/Manager Pendulum:
“You can only really improve at one of these things at a time: engineering or management. And if you’re a manager, your job is to get better at management.”
There is no easy solution. In my own life I sacrificed (and continue to do so) my personal time to study and learn in the off hours. I have not found a way to develop technical knowledge without significant uninterrupted time.
The imposter syndrome is real. I am surrounded by people smarter than me with deep technical experience. It takes time to uniquely define your value as a manager without engineering experience, especially if you move into a management role early in career.
Advantages of a manager who can’t code
So how can a manager who doesn’t code, or doesn’t have an engineering background, manage a team? Let’s start by looking at what strengths they can bring to the table.
I can’t hog opportunities for growth. Technical managers can keep the more interesting, challenging, or complex pieces of work for themselves. This can happen when a manager perceives their technical or individual ability to be their primary value.
Manager that focus on their individual ability lose the bigger picture — that they need to amplify their teams. As an individual contributor I was only responsible for my own work which was around 2,000 hours per year.
I am now responsible for the output of 17 people (counting myself), which is about 34,000 hours of work per year. If a manager is focused on themselves and what they can do rather than their team — their impact is minimized.
I am a walking “rubber duck.” My team often has to simplify and explain their thoughts around me, creating positive secondary effects.
My team is used to hearing me say a quote from the movie Margin Call: “Please explain it as you might to a young child … or a Golden Retriever.”
Being a rubber duck constantly proves helpful to my teams in our group discussions. Often, important assumptions and underlying concerns are revealed. Ideas are also refined and improved by talking them through and breaking concepts apart in a simpler way.
I can’t micromanage. Since I am not an expert in my team’s work, I can’t micromanage them by staring over their shoulders. I am not going to judge someone’s quality of code against my own. My teams have space, empowerment, and time to self-organize.
Tips for non-technical managers
Be vulnerable and ask a lot of questions. Accept you have a lot to learn and embrace it. Shame about that fact will hinder you. Learn to be vulnerable.
Constantly listen, understand, learn, and reflect back information in conversations. Encourage your team to correct you (both publicly and privately) whenever you reflect information back poorly or don’t seem to understand something.
Don’t micromanage what you don’t understand. People often increase control over what they don’t understand. This will slow down everything and everyone. Trust your team and find your own independent value over time.
Be constantly curious and dig deep when you can. Take advantages of the times you can dig into a technical issue or subject. Most of the time your team and customers will happily discuss them in detail with you.
Define your value. Over time, I learned technical skills to augment my team:
- Development of use cases, product needs, and requirements from the broader organization
- Creating bug, feature, and issue specifications
- Neutral facilitation of technical conversations (since I don’t have an opinion)
- Prioritization/triaging of bugs, features, and issues
What is right? Technical Managers or not?
A 10-year study from Google identified the top ten behaviors in their best managers. Out of the top 10 of those behaviors, only one of those directly references technical skills.
In my opinion, it comes down to the individual job itself. Does a manager need to be technical? Yes. But how technical? There are a number of factors that might influence how technical a manager needs to be.
- What are the needs of the organization/team?
- Is there support to grow this individual’s technical skills?
- What is the size of the team and the type/complexity of technical work?
- What is the experience makeup of the team (Leads/Senior/Mids/Juniors)?
- What are the type and complexity of the team’s work, and it is novel/unique?
Originally posted to my Medium blog