Management Myth 21: It’s Always Cheaper to Hire People Where the Wages Are Less Expensive

[article]
Summary:

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.

User Comments

3 comments
Mukesh Sharma's picture
Mukesh Sharma

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.

September 23, 2013 - 5:21am
Tom Grega's picture
Tom Grega

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.

September 24, 2013 - 3:25pm
Tom Grega's picture
Tom Grega

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.

September 24, 2013 - 3:26pm

About the author

Johanna Rothman's picture Johanna Rothman

Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:

  • Manage Your Job Search
  • Hiring Geeks That Fit
  • Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
  • The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
  • Behind Closed Doors: Secrets of Great Management
  • Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People

Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09