I’ve often insisted that project managers should write code and lead from the front. As you dive in, roll your sleeves and fight the battle hand in hand with your team it is equally important for you to consider them as comrades and not mere soldiers ready to charge or strike at your command.
When engineers, sometimes even smart and able ones, come to you expecting you to take their decisions for them it is often very tempting to take a decision and establish your ‘seniority’. The more you do it, the stronger you feel about your role in the organization and the dependence of your team on you. After all, it makes you feel wanted and it makes you feel in control. A whole lot of managers I’ve seen in multiple organizations around the world enjoy their involvement in any decision that happens in the project. Do you, dear reader, love being in charge of the driving wheel in your project or organization?
If you answered yes to that question with knitted brows wondering what’s so wrong with your being in-charge and in-control of your project, what you may not realize however, is that you might be, silently introducing the culture of mitigated speech in your organization.
Joel Spolsky describes how he himself, failing to give up the driving wheel on the right time and giving a careless tacit approval for a feature to be built in the product, nudged his team to start working on the feature without giving a lot of thought on whether the feature should have been actually built in the first place. He ends his post with a resolution to the problem that takes a lot of conviction on the part of the manager. His suggested recommendation is simple:
|
The solution, of course, is what I’ve been saying all along. STOP FRIGGIN’ LISTENING TO ME. I don’t know what I’m talking about. If you work for me, you’re welcome to get my advice, but you have to make your own decision because chances are you’ve thought MUCH MORE about the issue than I have and in fact we probably hired you because you’re smarter than I am. |
The idea of lending control to your team members might sound a little absurd and often makes young, budding and even the most veteran leaders just-a-little insecure at first but is has a lot of obvious advantages:
- It frees you up to take bigger and better challenges.
- It enables your team to make smart and honest decisions.
- It helps avoid the perils of mitigated speech.
Malcolm Gladwell, in his latest book, Outliers, describes how important handing over the driving wheel to juniors in your team is when he talks about the perils of mitigated speech. He explains:
| Mitigation explains one of the great anomalies of plane crashes. In commercial airlines, captains and first officers split the flying duties equally. But historically, crashes have been far more likely to happen when the captain is in the “flying seat”. At first that seems to make no sense, since the captain is almost always the pilot with the most experience. But think about Air Florida crash. If the first office had been the captain, would he have hinted three times? No, he would have commanded – and the plane wouldn’t have crashed. Planes are safer when the least experienced pilot is flying, because it means that the second pilot isn’t going to be afraid to speak up. |
The next time someone walks up to you with a Should-We-Build-This-Feature or for that matter any question, take him to a whiteboard and turn the table on him by triggering a I-am-not-sure-lets-see-what-you-think brain-storming-session. Discuss the pros and the cons, give recommendations, provide suggestions but make sure that it is not you who is making the final decision. It is your team that has to learn to do that in the long run.
Long story short, unless you are heading for a crash, lead from the front, inspire the team, enable them, take sizable development tasks on your project, but don’t always take control of the driver’s wheel, specially when it comes to taking decisions.
If you want to lead, find lots of kickass programmers and one man armies who are capable of driving projects to successful ends. Mentor them and then leave the driving while in their safe and able hands. You can’t be driving multiple cars at once anyways.
Don’t handhold individuals on their way to success. Empower them to have their own share of mistakes and their own share of failures as they slowly attain success without any handholding. If you’ve picked a kickass team, got them to flock well in the right culture, and mentored them genuinely, they will take control, ownership, responsibility and start driving your projects towards success faster than you can think. Go ahead, lead from the front; but remember; you don’t always have to be at the driver’s wheel, taking every single decision in your project, in order to do that.
Comments are closed.