Let developers make changes you think are wrong

Being a technical leader you'll often have a vision of how a product (or a feature) should evolve, how the architecture should work or what conventions are most suited for it.

As the product matures, the codebase grows and more developers join the effort, there will be times when people diverge from your vision - whether by mistake or on purpose.

The natural inclination when someone comes with a proposal that contradicts that vision is to reject it, explain the vision and why the code is the way it is and send the developer on the right path.

I'd argue that in many cases, maybe even most, the natural inclination is the wrong one, instead of pushing back - let developers working on your code make changes you believe are wrong.

It's a hard thing to say, and it's an even harder thing to practice (I know it is for me), But I think it's something that is vital for the growth of both the codebase/product and the team/organization.

Why let developers make changes you disagree with

Here are the arguments for going against your instincts:

• We can be wrong. Sometimes we very confident when we're wrong. If you don't allow for the possibility that other people are right, you inherently tie your product to your own failings.

• Ownership is a key factor in the success of an engineering team. Part of owning a product or feature means the ability to decide, and every time you take away an engineer's agency on the product's code and architecture, the team's capability and engagement deteriorates.

• Diversity in thought and process contributes strongly to a products growth. When you hire talented and engaged people they need to be able to use their talents to their maximum.

• Failure is often the best teacher. There is only so an engineer can learn from advice. A lot of the hard lessons can only be learned by doing the wrong thing.

• If you don't let developers try and stumble when you are around, they'll fail on critical stuff when you aren't.

The 3 tests for diverging from the vision

I have 3 simple guidelines to determine if I should hold my ground on a change or let an engineer do something I disagree with:

1. Trust - The engineer is someone I trust - usually that means she has experience with the product, is doing something that she thinks will benefit the product/company and has generally made good decisions in the past.

2. Facts - We agree on the facts, or at least most of them - the implications of the change, the size of the task and the tradeoffs we take by doing it.
   What we can disagree on is the weight we give different tradeoffs and predictions on the future.

3. Impact - The change is not too hard to reverse. Often means reducing the scope of a change, or changing it work to be iterative instead of transformative.

If those 3 tests hold true, I'll probably try and convince them. But in the end it's their choice to make, and I'll support them even if I disagree.