Johanna Rothman bucks conventional wisdom and writes that it's not always cheaper to hire workers from places where the wages are less expensive. When you have fractions of teams in remote places, you could have communication problems and other issues that will increase the cost for every feature.
“George is on his offshoring rampage again,” Cindy said as she slumped down in Ted’s visitor chair.
Ted saved his document and turned around. “Oh? Want to tell me about it?”
“I need more testers for the feature teams we’re starting, right? I told him. I showed him the project portfolio and the projects we can’t start. I showed him my unstaffed work. He told me, ‘Hire people in India. They’re cheaper.’ Well, they are cheaper, but the cost of doing business makes things so much slower, it’s not worth it. They’re smart, really smart, but by the time we get them trained, and with the time delay, it’s just not worth it.
“Now, if we were talking Brazil, maybe. But even then, we’re in Denver, so we still have a time delay. Mexico City, maybe. But why can’t I just hire testers here? Are you getting the pushback on developers?”
“Yes,” Ted agreed. “I’m being told to hire testers in Ukraine.”
“Well, that’s just crazy. We should hire feature teams somewhere. And make them employees. Doesn’t George realize that?”
“He’s still thinking waterfall. You know—first you need developers, then you need testers. We have to help him see we need everyone all the time. We need to explain to him the cost of asking a question and the cost of delay. Maybe we should show him the value stream.”
“Can he even spell value stream?” Cindy rolled her eyes.
Ted glared at her.
“Oh, fine. I’m being juvenile,” Cindy said. “But he’s being ridiculous. He wants all the advantages of agile without understanding the first thing about it. Even if we weren’t agile, it wouldn’t make sense.
“We would spend time developing requirements or a feature, then have to send it to some place more than eight hours away for testing? How do we explain to the poor testers what we mean? They don’t have the context. And, if they aren’t employees, we get different people every month. We keep training people, week after week. I swear, at my last company, I must have trained six people in a year. When I asked what happened to them, the answer from their management was, ‘They left.’ When I asked the testers, finally one told me, ‘They got a better job for more money.’ We paid for their training.
“I don’t mind training people, but I want to hang on to them for more than eight weeks. We have to make them employees. Or we need a good offshoring partner, not just some commodity body shop. The way George is going into this, he’s going for cheapest price.
“We’re going to pay. Our projects are going to be late. Our people are going to try to do standups with people who don’t know agile and are eleven and a half hours ahead of us. That’s just nuts. This is not ‘follow the sun.’ This is stay-up-too-late or get-up-too-early.
The delays on the project are going to cost way more than any labor cost would be,” Cindy fumed.
“Have you written up any of your experiences with offshoring?” Ted wondered.
“No.”
“I’ve had some of the same experiences you’ve had. I’ve had great experiences with feature teams. I’ve had bad experiences with just developers or just testers. Let’s explain what our experiences have been and put some money to those experiences. If we articulate why we’re so frustrated and that we’re not against feature teams in other places, maybe we can get George to listen to us.”
“OK. Here’s what I’ve seen.”
Project Cost Is More Than Wage Cost
When you have fractions of teams in remote places, you have a problem with team communications. Part of the team needs to ask another part of the team a question, and that causes a delay. That increases the cost for every feature.
Even if there is no question for a given feature, there is a built-in time zone delay. If the developer and tester are remote from one another, there is no easy interaction. Instead of the developer walking over to the tester and saying, “I’m done with the developer-testing and I’ve checked that feature in, so it’s up to you now,” the developer has to send an email to the tester.
Here’s an example. Imagine the developer finishes a feature at eleven o’clock on Thursday morning. If the tester were sitting next to the developer, the tester could start work around lunchtime, depending on what else the tester was doing. However, if the tester is in a time zone eight hours away from the developer, the tester doesn’t even know the developer is done with the feature until the tester arrives at work the next morning.
Now, what if the developer has made a mistake? Sometimes developers do. If the tester is in the same room or on the same floor as the developer, the tester can let the developer know while the code is fresh in the developer’s mind. The developer may not have started anything else.
However, with a remote tester, the developer has started some other feature. The developer now has a context switch. If the developer has made a mistake, the developer will incur a cost to return to the original feature. Or the developer might decide to finish the current feature to decrease the context switching and increase the cost of delay for the testers.
It is possible the tester doesn’t receive an answer until late Friday. That’s a significant time delay.
You can show this time delay on a value stream map. In fact, if your management is considering offshoring anything, you should. They should understand the cost of delay.
Cost of Delay Affects Any Project, Agile or Not
I’ve used developers and testers as the examples here, but you might have the developers and testers together and have the product management be remote. I’ve seen ScrumMasters be remote from their teams—something I don’t understand at all.
Any time you have a necessary role remote from the team, you incur delay in the project. That delay has a cost.
Maybe your project isn’t driven by cost. Maybe it’s not driven by schedule. If not, why is your management so keen on offshoring?
Offshoring Provides You Access to Talent and Other Cultures
A client of mine once said, “There are smart people all over the world. Why shouldn’t I use them on projects?”
He was right.
The best way to employ them is to use those smart people as feature teams, where you can provide the requirements to those smart people and answer questions for them. They will innovate in ways you cannot even imagine.
But as for one person on your team who is more than eight hours away? Or even more than four hours away? Explain to your management that wage cost could make your project much more expensive.
Read more of Johanna's management myth columns here:
- The Myth of 100% Utilization
- Only the 'Expert' Can Perform This Work
- We Must Treat Everyone the Same Way
- I Don't Need One-on-ones
- We Must Have an Objective Ranking System
- I Can Save Everyone
- I Am Too Valuable to Take a Vacation
- I Can Still Do Significant Technical Work
- We Have No Time for Training
- I Can Measure the Work by the Time People Spend at Work
- The Team Needs a Cheerleader!
- I Must Promote the Best Technical Person to Be a Manager
- I Must Never Admit My Mistakes
- I Must Always Have a Solution to the Problem
- I Need People to Work Overtime
- I Know How Long the Work Should Take
- I Must Solve the Team’s Problem for Them
- I Can Move People Like Chess Pieces
- Management Doesn’t Look Difficult From the Outside, So It Must Be Easy
- I Can Compare Teams (and It’s Valuable to Do So)
- It’s Always Cheaper to Hire People Where the Wages Are Less Expensive
- If You’re Not Typing, You’re Not Working
- You Can Manage Any Number of People as a Manager
- People Don’t Need External Credit
- Performance Reviews Are Usefult
- It's Fine to Micromanage
- We Can Take Hiring Shortcuts
- I Can Standardize How Other People Work
- I Can Concentrate on the Run
- I Am More Valuable than Other People
- I Don’t Have to Make the Difficult Choices
- I Can Treat People as Interchangeable Resources
- We Need a Quick Fix or a Silver Bullet
- You're Empowered Because I Say You Are
- Friendly Competition Is Constructive
- You Have an Indispensable Employee
User Comments
Hi Johanna,
Thanks for an interesting series of management myths and I am tempted to comment on this specific one. I agree with your larger myth title that it is not necessarily cheap to hire people where wages are less expensive – however in my opinion, this is true when the hiring and management is not done effectively. I agree just hiring a bunch of individual developers or testers from a body shopper is not going to give you much ROI, however when undertaken as a planned and thought through outsourced effort where you partner with a company, there have been several success stories including ones that have been cost effective, both in the industry and at our company, QA InfoTech. My take away from your article is that you are suggesting outsourcing only complete features (design, dev, testing inclusive) as opposed to any individual piece (say outsourcing testing alone) and this is the point that I do not completely buy into – ofcourse, if you are able to outsource a full feature to a 3rd party services provider or your own global subsidiary that is able to drive the effort E2E, they are empowered to take on full ownership and you are setting them up for success. Suppose an individual piece (say testing only) of a feature is outsourced, I agree there are greater chances for increased overhead and costs, especially if the communication protocols are not defined and flexible enough to align with the product’s dynamics, but it is not impossible to set a team up for success in this case too, helping the organization reap the cost benefits of working with a team in a place where the wages are cheaper.
While cost is a factor in any project or program - it should never be the sole consideration in selecting partners. While it is certainly possible to co-locate a entire software development team, it is rare that most organizations can do this, and not just for cost reasons, but talent as well. Hiring Full Time Employees en-masse is generally out of the question for most projects. I am approaching this as an executive program manager, where I have many projects within my portfolio. When making a decision to select a partner, I account for ramp up time as the article suggests. However, this ramp up time occurs whether you co-locate or work remote. I use the same methods in training and developing FTE as I would contractors. Indeed most of my projects used mainly partnerships or contractors. These methods are simply traditional methods of defining roles clearly, assuring a communication and escalation path exists that is clear, and all roles are cross trained. If a project is limited to questions in which only two people may submit and answer - this is a symptom or poor project management, not the fact of where the individuals are located.
I also prefer independent QA firm as opposed to one in-house simply because they approach the project broadly and catch things a dedicated team would not. I also like to multi-source my vendors for the same reason. In the end I get a better product. There are also questions of scale that are easier to ramp up (or down) based on the project needs. Development is more tricky in this regard, but I've had great success using different development teams that have strengths that balances another group's weakness and the reverse
Yes it is hard to manage dispersed teams, but this is not a poor reason not to do it. Time Zone differences are becoming less of an issue simply because I know of no one in a large scale technology organization that works banker hours. It does not follow that people work 24/7 - but working with dispersed teams requires flexibility - and personally is an attractive benefit to manage a work / life balance.
There are many collaborative tools available today that make managing globally dispersed teams not only easier, but more effective than attempting to keep everyone on the same floor.
In conclusion is it cheaper to use dispersed groups, yes and no - but there are many other factors one should take into consideration on the management of their projects, nor is co-location always ideal or frankly possible. Co-location may be optimal for small, specific, and linear projects - but it is hardly an option for large development efforts, unless one has the financial strength of an Apple or Google - and yet even they use globally dispersed teams. I am unclear what feature based projects mean as at some point integration will / must occur for most software projects - and it is best to master managing global teams prior to that point.
While cost is a factor in any project or program - it should never be the sole consideration in selecting partners. While it is certainly possible to co-locate a entire software development team, it is rare that most organizations can do this, and not just for cost reasons, but talent as well. Hiring Full Time Employees en-masse is generally out of the question for most projects. I am approaching this as an executive program manager, where I have many projects within my portfolio. When making a decision to select a partner, I account for ramp up time as the article suggests. However, this ramp up time occurs whether you co-locate or work remote. I use the same methods in training and developing FTE as I would contractors. Indeed most of my projects used mainly partnerships or contractors. These methods are simply traditional methods of defining roles clearly, assuring a communication and escalation path exists that is clear, and all roles are cross trained. If a project is limited to questions in which only two people may submit and answer - this is a symptom or poor project management, not the fact of where the individuals are located.
I also prefer independent QA firm as opposed to one in-house simply because they approach the project broadly and catch things a dedicated team would not. I also like to multi-source my vendors for the same reason. In the end I get a better product. There are also questions of scale that are easier to ramp up (or down) based on the project needs. Development is more tricky in this regard, but I've had great success using different development teams that have strengths that balances another group's weakness and the reverse
Yes it is hard to manage dispersed teams, but this is not a poor reason not to do it. Time Zone differences are becoming less of an issue simply because I know of no one in a large scale technology organization that works banker hours. It does not follow that people work 24/7 - but working with dispersed teams requires flexibility - and personally is an attractive benefit to manage a work / life balance.
There are many collaborative tools available today that make managing globally dispersed teams not only easier, but more effective than attempting to keep everyone on the same floor.
In conclusion is it cheaper to use dispersed groups, yes and no - but there are many other factors one should take into consideration on the management of their projects, nor is co-location always ideal or frankly possible. Co-location may be optimal for small, specific, and linear projects - but it is hardly an option for large development efforts, unless one has the financial strength of an Apple or Google - and yet even they use globally dispersed teams. I am unclear what feature based projects mean as at some point integration will / must occur for most software projects - and it is best to master managing global teams prior to that point.