Your First 100 Days as an Engineering Manager - Complete Guide

The first 100 days in any leadership role carry outsized weight. They set the tone for your relationships, establish your credibility, and create the foundation for everything you will build as an engineering manager. Whether you have been promoted internally or hired from outside, the decisions you make - and just as importantly, the decisions you deliberately do not make - during this period will shape your effectiveness for months and years to come.

This guide breaks the first 100 days into four distinct phases, each with clear objectives, specific actions, and common pitfalls to avoid. The structure is intentionally progressive: you start by listening and learning, then move to small improvements, then to strategic impact, and finally to reflection and forward planning. Resist the temptation to skip ahead. New managers who rush to prove themselves often create more problems than they solve because they lack the context to make good decisions. For a broader view of the engineering management career path, see our career path guide.

Before Day One

Preparing for the Transition

Your first 100 days actually begin before your official start date. If you are transitioning from an individual contributor role, use the weeks before your start to shift your mindset. As an IC, your value was measured by the quality and quantity of your personal output - the code you wrote, the systems you designed, the bugs you fixed. As an engineering manager, your value is measured by your team's output, growth, and health. This sounds simple in theory but is genuinely difficult in practice. You need to let go of the identity that earned you this role and build a new one.

Read foundational management books before you start - not to find a playbook to follow mechanically, but to build a vocabulary for the challenges you will face. Understand the basics of running effective 1:1s, giving feedback, and setting expectations. If possible, talk to other engineering managers about their first 100 days. Ask them what they wish they had done differently. Their mistakes are cheaper to learn from than your own.

Mindset Shifts from IC

The central mindset shift is from maker to multiplier. As an IC, a productive day meant you shipped something. As a manager, a productive day might mean you unblocked three engineers, had a difficult conversation that prevented a conflict from escalating, aligned your team's roadmap with a stakeholder's priorities, and gave feedback that will help someone grow. None of those things produce a pull request, but they are all high-impact work. If you struggle with this shift, our IC to engineering manager transition guide covers it in depth.

You also need to shift from certainty to ambiguity. Engineering problems have objectively correct answers (or at least clearly better ones). Management problems rarely do. The right way to handle an underperforming engineer, a stakeholder conflict, or a team re-org depends on context, relationships, and timing. Get comfortable with making decisions on incomplete information and adjusting course as you learn more.

Days 1-30: Listen and Learn

Building Relationships

Your first month should be dominated by conversations, not actions. Schedule introductory 1:1s with every direct report in your first week. These are not status updates - they are relationship-building conversations. Ask open-ended questions: "What do you enjoy most about working here?" "What frustrates you?" "What would you change if you could?" "What should I know about the team that I would not learn from reading documentation?" Take notes, but prioritise being present in the conversation over capturing every detail.

Establish a regular 1:1 cadence immediately. Weekly 1:1s of 30 minutes are the standard starting point for most teams, though you may adjust the frequency later based on individual needs. The consistency matters more than the duration. A 1:1 that happens reliably every week sends a powerful message: your people matter, and their time with you is protected.

Mapping Stakeholders

Engineering management is as much about managing outward and upward as it is about managing your team. In your first month, map out your key stakeholders: product managers, designers, other engineering managers, your own manager, and any senior leaders who have visibility into your team's work. Schedule introductory meetings with each of them. Ask: "What does success look like for your partnership with this team?" "Where are the friction points?" "What do you need from me that you were not getting before?"

Map the political landscape. Who are the key decision-makers? Where does budget authority sit? Which teams are your team's closest collaborators, and where are the dependencies that cause the most pain? Understanding these dynamics early prevents you from being blindsided later. The engineering manager responsibilities guide covers the full scope of stakeholder management.

Understanding the Codebase and Systems

You do not need to understand every line of code, but you do need to understand the systems your team owns at an architectural level. Review system diagrams, deployment pipelines, on-call runbooks, and incident histories. Understand the team's technical debt and where the biggest risks lie. This technical context is essential for making informed decisions about priorities, staffing, and trade-offs. If you are a first-time manager coming from an IC background, resist the urge to dive deep into the code - your time is better spent on people and process at this stage.

Days 31-60: Quick Wins and Systems

Identifying Low-Hanging Fruit

By day 30, you should have a solid understanding of the team's strengths, pain points, and dynamics. Now it is time to act - but start small. Look for quick wins: improvements that are low-risk, high-visibility, and address pain points the team has already identified. These might include fixing a broken CI pipeline that wastes 20 minutes per build, streamlining a meeting that everyone agrees is unproductive, or creating a shared document that answers the questions new joiners always ask.

Quick wins serve two purposes. They deliver genuine value to the team, and they build your credibility as someone who listens and acts. When people see that the concerns they raised in their 1:1s actually led to change, they start trusting you with bigger problems. Be explicit about the connection: "Several of you mentioned that our sprint planning meetings feel too long. I have restructured the agenda based on your feedback - let us try this format for two sprints and see if it is better."

Establishing Processes

Use this phase to establish or refine the team's core processes. If the team lacks a clear sprint cadence, introduce one. If retrospectives have become stale, revitalise them with a new format. If there is no documented on-call rotation, create one. The key is to introduce structure without creating bureaucracy. Every process you add should clearly serve the team's ability to deliver and grow. If you cannot articulate why a process exists, do not introduce it.

This is also the time to establish your team's working agreements: how you communicate, how you make decisions, how you handle disagreements, and what "done" means. Co-create these with the team rather than imposing them top-down. People follow rules they helped write. For templates and frameworks, see our engineering manager templates.

First Performance Conversations

Around the six-week mark, you should have enough context to begin having initial performance conversations. These are not formal reviews - they are calibration discussions. Share your observations of each person's strengths and growth areas, and ask for their self-assessment. This creates alignment early and prevents surprises at formal review time. Use the career framework to anchor these conversations in clear, level-appropriate expectations.

Days 61-90: Strategic Impact

Setting Team Vision

With two months of context, you are now equipped to think strategically. Work with your team and your product partners to articulate a clear team vision: what does this team exist to do, what does success look like in six months, and how does the team's work connect to broader company goals? A compelling vision gives people a reason to care about their work beyond the immediate sprint. It also provides a decision-making framework: when faced with competing priorities, you can ask "which option moves us closer to our vision?"

Translate the vision into concrete goals. If your organisation uses OKRs, this is the time to draft them collaboratively with the team. If not, set three to five clear objectives for the next quarter with measurable outcomes. The engineering management frameworks guide covers goal-setting approaches in detail.

Roadmap Contribution

By now, you should be an active contributor to the product roadmap rather than a passive recipient. Bring your unique perspective as the person closest to the team: which projects will stretch the team's capabilities in healthy ways? Where are the technical risks that product partners may not see? What capacity constraints need to be factored into planning? Your ability to translate between technical reality and business ambition is where you add the most value as a manager.

Deeper Stakeholder Relationships

Use this phase to deepen the stakeholder relationships you initiated in month one. Move from introductory conversations to genuine partnerships. Share your team's vision and ask how it aligns with their priorities. Proactively communicate progress and risks rather than waiting to be asked. Build the kind of trust that allows you to push back on unrealistic requests without damaging the relationship.

Days 91-100: Reflection and Momentum

Self-Assessment

The final ten days of your first 100 are a natural checkpoint for reflection. Step back and honestly assess your progress. What has gone well? Where have you struggled? What do you know now that you did not know on day one? Write down your reflections - the act of articulating what you have learned makes the lessons stick. Compare your current understanding of the team, the technology, and the organisation against the assumptions you held when you started. The gap between the two reveals how much context you have gained.

Soliciting Feedback

Ask your direct reports, your manager, and your key stakeholders for candid feedback on your first three months. Be specific in your ask: "What is one thing I should keep doing?" "What is one thing I should change?" "Is there anything I am missing or not paying enough attention to?" Make it safe to be honest - thank people for critical feedback and visibly act on it. This models the feedback culture you want to build on your team.

Planning the Next Quarter

Use your reflections and the feedback you have gathered to plan your priorities for the next quarter. By now, you should have a clear picture of the team's biggest opportunities and risks. Choose two or three themes to focus on - perhaps improving delivery predictability, developing a specific team member for promotion, or paying down a critical area of technical debt. Write them down and share them with your manager. Having explicit quarterly priorities gives you a compass for the hundreds of small decisions you will make each week and helps you resist the pull of reactive, urgent work that crowds out important strategic investment.

Common Mistakes to Avoid

Trying to Change Everything at Once

New managers often arrive with a mental list of improvements based on their experiences at previous companies or in their previous role. The urge to fix everything immediately is strong, especially if you can see obvious problems. Resist it. Every change carries a cost: it consumes the team's attention, disrupts existing workflows, and tests your credibility. Make changes sequentially, not simultaneously. Let each change settle before introducing the next. The team can absorb one well-executed improvement per sprint; it cannot absorb five.

Still Coding Full-Time

This is where new engineering managers fail most often, especially those promoted from IC roles. You know how to code. Coding feels productive. Management often feels ambiguous and uncertain by comparison. So you keep writing code, telling yourself you are "staying technical" or "leading by example." In reality, you are avoiding the harder, less familiar work of management while also creating a bottleneck: code you write is code your team cannot review, maintain, or learn from without your involvement.

It is reasonable to contribute some code in your first few months, particularly if the team is small. But your coding should decrease steadily over time, and it should never come at the expense of your management responsibilities. If you are cancelling 1:1s to finish a pull request, your priorities are wrong. For more on this transition, see our IC to engineering manager guide.

Avoiding Difficult Conversations

New managers often delay tough conversations - about performance issues, behaviour problems, or misaligned expectations - because they are uncomfortable and the stakes feel high. The longer you wait, the worse these conversations become. A small performance issue addressed in week three is a coaching conversation. The same issue addressed in month six is a formal performance improvement plan. Address problems early, directly, and with genuine care for the person's growth. Our managing teams guide covers techniques for difficult conversations in detail.

Not Building Peer Relationships

First-time managers often focus exclusively on their team and their manager, neglecting their peer group - the other engineering managers, product managers, and design leads they need to collaborate with. Your peers are your most valuable support network. They face the same challenges, can share context about organisational dynamics, and can advocate for your team in rooms you are not in. Invest in these relationships deliberately: regular coffees, shared problem-solving, and genuine interest in their challenges. The managers who build strong peer networks are consistently more effective than those who operate in isolation.