Office Hours #4 — Make Yourself Redundant

Ideas to increase competitive advantage for an ambitious startup and tips on how to achieve that

This is the fourth installment of the weekly Office Hours series, where I explore common questions raised in discussions with engineers within and outside of Xendit.

When I first set out to write this post, the intended audience was meant to be managers because one of the key requirements we ask of our managers is to make themselves redundant before they’re eligible for promotion. After talking with many of our senior ICs, I realized that this idea can and should be universally applied.

Making oneself redundant is often a confusing concept to many junior managers and ICs. We’re conditioned to want to be indispensable to achieve some amount of recognition and job security. However, taken to the extreme, this creates a high degree of inertia to maintain status quo or worse, incentivize creating unnecessary complexity to ensure that a small group of people are the only ones that can operate in a certain area.

In fact, there are many aligned incentives to making oneself redundant between a high growth startup and an employee. From the employee’s side:

1. Pursue more interesting and/or impactful work (aligns with personal development goals)
2. Gain experience in multiple business areas (often a requirement for career development)
3. Gain leadership and mentorship skills (build trust across the organization)

From the high growth startup’s perspective:

1. Put the best people towards the hardest problems
2. Higher retention and more engaged staff
3. Increase the bus factor, making the business more resilient

Once you’re convinced that becoming redundant is a worthy goal to pursue, the hard work truly begins. In practice, becoming redundant is difficult for operational and emotional reasons. On the operational side, there are likely many things which you’re not explicitly aware of that you’re doing which will be exposed as a gap during a handover process. On the emotional side, it’s likely that you’ve developed a deep connection with the work you’ve done. There’s a great saying to “give away your legos” which is especially apt here. Below, I’ll provide some tips on what has worked for me and what I’ve seen work for others:

1. Break up into discrete chunks
2. Hand over by risk
3. Groom owners in advance
4. Stress test
5. Self Serve

Let’s explore each of these.

Discrete Chunks

A reasonable strategy is to start by identifying discrete chunks that can be handed off fully. These chunks should not require your synchronous attention for them to be delivered effectively. You can definitely keep a review or signoff stage when the handoff begins to ensure that things don’t go completely off the rails. But, as much as possible, don’t make that a blocking stage or you won’t truly be redundant and the person you’re handing off to won’t feel like a true owner.

If you’re just starting off the process, start with smaller discrete chunks and work your way up so that you can gauge what you’re ready to hand off (both operationally and emotionally). Each chunk should ideally come with a set of documentation and resources for the new owner to quickly get themselves up to speed. All of this will take time to prepare, which is why starting small is appropriate. This will help you build momentum and confidence over time.

For a manager starting this process, a good candidate for a discrete chunk will be a project with minimal dependencies on external stakeholders (e.g. augmenting an existing feature within the team’s area of ownership). For an IC, this can look like handing over ownership of a module that is not relied on by other services.

Hand Over by Risk

One of the most common fears that I observe when going through this process is the question of “what if it fails if I’m not working on it?” It’s a fair question and what it highlights is that each area of work carries some amount of risk if it’s not done properly. However, that risk is unlikely to be uniformly distributed. There is work with very low risk if it fails like running load tests in staging and work with very high risk if it fails like delivering on expectations of important customers.

On the low risk end, you should be comfortable with handing over quickly and letting things fail and allowing people to learn from their own mistakes. On the high risk end, you should tend to hand over more slowly and ensure that learnings from previous mistakes (both within and outside the company) are made known to avoid those cases.

Groom Owners in Advance

What you’re looking for is not just someone to take on the tasks or responsibilities of what you look after. What you’re ideally looking for are OWNERS that are willing to take accountability of that area and have their own motivation to drive it forwards. This will ensure that you don’t get pulled back in with every new case and development, which will tend to happen often in a high growth environment.

However, these people are often already committed to other areas which means that by the time you’re looking to make yourself redundant, there will be few available candidates. This means that it’s important to get started early in identifying and grooming future owners. Good candidates may include more junior staff that are hungry to grow for lower risk areas or more senior staff that are looking for a change or increase their scope for higher risk areas. Getting started early is essential because this process of identifying and grooming can easily go on for quarters or even years.

Stress Test

Good engineers know that it’s important to test to verify that the system that was built works according to expectations. It’s the same with making yourself redundant. The advice I usually give is to “take a holiday” once the handoff is made. This doesn’t necessarily require a literal holiday (though taking breaks is important). It can be a mental break where you don’t respond to inquiries or follow up on work in what was handed off. Importantly, this assumes that the new owner has the basics to operate effectively, which is a huge topic in itself.

Start stress testing early and in low risk ways. Don’t start by taking an entire month away and expecting everything to work smoothly. Start by gradually reducing touch points (e.g. from daily to weekly) to ensure that risks are acceptable. I consider a manager to be competent if they can take a holiday and everything is still functional when they return. I consider a manager to be excellent if they can take a holiday and improvements have been made when they return.

Self Serve

As long as there needs to be a human owner, it means that redundancy remains a bigger challenge. New staff needs to be hired, trained, and humans are not the best at executing in a consistent way over time. For areas which require consistency and are largely process based, I recommend to create some kind of self-serve (e.g. documentation, tool) or even better, automate that process in some part so that humans can be redundant in the operation of that process.

This approach doesn’t work for areas which require creativity or alignment of stakeholders. Humans are still required to drive decisions and own risk. However, what this approach does allow is minimizing the number of humans that need to be made redundant. Humans are much harder to make redundant than documents and software.

Conclusion

Many readers can likely agree that the ideas and approaches presented above are relevant to managers. I wanted to go back to the start and address the topic of ICs. Through working with our most talented and senior ICs, I’ve realized that it’s just as important for ICs to work towards their own redundancy instead of relying on their managers.

What I’ve observed is that first, no one knows the challenges in your work better than you do. More importantly however is the fact that at a certain point, ICs will grow to a level beyond what their manager has achieved. If the manager is doing their jobs correctly, they will hire ICs that are more talented and senior than the level they may have previously achieved during their times as an IC. This is a feature, not a bug.

In a high growth startup environment, problems and challenges often grow at a superlinear pace. This necessitates redundancy of existing staff so that new challenges can be undertaken and customer value can be realized. In this context, making yourself redundant is not simply a “nice to have”, it’s a real competitive advantage for an ambitious startup.