What I Got Wrong in My First Year as an Engineering Manager

I thought I was ready.

I had shipped features, mentored junior engineers, run a few projects end to end. My tech lead experience felt like the right warm-up. When I got the EM role, I walked in confident... and fell straight on my face.

Twelve months later, my mentor asked me for retrospective doc that encompassed a list of mistakes and how I planned to fix those gaps. This post is that doc, written publicly, so you don't have to make the same ones.

Mistake 1: I Kept Trying to Be the Best Engineer on the Team

The bar for SDE's at Amazon is genuinely high, and for a while I thought my job was to stay at that bar. So I kept jumping into technical discussions. Reviewing PRs like I was still an IC. Volunteering opinions on architecture decisions nobody asked me about; frankly I was wrong on a fair amount of them.

Here is the problem. Every hour I spent being an engineer was an hour I wasn't doing my actual job: clearing the path for my team to move faster, building the relationships that would unblock us six months from now, and figuring out who on my team needed to grow and how.

My team didn't need a part-time engineer-manager hybrid. They needed a full-time manager. It took me longer than I'd like to admit to accept that.

What I do now

I ask myself one question before jumping into a technical discussion: "Am I adding something here, or am I just scratching my own itch?" Most of the time, it's the second one. I stay quiet and let the engineers own it.

Mistake 2: I Treated 1:1s Like Status Updates

My 1:1 template in month one was basically: what are you working on, any blockers, anything I can help with. It was a standup with better snacks.

The thing is, nobody tells you the real stuff in a structured status check. If you're running your 1:1s like a project sync, you'll never learn that your senior engineer is quietly looking for other roles. You won't hear that two people on the team have been stepping on each other for three sprints. You won't find out that the roadmap your team is executing against doesn't actually make sense to anyone.

1:1s are not status updates. They are your primary source of signal about what is actually happening.

What I do now

I start every 1:1 with one open question: "What's on your mind?" Then I shut up. The first thing someone says after a few seconds of silence is usually the most important thing they have to say. Some developers do waste their 1:1s, but it's a coaching moment that I can then pivot to.

Mistake 3: I Misread What "Ownership" Meant

Amazon's Leadership Principles are plastered everywhere. You read them, you nod, you think you get it. I thought Ownership meant that I should be personally involved in everything my team shipped. I reviewed every doc. I sat in on every meeting. I was the bottleneck masquerading as a high-ownership manager.

What Ownership actually means is that you are accountable for outcomes, not present at every activity. There is a big difference. One scales. The other makes you a single point of failure for your entire team.

I was solving the wrong problem. I was optimizing for control instead of accountability.

What I do now

I ask myself where I am creating dependencies versus where I am creating capabilities. If my team can't make a decision without me in the room, that's not ownership. That's a process smell.

Mistake 4: I Avoided the Hard Feedback Conversations

I had an engineer who was consistently late on commitments. Not catastrophically late. Just late enough to cause friction with the rest of the team. I gave vague, soft feedback in our 1:1s. "Hey, let's think about how we communicate timelines earlier." Classic manager hedge.

The engineer didn't change. The team got more frustrated. And when it came time for their performance review, I had a documented pattern I had done nothing real about. That conversation was ten times harder than the one I should have had in month two.

Here's the thing about feedback avoidance: you think you're being kind. You're actually just deferring the discomfort. And it compounds.

What I do now

I use a simple rule borrowed from Kim Scott's Radical Candor: if I find myself softening feedback to the point where the other person might not realize it's feedback, I start over. The goal is to be clear, not comfortable.

Mistake 5: I Didn't Invest in Relationships Outside My Team

In my first year, I was heads-down on my team. I knew my engineers well. I had okay relationships with my PM. That was basically it.

What I didn't realize was how much of my team's velocity depended on relationships I didn't have yet. The partner team whose roadmap conflicted with ours. The senior leader whose buy-in I needed for a headcount ask. The peer EM in another org who had already solved a problem we were about to spend three months on.

Engineering management at a company like Amazon is not a solo sport. Your network is your leverage.

What I do now

I block time every two weeks to have a coffee chat with someone outside my immediate team. No agenda. Just building context and relationship. It pays off in ways that are hard to measure but impossible to miss.

The Common Thread

Looking back at all five mistakes, there's a pattern. I was optimizing for things that felt like management but weren't.

Staying technical felt productive. Structured 1:1s felt organized. Reviewing everything felt like ownership. Soft feedback felt kind. Staying heads-down felt focused.

None of it was wrong, exactly. All of it was just... off-center. I was doing a version of management that was more comfortable for me and less useful for my team.

The shift happened when I stopped asking "what should I be doing?" and started asking "what does my team actually need?" Those are different questions. The second one is harder to answer and more important to get right.

If you're in your first year as an EM, I have one piece of advice: find someone who is two or three years ahead of you and buy them coffee. Not to get answers. Just to learn what questions you should be asking. I wish I had done that sooner.

The mistakes will happen anyway. But you can at least make new ones.