The first 30 days as an engineering manager: Moving from doing to enabling

When you transition into engineering management from an individual contributor, Scrum Master or technical product owner background, your instincts work against you. You spent years building tangible competence: shipping features, unblocking CI pipelines, facilitating agile ceremonies and refining backlogs. Those activities provided instant feedback loops and visible output.

Management offers neither. In your first weeks, you face ambiguous meetings, subtle team tensions and slow-moving outcomes. When delivery stalls or a sprint wobbles, the knee-jerk reflex is to reach for your old tools: grab the mouse in standup, rewrite poorly sliced user stories or pull down a branch to fix a build yourself.

Jumping into action feels productive, but it's a trap. When you step in to fix operational friction before understanding team dynamics, you don't solve systemic problems; you merely mask them. Moving from doing to enabling requires shifting from immediate output to sustainable systems, starting with deliberate restraint.

Why the order matters: The foundation before execution

A common failure mode for new engineering managers is attempting to optimize execution first. They implement strict WIP limits, overhaul Jira workflows or reorganize refinement ceremonies within their first month.

These process adjustments rarely stick. If engineers don't feel safe admitting when they're stuck, a polished standup format won't surface risks earlier. If the team lacks clear technical direction or product context, rigid backlog refinement just produces well-formatted tickets for the wrong outcomes.

       ▲  Execution & Growth (Ways of working, stretch tasks, hiring)
      ╱ ╲
     ╱   ╲  Direction (Ownership boundaries, debt strategy, product thinking)
    ╱     ╲
   ╱───────╲  Foundation (Psychological safety, servant leadership, trust)

Leadership connects in a specific sequence:

1. The Foundation: Trust, culture and psychological safety, talk-time balance and servant leadership. Without this, people hide mistakes and optimize for self-preservation.
2. Direction: Defining clear system ownership, aligning on technical trade-offs and focusing on user value over raw output.
3. Execution and Growth: Refining delivery cadence, eliminating process waste and expanding engineer capabilities through stretch work.

Execution problems are almost always downstream symptoms of fragile foundations or ambiguous direction. That's why your first 30 days must be dedicated to diagnosing the foundation rather than reorganizing the delivery machine.

The observer effect in engineering teams

In physics, the observer effect describes how measuring a system inherently changes it. In engineering leadership, that effect is immediate. When a new manager steps into a team, everyone adjusts their behavior. If you immediately start running meetings, offering solutions or chiming in on every technical debate, you won't observe how the team actually operates. You will only observe how they react to your presence.

Stepping in creates artificial stability. The team appears to function because you are absorbing friction, but you haven't learned how they self-regulate:

• Do engineers step up when a production build breaks, or do they wait for someone else to take the hit?
• Does the team resolve disagreements through constructive debate, or does the loudest voice dominate while others check out?
• How does the team respond to setbacks: do they dissect system failures, or do they assign blame?

To see the real picture, you have to practice intentional inaction.

Contracting the stance on day 1

Silence from a manager can feel intimidating if it's unexplained. If you sit in standup taking notes without saying a word, engineers may assume they are under performance evaluation. Be explicit about your role from your very first team meeting:

"For my first 30 days, my primary job is to learn how work actually flows here. If you see me taking notes and staying quiet during standups or refinements, it's not because I'm evaluating your individual performance or checked out. It's because I need to understand the system and your daily reality before I can help protect your focus."

Framing your silence as diagnostic research lowers anxiety and gives the team permission to run their rituals naturally.

The diagnostic ledger: What to watch in days 1–30

While resisting the urge to intervene, maintain a private diagnostic ledger. Track systemic patterns across four specific signals:

1. Talk-time balance and meeting hygiene

Watch who speaks in daily standups, refinements and retrospectives. Does 80% of the conversation belong to two senior engineers? When a junior engineer speaks, does the group listen, or do discussions quickly pivot back to the vocal minority?

Notice whether the team uses techniques that equalize input, such as silent writing in retrospectives or round-robin check-ins, or if decisions always default to whoever speaks loudest.

2. The language of setbacks (Avery's Responsibility Process)

Listen closely during incident reviews and sprint retrospectives. When something breaks, where does the team's language settle?

        ┌────────────────────────────────────────────────────────┐
        │ 4. RESPONSIBILITY: "Our contract tests didn't catch    │
        │    this edge case. How do we automate this check?"     │
        └───────────────────────────▲────────────────────────────┘
                                    │
        ┌────────────────────────────────────────────────────────┐
        │ 3. OBLIGATION / QUIT: "That's just how the legacy core │
        │    works. Nothing we can do about it."                 │
        └───────────────────────────▲────────────────────────────┘
                                    │
        ┌────────────────────────────────────────────────────────┐
        │ 2. JUSTIFY: "We had to cut test coverage because       │
        │    product pushed up the deadline."                    │
        └───────────────────────────▲────────────────────────────┘
                                    │
        ┌────────────────────────────────────────────────────────┐
        │ 1. LAY BLAME: "The platform team broke our staging     │
        │    pipeline again."                                    │
        └────────────────────────────────────────────────────────┘

A team stuck in Blame or Justify lacks psychological safety; they fear punishment, so they outsource responsibility. A team operating in Responsibility accepts setbacks as system feedback and focuses on adding guardrails rather than finding scapegoats.

3. Escalation latency

Measure the gap between when a blocker appears and when it's surfaced. If a pull request sits waiting for review for four days before an engineer mentions it in standup, or if an external team dependency stalls for a week without escalation, you are looking at an escalation bottleneck.

Engineers often withhold blockers because previous attempts to raise them led to micromanagement or disappeared into organizational black holes.

4. Challenge in refinement

Do engineers push back on unclear requirements, probe edge cases and challenge assumptions, or do they passively accept Jira tickets with missing context? A quiet refinement usually signals resignation, not alignment.

Establishing trust in 1:1s: Demystifying the power dynamic

Your 1:1s during the first month establish the foundation of your working relationship with each engineer. The most critical shift is eliminating the status update. If your 1:1 becomes a recap of Jira tickets, you have failed to use the time for what matters: understanding the person, their drivers and the systemic friction they face.

Clarifying the servant leadership stance early

New managers often worry about asserting authority. In reality, you build authority faster by clarifying what your role is and what it isn't:

• What you are there to do: Remove organizational blockers, clarify team priorities, protect engineering focus and support their long-term professional growth.
• What you are not there to do: Dictate technical solutions, inspect line-by-line code or police working hours.

The diagnostic 1:1 questions

In your first two 1:1s with each direct report, ask open, diagnostic questions that uncover systemic friction:

• "What part of your week consistently drains your energy?"
• "What is something in our tooling, codebase or release process that slows you down every day?"
• "When was the last time you felt truly engaged with what you were building here?"
• "How do you prefer to receive feedback: directly in the moment, written beforehand or in our regular 1:1?"
• "What is one thing you hope will change with me stepping into this role, and one thing you hope stays exactly the same?"

Listen without immediately defending existing processes. Ground your follow-up in objective actions and impact rather than assumptions. If an engineer mentions feeling disconnected from decisions, explore the specific instances rather than offering quick platitudes.

Earning technical respect without touching code

The most persistent fear for a newly promoted manager is losing technical credibility. You worry that if you don't write code, fix bugs, or actively review PRs, senior engineers will view you as an administrative layer disconnected from reality.

This insecurity typically triggers two counter-productive behaviors:

• The Ghost Committer: You grab critical-path tickets or pick up bug fixes after hours. Soon, management obligations pull you away, your PRs sit unreviewed, and you become the single biggest delivery bottleneck on the team.
• The Bike-Shedding Reviewer: You hover over pull requests, nitpicking syntax, formatting or variable naming to prove you still know the stack. Engineers quickly experience this as micromanagement.

Senior engineers don't need you to be the fastest coder in the room. They respect an engineering manager who understands technical systems deeply enough to ask the questions that protect stability, architecture and focus.

Shifting from solutions to systemic questions

Your technical background should serve as a compass, not a shovel. Instead of telling engineers how to build a feature, use technical leadership to help them evaluate risk, architecture and long-term maintainability:

Asking these questions demonstrates technical rigor without taking away ownership. You hold the standard for system reliability while leaving technical implementation where it belongs: with the team.

Actionable takeaways for days 1–30

• State your observer role explicitly: Contract your presence on Day 1 to remove ambiguity and prevent unnecessary anxiety.
• Use the two-meeting delay: When you spot a clunky ceremony or an uneven discussion, resist the urge to correct it in the moment. Observe the pattern twice before bringing it up in a retrospective or 1:1.
• Keep your hands off the critical path: Step away from sprint tickets. If you write code, restrict it to developer tooling, documentation or sandbox spikes that cannot block a release.
• Turn 1:1s into diagnostic listening: Ask about energy drains and release friction rather than checking off Jira statuses.
• Ask boundary questions: Build credibility by probing blast radius, failure handling and rollback plans rather than debating code style.