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.
“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