The Tricky Business
Leading developers is a tricky business. No. It is the trickiest business. And if you happen to find yourself involved in one such position, then this post is definitely for you. For starters, there is a great irony in the world of management. It goes something like this:
“The up you go, the less control you have.” Or what Spiderman’s dad would have said in this case: “With great power, comes great influence BUT diminished control”
It’s very true. Just because you’re in charge, that does not mean you’re in control. When you are a coder, you can get the compiler to do exactly what you wish. But when you become a manager, you can only hope that your developer will understand you and then pray to God in Heaven that he will a) do it correctly and b) do it on time. If you are a dev-turned-manager, it might be difficult for you to let go of the classic urge to do everything yourself to ensure it is done right. In such a position, while reviewing a dev’s work, you may even fail to distinguish between “that’s wrong and it needs to be refactored/rewritten” and “that’s not how I would have gone about it.” But you need to stop, step back and breathe. Let your junior devs flex their wings and give your senior devs some space to fly. Learn how to train your dragons correctly.
Then there will be engineering managers from non-engineering background and if you are one, you have even less control. That’s probably because you won’t have an in depth understanding of development hazards and processes. However, you will have the ability to divorce yourself from the illusion of control and rather think like an end-user or a client – which is very very valuable. For this reason, you can actually prove a better manager especially because you’ll be humble enough to think of yourself as a navigator of a ship with a crew, instead of a commander of an army.
That being said, a manager’s primary job is to bring out productivity in people. A great way to do that is to do the work that is getting in their way. Sorry but basically, whatever work is hated the most, shall become your work. Devs dislike documentation? You might have to do it. Few devs will show enthusiasm to write tests. Scoop that up too; you just have to get the ball rolling. If you are not a coder, you could learn enough to write a test. But I am a coder! Great, then build a test harness and add to it. And if you think that QA is not part of your JD; ha! You’re mistaken.
Now coming to the people’s problem. Your human resources can have competent capabilities but what even they can’t quit is being a human after all. A human who will screw up, flake, make mistakes, disappear, reappear, pester you, quit, lose faith in you, ignore you or simply go slow. But since you are a manager, their mistakes are your mistakes and it’s a good idea to get used to, well, this idea. You can work on developing a sixth sense that will anticipate people problems and have contingency plans just in case. And if you can get your resources to trust you, you will see how easily it will become to trust them in return.
In the bigger picture, managers translate the project into tasks for developers with details at every end. They also translate what the devs have done so that the users/clients could understand it. As a manager it is your job to understand the work more intimately in order to be able to break it down so that others can make sense out of it.
Okay, but what about credit? Nada. N/A. You won’t get the glory of writing the book. In this tricky business, the commendation will go to the clients for the wonderful creation or the devs for the code. Like someone once aptly put it; nobody sees a beautiful baby and praises the midwife.
Please remind me why I’ll still want to do this? Well, because even though your devs will have more control, you still have far more influence. As unpraised and un-celebrated as you may feel, the decisions you make and the shots you call will ultimately determine whether what your team is building ends up being great or bad. But if that is something you can’t relate to, you might be in the wrong field.