Refactoring

Refactoring

Share this post

Refactoring
Refactoring
The Engineering Manager Archetypes 📊
Copy link
Facebook
Email
Notes
More
🧵 Essays

The Engineering Manager Archetypes 📊

A thorough framework to identify how engineering managers create value inside orgs.

Luca Rossi's avatar
Thiago Ghisi's avatar
Luca Rossi
and
Thiago Ghisi
Jun 04, 2025
∙ Paid
42

Share this post

Refactoring
Refactoring
The Engineering Manager Archetypes 📊
Copy link
Facebook
Email
Notes
More
2
Share
Upgrade to paid to play voiceover

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:

  1. 🧠 Where do archetypes come from — from classical psychology to modern leadership.

  2. 🔬 Limits of existing EM archetypes — why we shouldn’t focus only on skills and tasks.

  3. 🪞 Images of leadership — moving from skills to modes of operation.

  4. 📊 Engineering management quadrants — balancing stability, change, people and execution.

  5. 👥 Engineering manager archetypes — identifying both productive and failure modes.

  6. 🎯 How to use archetypes — for your personal growth and your team success.

  7. 🗳️ 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:

  1. 🪜 Career level — you should be able to find implementations of the same archetype across all / most career levels, just with different scope and complexity.

  2. 🏢 Company scale — whether you’re in a 10-person startup or Big Tech, the core behavioral pattern should remain recognizable.

  3. 🪞 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:

  1. 🔒 Administrator — focused on maintenance and functioning, through stability and security.

  2. 🪴 Guide — focused on humanistic growth and supporting others, through affiliation and bonding.

  3. 🏆 Achiever — focused on victory and success, through sheer drive and achievement.

  4. 🔋 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:

This post is for paid subscribers

Already a paid subscriber? Sign in
A guest post by
Thiago Ghisi
Helping Staff+ Engineers, EMs & Tech Execs scale teams, grow careers & fix the hard stuff. Previously Eng. Director @ Nubank, Apple, Amex, ThoughtWorks. LinkedIn: linkedin.com/in/thiagoghisi
Subscribe to Thiago
© 2025 Refactoring ETS
Privacy ∙ Terms ∙ Collection notice
Start writingGet the app
Substack is the home for great culture

Share

Copy link
Facebook
Email
Notes
More