Senior Engineers Shouldn't Have Direct Subordinates (Structurally)

There’s an organizational decision that looks reasonable on paper but slowly damages the team from within: giving senior engineers direct subordinates structurally. Usually this decision is born from growth pressure — the team grows fast, the Engineering Manager isn’t enough, and the senior engineer closest to daily work looks like a natural candidate to “carry part of the load”. The intention is good. But the trade-off is often far more expensive than calculated. This article unpacks why the separation between the individual contributor path and the people management path isn’t just an organizational preference, but a design decision directly impacting technical quality, team health, and the engineer’s own career.

Two Fundamentally Different Roles

Before discussing why mixing them is problematic, it’s important to understand how fundamentally different the senior engineer and engineering manager roles are — not just in terms of responsibilities, but in the skills needed, the motivations that drive them, and the mental load carried every day.

What Senior Engineers Actually Do

A senior engineer is a high-impact individual contributor. Their greatest value to the organization comes from the ability to solve complex technical problems, make the right architectural decisions, and raise the quality of the entire codebase — not just the code they write themselves.

A healthy senior engineer’s scope includes:

• Solving technical problems too complex for juniors or mid-levels to handle alone
• Being the technical reference when there are architecture, performance, or design trade-off questions
• Doing substantive code reviews — not just checking syntax but questioning design decisions
• Informal mentoring: not because a structure requires it, but because they know when someone needs help
• Maintaining engineering standards at a consistent level — through example, not instruction

What is explicitly not a senior engineer’s responsibility: formal performance reviews for others, promotion decisions, handling interpersonal conflicts between team members, and all the administrative burden accompanying people management.

What Engineering Managers Actually Do

The engineering manager role explicitly focuses on people. This isn’t about leading technical projects or making architectural decisions — it’s about making sure every individual in the team can grow, contribute, and survive.

Concrete EM responsibilities:

• Managing individual performance continuously, including giving honest and timely feedback
• Coaching for areas outside technical competence: communication, collaboration, prioritization, mental resilience
• Capacity planning: who needs more challenge, who is overloaded, when to recruit
• Career development: helping each engineer understand where they’re growing and what to work on to get there
• Maintaining the team’s psychological health — detecting when someone is burning out, in conflict, or losing motivation before it becomes a crisis

flowchart LR
    subgraph IC["Individual Contributor Track"]
        JE[Junior Engineer] --> ME[Mid Engineer]
        ME --> SE[Senior Engineer]
        SE --> SSE[Staff Engineer]
        SSE --> PE[Principal Engineer]
    end

    subgraph EM["Engineering Manager Track"]
        EM1[Engineering Manager] --> SEM[Senior EM]
        SEM --> DIR[Director of Engineering]
        DIR --> VP[VP Engineering]
    end

    SE -.->|"Often happens<br/>(but problematic)"| EM1
    SE -->|"Should be"| SSE

    style IC fill:#e8f5e9,stroke:#43a047
    style EM fill:#e3f2fd,stroke:#1e88e5

These two paths differ not only in org chart structure — they differ in their DNA. Someone who excels on the IC track isn’t automatically ready or suited for the EM track, and vice versa. Forcing someone to do both simultaneously isn’t an efficient solution — it’s a recipe for doing both half-heartedly.

Why Mixing the Two Is Problematic

There are five concrete reasons why giving a senior engineer direct subordinates is a bad design decision, even when done with good intentions.

1. Distraction from the Highest-Impact Work

A senior engineer provides the highest value when they can dive into difficult technical problems and come out with good solutions. This requires deep focus — not in minutes, but in hours and sometimes days. Deep work is a senior engineer’s main capital, and it’s very easily fragmented.

Once there are direct subordinates, the senior engineer’s calendar starts filling with things unrelated to their technical work:

• Regular 1-on-1s that need preparation, execution, and follow-up
• Sensitive performance conversations that take longer than planned
• Interpersonal conflicts between subordinates and other team members that must be mediated
• Career questions from subordinates that can’t be answered in 5 minutes
• Reporting to the EM about team conditions — which means they need a different level of awareness

Each item above doesn’t just cut time directly — it also cuts concentration. Studies on cognitive switching cost show that moving from “technical problem solving” mode to “listening and responding to people’s emotional needs” mode and back again can’t be done without significant mental cost.

The result: the senior engineer no longer produces the best technical solutions they could produce. And because their technical ability is the main reason they were given that position, the organization is actually eroding its main asset.

2. Undetected Burnout

People management is emotional labor — work that drains energy in a different way than technical work. For engineers who didn’t choose this path and weren’t prepared for it, that burden can be very heavy.

What makes this situation dangerous is its invisible nature. A senior experiencing burnout from people management burdens usually still “looks productive” on the surface — code is still written, PRs are still reviewed, meetings are still attended. But underneath:

• They feel responsible for other people’s performance but have no tools to truly influence it
• They feel guilty when a subordinate has problems, even though the problem is beyond their control
• They’re trapped between two worlds — demanded as a technical leader and a people manager at once — and can’t give their best at either
• They can’t “turn off” manager mode even outside working hours, because they know people depend on them for things beyond code

stateDiagram-v2
    [*] --> TechnicalFocus: Senior engineer without direct reports
    TechnicalFocus --> DeepWork: Can dive into deep technical problems
    DeepWork --> BestSolutions: Produces the highest technical value

    [*] --> DualBurden: Senior engineer with direct reports
    DualBurden --> FocusFragmentation: Calendar split between technical and people
    FocusFragmentation --> QualityDeclines: Technical solutions not optimal
    DualBurden --> EmotionalLabor: Carries the people management burden
    EmotionalLabor --> Burnout: Invisible exhaustion
    Burnout --> Turnover: Senior resigns or loses motivation

This kind of burnout often ends in one of two scenarios: the senior engineer resigns because they can’t take it anymore, or the senior engineer stays but their motivation is dead — they come in, do the minimum, and no longer give the best contribution they ever gave.

Both are expensive losses for the organization.

3. Mental Readiness That Can’t Be Assumed

There’s a very dangerous assumption often underlying this decision: that an engineer great at technical work must be able to manage people well, or at least can learn fast enough. This assumption is wrong in many cases.

Managing people requires a skill set fundamentally different from making technical decisions:

• The ability to listen without immediately providing solutions
• Tolerance for ambiguity and slow processes
• The ability to give negative feedback in a way that doesn’t damage relationships
• Empathy for emotional conditions affecting performance
• Patience with non-linear development

Many technically excellent engineers are actually very uncomfortable with the things above — not because they’re immature, but because their brains are trained to seek fast, precise solutions, not to sit with human uncertainty.

What’s more problematic: when a senior engineer is given direct subordinates without adequate preparation, several unproductive negative patterns tend to appear:

Dysfunctional patterns that often appear:

✗ Technical micro-managing — the senior dives too deep into
  implementation because they're more comfortable with code than
  giving direction and waiting

✗ False authority — using the structural position to
  validate technical decisions that should be discussed,
  not commanded

✗ Resistance toward the formal EM — feeling their position
  overlaps with the EM and starting unproductive friction

✗ Inconsistent feedback — sometimes very technically detailed,
  sometimes no feedback at all, because there's no clear
  framework for people management

This isn’t the individual senior engineer’s fault. It’s the predictable result when someone is placed into a role they didn’t choose and weren’t properly prepared for.

4. Mentoring and Managing Are Two Different Things

One of the most commonly used justifications for giving a senior engineer direct subordinates is: “they’ve been mentoring juniors all along, this is just the formalization.” This is a very fundamental misunderstanding of what’s different between mentoring and managing.

When someone comfortable and effective as a mentor is forced into being a manager, what often happens isn’t a better mentor — it’s a manager uncomfortable with the formal aspects of their role and a mentor whose relationship becomes awkward because structural power dynamics have entered it.

Once there’s a formal superior-subordinate structure, the mentoring dynamic changes. The mentee becomes a subordinate. Honest questions about inability become risky because they’re equivalent to admitting weakness to someone with authority in career evaluation. The psychological safety that makes mentoring effective can collapse.

5. Accumulated Organizational Debt

Like technical debt, organizational debt isn’t immediately visible but keeps accumulating. Giving a senior engineer direct subordinates creates several forms of organizational debt at once.

Authority ambiguity. When there are two reporting lines — the senior engineer as structural superior and the engineering manager as formal superior — subordinates are often confused: whose decision is more final? Who should be approached for non-technical problems? Who determines priorities when there’s a conflict? This ambiguity doesn’t just waste time — it creates unnecessary stress for everyone.

Inconsistent feedback. A good EM has a system ensuring feedback flows regularly, structurally, and timely. A senior engineer not prepared for people management usually doesn’t have this system — feedback happens ad hoc, only when there’s a big problem, or is too focused on technical aspects alone and ignores other dimensions of a person’s performance.

Unclear career paths for subordinates. If someone’s direct superior is a senior engineer whose career path is the IC track, who facilitates the discussion about whether that subordinate wants the IC track or the EM track? Who has the context to evaluate their readiness for both paths?

Widening skill gaps. A senior engineer forced to spend 30-40% of their time on people management can’t develop technical depth as fast as if they focused. In 2-3 years, they may fall behind peers on the pure IC track — and this harms both the individual and the team.

Healthier Alternative Models

Understanding the problem is easier than finding the solution, especially when organizational growth pressure is very real. Here are three healthier models proven to work in mature engineering organizations.

Model 1: The Staff and Principal Engineer Track

The most elegant way to give senior engineers bigger responsibility without burdening them with people management is creating advanced levels on the IC track: Staff Engineer and Principal Engineer.

At these levels, a senior engineer has a wider scope — can be cross-team or even cross-organization — but still without direct reports. Their influence comes from technical decisions, the architecture they design, and the standards they set — not from who structurally reports to them.

flowchart TD
    SE[Senior Engineer] --> Q{Want bigger<br/>growth?}

    Q -- "Yes, through technical" --> SSE[Staff Engineer]
    SSE --> PE[Principal Engineer]
    PE --> DE[Distinguished Engineer]

    Q -- "Yes, through people" --> TEM[Transition to the EM Track]
    TEM --> EMR[Engineering Manager]
    EMR --> SEM[Senior EM / Director]

    Q -- "No, focus for now" --> SE

    style SSE fill:#e8f5e9,stroke:#43a047
    style PE fill:#e8f5e9,stroke:#43a047
    style DE fill:#e8f5e9,stroke:#43a047
    style EMR fill:#e3f2fd,stroke:#1e88e5
    style SEM fill:#e3f2fd,stroke:#1e88e5

This model explicitly separates career growth from people management, and allows engineers who genuinely aren’t interested in managing people to keep growing without having to enter a path that doesn’t fit them.

Model 2: The Engineering Manager as Single People Owner

In this model, every engineer has only one formal superior responsible for their people management: the Engineering Manager. Senior engineers may — and should — be involved in mentoring, code review, and providing technical direction. But all formal aspects (performance reviews, promotions, interpersonal conflicts) remain in the EM’s hands.

This creates very valuable clarity:

• Subordinates know where to go for different problems
• Senior engineers know the boundaries of their responsibility
• The EM has full visibility into the condition of all their team members
• There’s no confusion about who has the final word

The challenge is that the EM-to-engineer ratio must be reasonable — generally 1:6 to 1:10 is a healthy range depending on team complexity. If the ratio far exceeds that, the solution isn’t giving people management authority to senior engineers — the solution is hiring a new EM or restructuring the team.

Model 3: Non-Structural Mentoring Matrix

For knowledge transfer and technical development needs, a mentoring matrix is a flexible and effective alternative. In this model, a senior engineer can mentor several juniors at once — but the relationship isn’t tied to HR structure, there’s no formal evaluation, and both parties can end or change the relationship as needed.

flowchart LR
    SE1[Senior A] -->|Technical mentoring| JE1[Junior 1]
    SE1 -->|Technical mentoring| JE2[Junior 2]
    SE2[Senior B] -->|Technical mentoring| JE2
    SE2 -->|Technical mentoring| JE3[Junior 3]

    EM[Engineering Manager] -->|People management| JE1
    EM -->|People management| JE2
    EM -->|People management| JE3
    EM -->|People management| SE1
    EM -->|People management| SE2

    style EM fill:#e3f2fd,stroke:#1e88e5
    style SE1 fill:#e8f5e9,stroke:#43a047
    style SE2 fill:#e8f5e9,stroke:#43a047

Note that in this model, the EM remains the only people management path for everyone — including the senior engineers themselves. Senior engineers only play a role in the technical and mentoring path, without overlapping with the EM’s formal authority.

When Exceptions Might Make Sense

No rule is truly absolute in organizational design. There are conditions where giving senior engineers responsibilities touching people management can be considered — with very strict requirements.

CAN BE CONSIDERED if all these conditions are met:
  ✓ This is an explicit transition toward the EM track, not an added burden
  ✓ There's a clear timeline for formalizing their role as an EM
  ✓ There's specific coaching for people management readiness
  ✓ Technical responsibilities are proportionally reduced
  ✓ The senior engineer themselves chose and wants this

AVOID if any of these conditions exist:
  ✗ "Temporary" without a clear timeline — temporary usually becomes permanent
  ✗ Technical responsibilities aren't reduced — two full burdens at once
  ✗ The senior engineer was never asked if they want it
  ✗ The motivation is reducing the existing EM's load, not developing the senior
  ✗ There's no plan to create a new EM or restructure

If the main reason for giving a senior engineer direct subordinates is “our EM is overwhelmed”, the right solution is hiring a new EM or adjusting the team size — not delegating people management to someone unprepared and who didn’t choose it.

Signals That the Structure Is Already Problematic

If you’re already in a situation where a senior engineer has direct subordinates, there are several signals showing this structure is starting to cause problems and needs evaluation:

• The senior engineer starts being absent from technical discussions they previously always attended
• The senior engineer’s code review quality declines — more superficial, approved faster
• Subordinates more often bypass the senior engineer directly to the EM for non-technical problems
• There’s unproductive friction between the senior engineer and the EM about who has authority for certain decisions
• The senior engineer starts complaining about “too many meetings” or “can’t focus”
• Performance reviews the senior engineer writes for their subordinates feel very technical and ignore other performance aspects

Any one of these signals is enough to open a conversation about whether the existing structure is truly the best.

Summary

• Senior engineers and engineering managers are two fundamentally different roles — not just in responsibilities, but in the skills needed, the motivations that drive them, and the mental load carried every day.
• A senior engineer’s highest value comes from technical focus — every hour spent on people management is an hour not used to solve high-impact technical problems.
• Burnout from people management is hard to detect — a senior exhausted by the double burden often still “looks productive” until they resign or completely lose motivation.
• Mentoring and managing are two different things — adding formal structure to a mentoring relationship can actually destroy the psychological safety that makes mentoring effective.
• Organizational debt accumulates silently — authority ambiguity, inconsistent feedback, and unclear career paths are long-term costs often not accounted for.
• The Staff and Principal Engineer track is a healthier alternative — giving senior engineers growth space without forcing people management.
• The EM as single people management owner creates clarity — one formal path for everything human-related, senior engineers focus on technical and informal mentoring.
• If the EM is overwhelmed, the solution is hiring a new EM — not delegating people management to someone who didn’t choose and isn’t prepared for it.