I Locked Myself in a Bathroom Stall 3 Weeks Into My First Manager Role

I'm going to tell you something I've never shared publicly before. Three weeks into my first engineering manager role, I locked myself in a bathroom stall at our Austin office for fifteen minutes. Not to cry, exactly. More like to stare at the wall and wonder what the hell I'd gotten myself into.

My calendar had swallowed my IDE. My former teammates were suddenly awkward around me. And I'd just realized I had no idea how to actually do this job.

Here's what nobody tells you about the senior developer to engineering manager career path: the transition will break you a little before it builds you back up. Every blog post I'd read promised frameworks and tips. None of them mentioned the bathroom stall moments.

This guide is different. I'm going to walk you through exactly what happens in your first 90 days, including the failures nobody talks about. If you're considering making the switch from coding to leading teams, or you're already in the thick of it and wondering if you've made a terrible mistake, keep reading. I've been there. Four years after that bathroom stall moment, I can tell you it gets better—but first, it gets weird.

Section 1: Days 1–14: The Identity Crisis Phase

When Your Calendar Replaces Your IDE

The first two weeks hit different than you expect.

Day one feels almost exciting. New title, new challenges, maybe a small salary bump. You're ready. You've been preparing for this.

By day three, something feels off. Your fingers keep drifting toward your IDE. You catch yourself wanting to jump into that gnarly bug your team is debugging. But now there's a meeting. And another meeting. And a "quick sync" that somehow takes an hour.

By day eight, you'll experience what I call the identity vacuum. For years, your value was measured in shipped features, elegant solutions, and code reviews that actually taught people something. Now? Your calendar is full, but you feel like you've accomplished nothing.

Here's what those first two weeks often look like for new engineering managers:

• Meetings attended: Dozens
• Lines of code written: Close to zero
• Times asking "What even is my job now?": Too many to count

The hardest part isn't the meetings themselves. It's the realization that your old metrics for success no longer apply. You can't measure your day in pull requests anymore, and you don't yet know what to measure it in instead.

First-time engineering manager tips that actually helped me:

1. Accept that feeling unproductive is part of the process
2. Keep a "wins journal" even when the wins feel tiny
3. Block two hours daily as "no meeting" time, then protect it ruthlessly
4. Tell your team you're learning too

That last one matters more than you think. Vulnerability builds trust faster than pretending you've got it all figured out.

Section 2: The Former Peers Problem

Scripts for Seven Awkward Conversations You'll Definitely Have

Let's talk about the elephant in every new manager's room: you're now the boss of people who were your equals yesterday. Maybe even people you grabbed beers with last week.

In my case, I found myself managing engineers I'd worked alongside for years. One of them had actually interviewed me when I first joined the company. Now I was supposed to give him performance feedback.

If you're struggling to manage former peers as a new manager, you're not alone. This is the single most common challenge I hear about from first-time engineering managers.

Here are seven conversations you'll have, with actual scripts I've used:

1. "So... does this change things between us?"

Script: "Our friendship doesn't change. What changes is I now have responsibilities to the team and company that might sometimes create tension. I'd rather be honest about that than pretend it doesn't exist."

2. "Why did you get promoted instead of me?"

Script: "That's a fair question to ask. I can't speak to the specific decision, but I can commit to helping you grow toward whatever role you want next. Can we talk about what that looks like?"

3. "I disagree with this technical decision."

Script: "Walk me through your thinking. If you're right, we'll change course. If I still disagree, I'll explain my reasoning, but ultimately I may need to make a call you don't love."

4. "You're not coding anymore, so how can you even evaluate my work?"

Script: "Valid concern. I'm going to stay close enough to our codebase to give meaningful feedback, and I'll also rely on peer reviews more heavily. Tell me if you ever feel like I'm out of touch."

5. "Can we still vent about the company together?"

Script: "I'll always listen, but I can't participate the same way anymore. Some things I hear, I now have to act on or escalate. I'd rather be upfront about that."

6. "Are you going to tell [leadership] what I just said?"

Script: "Not unless it's something that affects the team's safety or the company's integrity. One-on-ones are confidential by default."

7. "I preferred how things were before."

Script: "Me too, sometimes. This is an adjustment for both of us. Can we check in regularly about how it's going?"

The key insight about managing former peers: the relationship does change, and pretending otherwise makes it worse. Acknowledge the awkwardness directly. Most people will respect you more for it.

Section 3: Weeks 3–6: The Competence Collapse

Why You'll Feel Worse at Your Job Before You Feel Better

Here's the brutal truth about what challenges first-time engineering managers face: you're going from expert to beginner overnight. And your brain hates that.

As a senior developer, you probably experienced "unconscious competence" in your technical work. You could solve problems without thinking too hard about how you were solving them. It just flowed.

Now you're managing humans. And humans don't compile predictably.

Weeks three through six were my personal low point. I call it the competence collapse.

The imposter syndrome that new engineering managers experience hit me hard. I felt like:

• A fraud in leadership meetings
• Out of touch in technical discussions
• Generally worse at everything than I'd ever been

What I didn't realize is that this feeling is the learning process. You can't build new skills without first becoming aware of how much you don't know.

The Four Stages of Competence model (also known as the Conscious Competence Learning Model) explains this. You go from unconscious incompetence ("I don't know what I don't know") to conscious incompetence ("Wow, I'm bad at this"). That second stage feels terrible, but it's progress.

First 90 days engineering manager mistakes to avoid:

• Micromanaging because you miss the technical details
• Avoiding difficult conversations because they're uncomfortable
• Making decisions alone when you should be facilitating team decisions
• Comparing yourself to experienced managers
• Trying to prove you can still code as much as your team

I made every single one of these mistakes. The key is recognizing them early and course-correcting.

Section 4: Technical Lead vs. Engineering Manager

The Decision Framework I Wish Someone Had Given Me

Let me address something that should come before the transition: the differences between technical lead and engineering manager are real, and picking wrong will make you miserable.

I've seen talented engineers become terrible managers because nobody helped them understand what they were signing up for. And I've seen great potential managers stay in IC roles because they assumed management meant abandoning everything they loved.

Here's my framework for evaluating whether you should become an engineering manager or stay technical:

Energy audit: What actually gives you energy?

Rate these on a scale of 1–10 (10 = energizing, 1 = draining):

• Solving a gnarly technical problem alone: ___
• Helping a teammate solve their problem: ___
• Attending a meeting with no technical content: ___
• Writing documentation about architecture decisions: ___
• Having a difficult performance conversation: ___
• Mentoring a junior developer through a concept: ___
• Defending technical decisions to non-technical stakeholders: ___
• Shipping code that you personally wrote: ___

If your highest scores are on odd-numbered items, the IC track might serve you better. If even-numbered items light you up, management could be your path.

The time horizon test:

ICs optimize for the current sprint or project. Managers optimize for the next quarter or year. Which timeframe do you naturally think in?

The multiplier question:

Are you more satisfied by 10x-ing your own output, or 2x-ing the output of five other people? Both create the same total value, but they feel completely different.

The skills needed for an engineering management role overlap with technical leadership but diverge in important ways. Both require technical credibility. But management requires emotional labor that technical leads can often avoid.

There's no shame in trying management and returning to IC work. Some of the best engineers I know did exactly that, and they're better ICs for the experience.

Section 5: Months 2–3: Building Your Manager Operating System

Without Losing Your Technical Edge

If you've survived the first six weeks, congratulations. You're past the worst of the adjustment period.

Now comes the construction phase: building repeatable systems that make the job sustainable.

Here's the operating system I've developed for how to transition from senior developer to engineering manager without burning out:

Weekly rhythm:

• Monday: Review team priorities, prep for the week
• Tuesday–Thursday: One-on-ones (30 min each, never skip these)
• Friday: Reflection time, career development conversations

Monthly rituals:

• Architecture review participation (keeps you technical)
• Skip-level meetings with your team's reports (if applicable)
• Personal retrospective: what worked, what didn't

Quarterly commitments:

• Career development plans for each direct report
• Technical skills maintenance (consider dedicating time to a small project)
• Peer feedback collection

Staying technical while managing is possible but requires intention. I recommend blocking dedicated time weekly for code review and architecture discussions. Not coding yourself, but staying close enough to provide meaningful guidance.

The senior developer to engineering manager career path doesn't mean abandoning your technical identity. It means expanding it.

Honest Metrics to Evaluate If This Path Is Right for You

You've made it to day 90. Or maybe you're reading this before starting and want to know what success looks like.

Here's my honest assessment framework:

Signs it's working:

• You look forward to one-on-ones
• Your team is shipping without you unblocking them constantly
• You've had at least two hard conversations that ended well
• The identity crisis has faded (not disappeared, just faded)
• You're finding new sources of satisfaction beyond code

Signs to reconsider:

• Every meeting feels like a waste of time
• You resent your team for "needing" you
• You're coding on nights and weekends to feel competent
• The stress isn't decreasing, even as you learn
• You miss IC work more now than you did on day one

If the second list describes you, that's okay. Returning to IC work isn't failure—it's self-awareness.

The senior developer to engineering manager career path isn't linear, and it isn't permanent. Some of the most valuable leaders I know oscillated between IC and management multiple times before finding their fit.

And those bathroom stall moments? They don't go away entirely. But they get shorter. And eventually, they transform into something else: the quiet satisfaction of watching someone on your team succeed because of conversations you had, systems you built, and growth you nurtured.

That feeling? It's worth the transition.