From Zero to Hero, or There and Back Again

You just landed your first software job. You’re excited, this is a great opportunity! You’ll be able to apply that expensive Computer Science degree to something useful and start paying back those students loans. (If you’re self-taught, good on ya). You know a lot of stuff and now you have the chance to use that knowledge to solve some interesting problems.

zero #

Your first day of work goes pretty well. You get set up with HR, someone gives you dev accounts to various tooling and you start poking around at the projects on GitHub. “Hey”, you think, “this is going to be easier then I thought”. A few days in, you are assigned a task to do. You check out the project and follow the README to run it locally. You start running into problems.

You ask your teammates for help, but you feel bad interrupting them because they’re busy on their own tasks. It’s also hard getting answers because usually only one person on the team knows how a particular piece works. You end up on Reddit waiting for someone to get back from a meeting. You’re also starting to feel a bit like a fraud; how does everyone here know this stuff and I don’t? Maybe software development just isn’t for me.

Let’s get this out of the way. You’re not a fraud. You’re suffering from imposter syndrome and it’s common in the tech field. It’s common because our work is constantly under peer review. A pull request is a threat, an opportunity to be “found out”.

You have to conquer impostor syndrome, it will only hurt your career. Here’s the good news: there are a lot of resources to help. There are often open spaces at DevOpsDays events focused on the topic, Forbes and the American Psychological Association have written about it, lots of people have talked about it on their blogs. The resources to help you overcome imposter syndrome are there.

hero #

Now onto the more pernicious problem. From earlier:

It’s also hard getting answers because usually only one person on the team knows how a particular piece works.

This is the elephant in the room.

The amount of risk introduced to a team (and ultimately a business) by not actively sharing institutional knowledge is negligent.

Your bus factor should be at least 2. Yep, this problem is so common we have a term for it. Critical institutional knowledge does not belong in the head of a single person. The Phoenix Project features a character named Brent that is the go-to guy for fixing problems because he knows a lot of things that other characters don’t. Brent is a hero.

Here are a few characteristics of a hero in software engineering:

  1. They hold a large amount of institutional know-how in their head.
  2. When an outage happens, they are on the front line to fix it.
  3. They prefer to communicate through their code.
  4. If they leave the company, the project(s) they’re on will likely stall.
  5. They don’t take much time off (there’s no one to cover for them).

Management loves heroes for #2 and #5, but they’re often unaware of the downside of having a hero on their team. The net effect is negative for keeping a team happy and maintaining a sustainable pace. As engineers, we need to be able to explain this risk to management.

Heroes may see hoarding information as job security. Making management aware that heroism is hurting the team (and increasing risk) removes this incentive.

zero #

This is what a sustainable engineering process looks like:


When we encounter a new technology, we have to learn to use it. At this point we are a zero, a beginner. We do some tutorials, get comfortable and then start working on integration. By the time it’s in a production workflow, we (hopefully) know the relevant details. We are a hero. This is when a lot of engineers move onto their next task.

This is the problem. Now only we know how something works. Instead, we should focus on transitioning back to a zero. We take the time to show a teammate how something we did works and the considerations and assumptions we made along the way.

Here are a few battle-tested ways to facilitate the hero -> zero transition:

“That sounds nice”, you say. “But my boss would never go for it. It takes too much time.” You’re right, it does take time. But your boss will go for it, if you can align your request to his/her interests.

Frame your conversation re: heroism to the needs of your audience and you’ll have a better chance of affecting the change you want.

conclusion #

Avoiding heroism is not a call for mediocrity. You can be excellent at your job without being a hero. Share what you know; help your teammates be excellent at their jobs too. They will respond in kind. By transitioning back to zero, you are actually providing more value to those around you and the organization you work for.

Thanks to Jennifer Davis (@sigje) for her talk “From Hero to Zero” at DevOpsDays Boston 2014. It was the inspiration for this post.


Now read this

Writing for Software Engineers: A Primer

READMEs. User manuals. Operation guides. Handbooks. Command-line help. Internal chat. Company blogs. As software engineers, we write often, and in many different contexts. The code we write often doesn’t provide value without some sort... Continue →