Going from IC to EM without losing the plot

I made the move from senior IC to engineering manager when I joined Oracle. I’d been adjacent to management for years — leading on-call rotations, mentoring, running incident reviews — but the formal title is its own animal. Three years in, here’s the short list of things I’d tell my first-week self.

1. Your job is no longer to be right

It’s to make the team’s decisions get made well and stick. If you’re the smartest person in the room on a technical question, you’ve usually failed earlier — at hiring, at delegation, or at trusting people who knew more than you. The hardest part of the transition wasn’t writing less code. It was watching a decision get made differently than I’d have made it, and not stepping in.

2. 1:1s are the work, not a tax on the work

I spent my first six months treating 1:1s like overhead. I had them, I prepared for them, but in my head they were the thing keeping me from “real” work. They are the real work. Every problem I had to fight in quarter two was a problem I could have prevented in quarter one if I’d been paying closer attention to my 1:1s.

The shift: stop bringing your agenda. Bring questions. “What’s draining your energy?” gets you more useful information than “How is project X going?” every time.

3. The calendar is the org chart

Show me a manager’s calendar and I’ll tell you what they actually care about. If your calendar is wall-to-wall meetings about the same project, the rest of your team is unmanaged. If you have no recurring 1:1s, you don’t have a team — you have a group of people who report to you on paper.

I now block focus time and call-it-mine time the same way I block 1:1s. The default state of a manager’s calendar is “completely full of other people’s priorities.” You have to actively defend space, or you become a router with no agenda of your own.

4. Performance management is a kindness

I dodged hard conversations for the first year and convinced myself I was being a nice manager. I was being a coward. The kind thing — for the engineer, the team, and the company — is to tell someone in week two that what they’re doing isn’t working, not in month nine when it’s a performance plan.

The frame that helped: if I were them, would I want my manager to tell me this now, or in six months?

5. Your output is your team’s output. Get used to it.

The dopamine hits are different. As an IC, you ship a thing and it’s yours. As an EM, you make six small adjustments — a hire, a re-org, an unblock, a coaching conversation — and three months later the team ships a thing. None of it points back at you, and that’s correct. Get your dopamine somewhere else.

What worked for me: writing. Side projects. TryHackMe. This blog. Anything where the loop between effort and result is short, so I can spend my work hours on the long, slow loop without going insane.

6. AI tooling is changing this job, fast

I’m still figuring out what to make of it. Code review used to be a load-bearing way I stayed connected to the codebase; AI-assisted PRs now arrive faster than I can read them. Hiring signals — what a “strong” coding interview looks like — are moving under us in real time. I’d rather be early to figure this out than late.

That’s most of what I’m writing about now. If you’re an EM in the same boat, ask me anything.

What I’d do differently

I’d have hired a peer mentor in week one. I tried to figure most of this out by reading and observation, which got me 60% of the way there. The other 40% would have come faster if I’d just asked someone six months ahead of me to grab coffee every two weeks.

If you’re early in this transition: do that. Today.