Skip to content

Latest commit

 

History

History
104 lines (66 loc) · 7.26 KB

role-transitions.md

File metadata and controls

104 lines (66 loc) · 7.26 KB

[Quickstart Best for orgs with defined Engineering Manager roles open to internal transitions]

Engineering Role Transitions (IC <> EM)

This guide is meant to help when people in engineering transition between roles, as in between an individual contributor and manager role.

In most role transitions, people will end up with different managers than they had before. See Guide to Manager Changes to facilitate an individual manager change, and apply it to each affected individual in the scenarios below.

tl;dr;

The most important thing is to communicate and set expectations with everyone involved. This means ensuring that anyone affected understands what is happening, when it's happening, and how their own responsibilities and relationships may change—all before making any changes official. The role of an Engineering Manager vs. Individual Contributor depends on your company culture, so refer to internal references (e.g. role ladder / level descriptions) if available or consult your manager.

Manager to Individual Contributor

<drafting...>

Individual Contributor to Manager

Why become a manager?

The main reasons someone may choose to transition into a manager role include:

  • There's a clear need for a manager on the team
  • They have already been successful with mentorship and technical leadership, and are interested in focusing more of their time on the development and support of people and teams
  • They have a clear understanding of the expectations of the new role and are excited by them

What are the steps to take?

Terminology

  • Outgoing Manager: Manager that is facilitating the transition of the person who is switching roles
  • New Manager: the person switching roles / soon-to-be new manager

If the above reasons hold true, here are some steps to follow:

Define the new role and associated responsibilities

Both people should work together to define the scope, membership, responsibilities and goals for the new team. Because manager roles are filled upon need, there should be a natural mission for this team that already exists, though it might be a specialization of an existing larger team that's splitting in two (a.k.a. team mitosis). This plan should include:

  • Definition of team: purpose, goals, projects it will take on in the first 3-6 months
  • Membership of team: who will be part of this team
  • Important information to be aware of: key in-flight projects, oncall rotation, incident response

A good rule of thumb for new team size is somewhere between 3 - 8 people, where < 3 feels like the scope is too limited to warrant a new team and > 8 is a tough challenge for a new manager.

Get feedback from team members, peers, other engineering managers

The outgoing manager should get feedback from people the new manager has worked with or helped mentor and develop. This includes discussing the transition with other engineering managers familiar with their work and what the new role entails.

In gathering feedback, the outgoing manager should also be explicit that the feedback will be used as input into a role transition. E.g. "We've been talking about having become a manager for team X working with Y, and I'd love to get your thoughts on this." This should ideally not come as a surprise—it should be clear a manager is needed and that the person has already been playing a leadership role.

  • For all / in general: what are the new manager’s capabilities when it comes to technical leadership and technical ability? What about team and project leadership?
  • For people they have mentored: how were they as a mentor? what did you rely on them for and how did they help you grow?
  • For peers / other teams: how did they help their projects or the team succeed?
  • For other managers: how do you think they will tackle cross-org manager responsibilities? Working with you and other teams?

This feedback gathering often happens by starting a discussion with a peer group of managers or fellow managers in your organization; first explaining the potential transition plan and then giving people an opportunity to share any thoughts or concerns.

Communicate the plan with the new team members

If the feedback comes back positive, the next step is to communicate with the team, with more focus on people whose manager will potentially be changing. I.e. "As we discussed previously, we're considering transitioning into a manager role on the team, where they’d be your new manager." This is a good time to get any additional feedback that might come out of making this more explicit.

If there are clear blockers, the transition should be stopped and pertinent feedback should be communicated directly. E.g. "I've been gathering feedback about the potential transition, and here are things I think we should focus on improving" + [before we make the transition] and/or [and I don't think this will be a good fit for you at this time].

Set up an evaluation period (~4-6 weeks)

The outgoing manager, new manager, and affected team members should agree on an evaluation/transition period that makes the following clear:

  • Weekly 1-1s with the new manager as if they are the new official manager
  • Continued check-ins with the outgoing manager
  • Transfer of information / context on each individual from the outgoing to the new manager

If something comes up during the evaluation period that might block the transition, that feedback should again be shared with the new manager.

If successful, complete the transition and communicate it more widely

If the evaluation period goes well and everyone is comfortable with the new role and manager, we can complete the transition.

  • Outgoing manager confirms the transition with the team
  • Outgoing manager can cancel or cut down recurring 1-1s with any moved team members
  • HR-finalize the transition for each person (e.g. updating official manager information in people systems)
  • New manager is added to company engineering manager groups and meetings
  • New manager will take over any performance conversations and reviews, including catching up on previous feedback or written reviews
  • Outgoing manager can announce the transition more broadly

Once this is finalized, the new manager will take on several additional responsibilities, including but not limited to:

  • Understanding the company's people philosophy, including delivering performance feedback and compensation changes as they come up
  • Being involved in the recruiting, hiring, spinning up new hires
  • Anything else the Engineering Manager role entails for your company

Checklist Version

  • Define new role and team, including charter and members
  • Collect 360 feedback from teammates, peers and partners, other eng managers
  • If feedback comes back with any blockers, stop transition. Otherwise, proceed.
  • Setup 4-6 week transition period with "double management"
  • Confirm and finalize the transition with each member of the team—in person in 1-1s, in team meeting, etc.
  • Confirm and finalize with the broader engineering organization
  • HR-finalize the transition for every affected person on the team
  • Announce the change to the broader organization or company
  • Attend any relevant new manager training programs

Questions & Feedback?

Open an issue or submit a PR!