Heroic != Fearless
Heroic and Fearless
They seem almost the same but when it comes down to company culture these two words couldn’t be more different. There is only one teeny, tiny difference between companies that can keep the best & brightest and those that churn & burn them. It’s hidden between these two words.
I’m going to reference engineers in this post, but this really applies to any kind of individual contributor and their managers.
What are Heroes?
Now don’t get me wrong. If you shipped some stupid bug into production that keeps knocking out the database, you SHOULD have to stay up all night restarting it until you can get it fixed. But that is not the kind of situation I’m talking about here.
Heroes are the guys that build out entirely new services by themselves in under a week. They are the ones that stay up all night every time the network goes down to fix it. They are the ones, and the only ones, that can wield the arcane magic of the database migration on your precious app. They answer more tickets than anyone else. They never ask for help. No one has any idea how they do what they do. The code they write is as mysterious and unknowable as the far edges of our universe but it never fails to get the job done, at least for a while.
But when you need them, sometimes even before you realized you need them, there they are, seemingly giving everything to the cause of keeping this company online.
What’s the problem with Heroes?
Mainly, they are fucking with the metrics regarding the health and scalability of your company.
With their behavior, they are basically eating the red flags that should be making their way up the management structure to inform prioritization decisions. Oh, he wakes up in the middle of the night every night to restart the database to keep the whole application from going down? Yes, that’s awesome because the application didn’t die, but also, now no one deciding priorities necessarily knows that the database crashing is a problem that needs time and attention.
(Now, really GOOD management will have seen this kind of behavior before, know how it’s going to end, and log the red flag anyways. But since this post is mostly directed at your average full-of-20-somethings startup let’s not hold our breath for that…)
Heroes take systematic failures in the organization and/or codebase, and cover them up with their own behavior. Examples of these failures might be:
- unclear planning or priorities
- MF-spaghetti code
- no repeatable code review or deployment practices
- lack of proper stack monitoring
- poorly constructed apps with too many core dependencies
- or even lazy hiring practices.
It can be anything that consistently causes major, unforeseen clusterfucks in your organization. The toughest part is the problems themselves may not be consistent or correlated even though the cause is — not seeing the signs for where you were headed and dealing with things before they got out of control.
Why would anyone do this? At first, it’s usually for an actually heroic reason: during the early days of the company when there just wasn’t TIME yet to have invested in monitoring or structure, they didn’t want anyone else to have to deal with the pain and suffering of these failure. But the then that get corrupted into the line of reasoning where since they CAN deal with it, they think that they SHOULD deal with it, or they are just being selfish.
(If you are reading this, you are probably the type of person that cares deeply about your team and your company, and look me in the eyes and TELL ME you’ve never gone down this line of reasoning…)
The social apparatus of the organization kicks in on both sides to support this initially heroic behavior. There is the carrot coming in on one side: when you are the one repeatedly staying up all night to keep the system up or single-handedly writing the only major launch for this quarter, everybody starts calling you AMAZING — lauding your magical, ninja skills that no one can hold a candle to. And you want to believe that because it’s a nice thought to hold on to when you are fucking stressed and exhausted from powering this organization like a human battery pack.
On the other side comes the stick: Which is usually something along the lines of “People will think I’m being selfish if I ask for help”, or “It will be hard for my team to learn the things I’m doing and I don’t want to watch them deal with that difficulty”, or “Leadership will be so disappointed if we have to take time away from our big customer-facing feature to build a deployment process”, or a lot of times just the simple “I get the sense that my manager will think I failed if I somehow can’t keep up this inhuman level of effort forever…”
What do you want instead?
Ok, so if you’ve bought into my argument this far, we can all agree that heroes are a bad thing turning your codebase into a mine field under the guise of being your most awesome contributor.
But all those things that heroes get you — new products in at warp speed, your app never going down, bugs getting resolved uber fast — sound SOOOOO nice! Can you have those things without heroes?
Yes, by building a FEARLESS TEAM.
And for that you are going to have to make some COURAGEOUS decisions.
You’re a tech company, stop fighting with a sword and shield
What is the difference between Captain America and the real Marines? Captain America is the hero, and everybody else is just there to run around behind him, cover his back and give him someone to save. Nobody acts like Captain America in the Marines. They are a team. They are a unit. They move, work, think and fight together as one.
Being Captain America is a cool thought though, right? It feels nice! Who wouldn’t want to be that awesome?! But the workplace is not a movie set. It’s not a place for you to act out your fantasies using your coworkers as extras. If you really want to be a hero, stop being heroic and start being a leader. Courageously do the hard things. Make the hard decision to act like you are all human beings with limits, and then build an organization that leverages everything within those limits to the utmost.
Your goal should be that everyone on your team can approach any new feature, any deployment, and any critical bug or system failure just as fearlessly as your heroes. Because they know they have the knowledge, tools, and support to hit the ground running, and because their practice wielding them has convinced them they will be successful.
When your hero is around it can be very difficult to make that happen. Most heroes are heroes because they got addicted to the heroics during some previous difficulties the company went through.
That’s why I’m a big fan of making people take vacations. It’s like releasing Chaos Monkey on your people stack. It lets you know where your weaknesses are — where you forgot to install fail-overs, load-balancers and back-ups for your people. We understand all these tools we need to operate our tech stacks well, but people organizations work just the same way. You have to optimize those resources and the interactions between them just the same if you want to be able to scale.
And as a manager you’re going to look at your hero being out of the office for two weeks…and realize it’s going to suuuuuuuck. It’s going to be hard for your team to fill in the knowledge gaps and hit the deadlines you’re committed to in that timeframe. You’re going to like, have to work to keep your team’s head in the game and remind them why this is totally worth it even though it’s hard. You might even have to engage in like, some real people management those 2 weeks instead of just phoning it in with a meeting agenda and a powerpoint…
Yeah, it’s going to be hard. That’s why it takes courage to do it — to put yourself and your team through that test to see where your weaknesses are.
And then when your hero gets back, you don’t let them just go back to doing those things you found out you were missing. You make them teach everybody else how to do those things, and your create repeatable, scalable processes for doing those things, and monitoring for if and how you are doing those things.
And again, that can be tough. A lot of times heroes don’t want to be the teachers, or to build the repeatable systems. They really believe it will just be “easier for everyone” if they just keep doing it themselves. As a manager you are going to have to help them see the wider picture, and the future vision, and get them to buy into the idea of building a whole ninja-SWAT-guru-task force instead of just relying on them alone. Sometimes, you might even have to make the really difficult decision to remove them from the front lines for the long term. That’s a pretty rare exception though. Usually with good people management you can redirect that hero energy just as easily into growing your team or building things to enable them. You just have to celebrate those tasks as much as you used to celebrate their previous heroic successes.
And you are going to have to support your hero and the rest of your team in making that transition; it’s up to you to make sure that they feel as successful and validated as they did before, even though everyone will probably have to work “harder” for a while. The team has to believe the challenge is worth it — like boot camp that they’ll come out faster, stronger, BETTER devs on the other side.
NOW, you are building a real team.
NOW, you a building a resilient application and organization that can withstand the real chaos you’re going to have to make it through to be in that tiny 10% sliver of startups that don’t fail.
This post is dedicated to Trevor and Colton Schremmer. So proud of you!
