Maintaining technical continuity through turnover

Technical continuity is an important aspect of any engineering team as the team’s staffing changes over time. Engineers will move on to new opportunities for legitimate reasons and new faces will be hired to take their place. For large enough teams, losing a few seasoned engineers at once is not a huge deal as the other team members will help fill in the void and participate in onboarding the departed engineer's replacement. Even so, losing a team member can mean losing precious institutional knowledge and context around difficult technical decisions made in the past and how those decisions were reached.

This problem is much worse for smaller teams where there tends to be less redundancy on domain expertise, as each team member represents a larger proportion of their team’s institutional knowledge base than they would for larger teams.

To avoid this problem, team leads will need to ensure they are building their team for technical continuity, and when their team suffers from turnover, they will need to help rebuild that continuity.

Building a team for technical continuity

Documentation of design decisions is one of the best ways to ensure technical continuity on a team. If the team decides to go with one approach to solving a problem instead of another, documenting the decision in a design spec along with the rejected solution and the reason why it was rejected can help increase the longevity of this decision. Along the same lines, documenting the long term vision or trajectory for this design is equally as important, since it influences the decisions made today and helps future engineers continue executing towards this vision. The existing design specs are a great place for both of these bits of data, as this is typically the first place engineers should look when ramping up on a new component.

This approach also applies to code: we sometimes end up writing a block of code we aren’t proud of in order to work around a strange behaviour or other unforeseen dependencies. Adding inline comments next to this block of code when writing it can help warn future generations of engineers against trying to refactor this section of code only to re-discover why it was written that way to begin with.

Holding blameless retrospectives after each major milestone are a great way to ensure not only the growth of the team as a whole, but also calling out the mistakes that were made so that the team is not prone to repeating them again in the future. These could be design mistakes, assumptions that were proven wrong, processes that didn’t work, technical debt that was added, technical research items, etc.

Most importantly, the lead will need to constantly map out the team’s skill sets and areas of expertise to identify any holes and influencing the team to help fill those gaps. Areas with thin expertise should be cause for concern and addressed as soon as possible — the lead will need to provide the engineers in that position with the help they need to fully ramp up on these areas.

Lastly, when it is known in advance that a team member is departing, schedule some knowledge transfer time between that person and the engineers who will inherit that person’s area of expertise. The departing engineer’s primary goal at this point should be to train their replacement and set them up for success — all other tasks (including closing out technical tasks) are secondary.

Rebuilding technical continuity after turnover

Sometimes, a new team lead will inherit a team which has suffered a lot of turnover in a short period of time — in the worst case, the team has turned over completely. In this situation, the new team will need to ensure they stay highly productive by avoiding to repeat the same missteps that occurred in the past or retracing the same designs only to end up right back at the same decisions their predecessors made. The team’s most important goal in this situation is to rebuild their domain expertise and institutional knowledge base.

New teams should assume their predecessors were at least as smart as they are. First, they will need to seek to understand the current solutions in place and what decisions drove them before they plow ahead with major changes. The biggest mistake a team can make when they finding themselves here is to see it as an opportunity to throw away all current state and start over from scratch. Starting over means erasing all previous productivity to rebuild systems that already work and repeating all prior mistakes — definitely not the best use of the team’s time.

If the previous team was built for technical continuity, they will have left behind documentation and other collateral detailing out how the current systems work, architecture, designs, decisions, retrospectives, best practices, coding standards, values, etc. The new team’s short-term goal in these situations is to read them, discuss them, and familiarize themselves with the content in these documents. Typically, this collateral will not be complete (or not be there at all) or not always make perfect sense. The new team should try to fill these holes by seeking context from other engineers who may have been around at the time or by just diving into the code and playing around with it to understand how it is put together.

If some of the previous team’s engineers are still within the organization but in different roles, asking them to participate in code reviews for the new team is an excellent way to help bridge the past with the present. Code reviews are important for teasing out details to rebuild domain expertise and start valuable conversations around vision, etc.

Decisions to overturn current designs or architectures should be made deliberately and with deep understanding of these designs, rather than because the new team can’t be bothered to figure out how the current solution works or why it was built that way. Typically this happens when the new team is asked to fix or enhance an existing component — avoid the gut reaction to “just rebuild it better” unless it is absolutely necessary.

As the team rebuilds its institutional knowledge base and regains confidence and momentum, the team lead’s will need to put in place the safety nets described in the previous section to ensure the new team’s institutional knowledge base is built to last.

Conclusion (TL;DR)

Build to last:

• When making decision, document them so they have staying power.
• When learning from previous mistakes, document them so future generations don’t repeat them.
• Hold blameless retrospectives after major milestones.
• Map out & assess subject matter experts, make sure there is always a backup.

Understand the past:

• Seek to understand what drove predecessors to make the decisions they did. There is usually a good reason for it.
• Avoid rebuilding existing components/systems without first understanding them.
• Read through previous retrospectives when launching a new similar project or phase of a project.
• Include previous team members in code reviews if possible.

Do you have a different strategy for maintaining or rebuilding continuity? I’d love to hear about it!