I've written before on the problems of hero culture. It is still my favorite post that I've written because it hits so close to home for me.
Every situation in that post is hypothetical, but based on a real situation I had to deal with myself.
Unfortunately, that post is very light on the solution, despite the claim of it being easy. That's because most of my experience at the time was in the suffering, not in the prevention.
I still think the tactics I listed are important, but they're not enough.
It's been a few years. I'm a little older. Hopefully a little wiser. That time comes with some new insights.
The most impactful one is going to be investing in your team. My last post mentioned pairing someone up with a hero so that they can learn. That's still important, but insufficient.
Most people don't learn by watching. Humans learn by doing.
And in the case of software development, "doing" isn't just writing code. "Doing" involves all the decisions made around that code.
That means you shouldn't have a senior or lead dev design a system and have another developer implement it. The person working on the code gets to make the decisions.
And I mean really make them. Not: allowed to make them in the beginning only to have it reversed in code review.
Making the decisions gives people ownership of what they're building. It's a little terrifying because there's no one to blame if something goes wrong. But it is also invigorating because ownership gets people to think more intently on the problem at hand.
It also changes the frame of thinking from "is this what my lead wanted?" to "is this actually going to work well?" The former is a line of thinking that creates a dependency on certain people on the team. The latter line of thinking is what developers need to learn.
That learning comes with a whole host of positive side effects.
You're not reliant on a couple of people to catch every possible issue in code reviews. Everyone is capable of maintaining quality. This reduces the frequency where you're going to see a crisis with your systems.
You also now have a team with a stronger understanding of the systems in place. That understanding empowers everyone on the team to investigate issues when they arise, preventing a reliance on heroes when a crisis appears.
You also have a team where everyone feel like they're contributing and that they're growing as developers. This usually helps with retention, and who isn't worried about retaining developers these days?
The primary challenge with letting everyone making decisions is going to be: what if they make a bad decision?
There are many ways to address this. First off, just because you are letting someone make the final decision does not mean they shouldn't get feedback. The feedback just shouldn't be in the form of "you need to change this to X because my experience says it is the best way." The feedback should be more in the form of "How do you handle situation X? I've seen that trip us up a couple of times."
Let the developer come up with the answer to the question. Let them ask for suggestions if they need it.
There of course will be a situation where they will pick something you think is sub-optimal. You won't find a way to provide constructive feedback in a way that gets them to pick what you think is the best solution.
This is going to be the hardest part. The important question to ask is: what are the stakes of letting them implement their solution versus forcing them to use what you think is best?
What is the worst case scenario if every bad thing you can think of comes to pass?
You'll find that most of the time, it won't be that bad. And your developers will learn quite a bit from the experience. You'll see the dividends from that learning a lot sooner and see them be a lot bigger than you think.
It certainly isn't easy to do. It requires letting go. People usually have trouble letting things go, especially if they know a better way of doing something.
But the alternative is to start the slow downward spiral to hero culture. That will certainly be harder to deal with in the long run.
Top comments (0)