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

[article]

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:

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

Oct 12
Oct 15
Nov 09
Nov 09