“There are only two hard things in Computer Science: cache invalidation and naming things.”— Phil Karlton
In today’s tech organisations, you find 2 types of technical leadership roles in teams – Tech Leads and Engineering Managers. Tech Leads are better defined with The Definition of a Tech Lead but the Engineering Manager (EM) role remains unclear. In this article, we will explore 5 Engineering Manager archetypes commonly found in the industry.
Roles Differ Across Organisations and Teams
Role names, job descriptions and titles are never consistent. The scope of one role varies across organisations and sometimes even within the same organisation. For example, despite many attempts, we still have no industry-wide definition for a “Senior Software Engineer.” See “On Being A Senior Engineer“, “What Makes A Senior Software Engineer“, “8+ Years of Experience isn’t the Definition of a Senior Software Engineer…” or “What Defines a “Senior Developer?”“. In response, each organisation defines their own expectations in what is typically called a “growth framework” or “career ladder.” These expectations are rough approximations and each “growth framework” or “career” ladder is different. http://progression.fyi offers a number of real-world examples.
Leadership roles vary even more as leaders step in to fill gaps. These gaps may be temporary as a leader finds someone to fill the gap in the long-term. Take a snapshot of a team one day, and a leader’s scope may be quite different from a snapshot 6-12 months later. For example, when a team doesn’t have a Product Manager, its responsibilities must still be cared for. Someone must manage stakeholders, establish priorities and manage internal and external communication. Sometimes a team chooses to distribute the responsibilities across team members. More often, an existing leadership role like the EM inherits them.
I’ve read hundreds of EM job descriptions and spoken with many more EMs. Unlike a Tech Lead, whose responsibilities are roughly consistent, the EM’s responsibilities vary much more. A single definition would be too generic to be useful or too narrow to reflect reality. View the role of the Engineering Manager as one of five different archetypes: The Tech Lead EM, Team Lead EM, Delivery EM, Product EM and the Lead of Leads EM.
We can think of archetypes like software design patterns. Common structures you might see again and again. I think of archetypes like the character classes in a role-playing game (RPG) such as a mage, ranger, or warrior. In an RPG, one character class is neither better nor worse than the other. Each offers a different combination of strengths useful in different circumstances.
In an RPG, a person selects a particular character class, each with a starting set of skills. As the character completes quests or overcomes battles they gain experience points (XP). A person uses XP to strengthen or acquire skills. You might recognise a character from their starting class but they will look different over time. We can treat these archetypes as different character classes for an EM.
Let’s assume we have 10 XP (represented as 🌟) per archetype, preallocated across different skill areas. The higher the 🌟 rating, the more expertise and experience they have in that skill area. The skill areas are outlined below.
| || || || |
Archetype 1: The Tech Lead EM
The Tech Lead EM archetype emerges when a person assumes both EM and Tech Lead roles. The Tech Lead EM manages team members and leads a product’s technical direction. The Tech Lead EM writes code on a regular basis and is often an expert or experienced coder in the team’s tech stack. They focus on providing architectural direction and managing technical debt. Besides leading technical topics, they lead and manage team members. They run regular 1-to-1s, foster a culture of feedback and build a high-performing team.
The Tech Lead archetype acts as a strong technical mentor for team members, often more hands-on than other archetypes. They model ideal developer behaviours and advocate for good engineering practices. Example practices might include pair programming, trunk-based development (TBD) or test-driven development (TDD). This doesn’t mean they are always the developer with the most expertise. Instead, they use their technical expertise to improve quality through design or code reviews. They champion improvements to technical quality continuously. This includes plans that improve performance, or remove complexity to improve a system’s ability to evolve.
A Tech Lead EM is less effective when the team grows beyond 4-5 people, or a system grows in complexity and scale. With a bigger team or more complexity, the Tech Lead EM has less time to equally care for both people/team and technical topics. The Tech Lead EM prioritises one area at the cost of the other, or tries to do both poorly. Due to their hands-on nature, many choose to prioritise technical topics at the cost of people/team topics.
Archetype 2: The Team Lead EM
One of my earliest teams had two people sharing leadership responsibilities – a Tech Lead and a Team Lead EM. The Tech Lead excelled at keeping abreast of architecture and technical changes. They were less skilled at growing people and building a high-performing team. The company added a Team Lead EM to provide balance. The Team Lead EM had less technical expertise but was great with people, so inherited people and team management. You will often find the Team Lead EM paired with a Tech Lead.
In some organisations, the Team Lead EM may not write any code. Their value add is managing the environment and growing people to enable the team to do their best work. This might involve removing blockers, managing stakeholders and risks. The Team Lead EM has a strong focus on growing individuals, providing feedback, coaching and mentoring and addressing performance issues.
In some organisations, the Team Lead EM may write some code but represents only a small fraction of their weekly calendar. Where a Tech Lead EM actively drives technical discussions, the Team Lead EM may only step in when the team is unable to reach a decision.
The Team Lead EM organises activities to increase team engagement and foster team spirit. They communicate with external stakeholders, distilling information into useful context for the team. In large organisations, the Team Lead EM navigates complex structures to resolve dependencies. The Team Lead EM builds the best team they can.
In some companies, a Team Lead EM manages engineers spread across multiple teams. A common example in cross-functional teams is a functional lead (e.g. Mobile Team EM) but each person they are leading or managing sits in different teams in different product areas. In this setup, the Team Lead EM has more difficulty assisting with or keeping track of day-to-day activities. Where the Team Lead EM doesn’t have a common goal for the people they are leading, some organisations call this archetype a “People Manager.”
Archetype 3: The Delivery EM
You will typically find Delivery EMs in project or date-driven organisations. These organisations demand a lot of paperwork or time in meetings. Typical examples include preparing regular status reports and attending review or approval meetings. I have seen these Delivery EMs when working with external development teams. Many Delivery EMs have a strong project management background.
Since this archetype typically exists in project or date-driven organisations, success means delivering. A Delivery EM focuses on technical or team topics when they see delivery at risk. Effective Delivery EMs understand the positive impact of good technical quality and high-performing teams. But they will delegate these to team members or other roles like a Tech Lead or Senior Software Engineer.
Delivery EMs spend significant time managing many stakeholders and a delivery roadmap. Organisations with Delivery EMs usually see teams as a vehicle for delivery. These organisations fail to see teams can also be a source for potentially better product features or ideas.
Archetype 4: The Product EM
In many teams, the EM works with a Product Manager to scope what a team works on. Where a Product Manager focuses on the “What” or “What Next”, the EM works with the team on the “How”, “How Big” and “How Long”. Some teams don’t have a Product Manager role, so the EM inherits these responsibilities, giving birth to the Product EM archetype.
Like the Delivery EM, the Product EM spends a lot of time away from the team. The Product EM needs to spend time with stakeholders but they also need to spend as much time as possible with end-users. This contact with end-users gives them a better ability to refine the product roadmap.
A specialised Product EM archetype emerges when a team provides a technical product or service. Typical examples include Platform or Infrastructure teams where the users are deeply technical. In this case, the Product EM has a slightly more technical background than your average Product EM. These types of Product EMs are more technical because they need an intimate understanding of the “How.” Product EMs take interest in the “How” because it constrains or enables the “What” or the “What Next”.
The Product EM’s biggest challenge is managing time effectively. Depending on the phase of a product (e.g. experimental, scale, or stable) a Product EM may find themselves spending more time outside of the team than with the team. Essentially they find they are working as a full-time product person, making it more difficult for them to lead and manage their team effectively.
Archetype 5: The Lead of Leads EM
You find the previous four archetypes at a team level, leading a group of 3-8 people. What makes this 5th archetype different is that they lead a much larger group of 9-30 people. The larger the group size, the less sustainable it is for one person to lead individuals and manage work. Thus the Lead of Leads EM leads a group of people, each themselves acting in a leadership role.
The Lead of Leads EM appears more often in larger organisations with a focus on maximising the effectiveness of a group of teams. They do this by managing the supporting structures and filling in gaps. These might include changing team structures, reallocating or splitting work, and iterating over planning and communication processes. The Lead of Leads EM works very closely with the business and product teams, ensuring their group delivers the most impactful work.
The Lead of Leads EM is an evolution of one of the other EM archetypes. Yet it is still often labelled as an “Engineering Manager”. This archetype requires more experience and owns a greater set of responsibilities. Some organisations use a different name for this archetype. Some may use the title “Senior Engineering Manager” or “Head of Engineering.” Remember that role names and their expectations differ across organisations. Instead of focusing on the name or title to detect this archetype, focus on the scope and team size.
Those moving into engineering management should avoid the Lead of Leads EM archetype. Building core leadership and management skills is difficult enough for a first-time manager. The Lead of Leads EM archetype requires the added ability to lead other leaders. This is a significantly different skillset from leading individual contributors. Leading other leaders demands a broader understanding of different leadership styles. It also means a person must adapt their own leadership style in response. Successful Lead of Leads EMs first built their skills leading at a team level before transitioning to this archetype.
Use These Archetypes as a Conversation Starter
The fluidity of the Engineering Manager role leads to too many misunderstandings. It is easy to have a misunderstanding when two people attach different meanings to the same word. A role a is useful shorthand for the set of responsibilities attached to it. But only when people have share a common understanding.
These archetypes are useful to qualify what expectations you might have for an EM. In reality, roles change and evolve. A person in the same team might play one archetype. Fast forward 6-12 months and that very same person in the same role may play a different archetype. And that’s perfectly fine! Like George EP Box stated, “All models are wrong, but some are useful.” I hope these archetypes prove useful to you.
Thanks to Francisco Trindade (@frankmt), Gergely Orosz (@GergelyOrosz), Luca Grulla (@lucagrulla), Maria Gutierrez (@mariagutierrez), Sarah Pimentel Abrantes and Tim Goodwin (@timrgoodwin)for providing early feedback on this article.
- Enjoy this article? Sign up for Level Up, a free curated newsletter for leaders in tech.
- Want to level up as an Engineering Manager? Sign up for training with the Engineering Manager Essentials course or self-paced courses at http://techlead.academy
- Do these archetypes resonate with you? What other ones have you seen? Leave a comment.
11 thoughts on “5 Engineering Manager Archetypes”
I really enjoyed reading this article and how it creates a new vocabulary for us to talk about team leadership roles. My only suggestion would be around the readability of the text. The use of “EMs” breaks fluidity and makes reading the article very cluncky. I would suggest, for example, you defining the roles at the start and refering to them later in the article without the EMs where possible. Or surpress the EM altogether on the archetype names. Hope it helps!
The Team Lead EM sounds a lot as a Scrum Master.
Thanks for this article. Very useful. Also the related links.
There’s a lot of variance with Scrum Master’s. My understanding is that the only role a Scrum Master should have is about helping a team adopt Scrum. Many organsations go overboard with the role which is probably why you see many similarities.
Very helpful article Pat! I read another one that that this makes a good companion to by Amy Phillips if anyone would like another perspective.
I agree with the Santiago that Team Lead EM does overlap with the scrum master duties and is very much like a role I have on my teams. Additionally, to Pat’s point, I’ve always considered the Team Lead EM & Tech Lead EM to be co-leaders of the team and part of my extended leadership team as they exhibit such complimentary skills.
Thank you very much. Amy’s article is also very good.
Hi Pat, the article was very useful. I need a suggestion from you. I am about to take a MEM course (
Course Link – https://www.uowdubai.ac.ae/computer-science-and-engineering-programs/master-of-engineering-management-mem-degree ). What do you think about taking this course? Expecting your suggestions.
Hi! Taking a quick look, it looks like the program targets more traditional fields of engineering (like mechanical). There is probably some useful theory and concepts that might apply but not sure how well they will directly translate into the field of software engineering. I didn’t see any focus on software topics and there are some strong differences amongst physical engineering and software engineering IMHO.
I’m a bit late to this conversation, but something I remind people about is that I am not an “Engineering Manager”. I am a manager of engineers. My primary job is to provide feedback, delegate work, and coach my reports on their performance. My primary tool for this is the one on one. There is nothing unique about engineering that requires special tools or knowledge when it comes to managing people.
There is a Software Engineering Management, but that is more about the process, the product, and establishing controls and metrics. The term “engineering manager” is meaningless. My focus is on the people.
It sounds like you have a clear picture of what your role is, which is great. It also sounds like you need to manage expectations of people who have different expectations of you. I can understand how you might see the term, “Engineering Manager” as “meaningless” from your perspective, but that does not mean other companies and roles do apply a certain meaning (and therefore expectations) to this term and why this post seems to resonate with many people.
Hi Pat! Loved the article! Can i translate it to portuguese?
Thank you in advance
Hi Rafael. I’m glad you liked the article. As I have no way to verify translations (i.e. my Portuguese is non-existent), I would prefer not. Thank you, though, for your offer.