How to Work Yourself Out Of Your Tech Job (And Why That's a Good Thing)

I had an interesting dream last night.

I was working remotely in some random house and conducting a sprint review.

The primary stakeholder was also in this random house, but working remotely from a different room. The sprint review was carrying along fine, business as usual.

Out of a nowhere, a tornado rips through the house leaving the primary stakeholder and I hurt and freaking out a little bit.

But the sprint review carried on. Somebody else picked up where I left off in the demo and another person picked up raising concerns for the primary stakeholder.

I woke up shortly after that and started processing everything that just happened.

I have no idea why I had that dream, but it left an impression.

That sprint review, arguably the most important meeting for a software development team, just carried on without the two most important people. No hesitation. They picked up right where we left off.

My first impression was to be offended. But after thinking about it, I was actually very happy (outside of those jerks not being concerned for my well-being). What I realized is that I was not 100% necessary to perform the daily operations of the team.

I had worked myself out of a job.

If your team can carry on daily operations without you present, then you're doing the right thing. The last thing you want is to build up a team that literally cannot function without you. That's how people get "handcuffed" to products/teams/ideas. They become the one and can never shake it.

That's not how you progress your career.

You must take a problem, fix it, teach others to maintain it, and move on.

Why Work Yourself Out Of a Job?

To be clear, working yourself out of a job doesn't mean you will be jobless. It means that you are not absolutely necessary for the role you're in right now.

Personal Benefits

Working yourself out of a job means you can move on. You have the opportunity to take on new challenges.

Oftentimes it means you can take on more responsibility and move up the career ladder. If you did your job right, you've proven that you can do the work given to you and you can do it well.

People who have the ability to see projects successfully to completion are often rewarded with increased respect and more important projects.

You might even get more projects at once. Maybe before you were over a single project/team. But you proved you excel with that level of responsibility and now you've been given the opportunity to run two projects/teams.

More responsibility often means better title and more money. So if that's what you're into, is there anything more to say?

In the software industry, I see many technical folks who have made their way into leadership positions. This is great! Technical leaders are a breed of their own because they thrive on the how and why and happily take on new challenges.

Photo by Sebastian Herrmann on Unsplash

Benefits to Others

One of the most rewarding experiences as a leader is building up other people. Helping others reach their career goals is something every leader should strive to do.

When working yourself out of a job, your primary goal is to either pass on or distribute your responsibilities to others. By giving away your responsibilities, you are bolstering the career of the people who work for you.

Providing more responsibility to others means they are moving up in the career ladder just like you are. They get to enhance their skills, learn something new, and be treated as an authority in a new area.

People around your organization were used to seeing you fulfill a specific duty, but now they are seeing this new person, which boosts their status in the company.

In this case, you are directly responsible for helping build up others' trust in your employees.

Benefits to the Company

Have you ever heard the phrase "tribal knowledge"?

In software, or any business really, tribal knowledge refers to unwritten information that is known only by the people on the team.

Try to avoid best practices that can only be discovered through interrogation of your team. Document your processes. Adopt known standards. Try to make the onboarding time for new people as short as possible.

Another goal as someone who is trying to work themselves out of a job is to make sure people know what you're doing.

Secrets secrets are no fun. Secrets secrets hurt someone.

In this case, you're hurting yourself if your team is rife with secrets. It's not going to be easy to replace you or anyone on your team if everyone holds the secret keys to how you work.

By documenting and adopting industry standards, you directly benefit the company by allowing anyone to come in and pick up where you left off. Your team will be seen as agile and fluid. When you're gone, you want the team to be as productive (if not more) than when you were there.

How to Work Yourself Out Of a Job

Now that we understand the numerous benefits of working yourself out of a job, let's talk about how you can do it. There are a few quick and easy ways you can go about it.

Delegate Responsibilities

When I got into management, the hardest part for me was letting go. Most engineers live under the I can do it better and faster than anyone else mantra. I am no exception.

But when you get into a management or leadership position, you simply don't have time to do it all. You must start delegating responsibilities to others.

I'll be honest, I fought this for a long time. I tried to do my management duties and take on the difficult engineering tasks. While I was able to do it for a while, I started to feel like I was spreading my self too thin.

It's not a sustainable activity. Once I accepted the fact that I couldn't do it all, daily work got enjoyable.

As it turns out, people like it when you delegate work to them. People like responsibility. It ends up being a win-win.

You will be surprised at what people can do when given the opportunity.

By giving people on your team more responsibility, you make it easy to fill in the gaps when you move on to something else.

Build Repeatable Patterns

Development is all about establishing repeatable patterns.

Some people argue that no "new" code has been written since the 90's. It's all just variations of code that has been written before.

Whether you believe that or not, you should strive to build as many patterns as possible. No matter what you're doing, be it writing code, building a birdhouse, or cooking dinner, it's always easier following an example.

Eliminating that discovery phase is key to quick, high-quality work. If you have a known way to do something, push for new development to be done that way in the future. You know it works and you know it results in robust, performant code.

Continuing down that path for new projects will ensure that your team knows how to do something if you aren't available.

If your development team is the only one that does things a specific way but that way is industry standard and proven to work, share it with other teams. Get it adopted by your company. Make it as easy as possible for somebody new to step in and take the reigns.

Photo by Yogendra Singh on Unsplash

Empower Your Employees

Empowering is different than delegation. Delegation is "hey, do this for me."

But empowering is building up your employees to make decisions and establish the confidence they need to be a leader. So instead of "do this", you say "how do you think we should do this?"

Get them thinking critically. Engineers are no strangers to problem solving. It's our bread and butter. Offering your employees the opportunity to think strategically will dramatically increase their value both to the team and to the company.

Empowering employees isn't something you can do overnight. It starts small and works its way up to your eventual replacement. Get them used to making decisions, be it architecturally, managerially, or strategically.

A little goes a long way.

Work With Others

Your responsibilities as a leader don't stop at your development team.

You are seen as key figure to other people around the organization. If support has a problem, they come to you. If professional services needs help with a client configuration, they come to you. If sales wants to know if it's possible to add a feature, they come to you.

You see a pattern here?

Spread the love. Delegate responsibilities to people on your team to talk to others. Make sure that sales knows if they want a status update or an estimate to talk to this person.

Does support need help? This developer is your go-to girl.

Take the dependency off of you. Establish backups.

When I'm assigned to a task, one of the things I always assess over time is the bus factor. The bus factor refers to the number of people that would have to suddenly disappear for a project to stall due to lack of know-how.

The phrase comes from the saying "what if I was hit by a bus on my way to work tomorrow". If you're the only person that can get something done, you have a bus factor of 1. If you and three other people on your team can do the job equally as well and can pick up where each other left off, you have a bus factor of 4.

Strive to have a high bus factor. When you move on to bigger and better things, that number is going to reduce by one.

Conclusion

It's not easy to work yourself out of a job. It takes time. It takes focus. It takes dedication.

But it's worth it.

You help yourself, others, and your company in the process. By building up the careers of those who work for you, you build up your own career. You are given new opportunities because you're seen as someone who can get it done and leave it better than they found it. You're a people builder.

The world needs people who can work themselves out of a job. They are the strongest leaders we have.

Now get out there and go empower some people!