One of the hardest tasks I have as a manager is empowering developers to make their own decisions. I like to think I do it pretty well, but I know way too much about a lot of applications. Sometimes I find myself defining how something should be done instead of just what should be done. For developers turned managers, I imagine you might feel the same way. What it really boils down to is understanding when to step in and when not to.
Stay out of application design meetings. Most managers that have been in an organization for a while have a good idea how something should be done. This doesn’t always mean they need to express it to their developers though. Staying out of these meetings allows leaders to step forward and drive the conversation. With a more senior person in the room, they may stay silent. Most good teams will leave a design meeting with an awesome plan and a list of questions for me anyways.
Steer developers away from pitfalls. In the above, I mentioned staying out of design meetings. It doesn’t mean you should be ignorant to the design of an application or feature. Get someone on the team to give you a summary, and recognize any concerns you have. You shouldn’t let developers do something that you know has a high chance of failing because you have experienced it. Plus, you are a domain expert, your guidance may shine light on something they didn’t think about. The important thing about giving feedback is it is after they have an idea of how to do something. Then, you are not defining the how but the what if.
Influence through teaching. Good code has certain traits. Easily testable. Decoupled. Inversion of control. Etc etc. Instead of defining how they apply to a given scenario, teach developers why they are important. It is one thing to explain inversion of control and dependency injection containers, it is another to define a class diagram for a given feature. Let them figure the latter out on their own.
Let them go out on a limb, every now and again. Management has a lot to do with trust. Once you trust a team, it is alright to let them go out on a limb every now and again and do something you aren’t 100% comfortable with. As I get further from day-to-day development, this happens more often. It is a good thing actually. I don’t know the specifics of certain technologies my teams are using anymore, but I have teams embracing them. Letting them do it is a huge step away from the how and into the what.
Managers that define the how prevent leaders from stepping up. For a team to feel ownership of an application, they must be empowered to make decisions about that application. This really starts by helping define the outcome and not the steps to get there.