The Engineering Manager is not a Tech Lead
How getting this wrong leads to robotic tech leadership
No unicorns available
I see Engineering Manager roles advertised like the one above, from Adobe, all too often. They are looking to hire someone who is an Engineering Manager but who will also act as a Tech Lead. It is my conviction that job descriptions like this are confusing two very different roles and trying to munge them together, which in my experience, never works out.
The summation of the problem is that too many companies are looking for a unicorn who somehow:
Possesses the exact measure of hard and soft skills required to contribute to code and lead.
Has the ability to switch between manager and contributor modes at the drop of a hat without any side effects.
Is equally qualified and experienced in writing software and managing people.
Is equally passionate about writing software and managing people.
The type of person who can truly meet the requirements of such a role is so rare that in 20 years of working in tech, I’ve never interviewed or worked with someone who completely fits the bill.
What usually happens is that the company hires or promotes an individual who genuinely believes they can do the job — or will give it their best shot while knowing they will realistically have to lean more or less into the coding or people management and not both. Someone in this role is destined to please their leadership but disappoint their team, or vice versa. Sometimes, people in these munged roles allow chaos to unfold on their teams because they are too focused on being a good Software Developer or Tech Lead. Others will do a great job of managing the people but will lose respect from higher-ups who expect them to have a stronger hand in guiding technical requirements and make frequent contributions to the codebase.
Call me jaded, but middle management and above are often not aware of (or don’t particularly care about) the nuances of leadership challenges at the line-manager level.
Call me jaded, but middle management and above are often not aware of (or don’t particularly care about) the nuances of leadership challenges at the line-manager level. So ideas like creating a hybrid manager/tech lead role must seem attractive as a way of consolidating roles into a smaller headcount, but may not be very firmly based in reality.
The crux of the problem
In some organizations, this misunderstanding about the Engineering Manager role stems from the fact that even at higher levels like Director or CTO, leaders are still overly focused on managing the technical roadmap and aren’t assigning enough importance to great people management. It is not unheard of for Director’s and CTO’s at some organizations to be very hands-on with the code themselves, or to micro-manage their direct reports with regards to technical oversight, therefore it is no wonder that the soft skills and responsibilities of people management are under-appreciated, downplayed, or misunderstood. At these companies, it is a written rule that managers must remain technically excellent and an unwritten rule that those skills trump all others. These same leaders are notorious for their lack of compassion, empathy, and basic leadership, and people do not enjoy working under them, but the low morale amongst tech teams and the constant churn of employee turnover don’t seem to get in their way or cause any self-reflection.
Unfortunately, many leaders in the tech industry have never learned people skills, and may never have been encouraged to do so — many organizations lack formal growth and training plans for new managers. Then, as these leaders climb the corporate ladder, they continue to over-index on their hard skills and allow it to become their unwavering worldview, which then trickles down through all the other rank and file until the overtly technical bias of leadership becomes normalized. People who lack empathy and communication skills promote more of the same archetype. The fish rots from the head, ad infinitum.
Why this is a problem
My first foray into Engineering Management was in just such a hybrid role that we’ve been describing: I was given three Software Developers to manage and was expected to continue my previous role as Senior Software Engineer at the same time. In many ways, just as Wil Larsen has written, this manager/tech lead role is a trap. When I began, I was excited to develop my soft skills and learn how to be an effective leader, but I still had to stay fully immersed in the code, provide technical guidance to the other developers, and help make big architectural decisions.
This ended up being a fool’s game where no matter what I focused on, I was losing, and letting down either my team or my manager. When I took deep dives into the codebase and tried to lead new feature builds, large refactorings, or migrations, I wouldn’t come up for air for days, leaving team members with an inaccessible manager who could not empathize with them when they were struggling.
Conversely, when I decided to focus on team behavior, individual career guidance, or learning how to conduct the best 1:1 meetings, my work was mostly invisible to my manager and higher-ups, and they seemed skeptical, even distrustful that I was providing value because it couldn’t be measured in lines of code or features shipped. I would arrive at my 1:1 meetings disorganized and unprepared because my mind was still dwelling on code problems, meanwhile, I was spending enough time thinking about the team or helping them overcome hurdles on other days that I then had to work extra nights and weekends to avoid missing code completion deadlines for products that needed to be shipped.
Who cares about the people behind the work?
As I’ve alluded to already, I believe a major reason for this lack of trust is company culture that over-indexes on individual code contributions and a management hierarchy that assumes effective people management is of secondary importance and can not be measured. I was sometimes given the feedback that because I only managed three direct reports I had plenty of time to be heads down in code. After all, three 1:1 meetings per week only amounted to 90 minutes, assuming I met each of them for 30 minutes a week. I was told my time should be at most, 80/20 split between software development and management. This, of course, is an egregious error in understanding how a good people manager spends their time.
So, should an EM be technically proficient?
An Engineering Manager can, and absolutely should be an individual with a background in software development, and ideally should have worked on the same or similar codebase as the one their direct reports are building and maintaining. For this reason, some of the best Engineering Manager candidates may come from within your existing employee base, rather than your external pipeline. The reason for this is that to be an effective manager of the team, they will need to be able to relate to the type of work performed by team members and empathize with the types of problems they will run into during their time on the team. But it’s important to draw a distinction around how they are measured in their role and what they are truly accountable for.
The truth is, there are various ways to approach the Engineering Manager role, and that could depend on the kind of organization you have, whether or not the company is a start-up or a mature enterprise, and whether or not the tech department is split into large teams or consists of very small teams. Wherever your company lands on this spectrum, the Engineering Manager is going to be a role consisting of trade-offs and it’s critical to understand that not all hats can be worn at all times or provide the same level of value. To make the role of Engineering Manager fair and equitable, leaders should offer clear guidance and clarity within a framework that actively acknowledges the boundaries of the role and keeps expectations realistic.
Archetypes
Pat Kua did a great job of highlighting these trade-offs in his ‘5 Engineering Manager Archetypes’. You should read his whole article, because it explains everything in a nutshell, but I’ll call out the second archetype as the one that I think most established companies should try to hire or promote, which is the type of Engineering Manager I always strove to be:
I want my readers to be aware of the nuance here. The above archetype is for a team lead EM, not a tech lead EM (Kua’s 1st archetype). The trade-off is clear: a team lead can’t spend much time in the technical realm or focus on process or product because they are aligned with making sure they take care of team needs first and foremost. There is no such unicorn, not even a robot unicorn, who can navigate each of these responsibilities with equal attention and energy.
The reason I index on this archetype is that I believe an Engineering Manager is primarily a manager — it’s in the name for goodness sake, and any measurement of technical ability should be evaluated in the sense that individuals in this role should know enough to be empathetic toward their team and for the team to respect their prior background experience, not to the extent that they are still expected to fulfill the requirements of a Software Engineering role — because as we’ve already discussed, that is untenable and unsustainable and will lead to burnout and disengagement.
What does an EM do?
In my professional opinion, a (non-exhaustive) list of what the Engineering Manager should be responsible for:
Cultivating team culture.
Building an environment of trust and psychological safety.
Providing career guidance.
Maintaining consistent, meaningful, and impactful 1:1’s.
Organizing team activities that build camaraderie and increase employee retention.
Hiring and onboarding new team members.
Staying in the loop on project progression, company policy changes, and best practices across the org and communicating these to the team.
Raises, bonuses, and performance reviews.
Fostering good relationships with non-tech stakeholders and other groups within the organization.
Raising awareness of team-level and individual achievements and leading the charge to celebrate wins.
Giving constructive, contextual, timely feedback regarding the individual behavior of direct reports.
At the same time, an Engineering Manager should be prepared to:
Provide some technical oversight (but not micromanagement), particularly on aspects of the work where they have more layers of business knowledge, domain expertise or a history of working in the same codebase.
Help senior developers plan out and design large architectural overhauls, leaning into trust but being accessible and ready to share opinions when it is helpful
Identify and build relationships with vendors who can provide tools and services needed by the team
With the understanding that many such technical decisions can also be delegated to senior staff as long as they are trusted and are given adequate guidance.
The backlash
There is nothing controversial about the above archetype and the list of expectations for the role, and yet I’ve personally experienced coworkers and managers who are quick to cast dispersions at such an idea, usually for the reasons already outlined: they simply can’t imagine a world in which technical people benefit from management that is primarily more human-centered and not overtly technical in nature, and they could never see themselves prioritizing the soft skills necessary to be effective in a role bounded and measured by how well one can motivate, inspire, coach and mentor employees on the emotional, cultural and psychological level rather than the level of technical mastery. Some of them are critical of the idea of delegating technical decisions to senior development staff, who I’ll argue are sometimes more keenly aware of the requirements and specifics of implementation and in a better position to see the benefits and drawbacks of any particular solution. This is a shortcoming on their part, not mine.
The ideal partnership
Furthermore, there’s no reason why any good people manager in tech can’t be paired up with a Tech Lead or Staff Engineer whose role is primarily focused on technical leadership and mentoring, without the overhead of team leadership. This could be the ideal partnership for many organizations if they do it right. On large teams, you’ll ideally also have senior staff who are able to prioritize process (Project Managers) and product (Design leads and Product Managers). The whole point of building a great team is to have people who can dedicate their energy to the right things. You don’t want them to be uncertain of their responsibilities, or trying to juggle too many competing priorities.
If you’ve ever received a top-down missive from the CTO that spoke to everyone like they were robots, you know exactly what I’m talking about.
Don’t feed the robots
I really wish companies — especially the large ones with thousands of technical staff — would stop posting such confusing job descriptions which lead to the proliferation of this misunderstanding and the continued problem of new Engineering Managers being caught between a rock and a hard place. I believe the confusion and lack of respect that organizations lend to this role is the reason why so many Engineering Manager’s give up at some point and end up going back into the purely technical track. It’s also why so many Engineering Manager’s and more tenured technical leaders never learn the importance of leading people in a humane way. If you’ve ever received a top-down missive from the CTO that spoke to everyone like they were robots, you know exactly what I’m talking about.
Companies that just don’t get it are allowing tech to exist in the absence of humane leadership. They are fostering a culture where tech leaders are robotic and treat their staff like mere cogs in an emotionless machine. They help to perpetuate an elitist and ultra-competitive culture where technical ability is the only currency. This may be why we have lately seen so many tech layoffs that have been devoid of empathy, why CEO’s have been mandating RTO, and why some companies seem to be poised to replace large numbers of workers with generative AI. The leaders at such companies are not demonstrating emotional intelligence, and it suggests to me that they never developed quality leadership skills, or the fundamental ability to read people, to empathize, or to seek to understand before they dictate. They don’t see people for who they are or for the potential of who they can become, they simply see skills, ROI, and numbers on a spreadsheet. They have a pretty fixed mindset when applied to people.
A bit of self-reflection is a good idea
If you are currently working as an Engineering Manager, what are you most comfortable with? Providing technical oversight, slinging code, or talking one-on-one with your direct reports and learning how they tick? When you reflect on your career so far, are you more invigorated by the thought of all the features you’re helping to ship and the new code frameworks you’ve learned, or do you find yourself musing on the simple joy of watching people grow? I’m arguing that the manager who leans more to the latter is going to be a more effective leader in the long-run and that if your passion is for crafting code then you’d be happier and more productive if you returned to the engineering track and aimed to become Staff Engineer instead.
And a friendly warning from someone who has been there: if you find that you were feeling great about your management career for a while but then you’re asked to dive back in at the deep end and own a large piece of the codebase because your manager has become distrustful, the bus factor on your team has suddenly dropped due to your team being reduced by ‘budget cuts’, or team members are quitting because of unfavorable work conditions, don’t roll up your sleeves unless you really want to become an IC again. I’m serious: it’s time to polish off your resume at that point — because the right solution would be to hire back-fills for the missing staff but your team obviously isn’t considered critical and is therefore disposable. Know your worth, and own the path you want to be on.
Becoming an Engineering Manager can be extremely rewarding and can put you on the path to Senior Manager, Director, and CTO roles, but only if you’re able to exercise the right qualities and prioritize the human aspects of your work. If you’re working for a company that doesn’t understand or appreciate the complexities, nuances, and value that management brings, outside of technical prowess, then in my opinion, you are not working for a company that truly understands the value of people or celebrates the myriad ways we can contribute.
Fantastic points, Jim. This aligns well with my thinking that an engineering manager should not be a code leader. An engineering manager should be a people leader first.