Planning for your replacement
The staff+ eng superpower to scaling
One engineer recently asked me, 'Hey Sidney, you move onto new projects quite a lot; how do you manage to "scale" and work on so many projects?' After some thought, I realised the answer was learning to "plan for your replacement": a process for effectively handing over projects to long-term owners at the right time. As I wind down my effort on one project, I can be deployed on a new one.
As a senior engineer, you frequently get dropped into the high-complexity and high-ambiguity phases of projects. It may be at the start where your role is to identify the problem and then prototype and define a solution. You may be dropped into a problem project where you redirect the project team. You may also be called in to solve a specific deep technical problem where your experience and expertise are needed to find solutions. In these situations, your role is to define enough of the problem and solution so that others can execute the details and maintain the systems long-term.
The challenge is that, as a trusted expert, leaders and peers will naturally turn to you whenever they have a problem that resembles a project or domain you have been or are currently working on. Without an effective delegation and handover strategy, you can be accidentally pigeonholed as the 'fixer' in a particular area, and you won't get the bandwidth or growth opportunity to pick up the next thing.
I use four practices to handover work to others:
Develop an exit strategy early - plan for and get early alignment on your transition off a project.
Pair-tech leading - intense collaboration to get others up to speed quickly.
"Get over yourself" - get comfortable not being the centre of a project.
Staying in touch - Use mental models to reduce the bandwidth required to keep track of progress.
Develop an exit strategy early
So your manager has asked you to 'look into this general problem area'. Maybe you've been asked to find a new product opportunity or improve the efficiency of a team or system. As you investigate the problem (see my earlier post on learning a new domain), define solutions, and propose projects, you should also consider:
Which teams are implicated, and who should own the systems long-term? They should be involved at the start of projects (even during the proposal phase, if only in an 'informed' capacity) and be actively involved in the project build.
What is your role on each project? You are called 'tech lead,' but what does that mean? You are likely driving alignment with affected teams, but how deep in the weeds will you go? Are you doing project management? What technical decisions are you driving versus consulting in (interface design? tech stack selection? code architecture?)? Are you writing the code? (hint: you definitely shouldn't be writing all the code).
A common pattern I have used as a senior staff level eng is:
I am responsible for presenting the problem being solved (short and long term) and the system architecture (i.e. services involved and to be built).
I define program phases and milestones down to, say, eng-quarter granularity.
I drive high-level interface design (what systems talk to each other, what data and functionality are owned by which system, and what data is communicated synchronously and asynchronously?). I can delegate detailed API specs (OpenAPI or Protobufs) and granular technical decisions (e.g., code architecture and tech selection) to other engineers.
This varies project-by-project and org-by-org depending on the size of the projects, who else is involved, and their level of expertise. For example, I will need to take on lower-level responsibilities where more junior engineers are involved, e.g., defining project epics or making more tech decisions.
It is crucial to align your role with your manager and stakeholder teams as early as possible. You don't want late surprises; sometimes, finding the right engineers to take over once your ideal role is fulfilled can take time. In particular, line engineering managers (EM) for teams owning the solution long-term must understand your role. I've found that line EMs do not always know how to leverage senior engineers and can expect you to be a 'magic engineer who can code 10x faster'; this is likely not your role nor the best value you can bring to the company. (To be fair, line EMs are usually accountable for project execution, so they'll naturally want more and faster engineers to help their projects go quickly.)
Pair-tech leading
As you begin project work as tech lead (in alignment with the role you negotiated with stakeholders and your manager), you should partner with the long-term owner(s) of the system(s) the project is building or modifying. Typically, they are less experienced than you, and part of your responsibility is to help them grow. This includes ensuring they understand why decisions were made, what design principles should be followed, and your thought process as you assemble your designs. This helps in the long-term maintenance of the system, and in growing a network of engineers, you can trust to make good decisions.
One of the most effective ways I found to learn to code was pair programming. It is quick because direct feedback is available immediately. You also get to observe thought processes and practice decision-making while making progress on a project. The intense period together also helps build rapport.
We can apply similar principles to tech-leading projects:
Where possible, involve partners in all relevant technical discussions so they have context and can see decisions being made. Evolve their role in these discussions; they may start as observers but encourage their participation. Eventually, 'stop talking' and redirect questions to them.
Have frequent pair-designing exercises with them. Co-author designs, possibly by having them start the write-up and you review. You could also define the overall structure of a design with your partner and then delegate sections.
When you define the overall solution, consider breaking it down into suitably sized work that your partnerscan take responsibility for (and you provide feedback on). For example, if several services are required, you can delegate specific service designs.
Have constant communication to gauge their confidence level in taking on more work.
Get over yourself
One of the biggest challenges is letting go of a project you've been leading. The proliferation but lack of shared understanding of the "Directly Responsible Individual" (DRI) concept has complicated this (which is why I talk about tech leading, not DRIing above). As a project DRI, you can feel you need to do all the work, make all the decisions, and be the "first author" on all designs. We also need to fight the "feel good" factor of always answering questions about the project; we always like to be needed.
The key is understanding your role and aligning with your manager (who writes your performance review and probably assigned you as project DRI). For me, a DRI is primarily there to ensure a project team succeeds by being there to unblock team members. You lay the tracks for the team 'train' to run by breaking the solution into chunks that the team can work on, interfacing and aligning with stakeholders so the team doesn't have to wait for requirements, and pushing decision-making along (e.g. detecting and moving the team past "analysis paralysis", tiebreaking, driving the one-way door decisions). Trust the team to execute and verify their work. You and your manager must accept that you won't be raising all (or even lots) of pull requests and writing all design docs. Be clear on what proof you need to show you're doing your job (or enough for a promotion if that's what you're after).
Staying in touch
Even when you're out of the day-to-day project work, it is still necessary to keep tabs on projects (trust the team to execute and verify their progress). There may be times when you need to jump back into a project to course correct.Understanding more of your company's systems also helps your role in connecting teams together. How can you achieve this at scale?
I rely heavily on creating mental models of how things should work. Your designs and engineering plans for a project should ideally be logical, with as few exceptions as possible (in an earlier post, how sticking to models can supercharge your systems). This means if you need to later answer questions about a project or jump back into it to help out, you just need to remember the mental model to be able to later 'compute' the current state of a project or system when you need to recall it later, and 'diff' against the latest project updates or designs.
Summary
Learning to plan for your replacement as an individual contributor was one of the hardest skills I have had to learn, and to be honest, I still get nervous when delegating and handing over projects and systems to others I have not worked with previously. However, I have consistently found that applying the four practices described here enables me to be deployed on projects where I add value to my employer (and interesting projects at that).