Developers: Here's why you should make yourself replaceable

I'm willing to bet you've worked with a Harold before. I don’t mean some actual colleague you once had who happened to be named Harold, but rather a persona that I like to think of as "Harold the Hoarder of Code." Harold has spent a long time with your company, building up a veritable empire of abstruse code that only he (or she) can understand.

Here are some signs that you might work with a Harold:

• The work on his part of the application simply ceases when Harold goes on PTO.


• If you trace a bug report into Harold's domain, you're instructed to "just assign it to Harold."


• Any code commit you make to Harold's purview is reverted the next day. By Harold.


• Right after you notice that your code was reverted, you turn around to find an irate Harold. He actively encourages you not to touch his stuff anymore.

As unpleasant or intimidating as it might be for you to work with this type of person, you might find yourself wanting to admire them a little, or at least to imitate their success. After all, Harold types tend to come and go from the office as they please. They ignore the dress code and skip team meetings. They get invites to meetings with the bigwigs. It doesn't take a lot of deep thinking to understand why Harold types are important and why they get away with so much; they’re bottlenecks when it comes to the company's operations.

Having spent time as a developer, manager and technical executive, I can offer some perspective on Harold (and why you don’t want to become one). In order to do that, let’s start with why making yourself replaceable is a better career strategy than turning yourself into a bottleneck.

Teamwork triumphs

Humans possess a cognitive bias known as the endowment effect, which causes us to assign higher value to our own possessions than to comparable items that we don't own. This manifests itself in corporate behavior, as well. We become unable to imagine life without a Harold, but it's not like we'd opt into a situation where we hired some cranky prima donna to be a bottleneck. Life without Harold wouldn't be nearly as bad as we think at first. Sure, we might miss a deadline or two while a series of new people learned the Harold module, but things would ultimately go on, and probably improve. Keeping a Harold type around is often the path of least resistance, but it's no secret to decision-makers that this state of affairs is a local maximum.

Self-improvement is essential

Harold types are not marketable, and it's not just the company that wallows in a sub-optimal state of affairs here. This situation isn't especially good for the person who becomes the bottleneck. This person spends so much time protecting their turf and buried in maintenance requests for their cobbled-together cavern of code that they’re likely not learning anything new. Being a bottleneck is a pretty time consuming pursuit, leaving little room for self-improvement. On the open job market, a Harold has little value.

Promotion comes easier with cooperation

Like we’ve just covered, a Harold type isn't marketable, so he probably isn't going anywhere. As his manager, I find him to be a pain, but getting rid of him would be a bigger pain, so he stays put. But "getting rid of him" doesn't just cover demoting or walking him out -- it also covers promoting him. Harold's method is holding the company hostage by being the single point of failure on a module or application. But if he ever wants to move on to an architect, team lead or managerial role, he's a victim of his own success. How could I promote him? Who would maintain his code?

Success begins with trust

Avoiding these behaviors is a great start, but in order to achieve excellence (and to fast-track your career), you need to be the anti-Harold. You can start by being pleasant and constantly devising ways to make the organization not depend solely on you. Yes, you read that correctly: Make the organization not depend on you.

It sounds like a high wire act with no safety net, but there is nothing better for your career. By doing this, you become the person who can adopt an error-prone process and automate it to flawlessness. You become the person who can take control of a terrifying legacy codebase and leave it in a state where junior developers can come in and be productive. In short, you become the person that can fix a bottleneck situation. And, speaking from a manager standpoint, there is nothing more valuable.

If you can come into your job and automate it to the point where someone less skilled can do it or to the point where it no longer exists, you aren't in any danger. What’s more likely to happen is that you’ll begin receiving raises and promotions and greater trust from the company. Bottom line? A successful career isn't made by holding companies hostage, it's made by setting them free.