Days 0 to 30: Stabilize relationships and gather accurate context

When you move from individual contributor to manager in the same organization the first priority is reducing uncertainty. People will test boundaries and expect clarity. Your role is to create predictable routines while collecting the information you need to make decisions that matter.

Key actions

  1. Announce your role change clearly Tell the team and immediate stakeholders what changed, who still owns what, and how you will communicate decisions. A single short message reduces gossip and sets expectations.
  2. Run skip level one on ones Schedule short, 30 minute conversations with each direct report and at least three skip level meetings with their stakeholders. Use the time to ask what is working right now, what blocks delivery, and what people want to stop, start, or continue. Listen more than you speak.
  3. Map current commitments and reliability signals Create a simple inventory of active projects, on call responsibilities, upcoming releases, and outstanding incidents. Note which areas are stable and which are fragile.
  4. Establish communication rhythms Set a weekly one on one cadence, a team sync, and an expectation for async updates. Clarify preferred channels for decisions versus discussion.
  5. Protect deep work time Block recurring maker time for engineers and your own learning. Signal that you will not be a constant interruption.

Decision criteria and quick wins

Prioritize changes that reduce immediate delivery risk and restore trust. Examples include reassigning a critical on call that has no backup, replacing a missing owner for a release, or documenting a production runbook. Quick wins should be visible and low friction.

Success signals to track in this window

  • All direct reports completed first one on one and shared one priority each
  • Active work inventory exists and shows owners for critical items
  • Team knows your weekly meeting cadence and how to reach you for urgent issues

Days 31 to 60: Clarify role boundaries and start shifting work

After stabilizing, the next phase focuses on role definition, delegation, and beginning to change patterns that do not scale. Your job is to transfer responsibilities that only you can reduce or remove and to coach for outcomes not activity.

Key actions

  1. Define who decides what Use a one page decision rights map that lists common decisions and the accountable person. Share it and iterate based on feedback.
  2. Run small delegation experiments Identify two non critical areas you will delegate for 30 days. Set clear constraints, an authority level, and check in points. Measure outcomes not inputs.
  3. Reset peer relationships Meet with former peers individually to address the change in dynamic. Acknowledge the shift, invite their feedback on how you can support them, and be explicit about communication norms when you need to escalate.
  4. Align with product and stakeholder leads Run a short alignment session with product management, design, and customer success to agree on priorities, definition of done, and escalation paths for conflicting priorities.
  5. Start performance calibration conversations If your organization has a performance cycle coming, learn the rubric and begin low friction calibration notes. Do not make promotion or performance promises you cannot keep.

Practical conversation scripts

When talking to a former peer who now reports to you try this frame. Start by naming the change, express intention to be fair, invite their perspective, and propose a first step. For example say “I know my new role changes our dynamic. My intent is to support your autonomy while ensuring we meet our commitments. What would be most helpful from me in the next two sprints?”

Success signals to track in this window

  • Decision rights map circulated and used for at least two decisions
  • Delegation experiments completed and outcomes documented
  • Stakeholders acknowledge clearer escalation paths

Days 61 to 90: Institutionalize routines and shape team health

In this window you move from running experiments to making durable changes. The focus is on scaling your management patterns, improving team health metrics, and setting a six month roadmap for skills and delivery improvements.

Key actions

  1. Codify handoffs and role descriptions Create short role descriptions for critical contributors and operational owners. Use these to avoid ambiguity during handoffs and to guide hiring or resource shifts.
  2. Build an onboarding checklist for future promotions Capture what you learned about the role transition so future internal promotions ramp faster. Include technical context, stakeholders, common pitfalls, and essential documents.
  3. Set skill development goals Work with each direct report to agree on two development goals for the next three to six months and the support you will provide. Make goals specific and observable.
  4. Establish a lightweight improvement cadence Create a monthly learning agenda for the team such as a postmortem, a code health sprint, or a cross team demo. Make attendance optional but valued by tying it to visible outcomes.
  5. Plan your first performance touchpoints If you have not already, hold focused development conversations rather than status updates. Use evidence and examples and agree on follow up actions.

Decision criteria for structural changes

Consider a team reorg only when three conditions are met. One the current structure consistently blocks delivery or creates duplicated work. Two you can articulate a clear target state with measurable benefits. Three you can implement the change with minimal one time disruption to delivery. If any of those conditions are missing prefer to iterate on process and ownership instead.

Success signals to track in this window

  • Role descriptions and handoffs are used in at least one cross team coordination
  • Each direct report has agreed development goals and a follow up plan
  • A repeatable team improvement cadence exists and produced at least one measurable outcome

Practical templates and phrases you can use

One on one agenda template

Start with a quick status update. Move to one coaching or development question. End with action items and a check on blocked work. Keep the meeting under 45 minutes for most contributors.

Escalation script for conflicting priorities

State the facts. Propose two options with trade offs. Ask the stakeholder to pick and document the decision. This keeps ambiguity out of execution and preserves engineering capacity.

How to preserve technical credibility without doing the work

Stay technically fluent by reading design docs, attending architecture reviews selectively, and maintaining a short list of systems you will keep a working knowledge of. Contribute by enabling technical decisions rather than making them. Use code review time for coaching rather than rewriting code.

Common pitfalls and how to avoid them

Promoted managers often fall into a few predictable traps. The first is trying to be the developer of record for major features. That adds risk and prevents developing others. The second is avoiding hard conversations with former peers to preserve friendships which causes role confusion. The third is failing to document decisions so the implicit rules create friction later. Guard against these by using the delegation experiments, scheduling necessary feedback conversations early, and writing short decision notes that live with the project.

How to measure your impact in the first 90 days

Combine qualitative and quantitative signals. Qualitative signals include direct report feedback, stakeholder responses, and the degree to which meetings produce decisions. Quantitative signals might be delivery predictability on critical projects, number of escalations, on call handover quality, and completion rate of agreed development goals. Use small, realistic targets rather than large percentile improvements.

Next steps after day 90

Use your 90 day review to propose a six month plan that includes technical capability lifts, hiring or resourcing needs, and team health goals. Frame requests with expected outcomes and the minimal investment required to reach them. Continue iterating on what worked early and stop patterns that no longer serve the team.


Leave a Reply

Your email address will not be published. Required fields are marked *