The first ninety days as an engineering manager set the trajectory for your entire tenure. Many new managers focus on shipping features quickly or proving technical authority. A more effective approach is to treat this period as a deliberate transition where you learn the team, the codebase, the stakeholders, and the organizational dynamics before making significant changes. This action plan breaks the ninety days into three phases with specific outcomes.

Phase One Days One to Thirty Listen and Learn

Phase one is about listening, building relationships, and understanding the current state. Do not make any process changes or major technical decisions during this period. Your primary goal is to earn the right to lead by demonstrating curiosity and respect. Schedule one on one meetings with each direct report and ask questions about their work, their frustrations, their aspirations, and their perception of the team. Take notes. Meet with your own manager to clarify expectations, priorities, and the definition of success for your role. Also meet with key stakeholders such as product managers, designers, and peer engineering managers to understand how the team is perceived and what dependencies exist.

During this phase, read through the team’s documentation, recent design documents, sprint plans, and any existing metrics. Attend all team ceremonies as an observer first. Do not interrupt or redirect. Pay attention to how decisions are made, how conflicts surface, and how work gets prioritized. Identify the team’s current processes and understand why they exist before evaluating whether they work well.

Phase Two Days Thirty to Sixty Identify Patterns and Early Wins

Phase two shifts from listening to identifying patterns, interventions, and early wins. By now you should have a clear picture of the team’s strengths, bottlenecks, and cultural norms. Share your observations with the team in a transparent way. Frame them as hypotheses rather than judgments. For example, say: I noticed that pull requests often sit for more than two days before review. I wonder what the root cause is and how we might experiment with a shorter cycle. This builds trust and invites collaboration.

Identify one or two low risk improvements that can produce visible results quickly. A common early win is introducing a simple change to standup format to improve focus, or creating a shared dashboard that makes project status visible. Execute these changes with explicit team buy in and measure the outcome. Communicate the results to the team and to your manager.

Phase two is also the time to establish your personal leadership rhythm. Set regular one on ones with each team member if you haven’t already, define how you prefer to be updated, and create a weekly leadership sync with your manager. Start developing a cadence for technical reviews or architecture discussions that matches the team’s maturity. If the team lacks a clear roadmap, work with the product manager to create a thirty day outlook.

Phase Three Days Sixty to Ninety Solidify and Set Direction

Phase three is about solidifying changes, addressing deeper issues, and setting a longer term direction. By now you should have enough data and trust to propose more significant changes to process, team structure, or technical debt prioritization. Introduce these changes as experiments with clear success criteria and a review date. For example, you might implement a new code review policy or restructure sprint ceremonies to better match team velocity.

During this phase, start contributing to the team’s technical direction without becoming the bottleneck. Pair with senior engineers on architecture decisions, mentor intermediate engineers, and ensure that technical decisions are recorded and communicated. Begin building relationships with teams that depend on yours and negotiate clearer interfaces or joint commitments.

Common Traps to Avoid

Avoid micromanaging by trying to verify every detail, making promises you cannot keep, or importing processes from your previous company without adapting them. Stay humble, listen more than you speak, and resist the urge to prove yourself through technical heroics. Your value as a manager comes from enabling the team to deliver better work, not from delivering it yourself.

By the end of ninety days, you should have a solid understanding of the team’s dynamics, a set of process improvements that are beginning to show results, a clear plan for the next quarter, and the trust of your engineers and stakeholders. The next ninety days can then focus on execution and scaling impact.