Empowering Teams Through Learning
Think about the last time you picked up a new skill. Were you amazing at it right away? Or did you make many mistakes, learn from each one, and tweak what you were doing to improve?
It was probably the second one. Learning anything new means trying it out, messing up, figuring out why, and trying again. Most of the time, things don’t work out on the first go. And that’s totally fine because that’s how we learn and grow.
The Importance of the Feedback Loop
This trial-and-error process is super important for developing any skill, even if you’ve been doing it for years. When people stop learning from their mistakes, their skills stop improving. This is especially true for software developers.
When developers make many mistakes and learn a lot, they often get promoted to leadership roles. These roles could be in management or still involve coding but with added leadership responsibilities.
Creating a Culture of Learning
So, what do we developers do when we step into these roles? We create processes to minimise others’ mistakes. We try to catch every mistake in code reviews and suggest design decisions to avoid past errors.
But here’s the thing—we end up holding back our teams from learning. Trying to prevent every mistake makes our team dependent on us. They stop learning and rely on our experience. This can lead to a “hero culture” where one person is seen as the only one who can save the day.
Encouraging Independent Decision Making
You might think, “But they’re learning from your decisions!” Sure, to some extent. But no two decisions are precisely the same. How often have you criticised a manager for making a decision because “it worked for them years ago”?
Knowing the outcome of a decision isn’t the same as learning. There’s so much more involved—considering all the alternatives, practising creativity, and living with the consequences of a decision. People tend to understand decisions better when dealing with the outcomes themselves.
Empowering Teams to Make Mistakes
I focus a lot on ensuring my team can make decisions even when I’m not around. The key to this is giving them the freedom to make mistakes.
There are many ways to do this. For example, I ask questions during code reviews instead of making demands. Have you considered X? What happens if we face situation Y? Why is this approach better than this alternative? The code review gets approved if the developer can justify their decisions well. It doesn’t matter if it’s different from how I would do it or if the error message could be better. What matters is if the developer is proud to own their code.
Balancing Risk and Learning
Of course, some mistakes have significant consequences and can’t be allowed. Code that would corrupt data or cause production outages is a no-go. But most mistakes are minor.
Beyond code reviews, the people writing the code should also handle the initial design and architecture for a project. These decisions are more impactful than any that come up during code review. Making these decisions requires understanding the full context of the project, which helps developers write better code and handle issues on their own.
Early Review and Contextual Decision Making
Reviewing these decisions during code review is too late. They need to be reviewed early on. The same principle applies—ask questions instead of making demands. Help developers gain the context they need to make good decisions. Consider the consequences if you think they’re about to make a mistake.
Will it create a large technical debt that will trouble the team for years?
That’s a significant consequence, and mistakes should be prevented.
Will it add a few days of extra work when they realise an approach won’t work?
That’s a minor consequence. I’ve let this happen many times. The result is always a short-term hit to productivity in exchange for a huge learning opportunity, leading to long-term productivity gains. Developers learn in a few days what would take months or years of nagging to achieve.
Final Words
People who talk about investing in their team usually mean training courses, one-on-one discussions, or time to work on personal projects. These are all important, but they aren’t enough. The best investment you can make in your team is giving them the freedom to make decisions and learn from real experiences in real projects. This way, they grow more confident and capable, and the whole team benefits from their growth.
Article by Dave Fuller
Related posts
Why We Sometimes Make Coding Harder (and How to Stop)
Let’s be honest—software development is complicated. It’s just the nature of the job. Bugs pop
Learning from Failing Fast
“Fail fast” is a phrase that gets tossed around often—and for good reason. In many sit
Microservices or Monolith? Why One Size Doesn’t Fit All in Software Development
Following the recommended methods and techniques may seem like common sense to many. It’s only