Onshore Lead for Off Shore Developers Tips
October 1, 2024 9:05 AM Subscribe
I will be leading a pretty small team of offshore developers starting soon and I wanted to get folks tips on how to manage them, keep my sanity and do well.
Some requisite things:
- I am a ABCD (American born desi) who is not culturally indian
- I led a team like this before awhile back but had a couple more onshore folks, and my experience was more stressful than it could have been. I spent alot of time giving them very very specific instructions
- I don't know the tech that well (like, I couldn't code in it myself)
- I don't know the folks i'm working with
-The shift timing for them is 2am-11am my time.
-Mornings are a bit tough for me because of two small kids, but I'd like to start my day at 8:30am every day, and a couple days a week at 8am
-I'd love to shift their time to 1030-730am some days
- I tend to get really stressed being a lead and end up not delegating well
- In past I've gotten very frustrated working with off shore teams since they seem to never really think outside what I ask, and when they hit roadblocks they don't seem to work around them
Some requisite things:
- I am a ABCD (American born desi) who is not culturally indian
- I led a team like this before awhile back but had a couple more onshore folks, and my experience was more stressful than it could have been. I spent alot of time giving them very very specific instructions
- I don't know the tech that well (like, I couldn't code in it myself)
- I don't know the folks i'm working with
-The shift timing for them is 2am-11am my time.
-Mornings are a bit tough for me because of two small kids, but I'd like to start my day at 8:30am every day, and a couple days a week at 8am
-I'd love to shift their time to 1030-730am some days
- I tend to get really stressed being a lead and end up not delegating well
- In past I've gotten very frustrated working with off shore teams since they seem to never really think outside what I ask, and when they hit roadblocks they don't seem to work around them
Best answer: Your experiences I think are typical - and I've been in a similar position in the past. I'd suggest focusing on changing your expectations more than anything else. You will have to give a lot of very specific instructions. They will probably take your instructions fairly literally, and not work around blockers. This is a common pattern, for cultural and other reasons, and you are unlikely to change it. Accept this reality and embrace it. You are not a leader of an autonomous team; you are a boss who gives orders and then reviews the outcome and makes corrections. Spend a lot of time drafting those very specific instructions. Work on ways of getting reports from them throughout their day, so you can spend your limited overlap time identifying those challenges and making course corrections. Accept this situation; accept its imperfections; think about how to manage the outcomes and iterate. Keep your expectations grounded, and work from there.
posted by Tomorrowful at 10:47 AM on October 1 [12 favorites]
posted by Tomorrowful at 10:47 AM on October 1 [12 favorites]
Best answer: Tomorrowful is spot on. Get your specs written down HARD and thoroughly reviewed beforehand. If you want to be a bit more diplomatic, take the time and perform a spec walkthrough/review with the offshore folks before you kick off. If they provide feedback that's even better, now they're involved. Don't rush into coding. Slow is smooth and smooth is fast.
You may want to bite the bullet and adopt a JIRA-style workflow here, just because it's easy to break tasks down into comprehendible tickets and then you assign away. Tickets will probably be a comfortable mode of working for them. Don't let them close tickets on their own - assemble a review period where they present, on video, a demonstration of the finished work. Then you can close and move on, or iterate if something isn't right.
I'm not saying go all SAFe/Agile here because that's the road to insanity. But something in the middle will bridge the gap. Best of luck to you.
posted by JoeZydeco at 11:18 AM on October 1 [2 favorites]
You may want to bite the bullet and adopt a JIRA-style workflow here, just because it's easy to break tasks down into comprehendible tickets and then you assign away. Tickets will probably be a comfortable mode of working for them. Don't let them close tickets on their own - assemble a review period where they present, on video, a demonstration of the finished work. Then you can close and move on, or iterate if something isn't right.
I'm not saying go all SAFe/Agile here because that's the road to insanity. But something in the middle will bridge the gap. Best of luck to you.
posted by JoeZydeco at 11:18 AM on October 1 [2 favorites]
Best answer: Yeah, you generally have to be very, very specific, because with the time difference, any need for clarification adds a big delay.
One thing that can help here is using consistent templates for certain kinds of requests, to make sure that you're not missing any key piece of information. E.g., if you're regularly asking them to add a field to a database, have a template with spaces to enter the name of the table, the name of the new field, the data type of the new field, any validation logic that should apply, the security permissions on the field, a mocked up screenshot of where that field should be surfaced in the UI, etc.
An example of a bug that came from not doing that: a coworker requested a new numeric field and asked the developers to add it to the interface. They did NOT specify a number format in the request, so they got the default one, and until the next update, customer-facing employees had to deal with dollar values showing too many decimal places, or rendered as scientific notation.
Another thing that's challenging is that the distance and time offset can encourage thermoclimes of truth, where in an effort to not give you bad news (because they hope a problem is fixable), they don't escalate things until it's a disaster. (This happens with in-person teams too; you just have more opportunity to overhear something and say "wait, what?!")
posted by Blue Jello Elf at 12:17 PM on October 1 [2 favorites]
One thing that can help here is using consistent templates for certain kinds of requests, to make sure that you're not missing any key piece of information. E.g., if you're regularly asking them to add a field to a database, have a template with spaces to enter the name of the table, the name of the new field, the data type of the new field, any validation logic that should apply, the security permissions on the field, a mocked up screenshot of where that field should be surfaced in the UI, etc.
An example of a bug that came from not doing that: a coworker requested a new numeric field and asked the developers to add it to the interface. They did NOT specify a number format in the request, so they got the default one, and until the next update, customer-facing employees had to deal with dollar values showing too many decimal places, or rendered as scientific notation.
Another thing that's challenging is that the distance and time offset can encourage thermoclimes of truth, where in an effort to not give you bad news (because they hope a problem is fixable), they don't escalate things until it's a disaster. (This happens with in-person teams too; you just have more opportunity to overhear something and say "wait, what?!")
posted by Blue Jello Elf at 12:17 PM on October 1 [2 favorites]
You're being set up to fail. Twenty years ago, companies decided that hiring offshore workers would be cheaper and more efficient. Never happened; the companies had to hire too many onshore people to fix their work and to deal with the issues we're all talking about here.
- I am a ABCD (American born desi) who is not culturally indian
This could be a problem if your culture is an enemy of their culture, but probably not, you're just another rich American to them who's bossing them around.
- I led a team like this before awhile back but had a couple more onshore folks, and my experience was more stressful than it could have been. I spent alot of time giving them very very specific instructions
As Tomorrowful says, yup. That's how it is.
- I don't know the tech that well (like, I couldn't code in it myself)
Not helping your case in their eyes.
- I don't know the folks i'm working with
You'll never know them any more than any other online stranger, unless you visit them for at least a few weeks and bond with them.
-The shift timing for them is 2am-11am my time.
-Mornings are a bit tough for me because of two small kids, but I'd like to start my day at 8:30am every day, and a couple days a week at 8am
Work WILL be delayed for this reason. No way around it.
-I'd love to shift their time to 1030-730am some days
As others have said, they are prepared to follow orders, so if you order this it could happen, perhaps.
- I tend to get really stressed being a lead and end up not delegating well
I'm the same way. It's really hard to do this even with people who share my culture; it is exactly why I have never volunteered to work with overseas folks, even though I'm a tech writer which is a common job for overseas people who speak English well. (And it still hasn't worked. The companies I know about who were writing for American audiences, wound up spending all of their time correcting the grammar and style of people who knew nothing about American audiences.)
- In past I've gotten very frustrated working with off shore teams since they seem to never really think outside what I ask, and when they hit roadblocks they don't seem to work around them
Yup. This will never change. They cannot think outside what you ask, because they are not you and your company. They are people in India who want to earn money for their families. Frankly, I'm surprised that in this day and age US companies are still attempting this.
I watched my competitor work very hard to set up an office in China, only to discover that the Chinese reverse-engineered their products. Despite a century or two of Americans thinking "oh, but of course the rest of the world should be like us!", people from faraway countries really do not have our best interests at heart. I'm sorry you're in this position, and the only advice I can give is to seek out others who may have been in your position, and learn lessons from them. Good luck.
posted by Melismata at 1:24 PM on October 1 [1 favorite]
- I am a ABCD (American born desi) who is not culturally indian
This could be a problem if your culture is an enemy of their culture, but probably not, you're just another rich American to them who's bossing them around.
- I led a team like this before awhile back but had a couple more onshore folks, and my experience was more stressful than it could have been. I spent alot of time giving them very very specific instructions
As Tomorrowful says, yup. That's how it is.
- I don't know the tech that well (like, I couldn't code in it myself)
Not helping your case in their eyes.
- I don't know the folks i'm working with
You'll never know them any more than any other online stranger, unless you visit them for at least a few weeks and bond with them.
-The shift timing for them is 2am-11am my time.
-Mornings are a bit tough for me because of two small kids, but I'd like to start my day at 8:30am every day, and a couple days a week at 8am
Work WILL be delayed for this reason. No way around it.
-I'd love to shift their time to 1030-730am some days
As others have said, they are prepared to follow orders, so if you order this it could happen, perhaps.
- I tend to get really stressed being a lead and end up not delegating well
I'm the same way. It's really hard to do this even with people who share my culture; it is exactly why I have never volunteered to work with overseas folks, even though I'm a tech writer which is a common job for overseas people who speak English well. (And it still hasn't worked. The companies I know about who were writing for American audiences, wound up spending all of their time correcting the grammar and style of people who knew nothing about American audiences.)
- In past I've gotten very frustrated working with off shore teams since they seem to never really think outside what I ask, and when they hit roadblocks they don't seem to work around them
Yup. This will never change. They cannot think outside what you ask, because they are not you and your company. They are people in India who want to earn money for their families. Frankly, I'm surprised that in this day and age US companies are still attempting this.
I watched my competitor work very hard to set up an office in China, only to discover that the Chinese reverse-engineered their products. Despite a century or two of Americans thinking "oh, but of course the rest of the world should be like us!", people from faraway countries really do not have our best interests at heart. I'm sorry you're in this position, and the only advice I can give is to seek out others who may have been in your position, and learn lessons from them. Good luck.
posted by Melismata at 1:24 PM on October 1 [1 favorite]
You complain about needing to spend a lot of your time giving specific instructions. Maybe that's a large part of the job? Ask your boss what their expectations are.
Not sure how I feel about the idea about shifting their hours on only some days of the week.
posted by kinddieserzeit at 8:09 PM on October 1
Not sure how I feel about the idea about shifting their hours on only some days of the week.
posted by kinddieserzeit at 8:09 PM on October 1
Coming in late, because life got in the way when I saw this question posted: as a few people have already said, very specific instructions and the offshore team having no flexibility to think outside what you ask or work around a problem are just what you get with offshoring (especially, but not exclusively, to India). You say you end up not delegating well, but the thing to know in this scenario is that you're not delegating, you're assigning. You can't expect anybody on an offshore team to make any decisions for you, because they don't have the incentives to work that way. They understand their work to be completing tasks, not thinking up ways to complete them.
Offshoring requires a whole lot more handholding than any of your managers will ever acknowledge, because making the decision to offshore in the first place means ignoring the shortcomings of that decision. You need to manage your offshore team, but you also need to be very intentional about managing up. The way you do this effectively is to document everything you do, while understanding that your managers won't read anything you write. So you need to come up with ways to summarize the work you're doing, preferably in charts and graphs.
Learn to use performance metrics on the offshore team in order to enforce code quality. Was a ticket closed in the requested time frame? Did the work done on the ticket accurately meet the stated requirements? How much time was spent reworking the work already done? You can and should also use these metrics the other way: if a ticket required rework, what does that say about how the ticket was written? Could the requirements have been more clearly defined? Was completed work abandoned because your managers or product owners in other teams changed their requirements after the work was requested? Being able to say that the team lost so many work hours because of incomplete or evolving requirements is one way you can encourage your managers to make sure the pipeline is as efficient as possible.
Also, you're going to have to work ahead of the pipeline to make sure that the offshore team always has work to do. If you're on a two week feature sprint, you should set clear expectations for the offshore team so they know what work to do when they finish their current tasks. And again, managing the pipeline is also an opportunity to manage up. Make sure that your managers and peers in other teams understand when certain tasks require other tasks to be completed first, and what your offshore team will be working on first thanks to the priorities you're setting when managing the pipeline. But your pipeline should be planned at least two sprints out so you can communicate expectations to your offshore team and milestones and performance metrics to your managers and peers.
As for work hours: you're going to have to come up with a five day schedule and stick to it. You cannot ask a whole team to shift its schedule only some days a week because that's what works for you. Do what you have to do to adapt your own schedule to meet whatever the remote team can do five days a week, and then suck it up. Sorry.
posted by fedward at 8:50 AM on October 4
Offshoring requires a whole lot more handholding than any of your managers will ever acknowledge, because making the decision to offshore in the first place means ignoring the shortcomings of that decision. You need to manage your offshore team, but you also need to be very intentional about managing up. The way you do this effectively is to document everything you do, while understanding that your managers won't read anything you write. So you need to come up with ways to summarize the work you're doing, preferably in charts and graphs.
Learn to use performance metrics on the offshore team in order to enforce code quality. Was a ticket closed in the requested time frame? Did the work done on the ticket accurately meet the stated requirements? How much time was spent reworking the work already done? You can and should also use these metrics the other way: if a ticket required rework, what does that say about how the ticket was written? Could the requirements have been more clearly defined? Was completed work abandoned because your managers or product owners in other teams changed their requirements after the work was requested? Being able to say that the team lost so many work hours because of incomplete or evolving requirements is one way you can encourage your managers to make sure the pipeline is as efficient as possible.
Also, you're going to have to work ahead of the pipeline to make sure that the offshore team always has work to do. If you're on a two week feature sprint, you should set clear expectations for the offshore team so they know what work to do when they finish their current tasks. And again, managing the pipeline is also an opportunity to manage up. Make sure that your managers and peers in other teams understand when certain tasks require other tasks to be completed first, and what your offshore team will be working on first thanks to the priorities you're setting when managing the pipeline. But your pipeline should be planned at least two sprints out so you can communicate expectations to your offshore team and milestones and performance metrics to your managers and peers.
As for work hours: you're going to have to come up with a five day schedule and stick to it. You cannot ask a whole team to shift its schedule only some days a week because that's what works for you. Do what you have to do to adapt your own schedule to meet whatever the remote team can do five days a week, and then suck it up. Sorry.
posted by fedward at 8:50 AM on October 4
« Older Addressing issues at long term care facility | Donating to help fight income inequality Newer »
You are not logged in, either login or create an account to post comments
posted by dws at 9:54 AM on October 1