The Engineering Manager's First 90 Days

The day I became an engineering manager, I made my first mistake. I spent the entire first week reviewing every pull request, attending every standup, and writing code on the team's most critical project. I was doing what had made me successful as a Senior Engineer — and it was exactly the wrong thing to do as a manager.

By week three, two things became clear. First, my calendar was 80% meetings and I was reviewing PRs at 10 PM. Second, my team was confused about their priorities because I was too busy doing individual contributor work to actually manage. The most senior engineer on the team pulled me aside and said, "I need you to stop writing code and start making decisions."

That conversation changed how I approached the role. The transition from individual contributor to engineering manager is the most disorienting career shift in software engineering. Your value is no longer measured by what you build — it's measured by what your team builds. Your tools change from IDEs and terminals to 1:1 meetings and roadmap documents. Your feedback loop goes from "tests pass" (minutes) to "team is productive and healthy" (months).

This guide covers what I wish someone had told me during those first 90 days — structured as a week-by-week playbook with practical advice on 1:1s, team dynamics, first wins, and the mistakes that trip up nearly every new EM.

The Mindset Shift: From Maker to Multiplier

Michael Lopp (Rands) describes the manager's job as "developing a instinct for clarity." As an IC, your instinct is to solve problems. As a manager, your instinct should be to create conditions where your team solves problems effectively.

This shift manifests in concrete ways:

According to Camille Fournier's "The Manager's Path", the most common failure mode for new engineering managers is continuing to operate as an IC — writing too much code, reviewing every PR, and making every technical decision. This isn't management; it's being a very busy senior engineer with extra meetings.

Week 1-2: Listen and Learn

Your first two weeks should be almost entirely about gathering information. Resist the urge to change anything. You don't yet have the context to make good decisions.

1:1 Introduction Meetings

Schedule a 45-minute 1:1 with every person on your team. Not 30 minutes — 45. The extra time gives people space to open up. Ask these questions:

• "What's going well on the team that I should make sure not to change?" This tells you what works and signals that you respect existing team dynamics.
• "What's the biggest blocker to your productivity right now?" This surfaces actionable problems you can address quickly.
• "How do you prefer to receive feedback?" Some people want direct, immediate feedback. Others prefer written feedback they can process. Knowing this prevents miscommunication.
• "What are your career goals for the next 1-2 years?" This starts the career development conversation early.
• "What should I know about how this team works that isn't in any document?" This reveals the informal culture, politics, and dynamics that nobody writes down.

Stakeholder Meetings

Meet with everyone your team interacts with — product managers, designers, other engineering managers, QA leads, and your own manager. Ask:

• "What does my team do well?"
• "Where do you experience friction working with my team?"
• "What would you change if you could?"

What to Observe

• How does the team communicate? (Slack heavy? Meeting heavy? Async?)
• Who are the informal leaders? (They may not be the most senior engineers)
• What are the unspoken rules? (Who reviews whose code? Who gets consulted on decisions?)
• Where does work get stuck? (Long PR review times? Waiting for external dependencies? Unclear requirements?)

Week 3-4: Establish Your Rhythm

Setting Up 1:1s

1:1 meetings are the most important tool in a manager's arsenal. Manager Tools calls them "the single most effective management tool." Set them up with these principles:

• Weekly, 30 minutes, same time every week. Consistency builds trust. Canceling 1:1s repeatedly sends the message that your report isn't important.
• Their meeting, not yours. The first 15 minutes are for the report's agenda. The last 15 are for yours. If they have nothing to discuss, use the time for coaching or career development.
• Take notes. Keep a running document for each report. Track action items, career goals, feedback given, and important context. You'll reference this during performance reviews.
• Don't use 1:1s for status updates. Status can be communicated asynchronously. 1:1s are for building trust, giving feedback, coaching, and discussing career development.

Team Meetings

Audit the team's existing meetings. Most teams have too many. For each meeting, ask:

• What decision does this meeting produce?
• Who actually needs to be in this meeting?
• Could this be an async update instead?

A healthy engineering team needs at most: a weekly team standup (15-20 min), sprint planning (if agile), retrospective (biweekly), and your weekly 1:1s. Everything else should justify its existence.

Communication with Your Manager

Your relationship with your own manager is critical. Have an explicit conversation about:

• How they want to be updated: Weekly email? Weekly 1:1? Only when there's a problem?
• What success looks like for you: What should you accomplish in the first quarter?
• Decision authority: What can you decide independently? What needs their sign-off?
• Their communication style: Do they want detailed context or just recommendations?

Week 5-8: First Wins

By week five, you should have enough context to take action. First wins matter because they build credibility — with your team, your peers, and your management chain.

What Makes a Good First Win

• Visible: The team (and ideally, stakeholders) can see the impact
• Quick: Achievable in 1-2 weeks, not months
• Low risk: Failure won't damage your credibility
• Based on team input: Addresses a pain point your team told you about during 1:1s

First Win Ideas

Week 9-12: Strategic Foundation

By this point, you should be transitioning from reactive (responding to what you find) to proactive (shaping the team's direction).

Write Your Team Charter

A team charter is a one-page document that answers:

• Mission: Why does this team exist? What problem does it solve?
• Scope: What is this team responsible for? (Equally important: what is it NOT responsible for?)
• Key metrics: How do we measure success?
• Ways of working: How do we communicate, make decisions, and handle disagreements?

Share this with your team, get their input, iterate, and then share with stakeholders. This document prevents scope creep and misaligned expectations — two of the most common sources of engineering team dysfunction.

Start Career Development Conversations

By week 10, you should have enough relationship with each report to have a meaningful career development conversation. Use a framework like:

1. Where are you now? (Skills, experience, current role)
2. Where do you want to be in 18 months? (Next role, new skills, different domain)
3. What's the gap? (Skills to develop, experiences to seek, relationships to build)
4. What's the plan? (Concrete actions for the next quarter)

Document this and revisit quarterly. Kim Scott's "Radical Candor" framework is excellent for structuring these conversations — care personally, challenge directly.

Common Mistakes in the First 90 Days

Mistake 1: Changing Everything Too Fast

New managers often feel pressure to "make their mark" by overhauling processes, reorganizing the team, or introducing new tools. This destabilizes the team and creates resentment. The team was functioning before you arrived — understand why before you change how.

Fix: Follow the "Listen → Understand → Propose → Implement" sequence. No changes in the first 30 days. Proposed changes in days 30-60. Implemented changes (with team buy-in) in days 60-90.

Mistake 2: Not Having Difficult Conversations

Avoiding conflict is the most common management failure. If an engineer is underperforming, address it directly and early. If two team members have interpersonal friction, facilitate a resolution. Every week you delay a difficult conversation, the problem grows.

Fix: Use the SBI framework: Situation (when/where), Behavior (what you observed, not your interpretation), Impact (how it affected the team/project). Example: "In yesterday's sprint review [situation], you interrupted Alex twice while he was presenting [behavior], which made him lose his train of thought and flustered him [impact]."

Mistake 3: Being the Funnel

All requests go through you. All information goes through you. All decisions go through you. This creates a bottleneck, burns you out, and disempowers your team.

Fix: Delegate decision-making. Define which decisions you need to be involved in (hiring, promotions, major architecture changes) and which the team can make independently (tooling choices, implementation approaches, sprint commitments). Document this explicitly.

Mistake 4: Neglecting Your Own Manager

New EMs focus so much on their team that they forget to manage up. Your manager is your primary advocate for resources, headcount, and recognition. If they don't know what your team is doing and why it matters, you won't get the support you need.

Fix: Send a weekly update (3-5 bullets) covering: what the team accomplished, what's blocked, and what decisions you need from them. This takes 10 minutes and saves hours of "catching up" in meetings.

Mistake 5: Trying to Stay Technical

Many new EMs try to maintain their technical edge by writing code, reviewing every PR, and attending every design discussion. This is unsustainable. You can't do two full-time jobs simultaneously.

Fix: Accept that your technical skills will atrophy somewhat. Stay technical enough to make informed decisions (read design documents, understand the architecture, occasionally review critical PRs) but don't write production code. If you're writing code, you're not managing.

The 1:1 Toolkit: Questions for Every Situation

Essential Reading for New EMs

• "The Manager's Path" by Camille Fournier — the definitive guide to engineering management levels
• "An Elegant Puzzle" by Will Larson — systems thinking for engineering leaders
• "Radical Candor" by Kim Scott — framework for feedback and relationships
• "High Output Management" by Andy Grove — management fundamentals from Intel's CEO
• "Turn the Ship Around!" by L. David Marquet — leader-leader model (vs leader-follower)
• Blog: Rands in Repose — Michael Lopp's management writing
• Newsletter: The Pragmatic Engineer — Gergely Orosz on engineering leadership
• Podcast: Manager Tools — practical management techniques

Sources

• The Manager's Path — Camille Fournier
• Rands in Repose — The Update, The Vent, and The Disaster
• Manager Tools — 1:1s
• Radical Candor — Kim Scott
• The Pragmatic Engineer Newsletter

I'm Ismat, and I build BirJob — Azerbaijan's job aggregator scraping 80+ sources daily.