“There are only two hard things in Computer Science: cache invalidation and naming things.”

— Phil Karlton

Introduction

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 responsibilites 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, who’s 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.

Why Archetypes?

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 or 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 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 team best 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 that 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 skill set 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 a 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.

Acknowledgements

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 a technical leader? Visit the http://techlead.academy, for training to accelerate your technical leadership journey.
• Do these archetypes resonate with you? What other ones have you seen? Leave a comment.