Photo from unsplash
The Freedom to Make Mistakes
July 28, 2020
One of the most important parts of my job overseeing a software development team is to keep them productive and communicative. Projects run more smoothly when the lines of dialogue are open and honest, and people are happier when they feel heard. And one of the key ways I've found to keep that openness and honesty is what I call the freedom to make mistakes.
As I've interviewed people for jobs, or welcomed them on board, I've found something that I've experienced myself: fear of punishment for being imperfect. A lot of developers I've interviewed and worked with have come from cultures of micromanagement and an approach that expects perfection in everything they do. The freedom to make mistakes doesn't work with micromanagement, and shows that I expect and embrace imperfection.
I'd even argue that it helps prevent mistakes.
Key Tenets
The X Musketeers
No two developers have the exact same skillset or interests. But when a mistake is made, it's all for one, one for all. Everyone who can help fix it helps. Everyone who can't help does what they can to back up the rest of the team.
The Buck... Doesn't Exist
When a mistake is made, it's much more important to fix it than it is to try to place blame. Once it's fixed, it's much more important to find the process that failed than the person. Did someone overlook something in a code review? Was there a simple misunderstanding of the code? If someone is at fault, turn it into a way to learn and grow.
Mistakes are Part of the Process
Show me 100% bug-free code, and I'll show you code that doesn't do much. Standard software practices add a lot of layers to help catch mistakes: code reviews, QA testing, unit tests. That helps catch most mistakes, and they'll often find things that the developer didn't think about. That's why they're there. And even with all those layers in place, bugs will make it to production. That's where the Musketeer culture comes in: we find it, we patch it, we succeed.
Confidential Communication
Particularly with more junior developers, it's important to keep an honest but confidential line of communication. I want my developers to come to me when they need help, whether it's a question about what they're working on or a realization that a major bug made it to production. I want them to know that I'll help them, or find someone who can, and that honest mistakes are part of the process and won't be punished.
I also have a dedicated, private chat channel that has all of the developers on the team, and only the developers. With the Musketeer culture in place, the channel itself becomes an honest, open dialogue, and the mutual respect that the culture helps foster keeps that dialogue very respectful and responsible.
What Does This Buy Us?
The freedom to make mistakes opens up communication. Big time. Not having the fear of appearing imperfect means that people will ask questions, even seemingly dumb ones, in a quest to improve. Developers are happy to be rubber ducks for each other. It's easier to give and receive constructive criticism because everybody wants to improve.
It promotes self-organizing teams. When something goes wrong, the open lines of communication empower everybody to fill in where they can, and not necessarily rely on any one person. This is especially important when members take time off, so others can step in and handle the load. Well-organized teams can even handle issues when the leader is away (as happened to me shortly after I first published this article).
It helps with measured experimentation. It means someone can try something they've never done before. If it fails, they can get help fixing it. If it succeeds, they can show it off and help everybody learn from it.
And, while it's a little harder to measure, I think it helps improve code quality. The culture adds some thought process around the development process that another part of the code might not work quite right. It helps improve thoughtfulness around handling imperfect data from imperfect code.
---
Updated August 4 with the benefit of self-organizing teams. It happened to me: