The new engineering manager started with a list of things to fix. He'd been brought in from a larger company to "professionalize" an engineering team that had grown faster than its processes. By day fifteen, he'd proposed reorganizing the team structure. By day thirty, he'd announced a new sprint process. By day forty-five, he'd started pushing for a complete rewrite of the CI/CD pipeline.
By day sixty, half the team was updating their resumes.
"He didn't listen to anyone," one engineer told me afterward. "He walked in with his playbook from his last company and started running it without understanding anything about our situation. Every time we tried to explain why something was the way it was, he'd dismiss it as 'not how it's done' or 'we'll fix that later.'"
The manager wasn't wrong about the problems—the team did need better processes. But he'd failed to understand that the first 90 days of engineering management aren't about making your mark. They're about earning the right to make your mark. Trust comes before transformation. Understanding comes before change.
At SmithSpektrum, I've coached over 80 new engineering managers through their first 90 days. The successful ones invest heavily in relationships and context before taking action. The unsuccessful ones arrive with solutions before they understand the problems[^1].
The Fundamental Principle
New managers face a paradox. They've been hired because someone thinks change is needed. The implicit mandate is to improve things. The temptation is to start improving immediately—to prove your value by fixing problems you can see.
But you don't yet know what you don't know. The problems you see on day ten are symptoms; the root causes take longer to understand. The changes that seem obvious from outside often have histories you haven't learned. The people you think are underperforming may be working around obstacles you haven't discovered. The processes that seem broken may be the least-bad solutions to constraints you don't understand.
If you act on your early impressions, you'll solve the wrong problems, alienate the people who could have helped you understand, and burn the goodwill that new managers get by default. The engineers will file you under "another manager who doesn't listen" and wait for you to fail or leave.
The alternative is to invest your first 90 days in listening, learning, and building relationships. This feels slow. It feels like you're not earning your keep. But it's not slow—it's the fastest path to effective change because it builds the foundation of trust and context that makes change possible.
Days 1-30: Deep Listening
The first month is about absorption, not action. Your job is to understand the current state: the people, the problems, the processes, the politics, the history. You're building a mental model of the team and its environment that will guide everything you do later.
Start with your direct reports. In your first week, meet one-on-one with every person you manage. These conversations set the tone for your relationship. Don't walk in with an agenda of what you want to cover—walk in with genuine curiosity about who they are and what they think.
| Phase | Focus | Key Activities | Anti-Pattern |
|---|---|---|---|
| Days 1-30 | Listen | 1:1s with every report, skip-levels, stakeholder meetings | Making changes too fast |
| Days 31-60 | Diagnose | Identify patterns, map dependencies, assess team health | Assuming you understand |
| Days 61-90 | Act | Small wins, address urgent issues, set direction | Big reorganizations |
| Days 90+ | Iterate | Build on momentum, tackle larger issues | Abandoning early observations |
Ask questions that surface their reality: What are you working on? What's going well? What's frustrating? What should I know that I wouldn't learn otherwise? What should I definitely not change? What do you need from me as your manager?
The last question matters especially. Different people need different things from their managers—more autonomy or more direction, more feedback or more space, more support with stakeholders or more technical guidance. Starting by asking signals that you'll adapt to them rather than expecting them to adapt to you.
Listen carefully to what people don't say as much as what they do say. When multiple people hesitate before discussing the same topic, that's a signal. When people praise certain things unprompted, that matters. When someone gives a careful, diplomatic answer to a question that should be straightforward, there's probably a story.
Extend your listening to stakeholders: your manager, the product managers you'll work with, designers, other engineering managers, key individual contributors outside your team. Each has a perspective you need. Ask them what success looks like from their vantage point, what's working well, what they wish were different.
Your manager deserves special attention. Understand explicitly what they expect from you. What does success look like at 90 days? What problems are you expected to solve? What should you definitely not do? What's the history you need to understand? Their answers shape your priorities.
Document as you go. Keep notes on each person—their background, their concerns, their hopes, their quirks. Keep a log of issues surfaced and themes that recur. Keep track of what's working well; you need to preserve the good things as much as fix the bad ones. This documentation becomes the foundation for your diagnosis.
Days 31-60: Diagnosis
By month two, you've absorbed enough context to start synthesizing. Now you're looking for patterns, connecting observations, forming hypotheses about what's actually happening and why.
Start with team health. What's the morale? How engaged are people? Do they trust each other? Do they trust leadership? What are the team dynamics—who works well together, where are the tensions? Look at the signals: how people talk in meetings, how they respond to disagreements, whether they help each other without being asked.
Assess delivery capability. Is the team shipping reliably? Are commitments met? What's the quality of what they ship? When things go wrong, is it usually technical problems, requirements problems, or people problems? Talk to stakeholders about their experience working with the team.
Evaluate technical health. This doesn't require you to understand every line of code, but you should have a sense of the technical debt situation, the architecture strengths and weaknesses, the tooling pain points. The engineers will tell you if you ask; they've been waiting for someone to listen.
Look at processes. Which meetings are useful and which are theater? How do decisions get made? How does work flow from idea to production? Where are the bottlenecks? Which processes are followed because they work and which because nobody has stopped them?
As you synthesize, form hypotheses. "Sprints always run over because requirements change mid-sprint, and they change because product doesn't have good customer feedback loops." "The senior engineer everyone avoids pairing with isn't actually bad—he's frustrated because he's been asking for help with technical debt for two years and nobody listens." "The team ships slowly because deployment is scary and unreliable, so they batch changes into risky big releases."
Test your hypotheses. Don't assume you've figured it out—you probably have pieces of the truth, not the whole picture. Share your observations with your manager and get their reaction. Float ideas informally with team members and watch how they respond. Validate before you commit.
Days 61-90: Action
By month three, you've earned the context and trust to start making changes. The key is choosing the right changes—not everything that needs fixing, but the changes that will have the most impact and that you can actually execute.
Start with quick wins that have visible impact and build credibility. Often these are things the team has been asking for—a meeting that everyone hates, a process that nobody follows but nobody has killed, a tool that makes everyone's life harder. When you fix these, you demonstrate that you listen and that you act on what you hear.
Avoid big changes early. Reorganizing the team, changing people's roles, replacing major tools—these require more context than you have and more trust than you've built. Save them for later, when you understand the full implications and have the relationships to execute them well.
When you do make changes, communicate clearly. Explain what you've learned and how it led to this decision. Acknowledge what you've heard from the team and how you're responding. Be explicit about what's changing and what's not. Give people a channel to provide feedback as changes roll out.
Anchor the stability as well as the change. People fear that a new manager will upend everything. Explicitly naming what's not changing—the values, the successful practices, the things that work—provides reassurance that you're not here to tear down what they've built.
Measure your changes. Have clear success criteria so you know if things are working. Be willing to adjust or reverse if they're not. "I tried something and it didn't work, so I'm trying something else" builds more credibility than stubbornly persisting with a bad decision.
The Manager Relationships
Three relationships particularly determine your success as a new manager: with your team, with your manager, and with your stakeholders. Each requires deliberate attention.
With your team, the goal is trust. They need to believe that you have their interests at heart, that you're competent to lead them, and that you'll follow through on your commitments. Trust builds through consistency: showing up for one-on-ones, remembering what they told you, doing what you said you'd do. It builds through advocacy: representing their concerns upward, removing obstacles, going to bat for them with stakeholders. And it builds through honesty: giving straight feedback, admitting when you don't know things, being transparent about constraints.
With your manager, the goal is confidence and alignment. They need to believe that you understand your mission, that you're making progress, and that you'll tell them when there's a problem. This means over-communicating, especially early on. Send regular updates even if they're not asked for. Share your thinking, not just your actions. Flag concerns before they become crises. Ask for feedback explicitly and show that you're acting on it.
With stakeholders—product managers, designers, other engineering managers—the goal is partnership. Understand what they need from your team. Be reliable about what you commit to. When there are problems, surface them early rather than surprising people. Find ways to make their lives easier, not just your team's lives easier. Cross-functional relationships are the connective tissue that makes organizations work; building them early pays dividends.
Common Mistakes and Recoveries
Certain mistakes are nearly universal for new managers. Knowing them helps you avoid them—or recover when you don't.
Moving too fast is the most common. You see problems, you have solutions, you act—and you alienate everyone because they feel unheard and steamrolled. The fix is to acknowledge the mistake explicitly, slow down visibly, and demonstrate listening before acting again. It takes time to recover trust, but it's possible.
Not listening is the deeper version. Some managers ask questions but don't actually absorb the answers; they're going through the motions while privately committed to their predetermined approach. This shows. People notice when their input has no effect on outcomes. If this is you, genuinely reconsider your assumptions. You were hired into a situation you don't fully understand; the people who've been there probably know things you don't.
Trying to be liked is a subtler trap. New managers sometimes avoid hard conversations because they want the team to like them. But the team doesn't need you to be their friend—they need you to be effective. Avoiding performance issues, letting deadlines slip without accountability, failing to make decisions because someone might disagree—these all erode your credibility. Being respected is more important than being liked, though ideally you can be both.
Copying your previous company is tempting. You saw something work before; you want to implement it here. But context differs. The process that worked at a 500-person company might be overkill for a 20-person startup. The culture that made sense at one organization might be toxic at another. Adapt your playbook, don't just run it.
Ignoring your manager is surprisingly common. New managers focus so much on their teams that they neglect the relationship with their own manager. But your manager is your air cover, your resource allocator, your interpreter of the organization's priorities. Keep them close. Over-communicate upward, especially in your early months.
The 90-Day Check-In
At day 90, take stock. Ask yourself honestly: Do I understand what my team does? Do I have relationships with each team member? Do stakeholders trust me? Does my manager think I'm on track? Have I made any positive impact? Do I enjoy this job?
Ask your manager explicitly: Am I meeting your expectations? What should I do more of? What should I do less of? What should I focus on next? This conversation calibrates your sense of how things are going and surfaces any gaps between your perception and theirs.
If things aren't going well at day 90, that's not necessarily a crisis. Some situations take longer to understand, some teams take longer to trust. But it's worth being honest about whether you're on a path to success or whether something fundamental needs to change.
The manager who tried to change everything in his first 45 days? He lasted six months before leaving under pressure. The team he left behind was demoralized and suspicious of the next manager.
That next manager took a different approach. She spent 45 days listening before proposing any changes. When she did propose changes, they were the changes the team had been asking for—and she involved them in designing the implementation.
By day 90, her team was shipping faster, working more smoothly, and feeling heard for the first time in years. Not because she had better ideas than her predecessor, but because she'd earned the right to be heard before she tried to make her mark.
References
[^1]: SmithSpektrum engineering manager coaching, 80+ new managers, 2019-2026. [^2]: Fournier, Camille. "The Manager's Path," O'Reilly Media, 2017. [^3]: Watkins, Michael. "The First 90 Days," Harvard Business Review Press, 2013. [^4]: Lara Hogan, "Resilient Management," A Book Apart, 2019.
Starting a new engineering management role? Contact SmithSpektrum for management coaching and support.
Author: Irvan Smith, Founder & Managing Director at SmithSpektrum