In theory, the idea behind having a team of people to do something is that I can delegate some tasks to the team rather than doing everything myself.
I work in software development and I regularly face the situation where I end up wondering whether I should have done the task myself after all. Let me illustrate this with a recent example:
My team gets assigned a task. It is seemingly straightforward - add a new column of type date to a specific table and show it in the UI.
The concrete steps are:
- Find the right table in the DB schema and in the UI.
- Add a column to the DB schema.
- List the column in the set of columns to be displayed in the UI.
- Check whether the column shows up and values are correctly displayed/saved.
I estimate this should take me at most two hours.
Two hours are two hours; we have many of these tasks, and I do not have an endless supply of two hour-blocks and lots of more complex tasks. I am supposed to delegate this kind of task to my five team members. Therefore, I assign the ticket to developer A.
Given that developer A is less experienced than I both in development and in the (huge) application we work in, I estimate they will take up to 8 hours (i.e. one day) for this task.
Note that as of here, a non-zero amount of time passes between each paragraph. Thus, I have to switch back my "mental context" to the task again with each new paragraph.
A asks me what to do as the requirements are not clear to them. I write down the path to the table in the UI, as well as the DB table name, after finding both of them (basically, doing step 1 for them). This takes me 20 minutes.
A asks for a call/screenshare to verify. We do so, discussing the context of the table. This takes another 20 minutes.
A reports they have modified the DB schema. Due to our process, I need to verify the schema change, which takes 10 minutes.
A reports they have integrated the new column in the UI, but when saving, the date is shifted by one day. I suggest to analyze this in the debugger and check at what point the value changes between client and server. This, along with all explanations, takes 15 minutes.
A reports they have found the time component on the datetime value to be "wrong" and request a call to demonstrate this. During the call, it becomes apparent the value arriving on the client is a date time value that is shifted forward by just the amount of time that A's timezone is shifted (Eastward) from UTC. I ask A to consider that and make sure the timezones are correctly applied/ignored on both client and server. This call takes 30 minutes.
A reports they have now solved it and ask for a call to show the final result. During the call, they show how they are adding a fixed amount of time back onto the time (i.e. just their local difference to UTC). A insists this works (because it has worked in all tests A conducted locally) and that there is no other solution. I ask A to connect to co-workers in other timezones, preferably further East of A. A asks me to suggest a contact as A does not know any of those co-workers. I pick a colleague B and announce A's call to them. In all, this has taken 45 minutes.
A reports they have checked with B. The time component is indeed different on B's machine. A asks me what to do next. I explain to check for ways to convert between UTC and local time and make sure this is used consistently. Upon request, I help A find the relevant methods in the documentation. This takes another 30 minutes.
A reports that they have solved the task. The solution are two calls on the incoming/outgoing value to make sure the timezones are consistently handled. This takes another 10 minutes.
At this point, I have spent 180 minutes (i.e. 3 hours) on the task, A has spent a total of two days, and in all, almost two weeks have passed. Also, I am left with a solution that I still have to verify because - thinking back to A's first "final solution" - I do not quite trust A's ability to reliably verify this on their own.
A is not one particular team member. I have gone through situations like the above multiple times with most of my team members, and even with virtually everyone in an additional team assigned specifically to reduce our workload.
Also, I do occasionally perform such small tasks myself and I am usually done with them within 30 to 60 minutes.
Now, I see several possible points of criticism:
- My effort estimate is off. Well possible. I am already applying a factor of 4 compared to what I think I would need for the task (and actually stay within such limits when I do such tasks myself). But that is a bit beside the point - even if it took a factor of 10 for A to finish the task, my gripe is that my own workload with the task did not decrease.
- Assign only larger tasks. If I picked larger tasks, my own estimated effort would be greater, and thus it would take longer to reach the threshold. Unfortunately, I have tried this a couple of times and it usually ends up like this:
- The explanation/meeting effort increases proportionally, and I essentially have to guide the developer until we're back to the level of granularity of the above task.
- The developer comes up with an (overly) complex solution that works almost, but not quite. Then, they ask me to help them solve that last bit, which means I have to spend much time understanding their solution to the point where I can adapt it. Sometimes, by this time, the solution has even become so complex that they do not understand it themselves anymore.
- Improve our documentation. A very valid point, as none of what I had to explain above was really documented. However, in other tasks where there was some documentation, developers typically wouldn't find it, either, and instead asked me to send them the relevant links.
- Improve our training. Valid, though I have a hard time defining what they need to be trained about.
What can I do to arrive at a state where I feel delegating tasks actually takes away workload from myself?