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.

 

Let us take a hypothetical manager in an organization who has taken upon herself to deliver a feature. The feature deadline is tomorrow. She is furiously working on it today, and suddenly the customer support person calls him and says there is an issue that needs an immediate resolution. Now, this person has no other option than to discontinue the task she is currently working on, look at the problem, figure out who in her 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, she happily rolls up her sleeves and starts typing the next line of code when the product manager walks up to her and says – 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 her 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 pick 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, she hopes at least now she can get back to her task.

bethany-legg-75nbwHfDsnY-unsplash.jpg

She is about to begin when a team member walks up to her 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 she 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 that do not have a tight deadline, which is good to have but always keeps 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.

Photo by Bethany Legg on Unsplash