Hands On Manager

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

icons8-team-1221959-unsplash.jpg

Let us take a hypothetical manager in an organization who has taken upon himself to deliver a feature. The feature deadline is tomorrow. He is furiously working on it today, and suddenly the customer support person calls him and says there is an issue 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 problem, figure out who in his team can work on it, assign it to the appropriate person and let the customer support in charge know that so and so is looking into it. Now with the 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 the reports like yesterday. The manager furrows his eyebrows, 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 work on this ad-hoc task or should I say no to the product manager right now and bargain for some additional time. With that out of the way, he hopes at least now he can get back to his task. 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 roadblocks and plan for the future. There goes the poor manager’s day and no progress on the feature 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 feature. For example, right now you do not have the means to version control your database changes, you are doing it through some ad hoc ant tasks. Database versioning is an excellent 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 your team members, gives you a good understanding of the inner workings of the critical code paths in the 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 an excellent understanding of your product and can empathize with the team.

Image from  Icons8 team