Go back

Engineer → Engineering Manager: 6 core mindset shifts

Published:

Across years in software, I’ve watched a pattern repeat that most people don’t catch — when an Engineer steps into a Manager role, most struggle not from a technical skill gap, but from continuing to think like an Engineer.

When you step into a new role, the question worth asking is: which skills do I already have, and which am I missing to do this well?

What follows are observations I’ve collected over time — they sound counterintuitive, but in a Manager role each one runs counter to the instincts of a good Engineer.

Some terms

  • IC (individual contributor) — an Engineer who contributes directly to the work without managing people. A pure Software Engineer.
  • EM (Engineering Manager) — a technical Manager responsible for an Engineering team and what that team delivers.
  • SME (subject matter expert) — the deep expert in a specific technical area within the team.
  • 1:1 — a private conversation between two people (Manager and a team member). Usually weekly or biweekly.
  • P0/P1 — bug priority levels. P0 is highest (impacting production, fix immediately), P1 just below.
  • Blameless — a culture of “no hunting for someone to blame” when incidents happen. The goal is learning from the failure, not finding a scapegoat.

1. EM is a lateral move, not a promotion

A Senior Engineer announces in team chat “starting next week I’m moving into a Manager role” — the common response is “congrats, promotion?”. The real answer: it’s not a promotion. It’s a lateral career change.

Google, Microsoft, Amazon and most large tech companies have two parallel career ladders, at equivalent levels:

  • IC track: Engineer → Senior → Staff → Principal → Distinguished
  • EM track: EM → Senior EM → Director → VP

A Principal Engineer (IC) can outrank a Senior EM. And this is a two-way door — you can return to IC if it doesn’t fit, as long as you keep your coding skills sharp.

The core difference isn’t “EM is better than IC”, but that success is measured in a completely different way:

AspectIC (individual contributor)EM (Engineering Manager)
PriorityIndividual output is the unitTeam output is the unit
TimeMostly coding and shippingMostly meetings, mentoring, strategy
Success metricsConcrete, weekly (PRs, ships)Team health, retention, long-term velocity
Role mindsetDoer / creatorCoach / enabler
Vantage pointGround level — today’s task50,000-foot — whole org, quarters and years

Consequence: you’ll have weeks where it feels like you did nothing. No PR of yours merged, no feature shipped — just meetings, 1:1s, unblocking others. Many new EMs reflexively jump back into coding to “feel productive”. That’s the sign they’re doing the role wrong.

2. People first — team before self

This mindset sounds like a cliché, but it defines almost everything an EM does.

As an IC, you optimize your time to code effectively. As an EM, you optimize the team’s time. Concretely: you spend time not solving bugs but unblocking the people who solve bugs. You don’t make technical decisions yourself, but create the conditions for the SME on your team to make them. You don’t pitch ideas to leadership yourself, but advocate for the team’s ideas.

In Engineer X’s first month as EM, Engineer Y — a new Engineer on the team — accidentally pushed a bug to production. Engineer X’s first instinct (from their years as a strong Engineer) was to find who was responsible: pull Engineer Y aside, maybe ping the QA team “why didn’t you catch this?”. If Engineer X had followed that instinct, the bug would have been fixed fast — but from that week onward, every time anyone on the team considered shipping a risky change, they’d ask themselves “if this breaks, whose name gets called out?” and start delaying, or over-guarding. That’s a culture of fear — quieter than a bug, but kills team velocity more reliably.

Engineer X caught themselves in time and went the other way. They sat with the team to fix the bug, reminding everyone that mistakes are normal in a fast-shipping environment. After production stabilized, they spoke privately with Engineer Y — not to blame them, but to figure out together what guardrails could prevent a repeat. Then they opened a team meeting framing the message: “mistakes are OK — as long as we learn from them”, encouraging Engineer Y to see this as a learning moment. Bug fixed. The team learned Engineer X doesn’t hunt for blame. Trust went up.

This sounds simple, but the key self-test is: what’s your first instinct when an incident happens? Find the person responsible, or find the lesson for the team? If your instinct still leans toward “find the person”, you haven’t completed this mindset shift yet.

3. Delegating right — let go without dropping accountability

This mindset sounds simple, but it’s the hardest one nearly every new EM wrestles with.

As an IC, when you face a hard problem you think: “I’ll do it myself, I’m the fastest”. As an EM, that thought is the bottleneck for the whole team — the better you are, the more you take on; the more the team depends on you, the less it grows.

In Engineer X’s second week as EM, they had a critical API integration task. The right call was to assign it to Engineer Y (the junior on the team eager to grow). But Engineer X did the math fast: “if I give it to Engineer Y, I’ll spend half a day teaching them, then review, then fix issues; I can do it myself in 2 days.” Engineer X did it themselves. Next week, similar task. Did it themselves again. Three months in, Engineer X was burned out from carrying IC work + EM responsibilities; Engineer Y was still at the same junior level; the team still leaned on Engineer X for every technical decision.

In month four, Engineer X realized they were wrong and tried a different approach. A similar hard task came up; they spent 3 days sitting with Engineer Y to explain context, approach, edge cases. Plus 1 day pairing while Engineer Y did the first task. Four days for the first task — more than the 2 days if Engineer X had done it solo. But from the second task onward, Engineer Y did it, not Engineer X. After 10 similar tasks, Engineer X spent only that initial 4 days; the other 9 ran without them touching anything. They saved 16 days compared to their earlier self — and Engineer Y leveled up to mid-level, able to mentor newcomers.

The math is tight, but it nails the biggest trap: the feeling of “I’m faster on my own” is only true for this task, today. For a chain of similar tasks — or any long-term responsibility — going solo is always the worst option.

But “delegating” isn’t simply offloading work. There are three modes that get confused — and Engineer X back in month two, before he learned, had actually moved from “do it myself” to mode one (the worst of the three):

AspectAllocationDelegationSubstitution
GoalGet the work done, full stopDone + the assignee learns a new skillSomeone fully replaces you
Approach”Assign and forget”Ongoing coaching — check-ins, feedback, retrosFull handover
AuthorityHand over completelyJust enough to act; you remain accountableAll authority transferred
Long-term opportunityNot a concernCentral — career growth for the assigneeFully transferred

Earlier on, Engineer X would message Engineer Y “please do this task, deadline Friday” and disappear — that’s allocation, and it accidentally signals “I don’t care what you learn, just get it done”. After he learned his lesson, Engineer X started investing time in mid-task check-ins, step-by-step feedback, end-of-task retros — that’s delegation done right. And critically: Engineer X remains accountable for the outcome. Engineer Y is the doer (responsible); Engineer X is the one who stands before the org if the task fails (accountable).

After delegating, the hardest discipline is not interfering. Each time Engineer X “swung by to quickly fix” so Engineer Y wouldn’t get stuck, Engineer X both disrupted Engineer Y’s flow and signaled “I don’t trust you”. Engineer X learned to accept Engineer Y taking longer detours — because they knew each detour taught Engineer Y something words couldn’t. A clear sign a team has shifted from dependent to autonomous: questions evolve from “how should I do this?” to “here’s how I’m thinking about it, what do you think?” — you’re no longer the answer-giver, you’re the validator.

Self-test: last week, how many tasks did you delegate as “assign and forget”, and how many did you actually invest coaching time in? If it’s 9:1, you’re acting like Engineer X before he learned the lesson.

4. Owning outcomes in ambiguity — Extreme Ownership

Imagine a typical scenario. You’ve just taken over a team. In week three, there’s a production outage. You didn’t write that code. You didn’t approve that PR. You dig in and find an Engineer on the team skipped code review to ship an urgent fix — and that patch caused today’s outage.

What’s your first reaction?

  • (a) Report up immediately: “Engineer Z skipped review, that’s the root cause.”
  • (b) Pull Engineer Z into a meeting, demand an explanation in front of the team.
  • (c) Tell your Manager: “Our team’s process has a gap. I’ll look into it and fix it.” Then go to the team without hunting for blame, but to figure out together why the process let someone skip — and put a technical guardrail in place so no one can skip next time, even if they wanted to.

Option (c) is extreme ownership — taking responsibility not just for your own work, but for every aspect that affects the mission. Accountability ripples — it extends to every step, every stage.

In the EM role, this mindset shows up in concrete moments:

When a project misses its deadline, you don’t say “my team didn’t have the right skills” — you say “I haven’t hired for the right skills, or trained enough; that’s on me to fix”. When a cross-functional partner doesn’t cooperate, you don’t say “that team is hard to work with” — you ask “have I set up the relationship right?”. When your boss makes a call against the team’s preference, you don’t go to the team and complain “the boss made me do it” — you go to the team, explain the reasoning, and stand behind the decision. That’s owning it.

The opposite trap new EMs often fall into is perfectionism — waiting until you have “enough data” before deciding. As a Manager, you almost never have enough data. Waiting is not deciding. This is analysis paralysis. You decide with 60-70% information, accept being wrong sometimes, fix fast.

For extreme ownership to be possible, the team needs a foundation: blameless culture — no person-hunting. Concretely through blameless postmortem (incident analysis without finger-pointing): when an incident happens, reviewers don’t get to name a scapegoat — they only dissect the system and process. Sounds soft, but it’s the precondition for Engineers to feel safe reporting problems early — and the precondition for the EM to take ownership without flinching.

Two sides of the same coin: you dare to own outcomes because the team is shielded from blame, and the team dares to report failures early because they know the EM will carry it, not deflect.

5. Time is your scarcest resource — Eisenhower Matrix

End of the workday, you look at your to-do list and notice most of the important items remain untouched — because the day was swallowed by “urgent meetings” from other people and dozens of Slack pings. This is the most common scene when an Engineer becomes an EM. A packed calendar feels like “busy contributing important work” — really it’s a sign of losing control of time.

The cause comes from a sharp distinction: maker’s schedule vs manager’s schedule. Engineers run on maker’s schedule — they need long, contiguous, uninterrupted blocks to drop into deep work. EMs run on manager’s schedule — the day is sliced into 30-minute slots, full of meetings, full of context switches. But the day is still only 24 hours; without a system, every hour evaporates.

The classic tool to regain control is the Eisenhower Matrix — named after US President Dwight Eisenhower, who famously said: “I have two kinds of problems: the urgent and the important. The urgent are not important, and the important are never urgent.”

The matrix sorts every task into 4 quadrants, on two axes: urgent (does it demand action now?) and important (does it affect long-term goals?):

UrgentNot Urgent
ImportantQ1 — DO (do now)Q2 — SCHEDULE (plan it)
Not ImportantQ3 — DELEGATE (hand off)Q4 — DELETE (drop it)

Examples per quadrant — read these and you’ll know immediately which one you live in most:

  • Q1 — Do: team 1:1s, P0/P1 bugs, production outages, critical project alignment.
  • Q2 — Schedule: team offsites, long-term on-call health plan, building the hiring pipeline.
  • Q3 — Delegate: running operations review meetings, on-call handoffs, generating sprint reports.
  • Q4 — Delete: catching up on social media, reading about other orgs’ projects unrelated to your team.

The crux: successful EMs live mostly in Q2 — important but not urgent. That’s the zone of long-term strategy, hiring, architecture, building process. Failed EMs live mostly in Q1 (firefighting all day) and Q3 (reacting all day to other people’s “urgent”).

Q3 is a particularly dangerous trap because it disguises itself as real work. A request from a stakeholder, with a clear deadline, looks like something you must do — but on closer look, it’s urgent for them, not important for your team’s mission. Spend all your time in Q3, and you’ll never have time for Q2. The reflex question for anything landing in Q3: “is there someone on the team wanting to grow in this area?” If yes — there’s your delegation opportunity.

Living in Q2 doesn’t come naturally. Three disciplines need building together.

First, declutter your calendar. For each meeting on your calendar, ask directly: “am I actually needed here?” If you only need updates, get them offline or via async notes. A packed calendar isn’t a sign of important business — it’s a sign of weak discipline at saying no.

Second, learn to say no. “No” doesn’t have to be a flat refusal. A better version is the counter-proposal: “To take this on, I need to drop or push back X. Which do you want to prioritize?” That forces the requester to reassess priorities — and often they retract the request. Setting boundaries for your team isn’t being uncooperative; it’s what good bosses respect. If you don’t protect your team’s time, no one will.

Third, async by default. Slack and email for anything not urgent; sync meetings only for genuinely time-sensitive matters or decisions requiring real-time consensus. Each context switch costs 15-25 minutes of recovery — meaning 10 interruptions a day eats 2-4 hours of real work. Protecting focus blocks (both yours and your team’s) is a baseline form of respect for productivity.

These three disciplines — declutter, say no, async — aren’t techniques, they’re a mindset shift. People who haven’t made the shift always feel “I’m too busy to apply this stuff”. That’s exactly the sign they need the shift most.

6. Continuous learning — admit your limits

The final mindset is simple but counterintuitive: the best EMs aren’t the ones who know everything — they’re the ones who know what they don’t know.

As an Engineer, your identity is tied to “knowing the answer”. As an EM, your identity shifts to “knowing how to find the answer through the team”.

Imagine a common scenario. Engineer Y asks Engineer X whether to use in-memory caching or Amazon ElastiCache (an AWS caching service) for an app. Engineer X doesn’t know the answer. Two common reactions:

Reaction (a) — admit and facilitate: Engineer X says plainly “I don’t have a clear view here”, suggests a relevant online course, connects Engineer Y with a tech lead on a sister team who has experience in that area, and asks Engineer Y to come back and share what they learned and decided.

Reaction (b) — avoid: Engineer X redirects Engineer Y straight to the tech lead without understanding the technical question, doesn’t follow up, learns nothing from the situation.

The two reactions sound similar (neither answers directly), but they’re qualitatively different. (a) is admit-and-enable. (b) is dodge. The best student in class is the one willing to raise a hand and say “I don’t understand this”. The best EM is the one willing to say “I’m unclear on this — let me look into it with the team”.

Two practices to sustain this mindset:

“See one, do one, teach one” — borrowed from medical training: observe someone do it, then do it yourself, then teach someone else. Until you can teach it, you don’t really understand it. Applied to the EM journey: shadow another EM (see), try in a stretch project (do), then mentor a newer Manager (teach). The cycle never ends.

Have both a mentor and a mentee at the same time — a mentor outside your org for outside perspective and to avoid internal bias; a mentee inside to pass on what you’ve just learned. It’s the loop that keeps a growth mindset alive: take from above, push downward, always be in the middle of learning and teaching.

Wrap-up — and a small reminder

The six mindsets aren’t a checklist. They’re internal shifts — and each one runs counter to a good Engineer’s instinct:

Mindset before (IC)Mindset after (EM)
Becoming a Manager is a promotionIt’s a lateral career change
I optimize my own outputI optimize the team’s output
Hard problem → I’ll do itHard problem → I coach someone else through it
Don’t decide without enough dataDecide with 60-70% data, own the outcome, fix fast
My time arranges itselfTime is your scarcest resource — needs a system
Knowing the answer is my edgeKnowing how to find the answer is my edge

The most important point: not every great Engineer should become an EM, and not every “average” Engineer fails at being a great EM. The two skill sets overlap on mentoring and technical judgment, but diverge sharply on people. And “putting people first” is a trait you either have or you don’t — very hard to train from zero.

If after reading these six mindsets they feel natural to you — welcome to the EM path. If they feel against your instincts — that’s also a valuable answer. Staying on the IC track isn’t a demotion. The IC track in modern tech companies can reach Principal or Distinguished Engineer, and that path carries just as much weight and impact as the EM track.

What matters is that you choose by understanding, not by default.

Previous Post