The Engineering Manager Archetypes π
A thorough framework to identify how engineering managers create value inside orgs.
Hey, Luca here! Todayβs article is from Thiago Ghisi, a dear friend and one of the most thoughtful engineering writers I know.
Over the past two months he created an incredible framework for identifying how engineering managers operate and create value inside organizations, backed by a ton of research + tens of real-world stories he witnessed and collected first-hand.
I am thrilled and honored that he is publishing it first here on Refactoring.
Long before we had words like red or blue, people used quick analogiesββlike blood,β or βlike the skyββto describe what they saw. This was fine at first, but it got limiting. Eventually, we coined color names, and that gave us a shared language for discussing color variations with precision.
Likewise, when it comes to people's behavior and leadership, we often rely on vague imprecise descriptions (βheβs too controllingβ, "sheβs hands-off", "he is a people's pleaser"). But thereβs a better way: archetypes.
Archetypes show up all around usβin myths, symbols, stories, and especially in the roles people naturally step into. We recognize them instinctively: the Hero, the Mentor, the Caregiver. But without clear names, we struggle to talk about these patterns with precisionβso they remain felt, but unnamed.
Finding and naming these archetypes is like creating a standardized color palette: it streamlines communication and exposes biases. Instead of vague criticisms like βthey take over everything,β you might say: βtheyβre leaning into the Hero archetypeββsomeone who steps up in high-stakes moments and takes responsibility fast. That taps into shared context and opens up a more useful conversation about strengths, risks, and situational fit.
So, the goal of this article is to provide a thorough framework for Engineering Manager archetypes β built on real-world patterns Iβve observed in fast-scaling startups and Big Tech.
These Engineering Manager (EM) archetypes should clarify the force a manager brings to a team. Itβs not about pigeonholing anyone, but rather understanding where you naturally thrive, how to harness your strengths, and what complementary skills will help you grow.
By the end, youβll know which quadrant you most often lean into and how to leverage it for greater impact.
So here is the agenda:
π§ Where do archetypes come from β from classical psychology to modern leadership.
π¬ Limits of existing EM archetypes β why we shouldnβt focus only on skills and tasks.
πͺ Images of leadership β moving from skills to modes of operation.
π Engineering management quadrants β balancing stability, change, people and execution.
π₯ Engineering manager archetypes β identifying both productive and failure modes.
π― How to use archetypes β for your personal growth and your team success.
π³οΈ How to find your archetype β with a little help from AI.
Letβs dive in!
π§ Where do archetypes come from
Human archetypes might look like the quintessential engineering abstraction, like design patterns for people, but the idea goes way back. Carl Jung used the term to describe recurring roles we instinctively recognize: the Hero, the Mentor, the Caregiver. He believed these patterns lived in a kind of collective unconscious: a shared mental codebase built over generations.
If a Large Language Model learns from the collective text of the internet, Jungβs collective unconscious is like humanityβs behavioral dataset. Archetypes are reusable modules in this repository, shaping how we respond to leadership styles, team dynamics, conflict, and changeβoften without us realizing it.
Today, archetypes are often used as shorthand for types or patterns. However, Iβm using them more deliberately hereβto describe the recurring roles we step into when we lead and collaborate. And no, this isnβt new in tech. π
π¬ Existing EM archetypes
If you ask Google or your favorite LLM about Engineering Manager Archetypes, you will likely get a combination of 3 articles, written by some of the most knowledgeable people in the industry: Pat Kua, Charity Majors, and Will Larson.
These are largely different frameworks, with some ideas in common:
5οΈβ£ Pat Kua outlines five β the Tech Lead EM, Team Lead EM, Delivery EM, Product EM, and Lead of Leads EM.
4οΈβ£ Will Larson maps four β the Tech Lead Manager, Team Manager, Group Manager, and Executive Manager.
7οΈβ£ Charity Majors describes seven β which reflect managersβ backstories or frustrations.
For the sake of clarity, these are incredible authors: they have made enormous contributions to our understanding of engineering management. I have learned a lot from them and am super thankful for their efforts (so the following is not a critique of them by any means).
At the same time, I believe that, as an industry, we still havenβt cracked the foundational archetypes of engineering managers. Let me explain.
One of the core qualities that make archetypes valuable is that they stay put over time. A foundational archetype should be unaffected by:
πͺ Career level β you should be able to find implementations of the same archetype across all / most career levels, just with different scope and complexity.
π’ Company scale β whether youβre in a 10-person startup or Big Tech, the core behavioral pattern should remain recognizable.
πͺ Leadership identity β archetypes should reflect how someone creates leverage, not just what function or title they currently hold.
So how do the existing archetypes fare on this? Itβsβ¦ complicated.
Letβs take Tech Lead EM as an example. I have seen this and this is especially true at the βM1/M2 level or L5/L6 levelβ (first level management) in most tech companies, but it completely falls apart beyond that. At M3+, no one is still a Tech Lead EM. Why? Because that mode doesnβt scale.
This description resembles more a transitional role or function, instead of describing an archetype that persists across contexts. Past a certain point, being a Tech Lead is a fork toward the Staff+ IC path, not a leadership model that holds over time for engineering managers.
The same applies to Delivery EM and Product EM. In my experience (especially in the US), these labels tend to describe people who transitioned into management from adjacent functions: TPMs, Scrum Masters, Business Analysts, Product Owners, and most of the time, they either evolve out of that identity or stall.
These archetypes break down as careers evolve, reinforcing the need for foundational archetypes that endure.
A Delivery EM in a 1-squad setup might thrive. But what happens when that EM inherits 3 squads across multiple time zones, or becomes responsible for org-wide processes? The old identity no longer fits. The Tech Lead EM who once owned the architecture of a small team is now buried under coordination, people issues, and cross-cutting dependencies.
Finally, on the Leads of Leads EM, Group Manager and Executive Manager, we are basically replicating the career ladder/levels/job titles with different names. They are framed by function/level/skill, not by leverage mode.
They are about tasks, not narratives. They describe what someone does, not the kind of story they tend to embody as a leaderβespecially in moments of uncertainty, conflict, or change.
For this reason, EMs often donβt really recognize themselves into these archetypes, and resort to using a mix of them π
This mismatch is why I believe we need a fresh lensβone that goes beyond job titles, skill sets, or frustration levels and digs into the actual leverage a manager provides.
So letβs try to build on the shoulders of giants, taking inspiration from these frameworks plus broader leadership research π
πͺ Images of Leadership
Frustrated by the lack of robust βreal-worldβ EM archetypes in tech, I went hunting in other fieldsβfrom law to medicine to going to historical HBR articlesβto see if anyone had found a more realistic model.
Most frameworks I found either repeated the same mistakes or applied to entirely different contexts. Many articles or research papers hinted at archetypal leadership, but they likewise blurred lines between skill sets, motivations, and organizational scope.
Then I discovered βThe Archetypal Images of Leadershipβ by Shirshendu Pandey (Journal of Organisation and Human Behaviour, 2018).
It's built on the psychological theory of Carl Jung and organizational psychology, proposing four archetypal leader images:
π Administrator β focused on maintenance and functioning, through stability and security.
πͺ΄ Guide β focused on humanistic growth and supporting others, through affiliation and bonding.
π Achiever β focused on victory and success, through sheer drive and achievement.
π Catalyst β focused on transformation and innovation, through inspiration and engagement.
This study was a game-changer to me because it spoke to unconscious projections: how people naturally see leaders, not just how leaders label themselves.
That paper led me to other, related, archetypical models:
Eight Archetypes of Leadership β by Manfred Kets de Vriesβ, which identifies Strategists, Change-Catalysts, Transactors, and more.
Competing Values Framework β from Robert Quinn, which maps cultural archetypes (like Producer, Mentor, Innovator) to organizational behavior.
What all these models have in common is they focus on how leaders drive impact.
Behaviors like driving change, hardening processes, or nurturing people's development finally feel like core modes of operation, rather than skills or tasks.
And thatβs exactly what I was looking for!
Now, what we are left to do is tailor this approach to tech industry dynamics β like scaling teams, product iterations, or the nuanced split between hands-on engineering and strategic alignment.
So letβs piece together insights from each model to build a simpler, quadrant-based model for EMs π
π The Engineering Management Quadrants
At first glance, engineering management covers two obvious domains:
π Execution β driving delivery and unblocking teams.
πββοΈ People β building culture, retaining and growing talent.
But thereβs a hidden third dimension that often goes unspoken: managing change.
Whether youβre rolling out new team processes, absorbing a reorg, or bridging product pivots, an EMβs real job is guiding people and execution through change.
Everything elseβtechnical acumen, business insight, stakeholder engagementβultimately boils down to how you embrace or hold back change in both your teamβs work and mindset.
So, it feels natural that managers generally fall along two axes, based on: