Hands on manager

When I was new to the software industry, I always used to wonder why managers/leads just delegate and ask for status updates instead of being hands on. This article is dedicated to the young novice naive me.

Let us take a hypothetical manager in an organization who has taken upon himself to deliver a feature. The feature has a tight deadline of tomorrow. He is furiously working on it today and suddenly the CS(customer support) person calls him and up and says there is this issue a lot of customers are reporting which needs an immediate resolution. Now, this dude has no other option than to discontinue the task he is currently working on, look at the CS issue, figure out who in his team can work on it, assign it to the appropriate person and let the CS in charge know that so and so is looking into it. Now with the CS issue at bay, he happily rolls up his sleeves and starts typing the next line of code when the product manager walks up to him and says, man, this feature that we released last week, the company board is asking for numbers, can we assign someone to work on it, I need those reports like yesterday. The manager furrows his eye brows, does a mental calculation of all the tasks going on, which can be de prioritized, who can be pulled out of their current work and be assigned to this adhoc task or should I say no to the product manager right now and bargain for some additional time. Ok, with that out of the way, he hopes at least now he can get back to his task and he is about to begin when a team member walks up to him and says we need to talk about this design trade off of using a new database table for this feature versus accommodating it in the existing scheme of things. By the time this is over, it is already mid afternoon and time to take stock of all the current tasks, clear road blocks, plan for future tasks etc. There goes the poor manager’s day and no progress on the task which he was supposed to deliver the next day.

Is the answer to this not doing any hands on work and just delegating? No, take on tasks which do not have a tight deadline, which are good to have but always keep getting pushed out due to some higher priority user facing or revenue generating features. For example, right now you do not have a scheme to version control your database changes, you are doing it through some ad hoc ant tasks. Database versioning is an awesome thing to have, but it is not needed like tomorrow and has no visible revenue/user impact, so it is ok if you plan to release it tomorrow but gets pushed out by a couple of days.

While choosing these sort of tasks, try to work on those that touch different components of the system, gives you a good mental model of the whole product, familiarizes you with the day to day issues faced by you team members, gives you a good understanding of the inner workings of the critical code paths in your product. If you do this, you have hit two birds with one stone, you are no longer just a delegator of tasks and to top it up, you have a very good understanding of your product and can empathize with the team.

Advertisements