65

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?

23
  • 64
    From your description, it sounds like you've been given a bunch of junior developers to work with. Junior developers need handholding, but ideally by senior developers, not by the team lead. If you don't have any senior developers, this probably isn't a problem you can fix, your employer is trying to do things on the cheap. Oct 10, 2023 at 9:40
  • 6
    @PhilipKendall: One of the issues here is that the department that supplies some of these developers managed to convince our management they provide us with highly skilled technology experts. And I feel unable to verifiably counter that claim with just (lots of) anecdotal evidence, while systematically tracking this kind of detours like the above would require considerable amounts of my time (that I do not have). Oct 10, 2023 at 9:42
  • 4
    @O.R.Mapper what does that mean though? Team lead can be anything from "yeah guide them" to actually being functional manager with hiring and firing power.
    – Aida Paul
    Oct 10, 2023 at 9:58
  • 19
    If you don't ever let the juniors do the work, how will they improve from 8 hours to 2 hours?
    – cdkMoose
    Oct 10, 2023 at 17:10
  • 11
    Would you consider yourself conflict-averse? There comes a point where you need to get serious about low ability which your examples seem to show to me. I would consider that you could tell them to get off your back and do their work themselves after around step 3. There is no special expertise required to know how to research time zone conversion and implement it correctly.
    – Tom W
    Oct 10, 2023 at 19:25

11 Answers 11

79

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.

13
  • 11
    Bingo. This is what delegating has to mean. It may require that you spend time in advance breaking the problem down into pieces of appropriate size for the skills you have available and ordering them appropriately, but you cannot delegate responsibility without delegating authority. If you can't trust someone to complete the task with minimal guidance/review, that is not a task you should give them; break it down further or clarify it or assign it to someone else.
    – keshlam
    Oct 10, 2023 at 10:31
  • 3
    @O.R.Mapper is this first time when you are leading a team? No judgement, just getting that strong vibe. And yes, stuff may not get delivered in time, but from the sound of it - it already isn't, and doing their work for them is not going to address it at all. You have some systematic problem, either of incompetent teammates, or debatable leadership that doesn't set and enforce expectations right. In the example you brought, he is gone for 2 weeks, delivers a faulty solution (outcome what's expected is noted down) so they go back to coding for whatever time to fix it, again. And you note that.
    – Aida Paul
    Oct 10, 2023 at 13:16
  • 4
    @O.R.Mapper this is very basics of delegation and accountability. You cannot cover for your employees, you need to hold them accountable for the screwups. And you need to keep track record of what's going on, why is stuff delayed, and then relay it upstairs if you think the people you got are not fit for the job. If the upstairs want you to be responsible for delivery of the whole team, they will also have to listen to you when you tell them "the 5 people we have are incompetent and hinderance". That's how you get there, with proof, and show how you tackled it.
    – Aida Paul
    Oct 10, 2023 at 13:18
  • 2
    @O.R.Mapper I literally just keep employee.txt and put dated entires there of what we talked about. Works for over 20 years now just fine.
    – Aida Paul
    Oct 10, 2023 at 15:01
  • 4
    @O.R.Mapper My first boss in IT told me to call if I ever got stuck. For the first two weeks whenever I called him he would give me advice. After that, he simple said "I don't know" unless it wasn't a technical problem (e.g, he would answer billing concerns or things like that). That's full delegation. It's generally not a manager's job to also be a trainer. If you start training, that will be all you have time for. Oct 11, 2023 at 0:12
24

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 :-)

3
  • 1
    I'm already asking some of the team members to work together. The fact that there's a language gap in the middle of the team (with especially the least experienced team members being located off-shore and speaking a not-easy-to-understand variety of English, and the other team members speaking English as a foreign language without being confident about it) makes effective pairings a bit challenging sometimes. Oct 10, 2023 at 12:48
  • 1
    That's an additional difficulty in the team composition, and if you want the team to work effectively they will need to work on these stumbling blocks. Oct 10, 2023 at 12:57
  • 11
    And specifically, ask the team to do tasks such as verifying the work.
    – David R
    Oct 10, 2023 at 14:20
15

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.
8

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).

5
  • 1
    Good questions, and I think all of them are clearly (albeit possibly not optimally, but I can't really change this) defined at my workplace: 1 + 2) The team lead, for their team members. 3) The team lead analyzes the tasks assigned to the team as a whole, and splits them up to assign the individual subtasks to team members or subteams. The team lead then checks when and how the subtasks are done so they can ultimately report back the overarching tasks to the issuers of those tasks. 4) The team lead's boss with levels above them, in accordance with the team lead. 5) The team lead together ... Oct 10, 2023 at 13:01
  • 1
    ... with the responsible product managers, depending on the business domain topic. In this process, product management mainly defines the tasks/goals, whereas the team lead sketches up first rough solution ideas from the technical side and pushes back before any tasks are committed that are unfeasible, either due to limited team capacity or because they are technically impossible to solve. (All of this is not a special arrangement between myself and my boss, but is handled the same way for all teams in the project.) Oct 10, 2023 at 13:01
  • I'm curious--what part of the OP makes it seem like the team is not performing to OP's expectations? The question isn't about increasing the performance of the team members, it's about reducing the overhead of delegation.
    – Mars
    Oct 13, 2023 at 4:03
  • 1
    @Mars: I do think the former is the cause for the latter. The overhead is that large because the team is not performing to my expectations. Oct 26, 2023 at 22:22
  • @O.R.Mapper In that case, you need to identify the cause of the gap in expectations. Are they not technically skilled enough? Are the requirements not clear enough? Are there normal issues such as not being used to a codebase and/or team standards? 1 and 3 probably need more hands-on training and the second one probably means you could use more training in clearly expressing expectations (especially in a case with language barriers). One is "obvious" in one culture isn't in another, so it's important not to assume!
    – Mars
    Nov 8, 2023 at 4:56
8

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.

4
  • 2
    +1 -- Totally agreed when reading the OP, I thought they need to use standard pull-request-reviews, and not accept ad-hoc "let me show you what I've done" calls all day. Oct 11, 2023 at 1:17
  • "You may also be concerned that you will be held responsible for their low productivity." - no, I'm not really concerned about that. My superiors are very understanding of the fact that my team members cannot work autonomously, and therefore the team's productivity is on the low side. However, during the annual reviews and other conversations, an aspect of dissatisfaction among the team members that regularly comes up is having too little guidance and opportunities to clarify doubts or get support from me in case of difficulties. I am indeed concernd this might reflect negatively on me. Oct 11, 2023 at 17:57
  • @DanielR.Collins: We actually have pull-request-reviews in place, and unfortunately, I do not see the difference in practice. For instance, this answer says: "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." But where is that metric? No matter whether it is in a PR or beforehand, there will be some time-consuming discussion where I have to spend significant effort to explain and show why the employee's solution is not suitable, or else I'll have to accept their claim that they have ... Oct 26, 2023 at 22:30
  • ... "been trying for a long time and there is no better way" or similar summaries. Oct 26, 2023 at 22:31
7

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.

7
  • 1
    Sounds like wishful thinking. Usually frameworks have a standard way to do things, that's why we use frameworks. Developers should know or research how things are done within the framework, then implement. Junior shouldn't mean lazy, stupid or just a code monkey that codes based on strict requirements (for this teach chatgpt). Junior means without experience but still with problem solving attitude. Do you think a Junior who has been taught to apply some strict recipes will all of a sudden be promoted and start researching by themselves. Strong -1 from me for this advice. Oct 11, 2023 at 13:42
  • 3
    > "Standard tasks should have standard solutions in your codebase. " . That doesn't really work for making software efficiently. It's fine to repeat a standard solution two or three times, but before repeating it much more than that a good programmer should generally in some way automate or abstract the repeated part so it doesn't have to be done again next time. It may be that the OP's team already does that, which means the only tasks that take significant times are non-standard tasks. Tasks that would be called "standard" effectively disappear.
    – bdsl
    Oct 11, 2023 at 21:14
  • 3
    Everybody can get stuck. I ask a lot after joining a new team and also ask a lot later in case somebody already knows something I need to research. But a repeated pattern of not learning from previous experience and lack of personal research is something I have suffered a lot in some teams. It took me years to realize that not everybody can learn. A little hand-holding in the beginning is fine and expected. Hand-holding in the long term is not acceptable if senior wants to retain sanity. Oct 11, 2023 at 22:08
  • 2
    @bdsl "It's fine to repeat a standard solution two or three times, but before repeating it much more than that a good programmer should generally in some way automate or abstract the repeated part so it doesn't have to be done again next time." What do you think a standard solution is, if not the first step in this process? I focussed on those tasks, because OP gave such an example. For a non-standard task, OP would probably accept longer times as well.
    – Chieron
    Oct 12, 2023 at 12:17
  • 2
    @bdsl Automation makes sense only when you know it will be used enough to pay back before environment changes will require rewrite. For many tasks, a doc instruction has the best reward for effort ratio by far, and it's usually much easier to update and modify than automation.
    – Frax
    Oct 12, 2023 at 15:54
3

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.

2
  • 5
    I'm afraid I am not convinced of this. Plainly speaking, the developer encountered a value x that inexplicably deviated by a certain number y from the expected value. Their approach to solve this was to hard-code the value of y into the code and thereby correct x back to the expected value. They just assumed it works, without trying to understand where y originates from or why x is different than expected at all. IMHO, this is a mistake even for an inexperienced programmer, and unrelated to knowledge about date and time functions. Oct 12, 2023 at 14:21
  • 2
    This is a good idea though it won’t solve the problem of OP being spread too thin as the same problem will arise any time the new devs get in territory that’s uncharted for them. OP really needs another senior dev to help with this coaching.
    – bob
    Oct 12, 2023 at 17:27
3

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.

1
  • "the employee's progress as if it were your own" - well, I am responsible for the team's progress. But the EDGE method you outline is a good explanation. Many times, I feel stuck in the "Guide" stage, never moving on to the "Enable" stage, in the end having to do the task myself (or having to tell the employee line-by-line what to write). Oct 26, 2023 at 22:45
2

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.

7
  • 1
    Mostly good advice, but I have a few problems with it.
    – Mars
    Oct 12, 2023 at 4:55
  • 3
    Hiring senior developers doesn't help if issues require codebase knowledge. (Plus OP mentioned that these people are supposed to be "senior" developers provided by... I think it was some outsourcing company... But from the lack of experience with basic DateTime concepts (and adding a fixed offset as a solution...) I guess you can assume they are not truly senior.
    – Mars
    Oct 12, 2023 at 4:56
  • 3
    Juniors can't make estimates. Even if you ask them to do make one, you should still make your own rough estimate (maybe taking their estimate into account). Yes, asking estimates is good practice, but it's time consuming and without a certain amount of experience, it's mostly useless
    – Mars
    Oct 12, 2023 at 4:57
  • 2
    Mars not wrong about juniors and estimates. I just wouldn’t impose your own internal estimates on someone else as deadlines.
    – bob
    Oct 12, 2023 at 17:20
  • 3
    True that hiring seniors doesn’t solve the problem of “only OP knows the code” but a real senior will be able to solve that problem for themselves with only minimal input from OP (assuming the codebase isn’t an absolute dumpster fire of spaghetti code) rather requiring the level of handholding OP is putting in with the juniors.
    – bob
    Oct 12, 2023 at 17:22
1

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.

5
  • 1
    I fully agree test-driven development is wonderful as it relieves me of manual testing and lets developers check for themselves whether their solution works as expected. But it's not clear to me how it could have helped in this case ... mind you, the developer did find the erroneous behavior (the date is shifted by one day at some point) themselves. It's the solution they came up with that was not suitable, and I wonder how this could be tested (or even foreseen when defining the test cases) without actually checking the implementation. Oct 12, 2023 at 10:13
  • 1
    Tests are only usefull when you are able to think of all the possible scenarios. In this case might be the developer even had no idea about time zones and how it can be very tricky if there are no clear way how it's handled in the application (as it seems since the default behaviour was wrong)
    – CrazyFrog
    Oct 12, 2023 at 19:12
  • @O.R.Mapper beyond this example, it seems that your problem is having slow iteration cycles, in part because the developer isn't good/experienced enough to even know they're going in the wrong direction. TDD would still need your involvement (potentially pair-programming on test cases at the beginning), but then you'd have crystal-clear requirements expressed by test cases, which is a must-have for struggling dev. In your example, there was an implicit "this must work in all TZs" req that the dev missed for lack of experience. That's typically easier to test in an automated test than manually.
    – AdrienF
    Oct 12, 2023 at 21:00
  • @AdrienF: I cannot really do pair-programming with ~5 developers and work on all the task that are actually difficult myself. Also, as I have stated in another comment somewhere here, I have no trust that these developers won't make automated tests pass by making a hard-coded distinction between the couple of cases tested in the automated test rather than actually applying any timezone logic. Oct 26, 2023 at 22:37
  • In that I'd echo what Phillip Kendall wrote in his comment to your question – you don't have a team, you have a bunch of junior devs that should be fanned out for serious mentoring by a more senior devs. You could act as that senior dev, but not for 5 of them; maybe for 2 max. Depending on your influence in the company, you could try to change your hiring practices. If you can't, then you're probably better of changing jobs.
    – AdrienF
    Oct 27, 2023 at 20:19
1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .