How to avoid having a higher total effort after delegating tasks to the team

Question

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:

1. Find the right table in the DB schema and in the UI.
2. Add a column to the DB schema.
3. List the column in the set of columns to be displayed in the UI.
4. 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?

Answer 1

What can I do to arrive at a state where I feel delegating tasks actually takes away workload from myself?

You have to let go.

To expand a bit, so far you seem to have taken the reins quite firmly (likely because stuff wasn't done etc), and that has resulted in extreme drain on your time. It may well have been the right call, but also as you've noticed it's not sustainable. What's worse is that now this is also making it very hard to show whether the employees are fit for the job or not.

What that means in practice is that you start treating those employees like the senior engineers they are supposed to be. You give them a task, have whatever kickoff you have do, make sure they understand the task, make sure they understand expected outcome and then you leave them alone until it's done.

They are welcome to reach out, ask questions, but you should be slow to respond, at least some of the time. You need to give them the freedom to resolve their own problems, in their own way, rather than giving them a solution you expect to deliver as ultimately you don't want to architect the solution for senior developer, that's extremely counter productive.

Once they are done, pull out your notes, compare what was discussed as deliverable, and what they delivered, and take action from there. If it's done, and it's working - great. If it's not, it goes back to being worked on BY THAT PERSON until it is done. All you do is note down the outcomes.

Take an employee through that ringer few times and they will either start delivering, or you will have plenty of evidence that they are unfit for the job that you can take "upstairs" and have it acted upon.

Or in paraphrase of a Russian proverb: You have to Trust them to do the work, but Verify the outcomes and hold them accountable.

Answer 2

One thing you should consider is to treat the team as a team, not as a pool of unrelated developers.

Building the necessary knowledge to implement requirements may be more effective when they discuss their understanding of the requirement and occasionally pair for a solution. Pairing can help to overcome mental blockers, and it immensely helps to share knowledge among the team members. As a senior developer, you may offer to assist in learning, but this should be limited to a small fraction of your time.

The specific mechanism to assign tasks to the team may vary, agile techniques emphasize self-organizing team structures, but assigning tasks to individuals may also work when you know the developers and their strengths/weaknesses. Just avoid to micromanage them, everybody hates that :-)

Answer 3

A lot of applicable answers, but I want to add one more viewpoint.

You can't compare the 2 hours you would have spent to complete the task and the 3 hours spent after delegating it. Here's why.

In case one, you would have spent 2 hours of effort and completed a task.
In the other case, you had 3 hours of effort, completed a task, and trained a team member. In other words, you spent more effort, but you made an investment.

I see three main components to your "effort"

1. Delegation: Explaining the task, expected outcomes, hints
2. Training: You handheld a lot
3. Verification: You confirmed the result. The first time had bugs, the second time they got it right. That's not uncommon.

Effort for ① and ③ will be reduced as you get better at delegating clearly. There was no mention of it, so i apologize if you already did/do this, but I would suggest giving test cases and expected outcomes when possible at the time of delegation. ("expected outcomes")
In this sense, Test-Driven-Development is great for clearly delegating.

There are multiple approaches for ②.

• Delegate the training. Recommend an adviser within your team or organization with whom the other engineer can ask for help
• Intentionally invest more time in training. If the member is expected to stick around (not a short-term contract employee, etc) then intentional training now means less need in the future.
  • You probably could have invited the other engineer to pair-program with you and knocked the task out in a 3 hour training session that would have a) resulted in faster delivery and b) skilled-up the other engineer. This skill up likely isn't as much growth as letting them flounder for a while (learn by doing and exploring!), but doing this kind of session occasionally is a great way to pass off coding standards/styles, recommended programming patterns and other internal knowledge.

Answer 4

Clarify roles and responsibilities with your boss

"Team lead" + "manager" is an in my opinion awkward construct since it's unclear who is on the hook for what.

Have an an open talk with your boss and discuss:

1. Who is doing performance review and management ?
2. Who owns onboarding, coaching, training, mentoring, etc.?
3. Who sets goals and metrics for the employees? How are they tracked?
4. Who assigns resources ?
5. Who scopes projects and required resources before committing the team?

Push back on "both" or "shared". That's just another word for "no one".

It sounds that your team is not performing to your expectations That's a classic performance management issue and whoever is in charge of performance management needs to address that. Training and onboarding takes time and effort. Whoever scopes the work and manages the total workload needs to include this into their budget (both training and current skill level).

Answer 5

This seems like a pretty clear example of needing to let go and expect them to be able to accomplish their work themselves, however...

You as a team lead do, I think, have an obligation to ensure that they are being conscientious - and the subtext of your question seems to agree. A lack of problem-solving ability such that you have described often goes hand-in-hand with laziness, and reading between the lines I suspect you are concerned about this as well. Do you implement a pull request workflow with code review? I'd suggest that your point for assessing the quality of their work is there, and you are perfectly within your rights to reject work that isn't done correctly. This also gives you a metric for where your teammates are not listening to your instructions, where you have to reject the same mistake more than once.

You may also be concerned that you will be held responsible for their low productivity. Hopefully your manager and stakeholders are reasonable, but hope is no guarantee. Being able to explain that you are aware of the issue and have a strategy where you intentionally avoid hand-holding them so that they learn to solve problems themselves would seem to me to be a reasonable answer.

Answer 6

While the example maybe is a bit contrived, it is given as a standard task. Standard tasks should have standard solutions in your codebase. If the junior is not introduced to those standard solutions, you will repeat the development process for those for each developer at least once. Your 2 hour estimate assumes this default process that is unknown to the junior. It is easy to forget, how long this originally took to debug and fix (the timezone part could've been mentioned to the developer, or point them to a similar location in the application)

So a solution for some of these problems is to preemptively create templates / approaches for such tasks, so that developers do not start from scratch all the time. That way they do not need to make and fix the same mistakes multiple times. This has the added benefit of leading to a more unified code style (copy+paste does have advantages sometimes).

As soon as those tasks have their standardized solutions, you can delegate more (of course, a final code review and test are advised). Furthermore, if there is a default approach, you can also delegate the support to another junior developer who went through the gauntlet already.

Answer 7

I faced the exact same problem once. The application we're developing is date/time sensitive and there is lots of date/time handling involved. The junior developers assigned to me had zero experience in that field and I knew that merely "knowing" all the date functions was not going to be enough.

So I spent at least one week teaching them about the business logic and the intricacies of dates (inclusive vs exclusive end date, checking if date ranges overlap, timezone basics, daylight saving time and leap year related issues, etc). They did not work on the date/time related functions of the application until they finished the "crash course". They caught up quickly and I estimated that it saved me at least 4 weeks of unnecessary involvement afterwards.

That being said, I think you underestimated the complexity of the problem, for the inexperienced programmer.

Answer 8

You answered the question yourself - "improve our training"

This IS training. Now if the same developer is stumbling over this again and again after you've gone through the exercise once, that's a whole other issue. But other than that, you can have a high expectation that the next time around, you don't have to be as involved.

I'm a former Boy Scout and Boy Scout leader. As leaders, we're prescribed what's called the EDGE method:

• Explain - what's the goal, how will it work?
• Demonstrate - point out necessary tools, resources, tables, web services. Make sure your employee takes notes.
• Guide - Let the employee go do some work, and meet back with you at certain milestones
• Enable - When you feel confident that your guidance is working, let go!

You are way too busy trying to bottom-line the employee's progress as if it were your own. That's not how people learn, friend. You'll just continue to frustrate yourself, and likely your reports, if you continue in the same mindset.

More on EDGE.

Answer 9

Hire a senior developer

It sounds like you’re the only senior dev on a team of junior developers which means you have to both lead and mentor/coach which sounds like it’s spreading you too thin. The solution is to hire (or request if you don’t have hiring authority) at least one additional senior dev for your team and then delegate some of your coaching and mentorship duties to them so you can focus on your leadership tasks. Make sure you get a competent senior dev who’s skilled at mentoring/coaching—you’re looking for demonstrated skills and experience, not just years of experience on a resume.

Don’t make estimates for others

Also don’t make estimates for others. It’s not realistic to assume you know how long a task will take them. Ask them to make their own estimates. This is also much better for moral which will help your team perform better in the long run.

Let people learn to learn

Finally when coaching, let the coachee struggle a little. Make them spend some time learning the codebase. Make them spend some time Googling possible solutions. Don’t take this too far of course, but if you always give them everything they need to solve their problem, you’re depriving them of the opportunity to learn to learn, to learn the codebase, and to learn autonomy.

Answer 10

Many great answers here already; I just wanted to add a note on test automation. In the example you're giving, a lot of the back-and-forth is around manual testing. As mentioned by other answers, if you hand developers clear requirement they should be able to figure it out.

Automated tests (at the unit or higher level) are a good way to make requirements explicit. You could develop more of a test-driven development approach where the developer that was given the task will first have to write tests for it, which you can review. Once the tests are comprehensive enough, their job is basically to get them to pass.

Even if you don't do TDD, tests are a very good way to iterate fast on a PR – I'll usually start by looking at the tests, and if they don't cover enough then I'll comment about that without looking at the PR.

Answer 11

What can I do to arrive at a state where I feel delegating tasks actually takes away workload from myself?

Probably nothing, in your circumstances.

Unfortunately delegation in software is an extremely expensive strategy.

Developers typically rely on a deep understanding, not just of general programming principles, but of the business itself, specialist domains of knowledge which apply to business problems, and of the codebase which has been devised to handle those problems.

In development, there is typically no relationship between the time taken to execute a task and the expertise required to execute it. Long-winded tasks may be conceptually quite simple and elongated only by a repetitive element. Meanwhile, tasks that take an experienced developer 5 minutes may draw on a massive capital of understanding built over years of involvement.

That said, two hours is an extremely short time in typical development. To delegate, there are overheads of communication and coordination. You would only delegate a two hour task if either the assistant had done the task before and clearly knew how to execute it on a simple command, or if the same task would occur so frequently in future that it was worth introducing the assistant to it.

You wouldn't delegate a two hour task, if the assistant knew little or nothing of the task, and if the agenda was to try and spare your own time and effort at that very moment.

I wouldn't assume a developer could find a table in a database and a matching screen in a front-end, unless there was a clear system for navigating and they had already demonstrated a proficiency in doing so.

If there isn't yet a demonstrated proficiency in that navigation, then certainly you're about to embark on a training session which will consume your time and effort, not a delegation saving your time and effort.

It's a mistake to simply expect to "delegate" where others are told a problem in general terms and expected figure things out for themselves with an extremely complicated existing codebase. That's not a proven approach.