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?

O. R. Mapper
  • 1,653
  • 1
  • 14
  • 17
  • 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. – Philip Kendall Oct 10 '23 at 09: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). – O. R. Mapper Oct 10 '23 at 09:42
  • 1
    What is your actual position within the team and the company? Are you boss of those 5 or their peer? – Aida Paul Oct 10 '23 at 09:50
  • @TymoteuszPaul: I'm officially their team lead. As for the additional team I mention, I am officially the head for that project, so I'm also in charge of supplying them with tasks. – O. R. Mapper Oct 10 '23 at 09:57
  • 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 '23 at 09:58
  • 1
    @TymoteuszPaul: I guide them, I am responsible for assigning tasks to them, I am responsible for distributing tasks assigned to my team in such a way that they are completed in time, and while I cannot unilaterally decide to hire or fire anyone, my boss who formally has that authority will, for my own team, not do anything against my wishes or requests. – O. R. Mapper Oct 10 '23 at 10:00
  • 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 '23 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 '23 at 19:25
  • is developer A an intern? – njzk2 Oct 11 '23 at 18:49
  • @njzk2: No, the developers in question have between 2 and 10 years of experience. – O. R. Mapper Oct 11 '23 at 19:00
  • May I suggest that a two-hour example cuts no mustard? Simply checking your junior's work will prolly take longer… just as might checking your own work. Do you not think there might be huge differences in projects taking 20-odd hours? – Robbie Goodwin Oct 12 '23 at 00:26
  • @RobbieGoodwin: I'd hope that the guidance/estimated effort ratio would improve for larger tasks, but ... I've already described what actually happens whenever I assign larger tasks in the question, look for "Assign only larger tasks". – O. R. Mapper Oct 12 '23 at 19:42
  • Sorry I missed that and since you point it out, it makes it doubly clear that you would do well to read Sun Tzu's The Art of War, which for about 2,500 years has been the most important manual on the achievement of objectives; at least as important as Machiavelli's The Prince. Consider also the WWII movie, Band of Brothers and much of the work of Bruce Lee or Cynthia Rothrock, among others.

    If you're really going through all that you described and still putting in more than you get out, is the common factor your students, or your own analysis/perspective?

     – Robbie Goodwin Oct 12 '23 at 20:07
  • Point for point: 1 seems ok, apart from (maybe) finding the table for them but better safe than sorry 2 you already did that in the first step. Either decline, refer them to the material you already provided or cut the time. This should take 5 minutes MAX. 3 Nothing you can do about that. 4 15 minutes it's way too much, just tell them to verify in the debugger and move on, 45 secs max. 5.6.7. Some automated tests would've easily caught that. 8 It's ok, you should verify the solution anyway if you are the team lead. That's 50m tops of your time and experience for them for the future – John Doe Oct 13 '23 at 11:49
  • @JohnDoe: Automated testing is not magic. It must be a very sophisticated automated testing engine to determine that one of the date times is shifted by just the timezone offset of a particular developer's location ( 5 ), to recognize the developer has hidden the issue by introducing a hard-coded value that just works for said developer, to suggest specific co-workers from another timezone and persuade a developer who does not believe their solution is problematic to change it anyway ( 6 ), and to trawl the documentation for a suitable method ( 7 ). – O. R. Mapper Oct 13 '23 at 12:14
  • @O.R.Mapper I know tests aren't magic, I work in software development as well. This example seems pretty straight forward to verify. 1 test on A's PC doesn't pass (hour mismatch that he saw). 2 test on A's PC passes but not on server due to 1 hour hack. 3 final code review. Some of the steps you wrote can clearly be removed, I don't know if this is just an example of it really happened but if it did I think you need to have a good meeting with who is giving you these developers and explain the situation because from what you've written they are clearly not suited for the position – John Doe Oct 13 '23 at 12:25
  • @O.R.Mapper the test is not supposed to say "hey, the time is different exactly by your time zone so you need to do this and this to fix it, check it" but "this is wrong, check it". It is then the developer that needs to find the solution – John Doe Oct 13 '23 at 12:27
  • @JohnDoe: The developer already found out on their own it was wrong. Then they implemented a solution that (after some tweaking) a unit test would most likely have evaluated as correct, leaving it up to a human user to check and find out about the unsuitability of the chosen solution again. – O. R. Mapper Oct 13 '23 at 12:38
  • @O.R.Mapper that's why you run the tests both on your machine and on the server, the same unit test would've worked on A's PC but not on the server since it was in a different time zone and the value was base don A's PC location. There's plenty of code around that "it was fine on my machine". I think my points still stand – John Doe Oct 13 '23 at 12:42
  • @JohnDoe: Actually, it would have worked on the server (or in any timezone West of A's), as well. Also (pseudocode): if (value.time == 24 - y) { value.time += y; } else if (value.time == 24 - z) { value.time += z; } Repeat adding these until all testers/test systems say "Great, unit tests all pass!" – O. R. Mapper Oct 13 '23 at 12:49
  • 2
    @O.R.Mapper if that is how your developers work I'm afraid you have way bigger problems than spending 3 hours trying to help them TBH – John Doe Oct 13 '23 at 13:09
  • "systematically tracking this kind of detours like the above would require considerable amounts of my time (that I do not have)" - your process should be doing most of the heavy lifting here. How do you track the work your team is doing? Does your team estimate how long each ticket will take before starting, and record how long each ticket actually took after finishing? – Kent Oct 13 '23 at 17:20
  • @Kent: "How do you track the work your team is doing?" - team members report regularly what they are working on, and I periodically check the completion state of all open tickets. "Does your team estimate how long each ticket will take before starting" - they do, but it's rarely accurate. A task estimated to take one week can easily take two months, which in turn can mean the developer actually worked on it for two months, or just for a few days with lots of time in between waiting for 3rd parties. "record how long each ticket actually took after finishing?" - I have no tool to do this. – O. R. Mapper Oct 18 '23 at 22:33

11 Answers11

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.

Aida Paul
  • 35,116
  • 15
  • 91
  • 128
  • 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 '23 at 10:31
  • 1
    Thank you, very insightful. Some remarks/questions, though: "You have to let go." - I'm not sure how this goes along with my responsibility to get the tasks assigned to my team done. "you should be slow to respond, at least some of the time" - as I wrote, the task I described took almost two weeks, and that was in part indeed because I usually took a day or two until I got around to looking into and responding to A's requests. Overall, I am not so sure how it could play out concretely. You wrote "make sure they understand the task, make sure they understand expected outcome", but isn't ... – O. R. Mapper Oct 10 '23 at 12:55
  • 1
    ... that just the effort that amounted to the first 40 minutes in my description above? But my main problem, to stick with the example I listed, is, that A did not recognize when "it's done". Remember, the "freedom to resolve their own problems, in their own way, rather than giving them a solution you expect to deliver" would have led to a solution that would not work East of A's timezone. And A would not have realized this without me spending extra effort in discovering this and explaining what's the problem. – O. R. Mapper Oct 10 '23 at 12:55
  • 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 '23 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 '23 at 13:18
  • @TymoteuszPaul: "is this first time when you are leading a team?" - indeed it is. When I took over this team some 6 years ago, it was still a bit smaller and had other members, but formally, it's still the same team. "from the sound of it - it already isn't" - true, lots of things do not get delivered in time. I think it would be a mistake to pretend everything works out. "And you note that." - I tend to note most of these steps in the tickets, though unfortunately, we lack the tools to systematically evaluate such timeline information. Hence, presenting any proof about the team's ... – O. R. Mapper Oct 10 '23 at 14:49
  • ... contributions that goes beyond singular anecdotes and "my personal impression" based on working with them is hard to come by. I'm not sure how to solve that yet. – O. R. Mapper Oct 10 '23 at 14:49
  • 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 '23 at 15:01
  • 1
    The workplace.SE user in me wants to upvote this answer. The SO user in me wants to downvote it because they'll just dump the question there! :-) – yshavit Oct 10 '23 at 22:55
  • 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. – Todd Wilcox Oct 11 '23 at 00:12
  • Delegating and "letting go" means resisting micro-managing. That is the #1 cause of this kind of over-involvement in subordinates' work. Your responses sound harried, e.g. this answer emphasises patience but you're complaining about time taken. Usually, such behaviour from subordinates is learned helplessness. Perhaps they will start working, reading, solving independently when they believe there is any point. Perhaps they'll stop soliciting your direction up-front when you stop giving it after the fact (i.e. "knowing what you don't want after you've seen it"). – benxyzzy Oct 11 '23 at 05:42
  • @benxyzzy: I am not sure I completely understand your last sentence, but I suspect it has to do with the extremely delicate tipping point between a) providing too little guidance, with the result that they make either no progress or progress into a questionable direction that I need to fix afterward vs. b) giving too much guidance, at which point they stop trying to solve the problem for themselves. – O. R. Mapper Oct 11 '23 at 18:03
  • Is it just me, or did this answer not answer any of the @O.R.Mapper 's concerns? At best one could imply that the answer suggests "be slower to respond so that they work it out themselves". – Mars Oct 12 '23 at 02:07
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 :-)

Hans-Martin Mosner
  • 3,455
  • 1
  • 10
  • 17
  • 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. – O. R. Mapper Oct 10 '23 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. – Hans-Martin Mosner Oct 10 '23 at 12:57
  • 11
    And specifically, ask the team to do tasks such as verifying the work. – David R Oct 10 '23 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.
Mars
  • 6,050
  • 2
  • 16
  • 36
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).

Hilmar
  • 120,104
  • 36
  • 233
  • 374
  • 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 ... – O. R. Mapper Oct 10 '23 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.) – O. R. Mapper Oct 10 '23 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 '23 at 04: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. – O. R. Mapper Oct 26 '23 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 08 '23 at 04: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.

Tom W
  • 1,363
  • 6
  • 12
  • 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. – Daniel R. Collins Oct 11 '23 at 01: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. – O. R. Mapper Oct 11 '23 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 ... – O. R. Mapper Oct 26 '23 at 22:30
  • ... "been trying for a long time and there is no better way" or similar summaries. – O. R. Mapper Oct 26 '23 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.

Chieron
  • 181
  • 2
  • 5
  • 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. – akostadinov Oct 11 '23 at 13:42
  • 1
    @akostadinov A junior who struggles with a standard task often needs some onboarding. And even seniors will stumble over some gotchas once in a while. Everyone inventing their own datepicker is just not a good idea. In practice, the some pitfalls should be foreseen by the senior, hence the standardized solution. Stupid solutions like a hardcoded offset for datepickers should be discarded before the developer starts them. The "recipes" allow them to get the idea to research inside your codebase as well in later tasks. – Chieron Oct 11 '23 at 14:51
  • 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 '23 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. – akostadinov Oct 11 '23 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 '23 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 '23 at 15:54
  • 1
    Whatever the solution to standard tasks is - whether it's writing up a doc, automating, or abstracting, if it works then the effect should be that the vast majority of development time is spent on nonstandard tasks only, or the nonstandard aspects of each task. E.g. in the OP's example the time was taken up by dealing with timezones, which it seems is not something done as standard in previous tasks. – bdsl Oct 12 '23 at 18:32
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.

Xavier J
  • 42,848
  • 10
  • 86
  • 146
  • "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). – O. R. Mapper Oct 26 '23 at 22:45
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.

Salman A
  • 231
  • 1
  • 5
  • 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. – O. R. Mapper Oct 12 '23 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 '23 at 17:27
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.

bob
  • 6,993
  • 1
  • 17
  • 43
  • 1
    Mostly good advice, but I have a few problems with it. – Mars Oct 12 '23 at 04: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 '23 at 04: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 '23 at 04: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 '23 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 '23 at 17:22
  • "Hire a senior developer" - unfortunately, that's not really something I can influence. The company has been trying to hire someone to support me for a long time, but software developers are an extremely scarce resource and it's hard to find any applicants even with external recruiters. "Don’t make estimates for others" - as a part of my duties, I am required to make some statement on how long my team will take to complete a given task, and the developers usually cannot or will not make any estimates, so what can I do? "Let people learn to learn" - the issue is that they are often ... – O. R. Mapper Oct 26 '23 at 22:49
  • ... convinced they have successfully solved the problem. They must feel they're not struggling with the task, but with me because I won't accept their (in their view) good solution. – O. R. Mapper Oct 26 '23 at 22:50
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.

AdrienF
  • 111
  • 2
  • 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. – O. R. Mapper Oct 12 '23 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 '23 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 '23 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. – O. R. Mapper Oct 26 '23 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 '23 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.

Steve
  • 11,560
  • 1
  • 16
  • 42