Your Job Is To Make Yourself Obsolete

In 1983, a lady by the name of Susan Glines living in Bryant Pond, Maine, a hard working, tax paying resident of the great US-of-A, have lost her job and she never returned to work in her profession ever again.

See, back in the 80s, Susan was a switchboard operator for hand-crank phones, the last of her kind.
She would come every day to the Maine telephone exchange, sit in front of a giant manual telephone switchboard, shoulder to shoulder with her colleagues, same as she had done for the past several decades. She would spend her days moving phone plugs from one jack to another, routing calls, getting people together. Susan was happy with her life.

But all that came to an end with the invention of the automatic exchange that replaced the human element of connecting one person’s call to another with an electromechanical system. It made call routing infinity more efficient and made long distance phone communication an affordable commodity worldwide.
As a result however, tens of thousands of switchboard operators around the world, and Susan, lost their job as their day to day responsibility was replaced by technology. Within less than a century, they all became obsolete.

Not Really Susan - Photo by Museums Victoria on Unsplash

I know It’s a scary thought, but think about it for a second. The definition of our profession, of software engineering, is to make other people’s job obsolete. Our day-to-day revolves around either automating things that were once done by people or things that were impossible to be done by people in the first place.
We build media websites and applications, making printing press workers obsolete. We build automated tax systems, making accountants obsolete. We create chatbots that make call center operators obsolete. We are even building autonomous vehicles aimed at making us as drivers obsolete.

Our job is to make people obsolete. Moreover, when you think about it, and some might argue with this, We software engineers are people too!
So unless you associate yourself with the shady discipline of “Mortgage Driven Development”, you are probably already spending your days as an engineer making yourself obsolete as well.

How? You might ask. You do it by writing easily readable and extensible code, so that others can easily maintain it instead of you. You do it by documenting and knowledge sharing, so that others don’t have to come to you with questions all the time. You do that by writing well designed software that is driven by configuration, so that not every feature will require new coding from you. And ultimately you do it by automating as much as possible of your day to day work, so you don’t have to do it.

So no, you don’t make yourself obsolete in the same way dear ol’ Susan did. These are the type of good engineering practices that usually do the opposite of getting you unemployed. What you are actually doing however, is investing time and effort into making yourself redundant for dealing with the things that used to be under your responsibility, usually with the goal of being able to take on new responsibilities and challenges.

While most of us don’t usually think about it that way, all of this should be fairly obvious to any good developer, after all that’s what we do. But have you thought for a second, if we are so good at automating our day to day work and making ourselves obsolete as engineers, why do we become so bad at doing it when we transition into being engineering leaders and managers?

Responsibilities stacking up - by zonyajeffrey on Pixabay

The transition into a leadership or management role for an engineer is a monumental thing, and frankly we don’t talk about that enough.
Usually we take our best, most talented and responsible developers, decide to put a virtual crown on top of their head, give them some rudimentary mentorship, or maybe not, and send them off on their way to figure things out.

It usually takes several months or even years before you understand that you’ve been duped.

Gosh darn it to heck, Engineering management is nothing like coding, this is like a completely different job!

Well yeah, because it kinda is a different job.

As the cloud of euphoria from your recent promotion passes, and the shell shock from realizing what it actually means starts to dissipate, you realize what your new responsibilities are now.
If before you were accountable just to your own code, now you are accountable to that of others. If before you could solve your problems by coding them away, now you need to talk to people, listen to them and try to guide them in the direction you believe is right.
You need to think about communicating things, managing processes, strategizing, managing risks, mentoring people and caring for their needs. And did I mention that Daria the senior engineer doesn’t like David the new hire, but you really need them to work together on that new project, because Linda said she is unhappy with her salary and might quit, and production is on fire again, and your boss is waiting for a status on that project that was already due last quarter, and your build is still failing and… It’s overwhelming!

What usually happens is that you go back to your gut instincts and you try to consolidate everything to you, because after all you were the best, most talented and responsible developer, that’s why you’ve got promoted. You got this!
But in reality, you try to translate what worked for you well as a developer, as an individual contributor, into a leadership or management role, and that simply doesn’t work. You try to turn yourself into that human switchboard operator, and what you end up doing is turning yourself into one of the biggest anti-patterns known in software. You become, a single point of failure.

At first this approach doesn’t appear that obviously bad. When things are small, having you as the bottleneck for all communication and decision making actually works to your benefit. It enables you to easily connect the dots, identify how one thing can affect another, and easily act as the router for information and decision making between one side of your team to the other, like a human switchboard.
The cracks however start to show as things get a little bit more complicated. As the team grows in numbers and responsibility, as the breadth of your architecture and stack increases over time, it becomes harder and harder to manage all that context by yourself. The detailed mental model of everything and everyone starts to become too big to fit in one individuals’s brain, no matter how talented or responsible that individual is.

These cracks reveal themselves in different ways to different people. Some might start dropping the ball as they forget one thing in favor of another. Some might find themselves actively over simplifying complex things just so that they would fit in their head, leading to poor decision making or badly managed projects and human relations. Some get overwhelmed by the amount of context switches they go through and start to burn out.
Some experience all of the above and then some.

Even if at first you don’t find yourself in that category, as you are able to keep up or simply don’t mind with things not going well, you still end up creating a problem for the organization you are a part of.
Because the more context and responsibility you retain only to yourself, the more you become an actual risk by being a Bus Factor of one. You are still a single point of failure.
You can tell that’s the case, if every time you just bring up a long vacation your boss gets nervous. It’s the case if you can’t have that vacation without getting at least one or two phone calls asking for assistance from someone. And it’s the case if every time you come back from a vacation, you find out your team made little to no progress on what they were supposed to do without you.
But once you reach that point it might be a little too late, things are already not working as well as they should and your team haven’t been trained well enough to help.

Time to move forward - by NEOSiAM 2021 on Pexels

If you are an engineering leader and any of what I wrote here resonates with you, it means you need to start taking action before things get too difficult, and even if they already are it’s never too late.

Whether you’re a tech lead, a team leader, an engineering manager or even an architect, your mindset should be, as the title suggests, that it’s your job as a leader to actively work on making yourself obsolete.
Think on how you can leave the “manual switchboard” paradigm behind you and work your way towards “automating” what you do so well, so it’s more scalable and future facing.

It’s all easier said than done, but you need to plan towards that goal as your top priority, invest in mentoring your team members and peers, provide them with the correct eco-system and frameworks to succeed, and of course by doing a lot of delegating… There, I finally used that word.

In my next post I will share my highly opinionated 6 (not so) simple steps program for becoming obsolete as a leader. And don’t worry, it won’t make you end up like Susan.