I find it really hard to delegate work to my development team, especially offshore developers because of the time difference. I can't reach out to most of my team during my work hours and they can't reach out to me...
Additionally, I keep looking at user stories and thinking: "I could do that myself, faster and exactly how I want it". But there are so many hours in a day and I keep restraining myself from taking on more work on my already full plate. Also, I recognize that if I did everything for my team, they miss on learning opportunities that I've enjoyed in the past.
I wonder how other lead developers do it? Any techniques or practices that might help?
Top comments (10)
I am not a lead developer here. But for the past few months, I've been working with this great developer from Canada. They have a small team down there, so they out-source most of the work to my team, here in Pakistan.
What that guy does is, he assigns us tickets every two weeks, enough for us to continue for at least two/three weeks. Then he schedules a skype meeting and explains what needs to be done.
As he developed the platform himself a couple of years ago, he knows a lot about the code base and the issues we might face when working on a ticket. So as a heads up, he would mention some of the major issues, right there, in the ticket, when he is creating it.
This way, we, the remote team, go through all of tickets before the meeting and then ask any potential questions we might have prior to getting our hands dirty! And he is accessible, pretty much always, whenever we have any more questions for him!
This might not be a very great technique. And one of my team mates actually asked him this very question that how does he manage his work, given that he spends a lot of time working with us? The thing he said, is the actual reason I am replying.
So, according to him, it's all about prioritizing stuff.
I hope this help!
I think this is really helpful. I need to put more thought into planning the work distribution. I also think the mere exercise of thinking about this and reading your comment helps me think about this a little more. Thank you!
Glad it helped :)
I was in similar situation and it took months to figure out a workaround. What was working for me: delegate bigger packages, not task by task, but a longer term goal, let the team understand a bigger piece and the goal of the project and let them work and trust them. Sometimes check in the version controlling system how it is going and ask them what is the status (I asked them for weekly status report). If you see a big difference between code and reports go deeper, otherwise let them work. That was what was working for me.
I agree with you on giving the team some autonomy. I think it’s important. I try to do that as much as I can. But I dont think doing weekly status reports will help. Havin junior devs on your team means that they need mentorship, especially when you need to deliver a high-quality codebase to your client.
I’m hoping that I can be more hands-off with time.
Sorry, I missed the point that they are juniors. I think the only thing what could help to introduce one senior developer to that team as local team lead.
My strategy has been to find another lead or senior level "counterpart" on the offshore team who I can delegate things to, who can then delegate things to the offshore team. Obviously you probably shouldn't just leave it all up to them, but especially for design/architecture related things, instead of having to communicate asynchronously with say 5 developers, it only has to be 1.
Even for architecture discussions I would try to have some time once per sprint where I woke up really early and discussed things with the offshore team to make sure they understood why decisions were made, what the business implications were (how their code tied into solving business problems), and ask for any feedback on designs.
We usually had 1.5hr overlap / day, but most of that time was spent in standup and user story refinement sessions.
If you can at all, I;d try to get the offshore team to be present for at least part of user story refinements. I've found it crucial for developers (especially offshore since they're asynchronous and can't just walk over or ping a business person) to understand the business requirements and ask clarifying questions. It's usually the developers first who figure out that certain business requirements either aren't feasible or will take too long to accomplish. And without having a good understanding of this up front, it's easy to find out halfway through the sprint on something that will be too big but you already committed to.
As far as getting more comfortable with "giving up the work", what I've found helpful is to go through each user story / or larger grouping of tasks and either do a design doc (sequence diagram, etc) or briefly pseudocode it out.
This accomplishes two things:
Playing the "architect" role in that way has always proved to be very helpful for me, and the rest of the developers I may be delegating things to.
This sounds like a great middleground and the more I read your comment the more reasonable it sounds. Thank you! This is definately steering me in the right direction!
Have you tried having some overlap hours? May be three or four hours a day.
That proves to be dificult with a two year old 😅