Knowledge Transfer in Engineering: How to make it go smoothly

Co-authors Andrei Mackenzie and Joe Roepcke

What to do when you have an engineer transitioning off of a team

If you’ve worked long enough in tech, you’ve probably had to perform knowledge transfers to rotate individuals or teams on to and off of various projects and products. It’s a common task and challenge faced by engineering teams, whether due to natural attrition, promotions, folks transferring to other groups, or new members joining existing teams. Since Xandr’s technical teams cover a wide range of features including high-performance ad auction processing, cutting-edge frontend UIs, and data engineering at petabyte scale, these engineers often need to learn from each other or even change teams. We actually encourage internal mobility to allow engineers to pursue their passions and explore different parts of our organization and the products we offer.

Being able to handle these sorts of transitions well is key to keeping your engineers growing, learning, engaged and motivated. In addition, this ensures your ability to continue running your business effectively, supporting your clients and products seamlessly, and protecting your sources of revenue.

In this post, we look at some of the most common challenges any engineering organization faces when a developer needs to transfer knowledge in order to take on new responsibilities and/or support new products and what things you should consider in your transition plan.

What sets the ball rolling

Usually, an engineer has identified an opportunity they want to pursue on a different team, or a new product team or division is being formed that will include this engineer. Sometimes, the move is based on some specialized skills or interests they have. For the purpose of this post, we’ll assume this is a permanent transfer.

One of the ways we’ve seen this initially unfold is the engineer who wants to move identifies an interesting opportunity and speaks to the new manager to learn more and confirm their interest. Next, the engineer speaks to their current manager to get their perspective on the move. The current manager then has an opportunity to share their ideas and offer some insight on what alignments can smooth the path to transition. Once all three people agree on the move, the engineer and both managers begin work on a transition plan. This is needed to allow the engineer to migrate from their current responsibilities and ramp up on new job tasks without disrupting day-to-day business and the teams involved.

Some Common Objectives in a Transition Plan

We found that a people first approach worked best. Some key objectives in what such a transition plan ultimately looks like are:

Support the remaining team well — Monitor how the existing team from which the engineer is departing is handling the new responsibilities they will now own (stress level, etc.). This includes how they plan to absorb that engineer’s product knowledge and potentially take over support for those products and systems. You must also determine which projects will soon reach reasonable stopping points, even if they are not fully complete yet, and what those stopping points are.

Support the transitioning engineer’s desire to move on to the new opportunity quickly and minimize the context switching — Design your transition plan in a way that achieves the best balance between letting the departing engineer learn their new product while still supporting their previous team. Don’t let the transition drag on endlessly as it can dampen the initial enthusiasm of the engineer transitioning.

Seamless manager transition — Ensure any context the current manager has is communicated well to the new manager. This is about enabling the new manager to get a head start on supporting their new team member by learning as much as possible about the engineer’s working style, likes and dislikes, career aspirations, etc. The current manager is often the one who knows a lot of these details and has insight into where this employee has shined in the past.

Business Continuity — You need to ensure there’s sufficient coverage for the engineer’s current responsibilities with the remaining team members (so support for the product doesn’t suffer).

Effective ramp-up — This process is not so different from bringing on a new hire. But it’s important to distinguish between what a new-to-your-company hire needs to learn vs. what an internal transfer needs to know. For example, there may be general engineering onboarding for new hires, but then more specific onboarding for sub-organizations (or smaller teams) that is tailored to the products and technology they cover. An internal transfer would only need to complete the more tailored onboarding.

Challenges faced and solutions found

Of course, no matter how carefully you create a transition plan, there will be many things you learn along the way and points where you need to adapt and be flexible. Our transition plan grouped issues into several major areas (your experience may differ). Below, we discuss some actions we took to deal with them:

The actual knowledge transfer

• Identify how you will transition current areas of expertise to existing team members. This means being explicit about who should learn what and setting up focused sessions with the individuals involved. This could include things such as familiarity with testing and debugging tools, code deployment paths, the location of key resources and documentation, or how to connect with other teams that perform essential integration tasks. What’s in this list will be determined by the nature of the role the transitioning engineer performed.
• Try to address any “scariness” the existing team has about learning a lot of new scope (to cover the responsibilities of the departing engineer). Check in frequently with these engineers to gauge their stress level. Reassure them that the engineer transitioning is still going to be accessible. The new manager may also need to address some anxiety around any technology the transitioning engineer has to learn, but this should be minor since they chose the new team and are eager to learn about their new position.
• Consider that some roadmap items might not be achievable on the original schedule given changing team dynamics. You may need to re-evaluate planned work for the transition period to realistically allow the engineer to transfer off in a timely manner. Be sure to set transition timelines that still allow critical work to get done. Also, keep in mind that engineers taking over the responsibilities of the transitioning engineer may not initially be as proficient or efficient in those tasks. This should also be factored into your road map planning, at least initially, until they are up to speed.

In-flight projects

• Be aware of the transitioning engineer feeling rushed to complete in-flight work in order to transition quickly. Be disciplined and set realistic transition timelines to avoid handing off unfinished work.
• Determine explicit milestones for projects and only set transition dates once you have considered a realistic date by which your transitioning engineer can achieve those milestones.
• Ensure the team is comfortable completing and supporting important work-in-progress. If that’s not entirely possible, consider shelving the work or extending the transition timeline. Don’t allow the transition of projects that have not reached reasonable stopping points. This may also require a re-prioritization of what is truly critical and a re-evaluation of what the existing team is able to achieve while still enabling the engineer to transition off.
• Build a framework to govern how the existing team will engage with the transitioning engineer for consultation and hands-on help post-transition. This may involve establishing office hours or holding scheduled sessions for targeted troubleshooting help as well as clearly documenting what steps should be tried first before reaching out for that help.
• Leverage pre-existing documentation and project-related JIRA tickets in any transition documents. This will help ensure continuity, build familiarity with the context of the features or products being handed off, and offer an opportunity for the stakeholders and engineers to learn each other’s names.

Support and Context switching

• The transitioning of the engineer may create gaps in product support, especially if the time zone coverage and overlaps are not sufficient. This is more of an issue if the departing engineer specifically worked a range of hours that had been deliberately chosen to accommodate the customer’s time zone and schedule (e.g., for providing technical support). Once the engineer leaves the team, the time zone difference and support requirements may be difficult for the remaining team to sustain. Therefore, it’s important to establish a pre-defined emergency engagement path for transitioned engineers within your company. Be sure to involve their new manager to establish the right level of focus (e.g., a single work priority order, so that the engineer doesn’t feel pulled in multiple directions by multiple managers).
• It takes time, focus, and effort to train new engineers. Having to shift between learning a new product and training those who are taking over products the transitioning engineer previously built or supported requires context switching. This compromises focus and causes the transitioning engineer to perform each task less efficiently. Below are 3 things you can do to mitigate this issue:
  — Create documentation — Doing this can help the transitioning engineer collect their thoughts, experiences, and knowledge in a central location and allow new engineers to learn asynchronously. These documents can take the form of schematics, process diagrams, specs, component overviews, typical support paths, or whatever the engineer can imagine to be useful. It’s also a good idea to review these documents yourself as reading them can help generate ideas for other areas that might still be missing.
  — Focus — The transitioning engineer needs to be explicit about focus areas and lean on their managers to carve out enough dedicated time, whether it be for pre-transition work or taking on new responsibilities. You need to allow the transitioning engineer to focus on tasks that are either in the old world or new world without forcing them to switch between the two too often.
  — Split % — Define the specific percentage of time that will be spent focusing on the previously supported products over time (e.g., 100%-80%-40%-20%).
• It can sometimes be difficult to stay in the loop after transitioning off of a team or product. The transitioning engineer may still need to offer guidance during the handoff phase. There’s a balance between allowing an engineer to fully focus on the new opportunity with no context switching, and just relying on their memory of legacy projects to support and advise the remaining team’s work. Staying in the loop means still knowing enough about the product and technical direction of the remaining team to not have to spend an inordinate amount of time catching up before being able to share knowledge effectively.
• Be sure to make it clear which meetings, chat channels, and other forums will provide the information critical to maintaining context on previously support products. This will allow the transitioned engineer to remain involved at a sufficient level. For example, the transitioning engineer might stop attending many of the detailed design reviews and team ceremonies that occur weekly but continue to attend the broader long-term planning and monthly All Hands sessions to maintain high-level context about projects on the horizon. In addition, the engineer should remain open to invites for ad-hoc collaboration on specific projects where their expertise could be especially valuable (e.g., some component or feature he/she previously worked on directly).

Time zones

If the time zones of the teams involved are a factor, you may need to consider how to allow sufficient time to collaborate across them. Try to make effective use of the overlapping hours by setting them aside for collaboration between the remaining and transitioning engineers. Initially, office hours and support can be offered during non-traditional working hours (but don’t overdo it, this should not be a long-term strategy). Being mindful of people’s work hours is part of a people-first approach and applies even if time zones are not an issue for your engineering teams.

Some special considerations

Having now completed a few of these engineering transitions within our teams recently, here’s some additional fine tuning we added along the way that our fellow colleagues (and you, perhaps) may find useful.

• Put a defined percentage-of-time focus model in place. It’s both effective and worthwhile. This really helped avoid unexpected or excessive context switching. A sample breakdown that we used was to gradually switch the percentage as we progressed through a transition:
  — 80% old / 20% new — the engineer starts the transition phase by participating in some ramp-up activities on the new product while remaining primarily focused on the previous team’s work and training folks to take over previous duties.
  — 40% old / 60% new — the engineer begins to focus primarily on the new team’s work, but remains involved in the previous team’s ceremonies and winds down any in-flight work.
  — 20% old / 80% new — the engineer focuses nearly exclusively on the new team’s work with only lightweight or ad-hoc involvement in the previous team’s design reviews, support requests in emergencies, etc.
• For larger in-flight projects that jeopardize the transition timeline (due to their size, complexity, or the specialized knowledge that needs to be transferred), try breaking them down into smaller, more achievable milestones. This can allow the transitioning engineer to complete the first milestone while allowing the new engineers to start working out the details of the subsequent ones.
• Plan transition timelines in a way that allows for some overlap between the transitioning and new engineers to give those new engineers time to learn while the transitioning engineer is still engaged.
• Be aware of how distance, language barriers, familiarity with the underlying technology, and/or any planned (or in-flight) changes of toolsets might affect your timelines.
• Carefully monitor the stress levels of both the engineer transitioning and the team that is taking over their previous responsibilities. Be sure to do this even if the engineers involved don’t proactively vocalize their potential stress. How? Try explicitly asking folks in 1:1s (weekly one on one chats) how they are feeling about the adjusted workload. If they share that the additional work is affecting their life negatively, look for opportunities to de-prioritize less important things or spread the load more evenly among the remaining team. Another signal could be if you see that people are working extended hours or are dealing with an unusually high number of off-hours emergencies as a result of fewer hands being on deck. Again, just because you are not hearing about these issues doesn’t mean they aren’t occurring (since vocalizing them can be seen as complaining). Be sure to ask.
• Be mindful of how in-flight work is transitioned. Strive for reasonable stopping points and milestones. Don’t let projects end in a place that is difficult to provide support for.
• Cultivate a bias towards action. At some point, it will be necessary to actually give new processes a try and allow people to step away from previous roles. Your people are talented and able to overcome challenges while still supporting each other. Trust that.

And a few final thoughts

As we all know, you can never figure it all out in advance, so be open to lessons that present themselves to you as you make your way through the transition. Some additional nuggets are:

• Once a transition opportunity is identified, strive to make it happen quickly. As much as team members want to support each other, people are eager for what’s next. Capitalize on that enthusiasm!
• Timing estimation is hard, don’t be afraid to shorten the cutover if the remaining team seems well equipped and ready in less time (e.g., we’ve had teams make a transition in 3 months that was planned for 6).
• Look for opportunities to reduce scope along the way. Ask yourself: “Are all of the transitioning responsibilities necessary?” Use the transition as an excuse to descope and simplify rather than just transitioning all responsibilities exactly as they are.
• Set up a recurring retrospective meeting with the teams involved (before the whole transition is done) to reflect on how the plan is going. For a 3 to 4 month transition plan, a monthly cadence can work well. The idea here is to learn and course correct as you go rather than trying to get the plan perfectly defined from the get-go.

And that’s it! We hope you found some of our experiences helpful and that you’re excited that your engineers are so engaged in your company and products that they both want to take on new and exciting roles and help their colleagues support what has already been built and is succeeding.