manager-dot-dev/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.

---

The EM Role in the New Era

Since the end of the zero-interest-rate period (post-2022), the engineering management role has been shifting:

• Fewer managers, higher IC-to-manager ratios
• More responsibility per manager
• Growing expectation that EMs can be "player-coaches" — contributing technically while managing
• A tougher market for line managers who can't or won't engage technically

Practical implications for job security and effectiveness:

• Stay close to the code — not at the expense of management quality, but enough to maintain credibility and context
• Strengthen your network inside and outside the company. Tenure matters; so does visibility
• Be the kind of EM who makes technical people around you better, not just the one who coordinates their work

---

7 Deadly Sins of a New EM

The most common mistakes new engineering managers make in their first months:

1. Taking critical coding tasks yourself instead of delegating
2. Fighting with the PM constantly
3. Not trusting anyone except yourself
4. Immediately trying to change things
5. Committing to unreasonable deadlines
6. Not running team meetings because "it feels weird now"
7. Making promises you can't keep

Most of these are instincts from individual contributor work applied in the wrong role.

---

The Blue Tape List

From The Art of Leadership (Lopp): when you arrive in a new role, everything that feels wrong gets a blue tape label — a note on the wall, a line in a doc, whatever works. You're not acting on it yet. You're just tagging it.

Wait 30 days. Then revisit your list.

Some things will have resolved themselves — they were temporary states you didn't have context for. Some will look different once you understand why they exist. Some will still feel wrong, and now you understand them well enough to actually fix them.

Why this matters: new managers often react to the first wrong thing they see without understanding the ecosystem around it. They fix the visible symptom and break three invisible things. Or they change something that looked like a flaw but was actually a deliberate trade-off.

The blue tape list separates observation from action. It preserves your fresh perspective (which disappears quickly as you normalize) while giving you time to gather context before acting on it.

Practical format: keep a running list of "things that feel off" with the date you noticed them. At the 30-day mark, review it with someone who knows the context. For each item: is this still worth addressing? Do you now understand why it exists? If you were to act, would you act differently than you would have on day one?

The list also becomes useful evidence. If the same issue appears in your notes three times over 30 days, that's different from something you noticed once.

---

Turning Around a Broken Team

When you inherit a struggling team, the instinct is to blame the previous leader and signal change fast. That almost always backfires.

Don't open with blame. Even if the prior situation was genuinely bad, opening with "the previous approach was wrong" signals disrespect for what people endured to get here. Show that you value their effort before you redirect their direction.

Name the baggage explicitly. Teams don't leave the past behind by hoping it disappears. Name what stops here — specific behaviors, processes, or patterns — and ask the team to help rewrite the rules. The more they co-author the new approach, the more they'll follow it.

Own your part. You may not have caused the problem, but if you were even partially complicit (slow to act, missed signals), say so. Teams forgive mistakes they're told about. They don't forgive the same mistakes being repeated silently.

Reset the target together. Ask the team to look 6–9 months ahead: imagine everything went your way. What do they see? What did you deliver? How do you interact? How do they feel? The shared destination becomes a filter for 100 daily micro-decisions.

Revise the behaviors, not just the goals. Goals without defined behaviors are empty. "Act like owners" means nothing. What specifically does ownership look like on this team, in this context? Be concrete.

---

The Dopamine Shift: What New Managers Miss

The most overlooked transition challenge has nothing to do with skills — it's neurological.

As an IC, your dopamine came from a predictable place: shipping things. Closing a PR. Fixing a bug. Watching something deploy. As a manager, those direct rewards vanish. For weeks or months, you may feel genuinely unfulfilled.

This isn't a sign you made the wrong choice. It's a sign you haven't yet rewired where you get satisfaction from.

The shift: you're not the star anymore — you're the facilitator. You don't ship a project. You help your team ship all projects. The satisfaction comes from different signals: a report growing noticeably, a difficult conversation that landed well, a team delivering something they wouldn't have without you.

Two other common traps for new managers:

• Reluctance to delegate. The rationalization is "they won't do it the way I would." Even if that's true, long-term you need your team capable of doing what you used to do — otherwise neither of you grow.
• Equating team size with success. More headcount isn't a sign of management skill. Quality of output is.

---

Dive Deeper

If the user asks where a framework came from, wants to read the original article, or wants more context on any topic in this skill — read references/sources.md. For second-time manager mistakes and the EM role in the post-2022 era, read references/extended.md.

---

Related Skills

• 1on1s — First-week 1:1s are critical for all four transition types
• delegation — Apprentices especially struggle with letting go of IC work
• feedback — Turning around a broken team requires direct, specific feedback conversations
• managing-yourself — The 10 EM traps hit hardest during transitions