Management Transitions

Management Transitions

Before Starting

Check for EM context first. If .agents/em-context.md exists, read it.

If .agents/em-context.md does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.

If a specific person is central to the conversation and .agents/reports/[name].md does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.

If the conversation reveals durable new context later, update .agents/em-context.md or .agents/reports/[name].md automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.

Response Style

Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.

Default to:

• State the likely diagnosis or recommendation first
• Ask at most 2-3 targeted questions only if the missing context changes the advice
• Give the next concrete action and, when useful, exact wording the manager can use
• Mention the relevant framework briefly, but do not explain every part of it
• Offer a deeper version only after the direct answer

---

How to Use This Skill

• Just became a manager / starting a new role — identify which type → The 4 Types of Transitions
• Taking over a team after an acquisition → Acquisition Integration
• Engineer asking whether to go into management → Counseling Engineers on the Management Track
• First weeks in a new role — what to observe and when to act → The Blue Tape List
• Inherited a struggling or dysfunctional team → Turning Around a Broken Team
• Feeling unfulfilled since switching from IC to manager → The Dopamine Shift
• Second time as a manager and making the same or new mistakes → read references/extended.md — Second-Time Manager Mistakes
• Understanding how the EM role has changed post-2022 → read references/extended.md — The EM Role in the New Era

---

Default Response Shape

When helping with a management transition, orient the manager before giving advice:

1. Transition type: Apprentice, Successor, Pioneer, New Boss, acquisition integration, or other.
2. First risk: the mistake most likely in this transition.
3. First 30 days: what to observe, ask, and avoid changing too early.
4. Trust-building moves: with reports, peers, manager, and stakeholders.
5. Message: how to explain the manager's approach to the team.

For inherited teams, separate learning the system from fixing the system. Premature certainty is the main risk.

---

The 4 Types of Transitions

From The Making of a Manager by Julie Zhuo. Every first-time manager falls into one of these four paths — each with its own specific challenges.

---

1. The Apprentice

You were promoted from within the team. Your manager moved on, and you stepped up.

Unique challenge: former peers. The power dynamic shifted, and everyone knows it. Some team members may feel they deserved the role. Resentment can go unspoken for months.

What to do: Talk about it directly. Acknowledge the awkwardness in a 1:1. It defuses more than you expect.

Unique challenge: balancing coding and managing. You're still expected to contribute technically, and it's tempting to stay mostly an individual contributor.

What to do: Start at 60–70% IC work if needed, but consciously step that down over time. Your value as a manager grows as you free up headspace from execution.

---

2. The Successor

You came from outside the team to replace a previous manager.

Unique challenge: no smooth transition. The previous manager is gone. No handoff. You're learning everything cold — team dynamics, technical debt, in-flight projects, unresolved conflicts — while people are watching to see who you are.

Unique challenge: the predecessor's shadow. If the previous manager was well-liked, you'll be compared unfavorably to things they did. If they were poorly liked, people will project those behaviors onto you.

What to do: Change slowly. Listen before acting. Earn trust before changing things. Resist the urge to immediately "fix" what you think is wrong — most of that assessment will be wrong in the first 60 days.

---

3. The Pioneer

You're starting a new team from scratch. There's no team yet — just you and a mandate.

Unique challenge: you're alone. No peers on your team, no existing culture to lean on, no playbook. Everything is being invented.

Unique challenge: early hiring decisions define everything. The first few people you hire set the tone for culture, technical standards, and working norms. There's enormous pressure to fill seats fast.

What to do: Don't hire out of desperation. A bad early hire is much harder to fix than a slower start. Be patient and hold the bar.

---

4. The New Boss

You joined from outside the company to manage an existing team.

Unique challenge: blank page advantage — and the pressure to use it wrong. You have fresh eyes and no baggage. The temptation is to immediately share all your opinions on what's wrong and how things should be done differently.

What to do: Listen first. Don't push your opinions in the first weeks. Ask questions, understand context, learn why things are the way they are. You'll be more effective when you've earned trust.

Unique challenge: building relationships from zero. The team doesn't know you. You need to build trust with each person individually before you can lead them as a group.

What to do: Schedule a 30-minute 1:1 with every person on the team in your first two weeks. Treat it as listening, not presenting. Ask about them, their work, what's going well, what's frustrating. These relationships are the foundation everything else is built on.

---

Acquisition Integration: A Fifth Transition Type

When your team or company is acquired, the transition combines elements of all four types above — but with a specific failure mode that deserves its own entry.

The most common mistake: moving too fast.

Acquirers often want to show progress quickly — integrating processes, standardizing tools, reporting structures. The acquired team reads this as: "They don't trust how we did things." The result: the exact people the acquirer wanted to retain start leaving.

What to do first: build trust before changing anything.

In the first 60–90 days:

• Run the same processes the acquired team already has, even if they're different from yours
• Ask questions about why things work the way they do before suggesting changes
• Find genuine shared successes — wins that both sides can claim together

The shared success is key. It creates a reference point that makes future change less threatening: "We did X together. Now let's try changing Y."

Then increase pace — but together.

Once trust exists, the acquired team will pull you toward improvement. Changes they suggest are adopted; changes you impose create resistance. The goal is to become the kind of manager they'd want to build with — not the acquirer who tells them how things should be done now.

---

Counseling Engineers on the Management Track

When a senior engineer asks whether they should become a manager, three structural headwinds now apply that weren't true in previous years:

The technical pace problem. Stepping back from the IC track carries real skill atrophy risk. The EM role leaves little time to experiment with rapidly evolving tooling, and that gap compounds fast. An engineer who pauses IC growth for three years may find the landscape unrecognizable.

The ladder has flattened. Companies have increased IC-to-manager ratios, meaning Director and VP slots are scarcer and more competitive — especially with experienced leaders displaced from layoffs. A strong engineer can often advance further on the IC track than as a mid-level EM waiting for a Director opening.

The pay assumption is frequently wrong. Staff/Principal IC compensation at other companies often exceeds EM compensation at the current company. The internal promotion looks like a raise but can be a cut relative to the external IC market.

These arguments don't apply to someone who genuinely wants to manage — intrinsic motivation still outweighs the structural math. But they are essential context for an EM helping a report make an informed choice rather than a default one. Present both sides clearly; don't let the engineer assume management is the only path to senior impact.

---

Second-Time Manager Mistakes

The second management role is supposed to be easier. Often it isn't — because experience creates overconfidence.

Five common mistakes when coming back to management after a break:

1. Assuming what worked before will work again. Different organization, different people, different context. You can't copy-paste your methods. Managing junior developers from a previous military-style context is not the same as managing experienced engineers in a product company.

2. Too eager to change everything. By the time you're promoted the second time, you have years of ideas backed up. The instinct is to immediately fix everything you see. But the previous manager did things that way for reasons you haven't discovered yet — especially in stakeholder relationships.

3. Making promises you don't follow through on. You arrive motivated, commit to all kinds of improvements, and then get overwhelmed. Three team meetings in the first year instead of the promised monthly cadence. People remember the gap.

4. Falling into the same old traps. The first time, you can excuse the hard conversations you avoided with "I'm new at this." The second time, the excuses run out — but the avoidance doesn't.

5. Never stopping to think. A year goes by and nothing you planned actually happened. Build in dedicated reflection time — treat it like a commitment to yourself to review what you planned vs. what you achieved.

---