Don't be a Hero

I am not saying don't save the day. I am not saying don't step up and help others. I am saying to make hero your job. There are many engineers that are always putting out the fires. They are always that one person who "knows" how to get something done. As a leader, it is your job to make sure your team or teams can take care of the things they own. If you just have one person that is critical to keeping the software running, then you are not doing your job.

As an engineering leader, it is your job to empower your whole team. This means you must take every opportunity to uplevel your team members. You need your hero to be a teacher, not a solo "get stuff done" person. How to debug the production issue? What are the landmines when working on this codebase? What permissions are needed to do this deployment? Obviously, all of this should be written down in your documentation store (first miss). If you have your hero, put them in charge of getting all of these responsibilities off their shoulders. If your hero is that good, you probably want them to bring your other team members up to par.

The process of moving your hero from saving the day to training the team can be difficult depending on their mentality. If they truly care about the company, product and customers this will be easy. They will want to get more people to the point that things run smoother. If you hear "It will just be quicker if I do it myself.", then you may have a battle on your hands. The statement is probably not false but may point to a mindset of "only I can do this". In actuality, you want any experienced person on your team to be able to get it done. Yes, there will be some faster or better than others but that does not mean you want to keep the hero doing it. What if your hero is on vacation? What if your hero is sick? What if your hero's phone died? In any team having a single point of failure is a bad thing. It makes your team weak.

The specific process for turning your hero into a wizen engineer teaching others the craft will take some time.

1. Explain the problem (what if the hero is unavailable?)
2. Set the expectation (things can take longer while teaching)
3. Painfully repeat the expectation (the team needs to be able to do it, not just the hero)
4. Talk through the benefits on the other side (less pressure on the hero, more team confidence, hero can do other projects, etc.)
5. Again repeat the expectation (going to have to do this a lot)

Depending on the person or the team this may take more steps. This will make a much healthier team and you will be able to get more completed.

What if the hero will not get on board? You have to ask "why". If the answer is they don't want to waste the time or no one can do what I do, then you may have to think about replacing this hero. I know that might sound crazy as they are the only one keeping everything running, but if your hero has built a system so brittle that it requires them to keep fixing it you probably don't have the right person anyways. If the answer is the rest of the team is not good enough, you have some evaluation to do. Is your hero right? Did you hire a subpar team? If you want to really dive into this, have your hero take one person to teach. Get your feedback from both people. And then you can decide how to proceed.

Just want to reiterate, I am not saying your people should not step up in crisis and help. I am not saying you can't have truly amazing team members. I am saying that the job description of "hero" needs to be removed from your org. You should have teams that can take care of business. You should reward people for once in a while heroic act. Your teams are healthier when the people on them are equals. Not meaning everyone has equal skills or experience, but they have equal ownership, accountability and expectations.