# How to onboard a new manager **New manager onboarding** is a ninety day transition that turns a promotion into supported practice. A strong plan clarifies authority, reduces the new manager's coding load, builds context about people and commitments, establishes a coaching rhythm, and defines observable success. Without that structure, the manager learns by reacting while the team pays for every unclear assumption. ## Why does ordinary employee onboarding fall short? A new manager may already know the company, product, and code. That familiarity tempts leaders to skip onboarding. Yet the person is entering a different social system. Former peers now interpret requests through formal authority. Private information arrives. Decisions affect ratings, pay, opportunity, and workload. Knowing the repository does not explain how to carry that responsibility. External hires face the opposite problem. They may know management but lack local context. An approach that worked in a large platform group may fail in a small product team. They need to learn architecture, customers, decision rights, history, and informal dependencies without copying every inherited habit. Both internal and external managers need a deliberate bridge into the role. Onboarding should reduce ambiguity before it accelerates change. When leaders say “make the team yours,” new managers often respond with visible action: reorganizing meetings, changing tools, or rewriting plans. A better instruction is to learn the system, stabilize essential work, and earn enough context to improve it with the team. ## What should be ready before day one? - A written role description that names people, delivery, technical, and partner responsibilities. - A clear map of decisions the manager owns, recommends, shares, or escalates. - A transition plan for the manager's former engineering work, including named owners. - A team brief covering people, commitments, risks, recent changes, and sensitive history. - A weekly coaching meeting with the manager's manager for at least the first eight weeks. - Access to policies, performance cycles, compensation guidance, and emergency support. The announcement also matters. Explain why the person was selected, when authority changes, what remains stable, and where questions belong. If they previously worked on the team, address former peer relationships directly. Silence forces everyone to guess whether friendships, review norms, and informal influence have changed. ## What belongs in the first thirty days? The first month is for listening, clarity, and safe operating basics. The manager should meet each direct report, key product and design partners, adjacent engineering leaders, and relevant support functions. Those conversations should explore goals, strengths, friction, commitments, and expectations, not promise solutions on the spot. Set a regular 1 on 1 cadence and explain its purpose. Let each employee shape part of the agenda. The manager should learn what helps the person think, how they prefer feedback, what growth matters, and what currently drains energy. Project status can live in planning systems unless it reveals a decision or support need. According to iSilta's 2026 survey of 146 organizations, 78% report weak 1 on 1s when training arrives late. New manager onboarding should therefore include early observation or review of 1 on 1 preparation. Protect confidentiality by discussing themes and manager behavior rather than exposing personal details unnecessarily. ## What should happen by day sixty? During the second month, the manager moves from listening to improving the operating rhythm. They should be able to explain current priorities, major risks, team capacity, and each person's immediate support needs. This is the time to tighten ownership, improve planning signals, and address one or two contained problems with the team. Delegation deserves special attention. New managers often keep difficult technical work because competence feels safe. Others abandon technical context too quickly and delegate vague tasks without authority. Good delegation names the outcome, why it matters, constraints, decision space, check points, and how success will be judged. The employee should know what they truly own. The manager should also practice direct feedback before stakes grow. Start with specific reinforcing feedback and small corrections tied to observed impact. Waiting for a serious issue teaches avoidance. Flooding the team with criticism to appear decisive damages trust. The goal is a normal rhythm where useful feedback arrives close to the event. ## What should happen by day ninety? By the third month, the manager should run the team's normal system with decreasing support. They should lead planning, communicate decisions, coach different experience levels, address conflict, and raise risks early. They do not need every answer. They need reliable judgment about what they can decide and when to seek help. Ask the manager to present a short team assessment: strengths to protect, constraints to remove, people risks, delivery risks, partner friction, and two priorities for the next quarter. Review the evidence behind each claim. This exercise reveals whether the manager sees the team as a set of individuals and relationships, not merely a ticket system. | Period | Main goal | Evidence | | --- | --- | --- | | Days 1 to 30 | Learn and clarify | Context map, 1 on 1 rhythm, decision rights | | Days 31 to 60 | Practice and stabilize | Clear delegation, prompt feedback, visible risks | | Days 61 to 90 | Own and improve | Team assessment, sound decisions, growth plans | ## How should the manager's manager coach? Weekly meetings should focus on judgment and behavior, not only reporting. Ask: What conversation are you avoiding? Where did you take back ownership? Whose perspective is missing? What did the team understand differently after you spoke? These questions turn daily events into learning without requiring the senior leader to take over. Prepare before important moments. Rehearse the opening of a performance conversation, inspect evidence for a promotion discussion, or map stakeholders before a difficult priority change. Then review what actually happened. The short loop between intention, action, and reflection builds skill faster than broad advice delivered weeks later. Observe selectively and transparently. Join a planning session, review a written decision, or facilitate a practice conversation. Do not secretly gather reports from the team. Explain what is being observed and why. Support should increase safety, not make the new manager feel watched from every direction. ## How much technical work should remain? There is no universal percentage. Team size, system maturity, and role design vary. Use a practical test: if the manager's coding commitment repeatedly displaces 1 on 1s, feedback, hiring, planning, or partner decisions, it is too large. If the team cannot ship because only the manager understands a critical area, transition work is incomplete. Technical engagement can remain through design questions, risk review, incident learning, and occasional bounded contributions. Avoid putting the manager on the critical path. The role should create more capacity in the team. A manager who must rescue every release trains people to wait for rescue and has no room for people leadership. ## What mistakes derail onboarding? - **Keeping two jobs.** The manager retains a full engineering load while people duties become evening work. - **Changing too much.** Visible action substitutes for understanding, so meetings and structures move before real constraints are known. - **Avoiding former peer tension.** Everyone acts as if authority changed nothing, then resentment grows around private information or uneven access. - **Using vague support.** “My door is open” replaces scheduled coaching and specific observation. - **Measuring sentiment only.** Early popularity hides unclear standards, delayed feedback, or weak decisions. Another mistake is treating onboarding as remediation. The new manager should hear that support is normal because the job is complex, not because leaders doubt the promotion. Normalizing coaching makes it easier to surface uncertainty before it becomes harm. ## How do you measure a successful transition? Use a balanced set of signals. Ask direct reports whether priorities, expectations, and support are clear. Review whether risks surface earlier and decisions have owners. Look for regular 1 on 1s, useful delegation agreements, timely feedback, and credible growth conversations. Delivery matters, but a single quarter can be distorted by inherited work. According to iSilta's 2026 survey of 146 organizations, 81% do not measure behavior change. Add simple checks at thirty, sixty, and ninety days. Each review should name evidence, one strength to preserve, one behavior to practice, and support the organization must provide. That makes progress actionable rather than ceremonial. Include partners without turning onboarding into a popularity contest. Product, design, and nearby engineering leads can describe whether decisions, ownership, and escalation became clearer. Ask for examples and compare them with the manager's goals. Partner evidence is especially useful when a team appears calm internally but creates confusion across service or product boundaries. At day ninety, decide what can move into normal management cadence and what needs continued attention. Onboarding ends when the manager can operate safely with known support, not when every leadership skill is complete. The best outcome is a manager who understands the team, uses authority carefully, learns openly, and knows that asking for help is part of the role. ## Frequently asked questions ### What is new manager onboarding? New manager onboarding is a structured transition that gives a manager role clarity, team context, operating expectations, core practice, coaching, and feedback during the first ninety days. ### What should a new manager do in the first thirty days? They should learn before changing major systems, meet each team member and partner, clarify authority, understand commitments and risks, establish 1 on 1s, and agree on success measures with their manager. ### How much coding should a new engineering manager keep? Only enough to maintain useful context without becoming critical to delivery. The exact amount varies, but people work, planning, and decisions must have protected capacity. ### How should a manager of a new manager help? Meet weekly, prepare important conversations, observe selected work, give prompt behavioral feedback, remove conflicting expectations, and review progress at thirty, sixty, and ninety days. ### When is onboarding complete? Onboarding is complete when the manager can run the normal operating rhythm safely, explain team context and decisions, handle core conversations, and knows when to seek help. Development continues after that point. Related: [the untrained manager wave](https://isilta.com/blog/untrained-manager-wave/), [training managers before promotion](https://isilta.com/blog/should-you-train-managers-before-promotion/), [the accidental manager](https://isilta.com/blog/what-is-an-accidental-manager/).