A Non-Coding Engineering Manager is One Thing, But What About Non-Technical?
A hotly debated topic is how technical an engineering manager needs to be. I dive into the topic, including ways a non-technical leader can learn.
Welcome to the Scarlet Ink newsletter. I'm Dave Anderson, an ex-Amazon Tech Director and GM. Each week I write a newsletter article on tech industry careers, and specific leadership advice.
I’m going to focus on engineering managers in this article, but I think the key concepts apply to any technical management position. We need to know how we identify which technical skills are necessary for a technical manager, and how do we build those skills if we’re not already there?
I was a senior engineering manager at Amazon, managing a group of multiple engineering teams. Lawrence worked for a peer of mine, and was likely my 47th favorite engineering manager at Amazon. I only knew around 48 engineering managers, so Lawrence was only really beating that dude from another country who insisted on scheduling a daily recurring status meeting at 10pm my time because I wanted some work from his team. No, I’m not bitter at all.
We were going through our annual planning process at Amazon (OP1), and one of my teams had a small dependency on Lawrence’s team creating a small new API in their service (let’s call it API XYZ for simplicity). On the positive side, I knew multiple other teams had the same dependency, so it was almost guaranteed to be funded.
I was a senior manager, and was part of the review committee looking at OP1 requests. We were ensuring that teams were fairly estimating their work, balancing their team’s investments among our highest priorities, etc. I noticed a pretty large oddity. Lawrence’s team had a 4-week estimate for building API XYZ for another team (call it Team A). That estimate sounded reasonable. But his team also had an estimate for building it for Team B, Team C, Team D, and one for my team. In all, he had 4 weeks logged against literally five teams to build the same API. In total, 20 weeks for what should be a 3 to 4 week task.
Something to keep in mind is that headcount at Amazon mostly works by a bottoms up additive approach. You add up all the important work a team needs to do, you calculate how big the team should be, and you give them that headcount. This means that multiplying his ask by 5x was asking for more resources for his team that he didn’t need.
As an experienced senior leader, I knew that the best option was a careful conversation with Lawrence in private to avoid embarrassment and an uncomfortable conversation. And yet, I decided to discuss it immediately in the group setting because Lawrence was my 47th favorite engineering manager. I think most of us have our moments of less than perfect behavior.
If you’re new to Scarlet Ink, welcome! Each week, I send an article to all subscribers. Free members can read approximately half of each article, while paid members can read the full article.
For some, half of each article is plenty! But if you'd like to read more, I'd love you to consider becoming a paid member!
Ok, on with the story!
“Lawrence, I have a question for you.” I said. “I see you’re building API XYZ, but you have 5 estimates booked against the same project. Why is that?”
Lawrence looked at his spreadsheet and nodded. “Yes, all those teams require that work to be done.”
“I agree that we all need the work done, Lawrence. But why are you doing the work 5 times?” I asked. “We all required the same work.”
Lawrence looked a bit confused, and looked at his manager. We had the estimates projected onto a screen on the wall. Lawrence’s manager was sitting there quietly, looking at the estimates. Lawrence’s manager was also not one of my favorite people.
“Well, the work is specific to each team.” Lawrence said. “We need to verify their requirements, and identify the overlapping needs, and ensure that our new API meets their needs individually.”
That was so much handwaving nonsense. Nonsense bothers me.
“Lawrence, have you seen the requirements?” I asked, a bit irritated. “We already collectively agreed that the requirements are exactly the same between our teams, and the API we all need is identical. There is no separate work required. You were in the room when we decided that. Did you forget?”
Lawrence looked at the spreadsheet, and at me, and then at his manager, and then at the spreadsheet.
Lawrence said, “Well, if you are all willing to commit that you won’t require any special development for your team, and you agree to take whatever API we build for Team A, then we can delete the estimates for the other teams, except for a 1-week per team for verification and QA.”
He had lost his attempt to multiply his request for headcount by 5, but was still trying to get a consolation prize of 1-week from 4 teams (literally a whole month of engineering effort). He clearly hoped that we’d shrug and move on. That often happens, when we run out of emotional energy to fight our co-workers. I don’t like shrugging and moving on. In fact I’ve received feedback before that I could be a little bulldogish on these topics.
“We don’t need a week of verification, Lawrence. If you build the API, we’re done. Please delete the estimates from the other 4 teams.” I said. As a senior leader (and perhaps more importantly, the only person talking in the room), I could make strong statements like that, and it would likely be followed. Even though Lawrence didn’t report to me.
Lawrence nodded and updated the spreadsheet while we watched the shared document. For what it’s worth, Lawrence’s manager still hadn’t said a single thing.
What happened behind the scenes in this story? A few things.
The key topic of this article. Lawrence was not one of my favorite engineering managers, in part because he was never on top of the details. He delegated all technical decisions to his team, to the point that he didn’t understand the critical decisions he was approving. While there’s considerable value in trusting your engineering team, I believe an engineering manager needs to be able to understand major topics, and ask the right questions. Lawrence was not asking questions. Lawrence was not only trying to steal headcount in this case, he also honestly didn’t understand what we were requesting. Through multiple discussions before and after this meeting, it was clear that Lawrence was putting numbers in a spreadsheet he didn’t understand.
Plenty of managers are not good at their jobs due to various reasons. Lawrence was missing communication and technical skills. Lawrence’s manager was missing basic leadership and ownership. Lawrence could honestly argue that his manager didn’t help him in this situation (or to prevent this situation). However, having an excuse doesn’t prevent your career from ending. You can’t fix your manager. If you run into a situation with a bad manager, you have two major options. You either change teams (which Lawrence probably should have done), or you learn to perform well without your manager’s assistance (another option for Lawrence).
I called out Lawrence because I didn’t trust Lawrence, I was annoyed at what Lawrence was doing, and I had no particular reason to preserve Lawrence’s credibility within the organization. If Lawrence had built trust with me before this meeting (such as being friendly with my team, volunteering to help others in the organization, mentoring new employees, etc), it’s entirely possible I would have chosen to confront him in private. Fair or not, your reputation with your co-workers can help you or bite you.
Another small point. I was in a room full of senior leaders. They didn’t speak up, I did. What frequently happens in meetings of all types is that there are a few loud voices, and many quieter voices. The loud voices exert outsized impact on the larger group. You can dislike that (as a quiet voice), or you can be a loud voice and lead. Your choice.
I’ve explained in the past why I don’t believe coding skills are necessary for technical managers. However, what about technical skills in general? Can you be a good engineering manager with a background in the culinary arts? I exaggerate, but I think this is an important topic to unpack.
In my experience, as an engineering manager, being technical is critical. You can say “I don’t code” or even “I’ve never coded”, but that doesn’t give you an excuse to only be a people / resource manager. Technology companies are not looking for someone to allocate humans to projects, they’re looking for engineering managers, or design managers, or QA managers. They need expertise.
Let’s walk through a few key topics.
What determines what a technical manager should be involved with, and what they can delegate?
Which technical skills are critical based on that knowledge?
How do you build those skills if you’re not already there?
What should a technical manager be involved with, and what can be safely delegated?
There are a few key measurements to determine how much a manager should be involved in the details.
Long-term vs. Short-term impact.
Are you designing the next version of your major service, which will be worked on for the next 3+ years? Huge long-term impact, the manager should be involved in the details.
Is this a temporary script to be used for a data migration? Short-term impact, may not need manager involvement.
Big risk vs. Small risk.
Would an outage of your service cause a severe financial impact to your customers? The manager should be involved.
If the new marketing campaign doesn’t work, it means the loss of some funds, but it’s not materially impacting to the organization. Might not need manager involvement.
One-way vs. Two-way doors.
This is a massive one I’ve talked about before.
If you are designing an API schema to be released to external customers, the manager should absolutely be involved.
If you’re designing an API to be used by a peer team within the company (and it can be safely changed later if it doesn’t work well), it might not need manager involvement.
High vs. Low political impact.
It might feel unfair, but if your VP cares about a specific project, the manager should be involved.
If it’s item 72 on your priority list, and only one low-level product manager cares, it might not need manager involvement.