Best Practice - Be honest with your staff

I just read an interesting question on the outsourcing forum on Linked In. It asked a simple question about whether it was time to lose "outsourcing" in descriptions of global technology sourcing partnerships. The general consensus was that no matter what you call it, your remaining staff will figure out that it's outsourcing. So the semantics matter less than execution.

I agree.

There is no need to try to disguise outsourcing because there is no need for the practice to be stigmatized. This is a hard sell, but here are a few points to ponder:
  • If your company buys software you are outsourcing the R&D and manufacturing of that software tool.
  • If your company uses UPS or FedEx to ship stuff you are outsourcing the delivery of packages.
  • If your company hires a firm to come in and water the plants in your office once a week you are outsourcing the care of your corporate flora.
You could get even more creative in this proof and eventually realize that all the for-fee services people take for granted are, in point of fact, a form of outsourcing. I haven't tested this argument with anyone so I don't yet know if it will sway staunch critics of outsourcing. But it is nevertheless true. All trade is a form of outsourcing. All companies outsource.

This leads me to the conclusion that it is not outsourcing that people fear or hate. It's the unknown aspects of what's behind the outsourcing (and how that will personally impact their jobs and livelihood) that people fear and loathe.

To get at what people think about various outsourcing decisions, take each of the three examples I listed above:

  • Software tools: Most people won't believe you when you tell them that this is outsourcing. But if you were completely vertically integrated, you'd make your own operating system. So why shouldn't you? Unless you are Google, all your staff will quickly answer:
    • because we don't know how to make an operating system.
    • Microsoft can do it much cheaper, and probably better.
  • Shipping: Why wouldn't you have your own truck fleet, and take your own packages around the globe? Wal-Mart has done that. Again, unless you're a massive company, this will be a no-brainer. Most everyone in your company would answer that you outsource your shipping, because:
    • it's a messy problem, requiring trucks, and planes, and delivery agents, and a lot of logistic expertise you don't have and don't want.
    • DHL, or FedEx, or UPS, or who ever you use can do it much cheaper, and more reliably.
  • Watering plants: Unless you're a very small company, you won't get much argument from your staff on this one. Your staff will understand that:
    • watering plants isn't core to your business.
    • anyone in your office who might be inclined to do this probably has a day job that is more valuable, so a service is more cost effective.
In each of these cases, the reason you outsource is obvious, and your staff is OK with your decision to pay some outside entity to do these jobs for you.

It's a tougher problem in technology outsourcing, where traditionally there has been more vertical integration (more in-sourcing). In this case, I have some simple, actionable advice to help your staff get their heads around your technology outsourcing programs, so that hopefully one day they will be able to say "of course we outsource our Exchange system administration... that's just a service we buy, like electricity or dial-tone."

Actionable Recommendations:
  • Call your outsourcing programs something simple and direct. I like "outsourcing." Don't get hung up on semantics, and don't go crazy trying to spin your programs.
  • Be clear and direct about your business drivers. Define (and document) why you are outsourcing aspects of your technology development or delivery.
  • Explain these business drivers to both your staff and your partners.
  • Establish a well articulated governance model that makes performance of the outsourcing partnership measurable and transparent.
  • Lastly, make it clear to your remaining staff that the partnership is now part of the new definition of "team," and go to work on the other management best practices I've defined herein.
There's more information on this topic (including the original question and comments from several people, including myself) on the blog "Horses for Sources".


Outsourcing and Security

Someone asked me this week if I had any thoughts or opinions about outsourcing and security. It turns out that I have both thoughts and opinions, so I thought I'd write a post about this.

I see the problem of security as related to technology outsourcing breaking down like this:
  • Confidentiality or privacy breach
  • Intellectual property theft
  • Sophisticated or inadvertent attack insertion
  • Physical security
  • Personal security and safety
I'll talk about each of these, and then talk in some detail about what I've seen done to address each.

Start with Trust

Ultimately, outsourcing partnerships are built on trust. Without this you will always have an adversarial relationship with your outsourcing partner and you will never enjoy the productivity and quality of work you might otherwise experience. I preach incessantly (in this blog and my other endeavors) that you have to think of your outsource team as if they were your own employees. In order to get to that level of shared fate you have to have trust. In order to trust, you probably have to first become paranoid about what could go wrong and then make sure you have contingency plans in place for everything you can think of...

After Trust, move on to Verify

"Trust but verify" is a great mantra when thinking about security. While this should not be construed as actionable or legal advice, I believe that you can't have effective security without a great measure of trust. For without this your security measures are likely to paralyze your business (see the photo above for a good example of this).

That said, part of the "verify" is the due diligence and audit aspect of any well run sourcing program. When selecting a vendor, references are key. Sideways references (people you know who work with the vendor, not necessarily references your vendor provides to you) are even more powerful. Before I move in to specific security risks and abatement measures, I'll give a couple of examples of "trust but verify" in action:
  • If your vendor claims to do security background checks on all its employees, verify their assertion: First, discuss with them that you will randomly audit the results of these background checks. Tell them you'd like to see redacted output of the background checks, and give them 24 hours to clear that with their lawyers. Then, give them 5 random names from your team, and ask them to produce the evidence of their security background checks. How they handle this will tell you a great deal about what they're really doing with respect to security checks. If the results are unsatisfactory to you, switch back to "trust" and tell them what they have to do to satisfy your concerns, and give them a time frame to accomplish that. Test them again when the time frame is over.
  • If your vendor claims to have 24-hour a day security cameras in all the data centers, follow the same routine above, and ask to see tape from last Thursday at 02:45 local time. (or any other random but recent time period.) If they can't produce this, figure out why, and give them corrective action to fix the problem.
If you take this approach of trusting what they say, but auditing what they do, you and your vendor will have a good business relationship that will grow further trust through time. (Or you'll figure out before it's too late that you partnered badly...)

Now, on to specific threats and how to manage to them:

Confidentiality or Data Breach

Protection of customer and employee data is highly regulated. Loss or inadvertent exposure of credit card numbers, social security numbers, or even names and addresses can have massive personal impact to the people whose data was disclosed and devastating financial results to the company who lost or disclosed the data. This security concern should be taken very seriously. The concern is compounded when "people who don't even work for us" in "some country half way around the world" are interacting with this data as part of day to day operations.
  • Transactional data within CRM (and other) systems - Think about the data that is present on a computer screen when you call technical support. The screen in any CRM application will have name, address, potentially social security numbers, and enough data to facilitate identify theft. This has to be guarded. CRM transactions should be logged for both reads and writes. Read access should be granular, and where possible critical components should be masked, and revealed only on an as-needed basis. In this, abstraction is your friend - if you have to store things like Social Security Numbers, do so in an abstracted table, and don't make that data element part of your CRM work flow.
  • Test data - This is an often overlooked security hole, prevalent with Offshore Product Development (OPD) teams. Test data sets are often cobbled together from production data. If that's the case, they will have real names, social security numbers, etc. in them. Disclosing this to third parties (or often to test engineers within your own company) can be construed as breach of confidentiality. Hence, you should de-identify all your test data. I won't write the regular expressions for you, but names should become random strings, numbers should be randomized, and for US data sets, any string of the form ###-##-#### (Social Security Number format) should ABSOLUTELY be randomized or redacted. I'll leave it to you to figure out how to do this without compromising your test results, but this is important stuff.
  • Data Residency - Irrespective of compliance concerns it seems intuitive to me that companies should not host sensitive data outside their own domains unless there are very strong security and contractual measures in place. A popular expedient (for American companies) is to host all customer and financial data exclusively in US data centers, to ensure that there is no potential for other jurisdictions to come in to play and seize or otherwise access company or customer data. This space is also highly regulated, and in come cases there is legal obligation around where data must reside, and a lot of complex case law about what levels of out-of-country access are allowable. This is one to talk about with your corporate counsel.
  • Printouts and other movable media - Many high-security offshore operations centers I've toured through the years are "paperless." This is to prevent a purposeful or inadvertent screen dump that results in critical data ending up in a waste bin, or in a briefcase. I've seen further measures in place wherein the offshore operations center is not networked to the public carrier Internet, but only has a route (through secure VPN) to the client's network. In this case, the remote network is effectively "air-gapped" to prevent inadvertent or purposeful file transfer. Obviously where security is paramount laptops are probably to be avoided and I've seen centers that only used diskless network consoles. And there are some great software solutions that prevent the use of USB drives, bluetooth, and IR ports, effectively making it impossible to transfer media to small mobile devices.
  • Third party attacks - This may seem like an unlikely risk, but it should be mitigated nonetheless. Fortunately, best practices in network management cover much of this. If your network traffic is run through a secure encrypted VPN, third party sniffing should be effectively eliminated. One thing to think about though is human to human "phishing" attack. Your offshore staff should be trained not to respond to such attacks, potentially to the point of having a procedure or protocol in place to ensure that no one at the vendor site is fooled by a third party claiming to be a representative of the client.
  • Contractual concerns - Obviously breach of data security is breach of contract. Your contract should be clear on this point. Work with your lawyers to make sure that you have an agreement that protects (and indemnifies) the concerns of the client in this case. This is particularly important where the "local" (China, India, Vietnam) laws might be construed to be in force with respect to data privacy. You probably want to have clauses in your contract that define jurisdiction as "local" to you (the client). Again, I'm not a lawyer, so please talk to yours about this.

Intellectual Property (IP) Theft

This concern gets a lot of play in the press, probably because of highly publicized software piracy in China, dating back 5 or 10 years. Aside from that, I haven't read or heard a great deal of credible instances where outsourcing firms stole trade secrets or IP. In my mind this breaks down into just two facets:
  • Assignment of IP and inventions - If you have an OPD team, and they're good, they will innovate for you. They'll invent stuff. They'll think of new ways to solve old problems. It's important that you work with your lawyers to put contractual vehicles in place to convey that innovation back to you, if that's your intent. Every OPD firm I've worked with has a keen grasp of this, and they actually want the IP to convey back to the client. An obvious tactical measure I've seen almost universally employed is to keep source code repositories in the client site, accessed remotely.
  • Inadvertent cross-contamination of IP - This one is tougher to manage. Say you hire an OPD firm, and they do some work for you, and one of their engineers comes up with a great new optimization algorithm for you. You're very pleased, until your main competitor sues you because that engineer learned said optimization algorithm while working for your competitor on contract through the same outsourcing firm. It's a bit of an unlikely scenario, but worth considering nonetheless. Usually OPD firms will already have a contractual structure that prevents cross-contamination. To implement that protection they may ask you who your main market competitors are, and if they happen to work with your competitors they will embargo transfers between the respective teams to prevent cross-contamination of IP.
Sophisticated or inadvertent attack insertion

This one has always seemed like a Fear, Uncertainty and Doubt (FUD) campaign to me, but in the interest of being thorough, I'll speak to it as well. It is possible with an outsourced technology development or delivery team to be subject to attack insertion. (Though it's just as possible that these attacks will come from badged employees...)
  • Purposeful, sophisticated attacks - I live in New England, and frequently shop at a local supermarket chain that shall herein remain nameless. They recently experienced a malware attack that resulted in the theft of millions of credit card numbers. This is not common, but the results can be devastating. To prevent this kind of exploit, you have to take a holistic approach to security, and ensure best practices in all aspects of your IT infrastructure. You open the door slightly by having a third party contractor in a position of trust. Ensure that your contractors have gone through the same background checks as your employees. Ensure that security access is granular, and is granted provisionally, and that all high security transactions are logged and scrutinized. If you have an OPD team, quietly ensure code inspection of their work, to guard against backdoor attack insertion.
  • Inadvertent attacks - These are more common and insidious. This hit me once, several years ago, and resulted in me having to take my R&D lab down for several days to patch vulnerabilities in a hundred or so SQL servers. A virus entered our lab network through a secure VPN from our OPD partner's test network. The systems there were not running anti-virus software, because we needed to test (for a variety of reasons) on base operating systems. The net result was a damaging virus infection resulting in the loss of two days of productivity. But it could have been worse if the lab network hadn't been isolated. For this one, certainly air-gap your lab networks, and ensure to the extent possible that all systems are up to date with security patches and other protective measures. In short, do what you already do for your own networks.
Physical security

If you have a sizable offshore team, doing ITO or OPD, you will likely end up with capital assets (either owned or leased) in your offshore center. If those assets are stolen, you will lose both the equipment and significant productivity so physical security within your offshore center should be a concern.
  • Access - Physical access to your offshore development or delivery center should be controlled. Your vendor should not allow unauthorized personnel into your center, just as you would probably not allow strangers into your office building. It will be up to you to work with your vendor to define "unauthorized." I've seen this range from casual (with a receptionist just inside the door smiling at people as they walk in) to formal (with armed security guards who inspect ID, issue visitor badges, and go through luggage looking for disallowed media or other devices). I've also toured centers that don't allow cell phones or digital cameras on-site. You'll have to decide what's appropriate for your business. While I wouldn't recommend this because it might be risky, I've worked with people who visit their offshore center unannounced in the middle of the night and try to "scam" their way into the building. This could land you in a (Chinese / Russian / Brazilian) jail, or you could politely and appropriately be escorted off the premises. Be careful with this one, but it could tell you a great deal about how seriously your partner takes physical security.
  • Monitoring - Access (badge swipe) logs and video monitoring are pretty common in this industry. But cameras are useless if the files are thrown away daily. And access logs are useless if the doors are frequently propped open. Ask to see your partner's policy on video retention, and figure out how long you need them to keep tape. Also, if you care to have a record of entry and exit from your center, physically inspect the site to be sure there are cameras appropriately positioned to see all the doors, that all the doors have badge readers, and that all the doors are kept locked.
  • Access Control - I'll throw this one in under physical security. I have read many times, and my own experience confirms the fact, that the most common attack results from social engineering. I've heard stories of OPD firms who forced their employees to record their usernames and passwords in clear text - in a spreadsheet on a shared drive - so management could control and manipulate access to client systems. This is a gross violation of security best practices. But just as bad is the post-it note on the monitor, with usernames and passwords to various systems. People will always do this, but you can train it out of them, you can force them to change their passwords frequently, and you can implement a good identity management system with single sign on.
Personal security and safety

Last but not least, you should think about the physical security and safety of your employees and contractors.
  • Your offshore center - You should inspect and audit the security at your offshore center. If you get a "bad vibe" about the facilities, you should seek corrective action from your vendor. If your company has a Security Officer, involve him or her in the audit, to get a professional opinion about whether your vendor's measures are appropriate.
  • Your staff, when they travel - You should put some thought into the safety of your staff, if they travel to your offshore center for knowledge transfer, employee exchange, etc. I won't give you actionable advice on this point, but personally, I would think twice about setting up an BPO center in Iraq right now, even if it was free.
I'm sure there's important stuff I'm forgetting, but this list is what's top of mind for me on the topic of security and outsourcing.


First fear, then hatred

I've been thinking a great deal about why technology outsourcing is met with such broadly negative emotion by staff-level technologists in the USA (and probably in most "developed" countries).

This short passage from The Lexus and the Olive Tree by Thomas Friedman might help explain why:

Few things are more enraging to people than to have their identity or their sense of home stripped away. They will die for it, kill for it, sing for it, write poetry for it, and novelize about it. Because without a sense of home and belonging, life becomes barren and rootless. And life as a tumbleweed is no life at all.

Strained prose aside, the salient bit is about how people are enraged when their identity or their sense of home is stripped away.

Globalization threatens people's identity and sense of home. Outsourcing has impacted the American workforce to the point where almost every job in almost every company is changed in some way. This is particularly true in high tech. People believe that jobs have "gone overseas." Whether this has actually what happened or not, the perception is "my job might disappear."

This gets right in the core of people's identity, and their sense of home. For some people, globalization, outsourcing and all that goes with it clearly threatens their identity. If they lose their job, they're no longer "an engineer" or "a developer" or "a Unix administrator" or whatever. And if they lose their job and fail to find another one, they might face loss of hearth and home.

I don't want to write a polemic argument about the validity of invalidity of this line of thinking, but it's important to realize that this fear is real and that in some cases the emotional reaction to outsourcing comes from the perception that it is a threat - not just to work norms and team dynamics - but to sense of self and home.



As anyone who has traveled outside the US in the last few months knows, the dollar is not what it used to be. The graph above shows the dollar's relative strength against the Indian Rupee (INR), the Euro, and the Chinese Yuan. Rather than show the actual FX rates here, I normalized the values for each currency against the value on 4/15/2000, to more readily show the ups and downs (and downs and more downs) the dollar has experienced since then.

If you work on the business side of global sourcing, this probably strikes you as important stuff.

Remember - irrespective of what vendors may say about talent pools or what I myself have said about India, China, Russia, and other locales as centers of innovation - the largest driving force that enables global sourcing and makes it all worth the trouble is labor arbitrage. At the end of the day everyone on the client side of global outsourcing enjoys the benefit of "cheap labor" somewhere else on the planet.

With the dollar shrinking relative to other currencies this "cheap labor" isn't as cheap as it used to be.

Since the dollar is on a down slide (some say free fall) a lot of people have been writing me and asking about foreign exchange, and what it means for their current or future outsourcing endeavors.

My thoughts are summed up as follows:
  • This is opinion only, but unless there is an all out collapse of the US government (in which case our outsourcing contracts will be the least of our concerns) the dollar will eventually rebound to close to historical values against the Euro. Because of the massive growth, FDI and general health of the Indian and Chinese economies, the Rupee and the Yuan will level out close to current values. That is, we're in a bad spot right now, but FX on the dollar will moderate. On this point, only time will tell.
  • Regardless of the outcome of my prediction, you should approach your contract negotiations with the understanding that currency exchange values fluctuate. Playing this market to your advantage in any significant way is most likely beyond your skills. (I say this not to insult the reader, but to simply state a fact that if you could make loads of money in FX arbitrage you'd be a fund manager, not a technologist or a sourcing professional.)
  • That said, you should seek to place the risk of FX fluctuation on your vendor, not on yourself. In my opinion you should write your contracts in your own local currency at a rate you find favorable; and you should not include FX clauses that could hurt you. That way if the dollar weakens your vendor loses margin but you aren't crushed with unpredictable costs. If the dollar strengthens your vendor makes more money but you still have predictability and, ostensibly, a cost position that you are comfortable with. If the dollar strengthens considerably call your lawyers and weigh the benefit of tearing down your term sheet and renegotiating.
  • I've read recently about both clients and vendors seeking to write contracts in Euros, or Swiss francs, or silver ingots, or anything but dollars and rupees. If you do that and are successful, more power to you. But it strikes me as more trendy than smart. Again, keep it simple, write your contracts in your own currency, and pay something you think fair.
  • Don't take on FX risk in your contracts, but don't pinch your vendor so badly that they lose money on you or you won't be a favored client and you won't get their "A-Team."
  • Remember that some costs of your sourcing deals are not actually in the contract and will be subject to FX fluctuation. Mostly this will be travel and capital equipment costs. You might experience these costs in local currency (Yuan, Rupee, etc.) in which case, you will pay more you thought you would for hotel rooms, computers, etc. While this is a real issue, I think it's largely a rounding error compared to other economic forces at work in cheap sourcing locales. While the dollar has slid about 10% against the rupee since 2000, hotel costs in Bangalore have gone up around 400% in the same time period, simply because of high demand and low supply.
  • Lastly, while this stuff is interesting and important, if you're a sourcing professional, a vendor, or the manager of an offshore team, you should focus on your team, and on their performance. If you don't believe me already, I probably won't change your mind with this statement, but cost or margin fluctuation due to FX is not the high order bit here. The potential value you can unlock by making your team solid, cohesive, and high-performing is much more significant than the points you can shave in clever manipulation of exchange rates.

By the way, all the data for my little graph was picked out of Oanda. If you don't know about it, it's a great free site for currency conversion, and is pretty much the gold standard for historical data on FX. (I've always used it to convert my foreign receipts back to USD for expense reports...)

Also of note, the Yuan was pegged to the dollar by China's central bank until 2005. Hence the inflection point in the graph above.


Yellow pages...

So, for those of you who were wondering, I was on vacation last week. Hence the dearth of new posts...

In my inbox when I got back was a message from a friend in the business pointing out this handy on-line directory of outsourcing service providers. It's called "OSourceBook 2008." It is apparently a pay-to-play directory so the results may not be perfect if you're searching for small companies or for companies in emerging markets; but it's a decent search engine. I used it to search by vertical and country for some companies I know well, and they popped up as expected.

You can also use it to search, for instance, for IT Service providers in Belgium (there is one) or for testing service providers located in Iceland (there isn't one). Not many lists of service providers I've seen offer such easy cross-sectioning of the industry.

No affiliation, just an interesting site.


Best Practice - Build a balanced team

No manager I know would ever build a team of junior, entry-level engineers.

But I know many managers who have built offshore teams of all junior staff.

It's hard not to fall into this trap, particularly if you are building your offshore team in India. The job market there is very hot. People get hired very quickly and the engineering population is on average younger than in America. So it's easy to end up with a team of ten software developers where the oldest among them is 26 or 27 years old, with only 4 or 5 years experience.

This team may seem productive but they will not be experienced. They certainly won't be capable of the kind of autonomy experienced by some of the more senior teams you may have worked with.

This best practice is very simple to describe, but a bit harder to put into action:
  • Don't hire all junior staff for your offshore team. Try to build a team with balanced experience. Typical staffing pyramids might see staff numbers something like this.
    • 12+ years experience: 1 or 2 people
    • 8 to 12 years experience: 2 or 3 people
    • 4 to 8 years experience: 3 or 4 people
    • Under 4 years experience: 3 or 4 people
  • This 10 person team would be well balanced and able to handle jobs requiring experience. This team also has enough critical mass to be able to take on one or more "freshers" straight out of college.
  • In my experience, ignoring the top end of this pyramid will result in a team that has excessive self-confidence, and not enough experience to avoid common pratfalls.
  • If you build a team that is too heavily weighted with junior staff, expect much higher management overhead, with the potential requirement for remote micromanagement (which seldom works).


Best Practice - This stuff takes time...

I've written before that companies outsource or go global because they want to be cheaper faster or better. Usually they start with cheaper.

So it's no surprise that they will often add offshore staff (whether through contractors or through a captive development center) and then freeze or reduce staff levels onshore. This is fine except that adding staff offshore is a productivity tax in the short term. So while they're getting cheaper, they're also getting slower and their quality is going down.

In the case where onshore headcount is frozen or reduced, senior managers will often take a hard line on the subject of productivity and quality during the "ramp time" for an offshore team. They'll adopt a both / and approach, saying something like "bring this new team up to speed, but don't let your day job slip."

This approach is bad for a few reasons.

First it creates a perception that managing the offshore team (or ramping them up, or answering their questions, or any of a number of tasks associated with being a global team) is not part of the day job. It should be.

Second it creates a nights and weekends level of priority that will doom the offshore staff to periodic and sporadic responses to their questions. An offshore team in this environment will not ramp up as quickly, and may never achieve their potential.

Lastly that approach creates resentment among the onshore team. I've heard people say things like "Wow, I get all this extra work and responsibility, no extra pay, and ultimately I'm training my replacement. Great!" This resentment cripples the performance of the offshore team while gutting the motivation of the onshore team. A nice two-for-one special, that.

A better approach is to acknowledge that the initial ramp-up and knowledge transfer stage of a new offshore team is a huge productivity tax requiring dedicated onshore resources. Don't do it in the middle of a time-sensitive project. Do it between projects. Or better yet carve out staff to handle the ramp up and keep them out of the critical path during that time. Acknowledge that being a liaison for a group of engineers somewhere else on the planet is a job, not a hobby. Tell people that this is what they're responsible for. If you ask them to do extra stuff (like getting up at 6 AM for conference calls or traveling a lot) give them extra perks (like a new laptop or a one-time bonus). But most importantly, acknowledge and stress that the tasks associated with bringing the offshore team up to speed and keeping them at speed are now part of the day job for the onshore staff. Plan accordingly and don't ask them to layer this new work on top of an already crammed and stressful 50 or 60 hour work week.

Actionable recommendations:
  • Ramp up offshore staff using resources who are not in the critical path for any of your projects.
  • Make sure you and they understand that there will be a productivity dip during the ramp up phase. Remember that your efforts here will control the duration of that dip - but that the dip is inevitable.
  • Don't send the message that managing the offshore team is "extra credit" work. Make it the day job.
    • Create a new job designation or specialization. If someone is the liaison to an offshore team, make them a Remote Team Lead. In your project plan allocate them 100% to the task of leading the remote team.
    • If someone manages an offshore team of contractors acknowledge them with the title of Remote Team Manager. Make sure they get the right training to be effective at that job.
    • Most importantly, make sure everyone in the company knows that managing or leading offshore teams is a real job and that a lot of the work happen outside the core 9 to 5 business hours. Cut these onshore leads and managers some slack on the core hour attendance. If they are doing their jobs well they are working many more hours than what you may see in the office.
  • Recognize and reward the changes you're asking people to make to their work norms and behavior.
    • If you ask someone to be on-call during evening or early morning hours pay them for that on-call time. Give them a $50 a week bump if they have off-hours responsibility. This recognizes that you're disrupting their home life and gives them a cost-effective token of appreciation.
    • Do the same thing when you make someone travel in support of their offshore team. Not everyone on your team will like to travel. Some will hate it. Make it easier and nicer for them. This one is easy. Just say, before they leave: Make sure you get out and do something fun while you're in (India, Russia, China, or wherever you happen to have your remote team). And make sure they know that's code for "have a nice time (within reason) and expense it."