This is a really interesting site, and a very novel idea.

As best I can understand it, ScriptLance allows "buyers" to post abstracts of their coding projects, at which point software engineers get to bid to do the project. The project is "auctioned", and somebody wins the bid. ScriptLance apparently holds the funds in escrow, and pays the programmer when the buyer says the job is done.

It's kind of like eBay for web development.

If this catches on, it will have massive implications to very small businesses, who may want to have custom software development done, but who aren't big enough to have their own IT shop, or aren't located in a city with a local pool of freelance contractors. I'll post more once I've found someone who's had a successful (or failed) project go through this site.


FYI - Some upcoming conferences on ITO and OPD

This is just a quick FYI for anyone interested in furthering their understanding of the outsourcing market, or in having a working vacation day in Boston or Barcelona...

I'm considering attending these conferences:
  • The Mass Tech Leadership Council is hosting "An Unprecedented Summit featuring Political & Business Leaders from three Leading World Markets: China, India & Russia." in Boston, on April 17. It's close to home for me, so probably worth the trip into Boston. YMMV.
  • The International Association of Outsourcing Professionals is having a big conference in Barcelona in the fall. "It is designed to specifically meet the educational and business development needs of outsourcing professionals in Europe by connecting the best in global insights to the very real differences in how companies across Europe approach outsourcing." And it's in Barcelona, which is supposed to be one of the most beautiful cities in Europe!

View of the Park G├╝ell, El Carmel, Barcelona(from WikiMedia Commons)


Best Practice - Swag

I've lived through some tough projects in my day. I've worked crazy hours, gnashed my teeth, and pulled out my hair during the blood-sport our industry calls regression testing. And like most people in this business, I've thought to myself "is this really worth it?" In those moments, I look down at my logo-embossed coffee cup and think to myself... Well, I've got this SuperMegaDynaCorp Network Management Suite 1.0 coffee cup to show for my troubles...

And that has made all the difference.

Seriously, swag may not fuel productivity or loyalty, but it does build small ties between people and companies, and amongst people in teams. Why else would I have received so many t-shirts, mouse-pads, backpacks, and coffee cups with company logos on them through the years?

Swag, in the sense I mean herein, isn't a universally recognized word. It's an American colloquialism, so for anyone reading who hasn't heard this usage before here's what swag really is... I use "swag" because I can't correctly spell tchotchke without great trouble.

This is an easy best-practice to implement:
  • Buy and deliver promotional items for your remote teams. Ship the stuff there if you have to. Better yet find a local producer, give them the artwork for your company's logo and get the stuff made locally. If your remote teams are in Asia, it's going to be much much cheaper to get the swag made closer to your teams than to ship it from America.
  • Make it a point to have swag for release parties or major milestones, preferably with the milestone or release noted on the item.
  • Create an "on-boarding swag" kit so that when you hire a new remote team member he or she gets a coffee cup and a mouse pad (for instance). You may think it's lame, but it's a pretty cool gesture for an employee's first day.
  • If you give away swag (and you should) make sure you do it consistently and universally. I've had situations where one manager was good about this, and seven or eight weren't good about it. That situation created resentment in the seven or eight remote teams that didn't get t-shirts...


Field of Dreams

Apparently, "If we build it, they will come" doesn't work for international airports.

A KLM flight scheduled to land in Hyderabad Sunday morning didn't get the news about Hyderabad's new airport, which came on-line at Midnight Saturday. Apparently they were quite surprised to hear that their destination airport had closed; and they flew around India all night looking for a place to land.

This is illustrative of the massive growth in India (how often does a brand new $600M airport go on-line?), and also the tremendous difficulty of cross-timezone communication...

Here's more about the airport. Glad I wasn't on that flight... Or trying to make a connection through Hyderabad Saturday evening.

And thanks DS, for the the link!

Best Practice - All-hands means ALL

I wrote last week about how you should have the names of all your contract or offshore staff on your Org Chart. The reason for this is that you don't want to send mixed signals to either part of your team about the importance of the offshore contractors.

Following this line of thought, the next practice that managers and executives need to adopt is the creation of inclusive all-hands meetings.

Many times I've seen all-hands staff meetings that exclude contract or remote staff. This is a problem for several reasons:
  • Usually these all-hands meetings are intended to share something about business results or vision, challenges, major milestones, etc. If this information is shared unequally the part of the team that doesn't get the information is at a disadvantage professionally.
  • If the remote team is excluded from an all-hands meeting, that sends a message to them that they are second- class citizens. It sends the same message to the local staff, and believe me, it doesn't go unnoticed.
To sum up my thoughts on this topic: when it comes to all-hands meetings, all means ALL.

This is a "globalization" problem, not specifically an outsourcing problem. It hits any team that spans multiple locations or multiple timezones. When I talk to managers about this, the defense I hear is that multi-campus meetings are just too tough to pull off. I sympathize, but it's still important to try.

Here are a few ideas to try for your next all-hands meeting:
  • Schedule the meeting at a time when all the team - local and remote - can attend.
  • Run the meeting as a webinar. Allow the remote participants to listen in, and enter any questions via the WebEx chat interface. This technology has been around for a while and is fairly mature. This can easily be implemented for a 200-person offshore development center, or a team of five software engineers.
  • Do two (or more) meetings. I frequently chose this approach with my remote teams. I'd have one meeting with the local staff, and then follow it up with a similar meeting with the remote team. I did this when I needed a particularly high level of interaction, which I've always found difficult to do with both a room full of people and a separate crowd on the phone. (The down side of this approach is that the two parts of the team don't interact, but this is sometimes outweighed by the upside of each team feeling a strong sense of commitment from management.)
  • In the case of REALLY big meetings, where there are multiple presentations from multiple speakers, video-tape the event so the remote staff can watch it, if they are so inclined. If you take this approach, you might want to have the remote staff run through the video, then schedule a WebEx or a conference call afterwards so they can ask questions or seek clarification.
  • But whatever you do don't treat the disparate parts of your global team differently. Try to give them the same information. Do it as close as possible to the same time. And give them the same opportunity to ask questions.


The politics of active engagement

I heard something on NPR yesterday that gave me pause.

It was a news report about the recent violent protests in Tibet.

In the report, a Tibetan government official affiliated with the Chinese Communist Party referred to the Dalai Lama, spiritual head of Tibetan Buddhism and the leader of Tibet's government in exile, as "a monster with a human face and the heart of an animal."

All I could come up with when I heard that was: Seriously? The Dalia Lama?

I've seen the Dalai Lama speak. I've read a number of his books. I mean, this guy won the Nobel peace prize. To call him "a monster with the heart of an animal" is a stretch.

We may never know exactly what has gone on in Tibet this week. Maybe the exiled Tibetan government is culpable in the violence. Maybe this is just the latest in a long series of similar events, with newly heightened international scrutiny because of the buzz around the Olympics. Or maybe this is just one slightly crazed Tibetan official with a bad translator.

But a few things are clear: With more and more of their economy engaged in foreign trade with democratic nations, China is going to eventually have to do something to mollify the people of Tibet. And they're going to open up news coverage inside China, and share with the rest of the world an uncensored account of what is really going on there. Otherwise, it's almost guaranteed that the rest of the world won't be comfortable doing business with China.

... or at least I hope that's true.


Action is... his reward.

I spent Sunday of this week at the Harvard Business School's India Conference.

The conference highlighted investment opportunities, infrastructure challenges, and the generally explosive business climate in India today. There were some very impressive speakers, including Alan Rosling from Tata Group, and Vivek Paul, formerly of Wipro fame, now at TPG.

These two guys were great speakers, and said a lot of interesting and insightful things about our business, and about today's India.

But the most interesting speaker at the conference was Sharad Devarajan, who spoke about his entrepeneureal venture with Sir Richard Branson and Deepak Chopra, who got together to form Virgin Comics.

Virgin is putting out a line of comics called "Shakti" - produced in India (story, story-boards, and all the art). As you can see from the cover of The Sadhu pictured below, the art work on these comics is just stunningly good. First blush, I'd say what I've seen is as artfully drawn as Sandman, or anything else I've read for that matter.

Pictured at the top of this post is Spider-Man India, from Gotham Entertainment Group (a precursor to Virgin Comics). In this comic, our friendly neighborhood Spider-Man - Peter Parker - is now Pavitr Pabhakar. In the American comic, Peter is mocked by his classmates for being a bookworm, and studying all the time. As Mr. Devarajan explained, this storyline wouldn't have worked in India, because those are common and admirable traits that simply aren't ever ridiculed. Instead, Pavitr is a villager, living in the bustle of Mumbai. He's mocked for his quaint village ways by all the cool kids in Mumbai. And instead of getting his powers from an irradiated spider, he gets them from an ancient yogi. Oh, and his spidey-toggs are transformed to look a little like traditional Indian garb.

Very cool stuff, and a very cool way to learn about the commonalities between American culture and Indian culture. (...if you happen to be an adult who isn't ashamed to still read comic books.)

Anyway, learning about these comics was worth the price of admission to the HBS conference, and I know what I'm buying myself as souvenirs on my next trip to India.


Best Practice - Fight attrition the old fashioned way...

I shouldn't complain about golden handcuffs. A few times in my career I have been the direct and material beneficiary of retention and compensation policies that "pay to stay."

But I'll speak sacrilege, and state my belief:

Golden handcuffs do not solve attrition problems, they merely mask them.

Think about it -- do you really want someone as part of your team or company if they are only staying because there's so much money on the line? Do you really think they'll do their best - for you, for your product, for your team - if their mindset starts and stops with their "walk-away" value?

There is a better way to fight attrition:

Create something that's cool to be a part of.

There's a decent article here, that talks about why employees quit their jobs. To sum it up, they don't quit their jobs. They quit their bosses. If you read the reasons, and think about the atmosphere they describe, you can come up with a few traits that would describe the antithesis - a job that's cool to have, and a company that's cool to work for:
  • Employees are valued
  • Employees aren't viewed as commodities
  • Employees are treated fairly
  • Employees aren't deceived or lied to
  • Employees understand what's expected of them
Here's the actionable advice:
  • Eschew compensation-based retention strategies. Pay your people fairly. If you can afford to, pay them more than fairly.
  • Make sure "management" knows their role in retention. Make them understand that people quit their bosses more often than they quit their jobs.
  • Make a workplace that's cool and fun to be a part of. Make it such that people like their jobs.
    • Do this for your "local" teams, as a matter of course.
    • Do this for your remote contract teams too, if you want them to be effective.
  • When someone does quit, make sure that you figure out why. When an employee quits, have a manager out of their chain of command conduct an exit interview. Figure out the root cause for the attrition. Watch for patterns. Maybe you have a bad manager who demeans his staff. Maybe you have an indifferent manager who doesn't recognize or reward her team's good work.
  • Address the root cause, not the symptom. Fix the managers if you want to fix your attrition problems.


Best Practice - I am the boss of you

It seems that managers naturally fall into the trap of viewing their contractor or offshore staff as "blocks of capacity" instead of as people. I admit that I have done this myself. When I first managed an offshore team, my Org Chart looked something like this.

After the initial knowledge transfer phrase, that team wasn't functioning as well as I would have liked. There was a a lot of attrition in India. There was a divisive attitude between the two halves of the team. And my staff in India didn't act like part of my team. (These are all common complaints about offshore teams, by the way.)

I asked the management team at my vendor for some advice, and fortunately, they were kind enough to loan me some of their clue. They told me that if I wanted to achieve a virtual team, I had to treat my contractors like equal members of the team. I had to address them by name, and think of them as working for me. I listened to them. After that, my Org Chart looked something like this.

If you use that first Org Chart, what you're telling everyone, usually without intending it, is that the remote team members don't matter - not even enough for us to know their names. They're just interchangeable capacity-blocks. That may be what some people want with their outsourcing practice, or with their global team, but it won't be very effective for a lot of reasons.

I already talked about how it's important to know and to be able to pronounce the names of the people on your team, whether they're local or remote. It's also important to have the whole team, by name, on the Org Chart.

Actionable best practice:
  • Put your remote team members on the Org Chart, by name. Figure out a way to represent that they are contractors, if that's the case, but do it consistently with other contractors in your local teams.
  • If there are reporting structures within the remote team, understand them and show them.
  • Remember, these people work for you, even though they may not have the same company's logo on their ID badges. Make the Org Chart reflect that reality, and you won't send mixed messages to anyone, in any part of your team.
Oh, and if, like me, you're having trouble convincing anyone in your life that you are the boss of them, I made this. I haven't had much success with it, but as always YMMV.

Best Practice - All work and no play...

The mantra of every growth company I've worked at or consulted for seems to have been:

We work hard, we play hard.

You could be cynical and say this is just an unsubtle way for management to extract unpaid overtime from eager young employees. But I really think people like to work in this mode. I know I do. When I was running QA teams, the vital last few weeks of a big release, when I was "on stage" and everyone was putting in huge hours on a tight deadline was the best time of a project. No doubt it was also the worst, most stressful, but I clearly liked it or I wouldn't have kept doing it. It reminded me of finals-week in college. Everyone is stressed out. There's lots on the line. But everyone is in it together.

And at the end, what happens? At least in my experience, when it's all over, everyone goes out together and blows off steam. In software companies, that usually means a release party. The company gets T-Shirts printed. They rent out a bar, or a theater. The executives all stand up and thank everyone for the hard work. And all the smart hard-working people drink lots of beer, eat lots of appetizers, and blow off a lot of steam. And the next week, they start the whole process all over, on a new release or a new project.

This is a time-honored tradition in software companies. Most managers get it, and they get why it's important.

Some of the best managers I've known have taken it a step further -- when their teams are in the crunch-time of a project, these managers start providing little perks... Everyone staying late to work on the project? Alright, say these managers. I'll go pick up Chinese food for everyone.

These little perks, and the big release party at the end, are much appreciated by all but the most cynical staff.

So, how does this apply to Global Teams?

The answer should be obvious -- One global team. If you're working with a team of offshore contractors, you need to make them part of your team to achieve success.

So when you bring Chinese food in for your staff in Boston, you should call your lead in Chennai and ask her to provide dinner to anyone who's working late on that part of the team.

When you give away t-shirts to all your staff in Schenectady NY, you should also send t-shirts to your staff in Mumbai India.

And when you have a huge release party and thank everyone for all their hard work in Austen TX, you should figure out a way to do the same thing for your staff in St. Petersburg Russia.

My global management adaptation of that old work hard play hard chestnut I referenced above is:

We work hard together, we play hard together.

This goes a long way toward maintaining esprit de corps, and keeping your team focused about what's common about their various elements and locales, instead of shining light on what's different.

The actionable advice for managers here is:
  • When your team is working hard, support and encourage all parts equally. Don't forget to offer small perks to the remote members of your global team.
  • When you give away gifts (t-shirts, coffee mugs, etc.) to your team as a reward for great work, do so for the remote members of your global team as well.
  • And when you have a release party, or celebrate a major milestone with your local team, don't forget about the remote team members who contributed to the project. Find a way to celebrate with them as well. Try to do it in such a way that you personally kick off the festivities, over a conference call or video conference. If not, send a note and ask the local leadership or management to read it on your behalf.
Do this, and the global part of your team won't feel like second class citizens. Do it very publicly, and your local team members will start to recognize that the remote team is a vital part of any project or release.


Best Practice - Responsibility

This is one for the managers...

I generally don't like "military" structure, but there is some wisdom in military chain-of-command. After all, the management techniques of armies have progressed in iterative and linear fashion for thousands of years. Corporations have been around less time. So maybe we can learn something from military chain of command.

Here's a paraphrase of something I heard recently, on an episode of the TV show Frontline. Apparently this is something that every commanding officer in every branch of the military has drilled into his or her brain from day-1.

You can delegate authority. You can not delegate responsibility.

That has profound implications to managing any team, and is generally a hard lesson for young managers. In the difficult and politically charged landscape of managing global teams, this truth is even more important to understand.

When I have picked apart failed or mediocre global or outsourced teams, I often hear managers describe the problem in words like "They screwed up." The "they" in that sentence is usually the offshore staff. I've already written at length about how "Us / Them" thinking and language destroys teams. Now lets talk about how "Us / Them" thinking and language destroys managers.

When a manager says "They screwed up" what's really being said is something like this:
  • I delegated authority for some aspect of the work for which I was responsible.
  • The team received the authority and acted.
  • I didn't pay particular attention to what they were doing, because they're supposed to be good at that stuff.
  • They failed.
  • I refuse to accept responsibility for their failure.
  • It's their fault, not mine.
  • So you can't blame me.
Sorry. Management doesn't work that way.

I have some sympathy for this manager. Far too often in this business people are promoted to management for the wrong reasons:
  • Do they have a deep and abiding wish to build great teams? No. Not so much.
  • Are they willing or eager to accept responsibility for the performance of a group of people? No. Not that either.
  • Are they really smart? Usually.
  • Are they great individual contributors? Almost certainly.
  • Have they "been around the longest"? Sadly, sometimes yes.
Perhaps it's no surprise then, that neomanagers shirk the fundamental responsibility of their station. I don't think our industry really teaches that responsibility is the core of management. And I've been in the business for a long time, and it was a Frontline TV documentary on war-crime tribunals in Serbia that exposed me to this simple truth about what it means to command, or in corporate parlance, to manage.

In closing, the actionable best practice here is:
  • If you are a manager, understand that you may delegate your authority. You may allow your team to act with autonomy. But you are still responsible for the work product of everyone who reports through you.
  • If you don't like that, or if you don't want to accept responsibility for the work product of your team, you should change jobs immediately.


Best Practice - Names

"What's in a name? That which we call a rose
By any other name would smell as sweet."

- Romeo and Juliet (II, ii, 1-2)

Really? Not to dis the Bard, but I wonder if anyone ever asked the rose how it feels about that.

Names are the only UID we use on a daily basis, from cradle to grave. Though we seldom choose them ourselves, they're uniquely personal, and deeply interwoven with personal identity. That's what makes the taunts of school-yard bullies so tough to bear. (Editorial Note - I speak from a point of some experience, since "Hickman" lends itself well to a variety of jeers and jabs that I shouldn't get into on a G-Rated blog.)

Suffice to say that few people enjoy jokes about their names.

And yet, it's shocking the number of times I've heard managers and staff in America mock their global peers because of "funny names."

I've heard seasoned managers, people who certainly know better, refer to Chinese members of their remote team as "Ping Pang Pong." I've heard staff engineers who I thought to be decent people refer to their peers in India as "Walawala Washington" instead of "Wadhwani."

I shouldn't even have to point it out, but if you work with someone from a different culture, their name will sound different to you. It might have a lot of consonants, or it might have a lot of vowels, and you might even have trouble making the sounds to pronounce the name correctly. That does not mean you get to make fun of other people's names!

I think it's a lot easier to fall into this trap of mocking people's names when you don't see them face to face. I can't imagine the manager I referenced above - the one who called a Chinese engineer "Ping Pang Pong" ever doing that to one of the Chinese-American engineers who worked in the same office as us. It just would never happen.

But let's think about what would happen if it did: The engineer who had just been mocked would hopefully take the issue to Human Resources. Why? Because it illustrates a basic dehumanizing prejudice, and it creates a hostile work place. Creating a hostile workplace is illegal in America, and the manager in question would hopefully get a warning, and a second chance to never do that again.

I think this name-mocking behavior happens more frequently with offshore contractors, because for starters they are in a subordinate position, as vendors. Secondly, they're remote, and it's easier to mock someone who might not walk around the corner and overhear you.

If you're trying to create a global team, or to create a sense of trust and mutual respect between peers from different parts of the world, or different cultures, you can not let this name-mocking happen, never not once.

Again, to end this Best Practice note with some actionable advice:
  • Never mock your peers or subordinates because of their names. Pick something else to make fun of, like their bad code, their lazy work habits, or their haircuts.
  • Understand that mockery around cultural differences creates a divisive, hostile work environment.
  • Remember that "our" names might sound just as funny to someone in China, India or Russia.
  • Understand that it's acceptable to admit that you have trouble pronouncing names. I've seen very senior executives apologize in advance for not correctly pronouncing names like "Gillenhaal" and "Krzyzewski." People generally don't mind having their last names butchered in these situations, because the Execs are understanding and apologetic, they aren't doing it on purpose, and it the error isn't a point of mockery.
  • Ask your peers and subordinates to tell you how they pronounce their names.
  • Don't be defensive if and when they correct you.
  • Look at this web site - inogolo - A website about not butchering names - for pronunciation clues. This site is filled with a lot of Anglo-Saxon and European words and names, but is slowly filling up with a planet's worth of pronunciation clues.
  • Remember the psychology behind mockery -- It dehumanizes people, and makes them "other" and "different". That's antithetic to "Us" thinking, and it destroys teams.


Best Practice - Inclusive Language

I've written earlier that Us/Them thinking is the cornerstone of success, or of failure, for global teams. A necessary but insufficient prerequisite to Us thinking is inclusive language. This best practice essay will explore a couple of scenarios, and show both exclusive Them oriented approaches, and inclusive Us oriented approaches.

Put simply, in order to build a highly functioning team, both leaders and staff have to steer away from language that puts up a barrier, or creates a feeling of division in the team.

Unfortunately, this is easier than it sounds.

Here's an example of how a development manager might approach a situation with her global team. The scenario is easy to imagine. Lots of developers are working long hours, there's an integration sprint, and work needs to get checked in so an automated nightly build can kick off. The manager, based in the United States, is talking to her team in India, during an early morning conference call.

We build at midnight, and it has to work this time! You guys better not break the build!
  • The approach creates an Us/Them dynamic right from the start. We're building the software at midnight.
  • That's midnight Our Time.
  • And we're worried You might break the build.
  • The manager might think she's doing a good job communicating urgency and holding her team accountable. But the choice of language and tone here creates an adversarial environment.
This simple, 30-second dialog has established a tone that pits the offshore team against the success of the project. Her team has just become a bunch of people who don't trust one another, but who happen to be working on the same code base. That's not a team. It's a recipe for disaster.

An alternative approach, with more of an Us oriented take on the same scenario, might sound like this:

QA is lined up to start testing this release tomorrow, so we have to get a good build today, team! The automated build script will kick off tonight at midnight EDT - what's that, 09:30 IST tomorrow? How can we all make sure that everyone in the Bangalore group gets their work checked in, and that everything compiles cleanly? Does anybody on the phone have any ideas on how we can make sure we get a good build tonight?

Notice a few things in this alternative approach:
  • The dialog conveys the same information, and asks for the same accountability, but the tone is completely different. It conveys a sense of urgency that is shared, not adversarial. We have to have a good build today team establishes that We're in this together, and that it's an important milestone for everybody.
  • The midnight is qualified with a time zone. That's important. Even if you're the boss, assuming that everyone who hears you speak automatically adjusts to what ever time zone you're secretly thinking about is just obnoxious, and it is divisive, and it makes any portion of your team not in your timezone feel like second class citizens. This manager handled the time offset within her team well.
  • Instead of confronting the remote team with a statement that impugns their professional skills, the manager approached them with a challenge to speak up and solve a problem, together. And she acknowledged that she was talking to a room full of people she couldn't see, by saying anyone on the phone. That is a huge motivator if you happen to be sitting in a conference room huddled around a Polycom.
Of those two managers, I know which I'd rather work with, and I know which is likely to be more successful at building a good global team, or getting a good overnight build for that matter.

It isn't just managers who have to pay attention to this Us/Them language. Staff engineers have just as much impact on team dynamic as their managers - maybe more! Imagine the scenario continuing like this:

It's the next day. Romesh, one of the development engineers from India, missed some files when he did his check in, and the build broke. Joe and Brian, both development engineers in the United States get in to work at 10:00 EST and find that the build is broken. They're standing around waiting for coffee to finish brewing when this conversation transpires:

Joe: Did you check mail yet? Looks like the build broke.

Yeah, I looked at the build log. Who's romeshg?
He missed a bunch of files and broke the build.

That's Romesh something or other. He's one of the offshore guys.

Man, they are horrible. Those guys are just clowns. I can't believe management lets them screw up our code like this.

This is clearly not an inclusive set of statements. You might think it doesn't matter how an engineer in the United States talks about a teammate in India. Romesh, after all, is out of earshot. But it does matter. Energy follows thought, and the thought in this case is clearly adversarial. In this case, both Brian and Joe walk away feeling peeved at their Indian coworkers, and feeling victimized by the global contingent of their team.

A better dialog might start the same way, but could take a different turn all together with a little inclusive language:

Joe: That's Romesh Something or Other. He's one of the offshore guys.

Brian: Man, they are horrible. Those guys are just clowns. I can't believe management lets them screw up our code like this.

Andy walks in looking for coffee, and overhears this conversation..

Andy: You both know Romesh. It's not Romesh Something or Other. It's Romesh Gaikwad. He came here for three weeks last fall, and sat in the cube next to mine. We all went out for beers together.

Joe: Oh, yeah, that Romesh... He was a nice kid.

Andy: Yeah, he's a good guy. What's the deal?

Brian: He broke the freaking build, that's what the deal. He blew a check in. Those guys are just clowns.

Andy: So? How many times have you broken the build this release?

Brian: Hmm. Seven. What's your point?

Andy: My point is you should cut Romesh some slack. We've all broken the build.

Alex (the release engineer) walks in, also looking for coffee.

Alex: Hey, I've been IM'ing with Romesh for the last couple of hours. He saw the build log and came in early while we were sleeping to fix his screwup. I kicked off another build a few minutes ago. Should be done soon.

In this second dialog, instead of walking away feeling annoyance at the "offshore guys", the original engineers feel a little shame at judging Romesh unfairly. After all, he screwed up, but no worse than any of the hotshots on the onshore team. And he did the right thing and fixed his screwup, before any of the onshore team even got their first cup of coffee. It was probably hard for Andy to stand up for Romesh in this situation. But he did, and he created a situation that contributed to Us thinking, instead of reinforcing a combative Them attitude.

To boil this down to a few action-oriented sound-bytes:
  • Say and think "we" instead of "you".
  • Remember that working remotely is hard on everyone. Acknowledge it verbally, and try to make the time-offset into a strength.
  • Involve the team in solutions. Instead of demanding performance, ask the team how they can achieve it.
  • Learn the names of your team mates, and don't make fun of their names, even if they sound funny to your ears.
  • Stand up for your teammates. Hold them accountable, but don't create a double standard.
  • Make sure everyone knows that there isn't a double standard.


It's Us or Them

Humans like to flock amongst our brethren. We like to be around people who look like us, and act like us, and talk like us.

Irrespective of my own or anyone's views on the matter, diversity and plurality don't often seem to be the "knee-jerk" reaction of any polity or plurality, going back about as far in time as you might care to study. One Cliff's Notes view of world history is that, well, everybody pretty much hates everybody else, and the rest is just implementation details.

It takes a great deal of open mindedness and a tremendous force of will to overcome this very basic human tendency to carve up the world between "us" and "them." This is stating the obvious, but no matter where you grew up, or where you live, it's just plain difficult to consistently see people on the other side of the planet, possibly with different accents, certainly with different cultural mores, as "the same as us."

It's a basic human tendency to see difference, and to create a taxonomy based on that difference. It's engrained in our language, and it's the foundation of how we reason. And the more I dig in to why good global teams are good, and why failed global teams fail, the more obvious it is to me that this Us/Them dichotomy is a root cause in both cases.

I've written before that "teaminess" is an important predictor of success in global sourcing. I'll now go out on a limb and say that all members of successful global teams identify themselves as "us" regardless of which continent they inhabit, or which company's logo is on their ID badge.

When I've talked to managers and staff about their failed outsourcing experiments, or their disappointing global teams, they always refer to the outsourced team, the contractors, the team in India or China as "them."

The "Us" managers and staff look at their global team and see:
  • Common purpose (We're all trying to ship this release on time.)
  • Shared fate (If we do, we'll all be successful!)
  • Shared skills and education (Hey, cool, we're all learning Ruby on Rails!)
  • Shared experience (Wow, Dilbert is funny whether you work in Bangalore or Boston!)
The "Them" managers and staff see:
  • Sinister purpose (They're trying to get more billable hours out of us!)
  • Opposed fate (It they're successful, we'll lose our jobs for sure.)
  • Disparate skills and education (I don't know what they teach CS majors in India, but my cat writes better code.)
  • Orthogonal experience (I just don't understand how they do stuff over there.)
I've long thought that any organization contemplating globalization or outsourcing of any technology operations should change their hiring dynamics for senior leadership. They should add "experience with global teams" and "affinity for managing and leading global teams" as bullets in their job descriptions, and they should quiz candidates not just on whether they've been involved in setting up a remote global team, but whether they enjoyed the process, and what they learned through it.

I still think that would be a good start, and could help secure talent with the force of will necessary to create an "Us" environment. But I think the hiring dynamics have to change deeper into organizations.

I've worked with engineers, smart, talented people with great experience, who are totally close-minded about globalization and outsourcing. In varying degrees, they view people anywhere else on the planet as incompetent, unintelligent, and "out to get our jobs." In my experience, people who approach globalization and diversity this way will never change. They start any effort with a chip on their shoulders, and they are poison to a team. They create a divisive environment, and they become a nucleation point for a "Them" mindset that will all too readily take over a team, and turn it into a group of adversaries.

Maybe, to address this problem, organizations should start interviewing for "multi-cultural" skills, as well as coding talent. Maybe they should look at world travel as a predictor of success in a global team. Maybe they should look for people who speak multiple languages already, on the presumption that this is correlative with embrace of other cultures. Or maybe they should just tell prospective employees that they will be traveling to India a lot, if they take the job in question.

And if the people are already hired, and are creating a "Them" team, I suggest that the organization in question has a tough decision to make. If somebody is creating, contributing to, or condoning a "Them" mentality, he or she has to go. Whether through termination or reassignment to a purely local team, that person shouldn't be allowed to work in a global context. But if they stay on the global "team" they will destroy it slowly.

Sadly, in software as in many human endeavors, it seems only to take a little bit of "Them" thinking to destroy a whole lot of "Us."