What do I do if someone on my team gets hit by a bus?

 

My friend who is also an engineering manager asked me a serious question, “What should I do if one of my guys gets hit by a bus?”

I hope that never happens. But most people leave after awhile. Maybe not today or tomorrow. Sometimes there’s an life-changing event you can’t control. Or they don’t like you.

Whatever the real reason, have a plan for unexpected departures.

Here’s the minimum that I’ve done

1. Keep production stable at all times
2. Increase redundancy within your team

1. Keep production stable

The best thing you can do as an engineering manager is to ensure your production environment is stable. I define stable as there exists a software system capable of running with little to no manual maintenance. If there’s any maintenance required, the instructions are carefully documented and easily accessible to you and your team.

Stable production is your contingency plan.

There is a worst case scenario and that’s when your entire org chart disappears. Maybe your entire team is on vacation or you couldn’t cover payroll. If you’ve done your job correctly, you let the system run on its own while you source new talent. Again, I hope this never happens.

Building a stable production system is very technical and beyond the scope of this article. On a high level, I recommend tracking availability to gauge how stable your system is. Are your users okay with just one 9? (90% with 36.5 days of downtime per year) or two 9’s (99% with 3.65 days of downtime per year)?

If not, then improve the worst performers of the system until you have a satisfactory availability.

2. Increase redundancy within the team

Encourage your engineers to freely talk about their projects. By proximity, other engineers should be able to absorb and retain some knowledge about what other engineers are working on. New ideas and projects will always show up when there’s collaboration. Be surprised and grateful when this happens.

I suggest taking a few engineers out for coffee, and preferably not the entire team. Two is a good number. This is important for engineers who normally don’t speak up. You create an informal setting where you can listen to potential problems or solutions. Encourage them to interact with each other. This is great especially if they don’t interact normally due to different projects. Do not drive the conversation, observe what happens.

Then pick up coffee for the rest of the org for a much larger gathering so everyone doesn’t feel left out.

When someone leaves

Your top priority is to ensure the train can get back up to speed again. If your projects are organized properly, departures should only temporarily freeze development, and will never impact production.

Finally, if you have the spare time, you should maintain your technical skills so you can always cover. You need to make sure whatever your engineers are working on, they have their code committed in a such a way that allows anyone to check out the repository and begin working on it.

Losing you

As the engineering manager, you are not as important as you think you are. Your team can keep working on projects without your input for a long time. Before something happens to you, you should think about your legacy and your job as a professional.

• What sort of state did you leave everything in?
• If you have to leave for any reason, what would your team think of you?
• Would they work for you again?

If you don’t care, there’s no hard feelings. Go. Your team will figure it out.

If you do care, I value transparency as a manager and keeping an updated roadmap on hand so my team can pick up after me if I’m no longer there. I keep my code commits small and documents updated.

Since I make so many decisions a day, I keep a hand-written journal on my desk with designs and meeting notes so there’s a log of what I’m doing. Go digital if you have that option and make sure your team can access it. Have a contigency plan.

Hope this helps.