Does every tech company have a group-engineering-manager tier?

No. Microsoft, Amazon, and Salesforce explicitly use a GEM-equivalent tier (Microsoft 'Partner SDE Manager', Amazon 'Director', Salesforce 'Senior Director'). Meta and Google often fold this scope into senior-manager (E7/L7) or director (E8/L8) without a distinct M3 label. Stripe historically has used 'Engineering Manager' as a single broad title differentiated by scope band. The right pattern when interviewing: ask the recruiter to share the company's leveling rubric or the sample scopes for the role.

What is the difference between a senior-manager and a group-engineering-manager?

Span and the unit of analysis. Senior-manager (M2): 15–40 people across 2–4 line-managers; the unit of analysis is the line-manager and the team. Group-engineering-manager (M3): 40–80 people across 3–6 line-managers and possibly 1–2 senior-managers; the unit of analysis is the sub-team and the engineering strategy across sub-teams. Larson's An Elegant Puzzle 'managing managers' chapter and 'organizational design' chapter cover the boundary. In practice the boundary is fuzzy and the title used is company-specific.

How is the engineering strategy document at M3 different from a roadmap?

Larson's 'Engineering strategy' on lethain.com names the distinction directly. A roadmap is a time-ordered list of features. A strategy is a written argument about what to do given a situation, with the alternatives named and rejected. Rumelt's 'Good Strategy / Bad Strategy' (Crown, 2011) is the underlying theory. The M3 strategy doc has three sections: diagnosis, guiding policy, coherent actions. The roadmap is downstream: it is what the senior-managers and line-managers produce given the strategy.

What does sociotechnical org design mean in practice?

Charity Majors's framing on charity.wtf and Larson's chapter on organizational design in An Elegant Puzzle both name the same idea: the technical structure of the system and the human structure of the team are not separable. A sub-team that owns a tightly-coupled set of services with a poorly-defined external API is going to struggle no matter how well-managed it is; a sub-team that owns a clean external API but is staffed with engineers who don't talk to each other will produce architectural drift. The M3 craft is reasoning about both at once: 'this team's API is the wrong shape because the team's communication structure forces it to be that shape; we need to either restructure the team or restructure the API or both.'

How much technical depth does an M3 need?

Less daily than senior-manager. By M3 your technical depth is exercised through judgment about the engineering strategy document and the senior-IC proposals it creates space for, not through code review. Charity Majors's framing still applies: an M3 who has lost the ability to read their orgs' design docs and form judgment cannot effectively steer them. The dangerous failure mode is the M3 who hides from technical conversations and becomes a project director. The other failure mode is the M3 who refuses to defer to staff/principal IC judgment on technical specifics.

How do M3s develop their senior-managers?

Fournier's chapter 7 and 8 (The Manager's Path) and Lopp's Managing Humans both cover the M2-to-M3 development path. Pattern: weekly 1:1, monthly career conversation, quarterly named development goal (often a stretch project that requires the senior-manager to operate at the next tier — running a cross-org initiative, hiring a new line-manager, writing a piece of the engineering strategy). Hogan's Resilient Management chapter 5 has the BICEPS-frame application here; the senior-manager who needs more 'choice' in their development plan is asking for autonomy, not for more 1:1 time.

Is M3 a bridge to director or a permanent tier?

Both, depending on the company and the individual. Some M3s sit at the tier for years — the company has the right span for them and they are doing the right work. Others use M3 as the explicit step toward director (D1). At Microsoft, 'Partner SDE Manager' is often a 2–4 year stop before 'Director, Software Engineering.' At Stripe, the M3-equivalent scope and director-equivalent scope are sometimes folded. The right framing in 1:1s with your director: 'is M3 the right tier for me for the next few years, or is it the bridge to D1?' The answer determines what stretch projects you take.

Engineering Manager Hub

Group Engineering Manager / M3 Guide for Tech Companies (2026)

By Blake Crosley · Last verified 2026-04-30

In short

A group engineering manager (M3 / GEM, typically 40–80 people across 3–6 line-managers and 1–2 senior-managers) sits between senior-manager and director on most modern-tech-company ladders. The job is sociotechnical org design (Charity Majors's framing on charity.wtf), strategy articulation across multiple sub-teams, and senior leadership development. Total comp at FAANG-tier M3 commonly clears $750,000–$1.2M with stock vesting; AI-labs commonly clear $1.4M+. Some companies fold this tier into senior-manager (Meta, Google) or director (Stripe); others use it as the explicit bridge to D1 (Microsoft, Amazon, Salesforce). Read the leveling rubric of the specific company to know what is expected.

Key takeaways

FAANG-tier and AI-lab GEM total comp $750k–$1.4M+ per levels.fyi 2026; not every company has a distinct M3 tier — Meta and Google often fold this into senior-manager (E7/L7) or director (E8/L8); Microsoft, Amazon, Salesforce use it explicitly. Read the leveling rubric to know.
The M3 job is sociotechnical org design — Charity Majors's charity.wtf coverage and Larson's An Elegant Puzzle chapter on 'organizational design' both name it as the central GEM craft. How are sub-teams structured? Where are the seams that produce friction? Which line-managers can grow into senior-managers? Which sub-teams should split or merge?
Strategy articulation across multiple sub-teams is the second M3 craft skill. Larson's 'Engineering strategy' essay (lethain.com) and Richard Rumelt's 'Good Strategy / Bad Strategy' (Crown Business, 2011) are the canonical references. The M3 writes a multi-quarter engineering strategy document that the senior-managers underneath execute against.
Senior leadership development becomes load-bearing. The M3 has 1–2 senior-managers reporting to them and is responsible for those senior-managers' development. Fournier's chapter 7 and 8 (The Manager's Path) and Lopp's Managing Humans both cover the M2-to-M3 development path.
The M3 reports to a director (D1) or senior-director (D2). The senior-leadership cross-functional partnership shifts: PMs are now the senior PM director equivalent, not the line-PM. Design partnership is at the design-director level. The M3 partners across the leadership tier, not the operational tier.
Hiring at M3 is mostly senior-IC and management hires. A new senior-manager hire is the most leveraged hire at the M3 tier — Larson's 'Hiring funnel' coverage of management hiring extends here. The behavioral interview rubric is heavier and the 'manage a difficult performance situation' scenario is more demanding.
Some companies do not have a distinct GEM tier. Stripe historically uses 'Engineering Manager' as a single broad title and differentiates by scope; Meta and Google use M-leveled scopes that fold cleanly. Always check the company's published leveling guide (where available) before assuming a title maps to a scope.

What changes at M3: the leadership-of-leaders job

The M3 / group-engineering-manager tier is treated as a distinct rung on some company ladders (Microsoft, Amazon, Salesforce) and folded into others (Meta, Google, Stripe). Where it exists as a distinct tier, the structural changes from senior-manager (M2) per Fournier (chapters 7–8 of The Manager's Path), Larson (An Elegant Puzzle, the chapters on 'organizational design' and 'managing managers'), and Charity Majors's charity.wtf archive are:

Span typically 40–80 people across 3–6 line-managers and 1–2 senior-managers. The M3 has both line-managers and senior-managers reporting to them in some configurations; in others, only senior-managers. The mix depends on the company's preferred span-of-control and the maturity of the underlying line-managers.
The unit of work is the sub-team, not the IC or the line-manager. At M2 you reason about line-managers and their teams. At M3 you reason about sub-teams as organizational units: are they correctly scoped? Do they have the right charter? Are they staffed at the right level? When does a sub-team split, when does it merge with another?
Engineering strategy becomes a written artifact. The M3 produces a multi-quarter engineering strategy document — typically 2–6 pages — that the senior-managers and line-managers underneath execute against. Larson's 'Engineering strategy' on lethain.com and the related chapter in An Elegant Puzzle are the templates. Rumelt's 'Good Strategy / Bad Strategy' (Crown, 2011) is the underlying theory.
Cross-functional partnership scales again. Director-of-PM (or senior PM director) is the typical PM partner. Director-of-design or design-director is the typical design partner. The conversations are about multi-quarter strategy and resourcing, not feature-level execution.
Senior leadership development. Promoting a senior-manager to the next M3 (sociotechnical), or developing a line-manager to senior-manager, is now a measurable M3 output. A GEM whose senior-managers do not grow has under-performed regardless of project shipping.

The empirical sign you have made the M2-to-M3 transition: you write multi-quarter engineering strategy that other senior-managers reference; your senior-managers run their orgs without daily input from you; your skip-skip-levels (occasional 1:1s with ICs two levels under you) confirm the senior-managers' read of their teams. The empirical sign you have not made the transition: you are still functioning as the senior-manager of one of your sub-orgs, doing skip-levels into individual ICs more than into senior-manager calibration.

Worked scenario: re-scoping three sub-teams during a charter change, in 12 months

A 12-month worked scenario — group engineering manager owns 3 line-managed sub-teams (one for product surface A, one for surface B, one for shared platform), 52 ICs total. The company strategy shifts in Q1: surface A is being deprecated, surface B is being doubled-down on, and a new surface C will be invested in. The GEM has 12 months to re-scope the org without losing more than 2 senior ICs. Drawn from Larson's 'Organizational design' chapter (An Elegant Puzzle), Charity Majors's 'sociotechnical org design' essays on charity.wtf, and Pragmatic Engineer's coverage of FAANG re-orgs.

Months 1–3 (analysis, no announcement). The GEM works with their director and the leadership of the affected product areas to map the strategy. Which features survive on surface A? Which engineers' skills transfer to the new surface C? Which platform-team commitments are now obsolete and which become more critical? The work is heads-down with the director, the GEM's two senior-managers, and the platform line-manager. The line-managers underneath the senior-managers are not yet looped in. The org as a whole sees no change. Pragmatic Engineer's coverage of major Meta and Google re-orgs (newsletter.pragmaticengineer.com) describes this as the canonical 'quiet planning quarter.'
Month 4 (preparation). The GEM writes the re-org memo: 3 pages, naming the strategic rationale, the new sub-team structure, the people-impact (who reports to whom, what changes for whom), and the timeline. The memo is reviewed by HR, by the GEM's director, and by the relevant cross-functional leaders. The GEM and senior-managers prepare individual conversation scripts for every IC affected by a manager change.
Month 5 (announcement and the hard conversations). The GEM holds an all-hands with the affected sub-teams. The reorganization is announced. Within 24 hours every IC who is changing reporting line has a 1:1 with their new manager. Within 48 hours every IC has the chance for a 1:1 with the GEM if they want one. The GEM blocks the calendar to make sure those 1:1s are possible. Larson's 'no surprises' principle: the senior ICs were sounded-out individually in the prior week. The most senior IC on surface A (the one most at risk of leaving) was given the courtesy of being told 24 hours ahead with a private explanation.
Months 6–9 (execution). Surface A wind-down. Surface B doubling. Surface C launch. The GEM's calendar is heavy on cross-functional with the director-PM peer. Two of the surface-A senior ICs decide to leave; one had been considering it before the announcement, one is a true surprise. The GEM holds counter-offer conversations with the surprise; the IC chooses to leave anyway with a clean reference. The GEM accepts this as cost of the re-org.
Months 10–12 (stabilization and retrospective). Surface C ships its first releases. Surface B's doubled investment shows velocity gains. The GEM writes a re-org retrospective: what went well, what they would change next time, what the lasting org effects are. The retrospective is shared with the director and with the GEM's peers. The single largest lesson named in the retro: the canonical mistake was under-investing in the senior-IC stakeholder management in months 1–3 — the surprise departure could have been avoided with a single 30-min conversation in month 2 instead of month 5.

The lesson Charity Majors and Larson both name in their writing on org design: the technical structure of the work and the human structure of the team are not separable. Re-orgs that optimize for technical clarity and ignore the social fabric leave the technical work unable to ship; re-orgs that optimize for social comfort and ignore the technical seams produce dysfunction at the boundaries. The M3 craft is sociotechnical, hyphenated, both at once.

Engineering strategy as a written artifact

The single largest M3 deliverable is the engineering strategy document. Larson's 'Engineering strategy' on lethain.com is the canonical mechanic. Rumelt's 'Good Strategy / Bad Strategy' (Crown, 2011) is the underlying theory. The standard structure across modern-tech-company practice (per Stripe Press's published material, Pragmatic Engineer's coverage of senior-engineering-leadership artifacts, and Larson's An Elegant Puzzle):

Diagnosis. What is the situation? What forces are acting on the team? What is changing in the company, the industry, or the technical landscape? Rumelt is explicit: most strategy documents fail at the diagnosis step because they jump to action without naming the situation. The M3's diagnosis is typically 1–2 pages and references real data — production metrics, hiring funnel data, retention numbers, NPS or partner-feedback signal.
Guiding policy. Given the diagnosis, what is the policy that makes choices possible? Larson's framing: the guiding policy is what you optimize for, what you say no to. Examples from Stripe (per Patrick Collison's interviews) include 'optimize for new-developer time-to-first-charge' over alternative metrics. The guiding policy is typically half a page; if it is longer, it is not actually a policy.
Coherent actions. The 3–7 specific actions or commitments that follow from the policy. These should be specific enough to refute (Rumelt's test for non-bullshit strategy) and concrete enough that the senior-managers underneath can execute. Typical: 'we will hire 2 senior ML engineers in Q2', 'we will deprecate the legacy authentication path by end of Q3', 'we will run an internal eval-tool sprint in Q1 producing a shippable artifact by week 6.'

The dominant failure mode is the strategy doc that is actually a roadmap. A roadmap is a list of features in time order; a strategy is a written argument about what to do given a situation, with the alternatives named and rejected. Larson's most-cited line: 'a strategy that does not refute alternative strategies is not a strategy.'

At M3, the strategy doc is shared with the director, with peer M3s, with the senior-managers underneath, and (with appropriate context) with the line-managers and senior ICs underneath them. Refresh cadence is typically every 6 months at most modern-tech-company orgs.

Compensation: the real bands at M3

Total comp at M3 / GEM (where the tier exists distinctly) FAANG-tier and AI-lab in 2026 (US, per levels.fyi self-reports, with the heavy caveat that not all companies have an explicit M3 — Meta and Google often fold this scope into senior-manager / director boundaries):

Company	Level	Base	Total comp
Meta engineering manager	E7-mgr (high) / E8-mgr (low)	$300k–$370k	$700k–$1.1M
Google engineering manager	L7-mgr (high) / L8-mgr (low)	$300k–$380k	$700k–$1.2M
Stripe engineering manager	EM-3 (high) / EM-4	$300k–$400k	$750k–$1.3M
Airbnb engineering director	L8-mgr (entry)	$320k–$400k	$800k–$1.3M
Netflix engineering manager	L7-mgr (high)	$580k–$700k	$800k–$1.2M (single-band)
Anthropic engineering director / senior staff EM	EM-senior-staff	$420k–$550k	$1.4M–$2.5M+ (heavy equity)
Microsoft Partner SDE Manager	67/68	$320k–$400k	$700k–$1.1M
Salesforce VP / Senior Director Engineering	SVP-1	$280k–$360k	$650k–$1M

The GEM tier sits at the seam between FAANG E7/L7 and E8/L8 in companies that don't formally separate it. The bands above are approximate and noisier than line-manager / senior-manager bands because the tier is less standardized across companies.

Frequently asked questions

Does every tech company have a group-engineering-manager tier?: No. Microsoft, Amazon, and Salesforce explicitly use a GEM-equivalent tier (Microsoft 'Partner SDE Manager', Amazon 'Director', Salesforce 'Senior Director'). Meta and Google often fold this scope into senior-manager (E7/L7) or director (E8/L8) without a distinct M3 label. Stripe historically has used 'Engineering Manager' as a single broad title differentiated by scope band. The right pattern when interviewing: ask the recruiter to share the company's leveling rubric or the sample scopes for the role.
What is the difference between a senior-manager and a group-engineering-manager?: Span and the unit of analysis. Senior-manager (M2): 15–40 people across 2–4 line-managers; the unit of analysis is the line-manager and the team. Group-engineering-manager (M3): 40–80 people across 3–6 line-managers and possibly 1–2 senior-managers; the unit of analysis is the sub-team and the engineering strategy across sub-teams. Larson's An Elegant Puzzle 'managing managers' chapter and 'organizational design' chapter cover the boundary. In practice the boundary is fuzzy and the title used is company-specific.
How is the engineering strategy document at M3 different from a roadmap?: Larson's 'Engineering strategy' on lethain.com names the distinction directly. A roadmap is a time-ordered list of features. A strategy is a written argument about what to do given a situation, with the alternatives named and rejected. Rumelt's 'Good Strategy / Bad Strategy' (Crown, 2011) is the underlying theory. The M3 strategy doc has three sections: diagnosis, guiding policy, coherent actions. The roadmap is downstream: it is what the senior-managers and line-managers produce given the strategy.
What does sociotechnical org design mean in practice?: Charity Majors's framing on charity.wtf and Larson's chapter on organizational design in An Elegant Puzzle both name the same idea: the technical structure of the system and the human structure of the team are not separable. A sub-team that owns a tightly-coupled set of services with a poorly-defined external API is going to struggle no matter how well-managed it is; a sub-team that owns a clean external API but is staffed with engineers who don't talk to each other will produce architectural drift. The M3 craft is reasoning about both at once: 'this team's API is the wrong shape because the team's communication structure forces it to be that shape; we need to either restructure the team or restructure the API or both.'
How much technical depth does an M3 need?: Less daily than senior-manager. By M3 your technical depth is exercised through judgment about the engineering strategy document and the senior-IC proposals it creates space for, not through code review. Charity Majors's framing still applies: an M3 who has lost the ability to read their orgs' design docs and form judgment cannot effectively steer them. The dangerous failure mode is the M3 who hides from technical conversations and becomes a project director. The other failure mode is the M3 who refuses to defer to staff/principal IC judgment on technical specifics.
How do M3s develop their senior-managers?: Fournier's chapter 7 and 8 (The Manager's Path) and Lopp's Managing Humans both cover the M2-to-M3 development path. Pattern: weekly 1:1, monthly career conversation, quarterly named development goal (often a stretch project that requires the senior-manager to operate at the next tier — running a cross-org initiative, hiring a new line-manager, writing a piece of the engineering strategy). Hogan's Resilient Management chapter 5 has the BICEPS-frame application here; the senior-manager who needs more 'choice' in their development plan is asking for autonomy, not for more 1:1 time.
Is M3 a bridge to director or a permanent tier?: Both, depending on the company and the individual. Some M3s sit at the tier for years — the company has the right span for them and they are doing the right work. Others use M3 as the explicit step toward director (D1). At Microsoft, 'Partner SDE Manager' is often a 2–4 year stop before 'Director, Software Engineering.' At Stripe, the M3-equivalent scope and director-equivalent scope are sometimes folded. The right framing in 1:1s with your director: 'is M3 the right tier for me for the next few years, or is it the bridge to D1?' The answer determines what stretch projects you take.

Sources

About the author. Blake Crosley founded ResumeGeni and writes about engineering management, hiring technology, and ATS optimization. More writing at blakecrosley.com.