Tag Archives: Offshore Traps

The Bottomless Pit of SEO

bottomless-money-pit-seo-If you are a novice blogger, an affiliate, or plan to make a killing by placing Google ads on your site you may believe that SEO will bring you tons of money. It may, but unless you watch every step and invest a great deal of efforts in building the traffic, it won’t.

A couple months ago I started a mid-sized SEO project. I guess by now, after going through a few dozens of SEO engagements I should not be too worried, yet I was. The SEO world has changed a great deal since my last project. Also this time I needed to start from scratch – new site, new for me, very competitive market, and as usual very small budget, both in terms of money and my availability. So, eLance / oDesk here we come.

As it’s typical for SEO engagements I started getting responses to my project almost instantly after I submitted it. 20 or so proposals came in the first hour, about same in next 24 hours, and about a dozen afterwards. Most of the proposals came from India with cost ranging between $5 and $15 an hour. Pretty much all proposals I got were boilerplate documents some of which were slightly modified to acknowledge my name and the project. For follow up I picked about 10 companies with near perfect rating and high number of hours billed in the last year.

Continue reading

Communication Failures in Outsourcing

It was Malcolm Gladwell who introduced me to Geert Hofstede’s concept of the Power Distance Index (PDI). After I read the chapter seven of Outliers I had to stop to catch the breath, it was just too exciting. Implication of PDI on cross-cultural communications is immense and it has direct relevance to outsourcing, and I’ve observed over the years. It’s something that you most likely dealt with as well. I did a bit of research and realized that I am far not the first to discover PDI’s impact on outsourcing, for example, this post offers great insights on PDI implications in the world of software development.

The idea behind PDI is quite simple, a perceived “distance” between a boss and an employee varies dramatically based on culture, biases, heritage, etc. The “distance” is defined as measure of how a person would generally react / respect / deal with a person of authority. The PDI is a measurement of that “distance”; it ranges from 1 to 120, the bigger the number the bigger the distance separating a boss and an employee. Small distance puts both boss and employee on very much the same floor of a corporate pyramid. As the distance grows the boss moves in a corner office or on the top floor, becomes master and commander, royalty and at some point a divine authority. While in cultures with small PDI an entry level employee can have a chat with CEO in a cafeteria, even just a single step in a corporate ladder can create master / slave relationship in cultures with high PDI.

In cultures with low PDI communications between a boss and an employee are quite different from countries with a high PDI. If you, an employee, are very much at the same level as your boss in terms of cultural hierarchy, you do not perceive any significant distance or differences with your boss and you tend to collaborate. A straight forward question gets a straight forward answer. If your boss is wrong you tend to have no qualms about pointing it out. And your boss expects you to. There are of course variations based on company settings and individual preference, someone might say to the boss “I respectfully disagree” and someone might use much less politically correct language. Moving up in PDI would convert collaboration into discussion akin to a military style of orders. Going higher in PDI changes a conversation into a dialog that for most of people from the Western world would be impossible to decipher as instead of a straight forward answer a response comes in a form of hints surrounded by layers of polite blabber, well, at least that is how people from low PDI cultures see it.

Interestingly enough high PDI doesn’t create too many communication issues between people from the same country. The traditions and unwritten rules of communications are well understood and do not present obstacles. Not always though, see some examples in Outliers, they are stunning and illustrate how high DPI drives catastrophic outcomes. And situation gets substantially worse when it comes to cross cultural communications, that’s where miscommunications and mutual frustration proliferate.

When we consider a typical IT outsourcing initiative in this country we face significant differences between buyer (boss) and supplier (service provider) – USA (40) vs. India (77) or China (80). It is not surprising that communication issues in all forms and shape plague the vast majority of outsourcing engagements. Even though I do not necessary agree with conclusions of The Real Reason Outsourcing Continues To Fail, blaming it all on PDI is an unjustified simplification, I believe PDI-related issues contribute a great deal to many of outsourcing engagements failures.

To minimize the damage that PDI difference can inflict on your engagement you need to deal with it on several levels:

  • Educating your staff, in particular local low-PDI employees.
  • Developing communication vehicles that inhibit PDI-related miscommunications.
  • Adjusting SDLC to minimize potential damage and inserting elements minimizing the impact.

That might be easier said than done, but there is no way around it. Left to themselves things tend to go from bad to worse.

PO Trip Adviser: China

And now a brief list of travel tips for one of my favorite destinations – China, the country that changes with amazing speed right before our eyes.

If there is anything that I regret about traveling to China it is not spending enough time there, not meeting enough people, and not seeing enough places.

I remember sitting on the Great Wall looking at the hills that look exactly like those on ancient paintings and thinking that for many Americans visiting China could be experience equal to visiting a different world, another planet… Well, that’s also changing rapidly.

  • A Visa is easy to get, but it may take a few weeks so allocate sufficient time. Also make sure that you have the travel plan worked out before you apply for Visa as you may need several entry authorizations as cities such as Shenzhen require special handling.
  • The most difficult aspect of traveling to China is language, very few people speak any English and you won’t find too many signs in English either. As a result public transportation even inner country air travel becomes challenging.
  • China is a reasonably safe country, and when it comes to main outsourcing destinations within country is very safe.
  • With petty crime on a raise you should be aware of environment and follow common sense practices such as not carrying large amount of money, protect your passport and valuables, etc.
  • The police in China are generally very friendly, though they speak very little English except in Beijing, Shanghai or Shenzhen, where some police can generally speak simple fluent English. If you are lost then ask for directions as they will usually be happy to help.
  • Stay in 4-5 star hotels remains relatively affordable. That will also ensure English speaking staff, access to tours, restaurants, etc.
  • Driving in China is somewhat strange experience – on one hand I was surprised with how closely some laws are followed, e.g. the speed limit – most of the cars travel ~5 mph below it. On the other hand I saw a lot of erratic moves and turns that were not aggressive just plain dangerous.
  • Sightseeing in China can be easily arranged with the help of the vendor or hotel staff. Keep in mind that most of professional tour guides are in cohorts with retailers specializing with ripping off tourists selling you “traditional” china, tea, souvenirs, etc. at 3-5 times the price you can get them elsewhere.
  • Eat only in good restaurants or at your hotel. Avoid eating buffet meals, even in high-end places. Not only drink bottled water, but also brush your teeth with it. Most of hotels provide bottled water for free. In restaurants I recommend boiled water / hot tea.

Of Frogs and Wrestlers

So you found a new vendor, negotiated a perfect deal and established relationships with key players. The team starts its work and shortly you can realize the savings you’ve been looking for. A year passes faster than you could ever imagine. Reports coming from the vendor showing good compliance with the benchmarks you established. You about to give yourself a pat on the back for being such an incredible offshore manager. And just to be a good sport you take a few business users for a dinner to share with them the wonderful achievements of incredible you.

Unfortunately even before you are done with the first round of drinks the conversation takes a rather unpleasant turn. No, they are not happy with both the quality of work your offshore team has been providing and their productivity. They are afraid of changes to be done to the systems your offshore team supports, they do not submit bugs because they are afraid that fixing one new bug would re-open a dozen of old ones; they do not enter RFEs because they do not believe they would ever be delivered, and so on.

What just has happened? All that rain on your parade is coming from a completely left field. Continue reading

Offshore QA and a Sly Fox

A fairly common model for working with an offshore vendor for SaaS companies is based on black box model – the requirements collected locally go to offshore team and code ready for production comes back, sometimes in a form of binaries. There are variations to that model with the same common thread – the full responsibility for development of the application and its quality assurance belongs to with the vendor.sly_fox

Can this approach work with an arbitrary software development shop? Absolutely! As a matter of that is the model used by all ISVs that do not employ offshore, so model works for sure. The question is whether offshore components in that model make the difference worth discussing, and unfortunately they do. The fundamental laws of outsourcing (FLO) affect efficiency and reliability of the model to a great extend, often making the model completely unreliable.

There are so many things that can go wrong inside of the proverbial black box turning it more into a Pandora’s Box:

  • Communications issues and information loss at every handover
  • Ever deteriorating quality of the resources
  • Inevitable deterioration of the quality of code
  • Growing blind spots in test coverage
  • And so on – you can continue this list ad nauseum

Continue reading

Offshore BC & DR

Thinking about Nostradamus predictions for 2012 and all cataclysms that will strike that year? Afraid and developing your bullet proof Business Continuity and Disaster Recovery (BC&DR) plans? Well, if meteors, super-volcanoes, and melting ice caps flatten, burn, and flood most of humanity those BC&DR plans won’t matter much. However, increasingly more powerful floods, hurricanes and earthquakes with enormous toll remind us about vulnerability of even rich nations such as the USA, Canada, or China…

As I pointed out in Force Majeure working with offshore organizations increases risk of substantial losses bring up the importance of having solid BC&DR plans. Of course if you are working with a mature offshore partner they would have their own BC&DR plans. That’s great with one important caveat – will these BC & DR plans work when needed?

It was not long ago when supposedly invincible 365 Main Data Center in SF went lights out for a considerable period of time after a scheduled (!) black out. So there are a number of questions you need to answer:

  • Does you offshore vendor has solid BC&DR plans?
  • How often are theytested?
  • What are the KPIs / metrics associated with these plans?
  • Are those metrics sufficient for your business?
  • Who audits these plans and activities? (You won’t take the vendor word on it, would you?)

Well probably the first set of questions you should address to yourself or your IT team responsible for BC & DR. Interestingly enough for many, especially small companies the answers from internal team are likely to be much weaker than those from offshore. And as a matter of fact for some offshore is the BC & DR plan.

After you covered two main points you need to check the route between them. There are many aspects to connectivity between offshore and onshore. Things can get lost on the way, connectivity may drop (if major cables are damaged for quite some time as it happen with India couple years ago). But even more important is to make sure that was sent to you is indeed what you expected and that it is what you received. Wrong code pushed to production (happens even to Google) is sometime more serious disaster than interruption in service. That gets into an area that deserves a lot of discussions by itself – QA and in particular acceptance testing. I will cover it in a couple of posts in the future.

One more major aspect to consider – what if the relationship between you and the vendor go sour? In one or another way – you did something wrong, vendor decided to rob you of your IP, etc. There are plenty of sad examples. That kind of disaster is most difficult to deal with. And with them being as unpredictable as the Acts of God you should have solid BC & DR plan for that as well. Starting with solid contractual framework, appropriate and frequent archiving, and so on. Yet you can’t be ready for everything – losing key resources, knowledge transfer cost, etc. Not easy to deal with, sometimes practically impossible. However there is a good news, when it comes to these kind of diseases I know very reliable medicine – Disposable Outsourcing.

Environmental Fears

As I mentioned in At Doorsteps of a New Engagement I have a new vendor to deal with. It is a company that has been working with my team for over two years and thus it’s only new for me. It took about a few days for me to encounter the first set of issues. And that set came from the area so common that it’s worth a post by itself – software environments. Below is an email which I was cc’ed on –

Subject: RE: WCM Publish failed

Ravi,
Please explain to me how the production environment does not match what is in UAT. This is unacceptable and must stop. This is not the first time a production turnover did not match UAT.
We need to review our build, turnover, and documentation procedures. This pattern cannot continue.

Looks familiar? I am sure it is…

If you are in business of delivering software as a service or similar to it the chances you will have the following environments: development, QA, staging, production, disaster recovery. You may also have dedicated environments including Build, UAT, Sand Box(es), Performance Lab, etc. If you work with offshore team the chances are some of those environments are duplicated in the offshore offices.

A number of issues arise as environments proliferate:

Continue reading

Bidding Sites and Building Frustration

A couple weeks ago I put an RFP out for a very specific set of SEO activities on one of bidding sites. This SEO project was for my darling app – WWHOW!.  Since WWHOW! is based on user generated content it offers serious SEO challenges. Having spent a few months fighting those I knew fairly well what I was looking for and did not make a secret out of my expectations. To no surprise my straightforward SEO request generated a lot of responses primarily from India-based providers. I just finished going through all responses I received to date and it looks like I will have to go through bid-response process again, maybe I have to try a new bidding site, maybe change my request format, content, layout… Frankly, I doubt that changing much on my side will affect the dynamics of the campaign and quality of responses. I might need to change the target development community…

The fact that I received not a single proposal that I could remotely go with was quite irritating. One of the reasons I was annoyed by it is its effect on my “buyer’s reputation”. In some way majority of established bidding sites penalize buyers for not accepting proposals. Some of them will even cut buyers off if they do not meet some criteria, e.g. certain percentage of project acceptance. It appears that they will cut you off independently from the reasons you do not accept the proposals. It happened to me on www.eLance.com a little while ago and since despite multiple attempts I could not reach the customer service I ended up moving to another bidding site.

Continue reading

More Thoughts on ESL

A while ago when still a student I stumbled upon a great supplemental income opportunity: a friend of mine, an editor in a science journal, was looking for part time interpreters. The task was quite simple: writing summaries of technical articles. To me my French even though practically non-existent seemed strong enough to do that maybe, just maybe, with some support of a dictionary. I stopped at my friend’s office and he handed off to me a half a dozen articles on various medical topics. I was quite flabbergasted and asked – why medical? I am a technical guy. Math, engineering, maybe software, but why medical? My friend just smiled – if I give you articles in your specialty I will only get back what you know of the subject, chances are, that everything new and or controversial will be missed, and that’s assuming that you know French well… After a few nights of checking every word in a dictionary and still not being able to put the puzzles together I decided to switch to different means of making money.

I have seen the same phenomena with many technology professionals for whom English is somewhat of a struggle. They often step back and rely on their technical skills in understanding their client needs, interpreting the information inflow, often to the detriment of the project. That in particular common for advanced ESLers. When working face to face with native speakers and not communication related misunderstandings are easier to address, non-verbal language and timely feedback are of great help in this case. When you introduce the offshore factor, the time and cultural differences on the top of language handicap communications mistakes accumulate and widen the gap in understanding. Technology professionals have a tendency to bridge the gap with things they are familiar with and make decisions on behalf of the client.

Dealing with this issue requires efforts on both sides and unfortunately there is no panacea. Trying to get every assumption documented and signed off is a recipe for a productivity disaster, leaving things up for interpretation by developers is asking for even more troubles. Many of the tools I find helpful and efficient in this case come from agile development practice, in particular short release cycles and frequent demos.

Of course learning English remains to be one of the most important tasks on the provider side. But with over 600,000 words it’s easier said than done. Classes and books will only get you a fraction of the way there. What can one do to continuously advance in that utmost important skill while keeping they day job? We take our chances and use different methodologies. For me motivational tapes from Brian Tracy, Zig Ziglar, and Anthony Robbins were the main tool not only in building the vocabulary but changing my Russian gloom and doom attitude. Some people listen to NPR some watch a lot of movies. Having mentioned that lat me share with you a story I hear from Kirill (offshore development manager for a large s/w company on weekdays and my blog reader in his spare time). He told me about a Russian developer manager who took watching movies to heart; he also combined business and pleasure and watched primarily action movies. Being very gifted in terms of language he built broad vocabulary of words and idiomatic expressions, a lot of idiomatic expressions unfortunately mostly borrowed from Dirty Harry wannabes. That did not do him particular well :( If you are working on your language skills here is Kirill’s advice –

One of my guys in St. Petersburg has outstanding English and I asked him how he had mastered it. He said that he listened regularly to free podcasts at www.eslpod.com. I checked the site out and downloaded tons (close to 5G) of historical podcasts. Topics are pretty basic, but the language they use and pronunciation is very good. I wish I had something like this when I just came over here :)

Well, as the say it’s better late than never – I’m signing up …

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to Ma.gnoliaAdd to TechnoratiAdd to FurlAdd to Newsvine

Offshore Impact: Personnel Issues

So you are moving forward with offshore initiative, maybe a new or expanding an existing one. What is going through the minds of your team members? What kind of questions are coming up? What is not letting them sleep at night? That’s not difficult to imagine:

  • Is my job at risk?
  • Is my salary at risk?
  • Is my career at risk?
  • Is my quality of life at risk?
  • Is my project / department / team at risk?

Let’s start with a reality check: chances are there will be three groups of people easily categorized by the answers to these questions – Yes, No and Mixed / In between. There will be people who can lose their jobs or forced to take lower paying jobs. Transferring jobs offshore may reduce scope of career opportunities or completely eliminate some. Some people might be asked to work odd hours, and so on. Maybe some of the team members won’t be affected at all. And for some there will be a mixed impact. That impact on employees inevitably affects the employer, and as I pointed in my earlier post The Darkest Side of Outsourcing that impact could be very serious. That’s why minimizing negative impact of personnel issues is likely to become your primary objective as an outsourcing champion or the manager in charge.

One of the ways to do it is to tune into your team’s WII.FM station. What’s In It For Me? What is the silver lining of the offshore initiative for your team members? That of course depends on specifics of your organization and the scope of offshoring; here are just a few general ideas for your consideration:

  • Offshoring might offer an opportunity to offload grunt work freeing up employees to work on more interesting / engaging projects.
  • In similar manner offloading grunt work may allow organization and its employees to focus on core strengths and areas of competence.
  • Sometimes offshoring opens an opportunity for the employees to learn new technologies / products.
  • Management / leadership opportunities can open up.
  • Specifically offshore management opportunities could be attractive option for career development. With offshore here to stay experience with offshoring can benefit many employees even those not involved in management / leading roles.

Let me repeat something I mentioned in The Darkest Side of Outsourcing: Associating introduction of offshore with layoffs – replacing local workforce with offshore resources is a double hit on remaining workforce with inevitable impact on employee morale and overall workforce quality:

  • Employee motivation will disrupted with result in increase in political behaviors, anger, fear – which is likely to negatively impact quality of customer service, performance decline, and decline in quality of work atmosphere.
  • “Survivors” experience more stress due to longer work hours with re-designed jobs, and increased uncertainty regarding future downsizings.
  • Senior and the most marketable employees may leave with result in decline of overall quality and qualification of workforce and loss of institutional memory.

A silver lining here is an opportunity those events could represent for some of the employees: an opportunity to show one’s ability to excel under pressure, a chance to step up to challenge and learn new product, skill, fulfill the void left by departing employee.

In my experience I’ve seen that on numerous occasions – a problem creating a launching pad for capable but for some reason unnoticed or underappreciated employees.

The question is whether as the leader of organization you can carry on positive message and motivate the troops to take advantage of the opportunity rather than dwell on native events and unforgivable loses. Another question is whether you can deal with inevitable negativity and ripple effect of the changes. Here are a few things to consider for dealing with the personnel impact:

  • Consistent non-stop communication. Check out 7 Cs of communications and follow those as much as you can afford considering the situation.
  • Consistent aggressive motivation. “Motivation is like food for the brain. You cannot get enough in one sitting. It needs continual and regular top up’s.” [Peter Davies]
  • Be prepared to pay above market. Hopefully offshore cost savings can offset some of the cost impact.
  • Invest heavily in the staff redundancy. That is a complex issue that requires longer discussion, let me just mention just one aspect of it: staff redundancy will give you the confidence to operate in the challenging environment that offshoring is likely to create in your organization.
  • Process and methodology changes / adjustments / improvements to create environment tuned to the new organizational layout.

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to Ma.gnoliaAdd to TechnoratiAdd to FurlAdd to Newsvine

The Darkest Side of Outsourcing

While writing a post on a topic of personnel impact of the offshore outsourcing I had to go through a rather unpleasant exercise – I had to terminate one of my employees. Termination is never fun, it is particular painful on a backdrop of economy downturn. Through my career I had to let go a great number of people, mainly due to the industry’s downturns / massive layoffs. Layoffs are painful yet the sheer size of the event makes it easier on everyone. Things tend to go much more close and personal when you have to let go someone on a performance basis.

Reaction of the person being let go on a performance basis is very difficult to predict and control. I have seen budges fly in my face, verbal explosions and threats, I have been in situations when I had to call security and once got very close to calling an ambulance. This time it did not go particular well either. The employee got agitated, angry and quite upset with the unfairness of the event. After the termination the direct manager of the employee and I started receiving harassing calls from a blocked number on our personal phones…

Sending jobs offshore is likely to create a few enemies. For example when I introduced offshore concept in Spear Technologies one of my key employees came back with a common in this case blackmail techniques: “I’ll quit”; he did not, just remained never ending pain in the neck. Two other people quit citing offshore decision as one of main reasons. If sending jobs offshore means layoffs things can get quite ugly. Especially if the laid off employees are picked on a performance basis, what is quite typical and the right way to go, especially in smaller companies.

Performance based termination rarely goes well, and sometimes goes exceptionally bad. It was not long ago when a laid off employee took lives of executives of his company in a Santa Clara startup. As my CEO put it “There is too often a thin veil that covers members of society and when the wind blows, the veil can come off. After 10 years in the emergency department I can tell you that apparently senseless violence is hardly rare. The details of this occasion are making headlines but frankly not the violence. Very sad to me is not just the violence but the lack of priority or even care for this guy’s own family. He destroyed more lives than he ended.”

I’ve written about potential pitfalls of outsourcing and will write more. You should move carefully and make educated steps when outsourcing, if your offshoring decision is causing / associated with local job losses be exceptionally careful. You could be making the decision based on spreadsheets and what if analysis, for better good, the company survival and bottom line needs; for you that might mean “nothing personal” yet for those who are about to face job search in today’s market it will be very personal. To minimize potential backlash consider a few general tips:

  • Deliver clear and consistent communications with messages covering reasons, expected goals and objectives, as well as processes behind. The communications should in general precede the events and continue on long past them.
  • Do not cut the jobs across the board. Rather, make the tough decisions to selectively cut jobs. Do not disguise performance based termination as layoffs.
  • Focus on those who stay, yet remember that “survivors” will judge you / organization by the way layoff was conducted and downsized employees were treated

Associating introduction of offshore with layoffs – replacing local workforce with offshore resources is double hit on remaining workforce with inevitable impact on employee morale and overall workforce quality:

  • Employee motivation will disrupted with result in increase in political behaviors, anger, fear – which is likely to negatively impact quality of customer service, performance decline, and decline in quality of work atmosphere.
  • “Survivors” experience more stress due to longer work hours with re-designed jobs, and increased uncertainty regarding future downsizings.
  • Senior and the most marketable employees may leave with result in decline of overall quality and qualification of workforce and loss of institutional memory.

This post was not intended to be “all gloom and doom”. Not many people make offshore decision just for the fun of it. Outsourcing is only one of the tools IT leadership has at its disposal today and as any tool it has its dark side. Knowing that side should help you apply the tool properly and minimize collateral damage.

And the last tip for now – if you are planning to replace some of your local underperforming workers with offshore resources get unlisted – make sure that your personal contact info is not in company directory, white pages, linkedin, resume, etc. – not a trivial task nowadays…

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to Ma.gnoliaAdd to TechnoratiAdd to FurlAdd to Newsvine

Using Agile with Offshore

One topic that often comes up with relationship to outsourcing software development projects is the use of agile methodologies. Having run a number of projects using agile methodologies with offshore (nearshore) partners I found that some of the classic principles do not work as well, for example XP’s “pair programming” and “moving people around” need to be taken with a grain of salt / adjusted with consideration of the lack of collocation.

Of course when it comes to agile development you need to start with agile evangelists’ take on the subject. Martin Fowler in what is now a classic article Using an Agile Software Process with Offshore Development covers 14 major lessons learned:

1. Use Continuous Integration to Avoid Integration Headaches
2. Have Each Site Send Ambassadors to the Other Sites
3. Use Contact Visits to build trust
4. Don’t Underestimate the Culture Change
5. Use wikis to contain common information
6. Use Test Scripts to Help Understand the Requirements
7. Use Regular Builds to Get Feedback on Functionality
8. Use Regular Short Status Meetings
9. Use Short Iterations
10. Use an Iteration Planning Meeting that’s Tailored for Remote Sites
11. When Moving a Code Base, Bug Fixing Makes a Good Start
12. Separate teams by functionality not activity
13. Expect to need more documents.
14. Get multiple communication modes working early

That list presents a great set of guidelines, and none of them are in the conflict with foundational principals of agile development. Some of them are unfortunately in a conflict with realities you might be facing on your project.

Let me start with items # 2 & 3. That is an absolutely correct way to improve communications – make the offshore as onshore as possible by swapping people, putting semi-permanent representatives on both sides of the ocean, etc. The problem with it is that many companies, especially smaller ones can not afford this approach. Bringing and offshore person on-site roughly brings his/her rate to what you would pay a local resource and for any considerable length of assignment is likely to cost even more than local resource. Sending your local resource offshore increases the cost substantially. Personal life of ambassadors is likely to be affected not necessarily in a positive way. To minimize the impact you might consider younger ambassadors however a lack of experience may defeat the purpose. Once again, I can not agree more with both techniques yet the chances are you would have to compromise on those and thus creating inevitable negative impact on the project.

# 4. To some degree this section plays down an obstacle that could be an agile showstopper. Martin Fowler presents a few interesting examples of cultural challenges that his team successfully overcame. You might have not as much success with it, especially when working with a third party provider rather than captive resources. Try “anti-authority attitude” with any top tier vendors in India, see how far you get – and do please let me know. Also, there is much to be said about forcing foreign culture onto people who will have to stay in the society that doesn’t support it.

There are of course many others cultural challenges that deserve a serious discussion; let me just touch on one: some people call it “having Agile in DNA”; some call it “agile aptitude”. That would be a topic for a very long discussion; for now I will cut it very short: some teams are just not made for agile; and that is a cross-cultural phenomena. The culture puts its additional imprint on the issue with deeply embedded cultural traits such as conflict avoidance, hierarchical structure, meaning of respect, etc. you often find offshore. Unless you have the luxury of building your own team you would need to asses the team’s ability to go agile and your ability to guide it thorough. In some cases you will find that being practically impossible. If ignored or not handled properly subtle sabotage will find its way to the surface through malicious compliance and will bring your project to a memorable fiasco.

# 9: Short iterations have a great positive impact on the project and alas high overhead as well which exacerbated by offshore communication challenges, time difference, logistics, etc. could be unbearable. In my experience two week iterations presented a reasonable minimum.

#12 & 13 get us into a line of fire of the holly war between agile and waterfall :) And in my opinion that is as productive discussion as the “mind over matter” (by the way the later one has been solved: “if you don’t mind it doesn’t matter”). This is not an argument anyone could ever win, there is a place for agile there is a place for waterfall, and everything in between. Pick the best tool for the job, adjust your methodology to accommodate for organizational requirements, environment and team at hand… of course “If the only tool you have is a hammer, you tend to treat everything as if it were a nail” [A. Maslow]

I think it’s enough of picking on the celebrity, time for a couple observations of my own:

Minimize the time gap. You can find many blogs and articles that talk about the time difference as an advantage, what a joke! 11.5 hrs time difference with India can easily result in 48 (business!) hours delay in resolution of urgent issues. If agile is your chosen path consider minimizing that gap; your best bet could be a nearshore offering, or farshore partners who understand the value of team overlap. Some of my favorite vendors take this issue on with a vengeance starting work hours for their employees at noon local time; interestingly enough that gives them some add on benefits such as less challenging commute.

Pick only engineers with fluent English. That one seems like a no-brainer yet you will find a lot of push against it if you deal with pretty much any geography outside India. The meaning of “all our engineers read and write technical documentation in English” translates from Vendorian (the language vendors speak) as “some of our engineers went through English boot camp when in college). While that could be a manageable obstacle for teams operating as a black box or in a well managed waterfall that will be a showstopper for a mixed team agile project.

Select developers with approximately the same skill level with exception of very few on a high and a low end; the ranking for those exceptions must be clearly understood and communicated across the team. That one cuts deep in the heart of some agile practices and beliefs so I have to put a couple thoughts here:

In software development all engineers are equal and some are more equal… The difference in productivity and quality of code for strong developer and average one could be tenfold, expecting them to work together is like expecting turbocharged Porsche and limping horse powered carriage travel together in an autobahn. If you build your team with the best and the brightest chances are they could be equal even if their experience is at different level: a bright engineer will have no problems stepping aside in a face of reason or experience. When freedom of expression is given to an average or a mediocre contributor on team that also has high quality developers the result is predictable – it’s either beat him into pulp or produce code at average or mediocre level.

There are many other negative trends that naturally develop in teams with wild mix of skill levels – cherry picking, slavery, slacking off – just to name a few. By no means I am advocating for arbitrary hierarchy though… In my experience the best agile teams are formed by like-mind professionals of approximately same level of skills gathered around a top notch technical leader.

Adding offshore spin on the requirement to keep developers at approximately the same skill level adds a huge challenge to the team building process, especially in hierarchical societies or/and organizations.

Build a team. Easier said than done, and that’s why it is my favorite craft. Building teams with offshore components elevates the complexity of the task to a completely new level. When it comes to agile development building a team from a group of people working on the same project makes all the difference; the difference so profound that it feels like magic. The good news is that you do not need to graduate from Hogwarts to be successful at building balanced teams that perform well on agile projects. OK, this topic requires much more than just a couple paragraphs or a few posts, maybe a very active stand-alone blog can give the topic the justice it deserves… For now let me just mention my formula for success :)

nsf

Establish solid project management. A dedicated PM is an absolutely critical role on an agile project of a decent size. This role becomes twice as important when the team is not collocated and another tenfold if the team spans countries. Strong s/w PMs are a very scarce commodity though. It takes solid technical knowledge, superb PM skills and personality match, considering limited pay rate and unlimited challenges – it’s no surprise they are so difficult to find. By the way, when it comes to agile projects I would take certified PMP and get him/her to learn SCRUM (or whatever the methodology is) over SCRUM master in 4 out of 5 cases. Not sure whether I am jaded or just biased. Having interviewed hundreds PM through my career that so far has been my experience.

Continuously improve the process. There are many techniques that will help you to do so, iteration retrospectives is one of the easiest ones. My teams use round table discussion approach with everyone presenting keeps and tries that are captured and tracked by the PM. Tracking is essential as even great ideas tend to get lost unless there is a driving force behind it.

And the last one for now: do not compromise on tools. Agile teams have all too common gravitation towards open source. That’s commendable yet needs to be taken with caution. More so, when it comes to development tools open source doesn’t always mean the best or even “good enough”. Some tools supported by gainfully employed professionals offer impressive value and are substantially more reliable than those supported by the community. For example my team after numerous attempts to work around some limitations of CruiseControl settled on Bamboo with notable impact on productivity. Same goes for many other tools (CI, Testing, Code Review, Wiki, etc.), so do not compromise on them, pick the best you can afford.

Well, with all those caveats and warnings you might think that agile and offshore do not mix. I would not say so, while running agile projects with distributed teams is not a trivial exercise it could be productive, efficient and a lot of fun. Given the right opportunity I would do it a heartbeat.

Once Bitten, Twice Prepared

A couple weeks ago I found myself in a typical Silicon Valley party with at least 50% of attendees from local technology start ups. Someone offered “offshore nightmares” as a discussion topic, that turned out to be a great icebreaker as everyone of us had a few of those laughs & tears stories to tell. More tears than laughs I have to say. Among the stories there were a few common threads; one of them was very close to my heart and painful experience – a practice of misrepresenting developers’ competence popular among some offshore providers.

  • Joel: we selected a vendor based on results of developer phone interviews. They were very good: great technical knowledge, decent communication skills, etc. We hand-picked tech leads and key contributors and moved forward with the engagement. People we picked were assigned to the project and we were expecting them to hit the ground running. It took a little while though – contact negotiations, setting up environment, you know. To our great surprise the productivity and quality of code was far below the expectations. The vendor blamed problems on communication, quality of requirements and so on. We tried to improve on those, put an on-site coordinator to resolve the problems, but the issues did not go away. After much ado we decided to send one of our key guys to India; he happened to be one of the people involved in the initial interviews. Few days later he called me saying that none of the people we interviewed were actually involved on the project. The people working on the project had “same names” and emails but were not the people we interviewed… [NK: Frankly, that story seemed so bizarre that I would probably did not believe it if I had not known Joel for long time.]
  • Vlad: When we started working with [NK: a well known top tier vendor] I received many resumes of people for the QA team we were building. Many of those 20+ page resumes. Honestly I was not at all excited to read them but that was my only window into the future team so I had to go through that recycle paper. It indeed turned out to be a waste of my time, even though it was a slightly entertaining pulp fiction – I found that the same text, not only description of the projects but personal achievements and responsibilities, was copied from resume to resume…
  • Nick: A few years ago I was going through the resumes of the team I had inherited. One of them was a resume of a junior engineer that came onboard from a corp-to-corp contract-to-hire arrangement just a few months before I took over the team. The resume had a lot of relevant experience and skills. It looked like we had gotten ourselves a great deal: the gal was perfect and hugely underpaid. These were good times, employee market, and I was not about to lose her on salary basis… I talked with her and was “pleasantly” surprised to learn that she actually never saw her resume; it was produced by her employer and had nothing to do with her real skills, experience and background…

I could bore you with more stories I heard that day and examples of similar nature, but I think the point is sufficiently illustrated. Offshoring brought putting a spin on one’s career in a resume to a new level. Misrepresenting skills of resources appears to be a common practice even among rather large companies. Fortunately, dealing with this issue requires just basic diligence on you part, here are a few simple guidelines:

  • Do not rely on resumes – interview your workforce.
  • If possible interview face to face: go to the vendor’s site or use teleconferencing, even simple webcam + Skype would do.
  • Include resume validation questions in your interview.
  • Consider including tests in your interview.
  • Do not take vendor suggested resource ranking for granted.
  • Develop ranking criteria in collaboration with the vendor.
  • Rank resources based on results of the interviews not resumes.
  • If sourcing and ranking is a black box for you control the individuals’ output (metrics, design reviews, code review, etc.)
  • If even control of individuals’ performance is practically impossible work at macro level holding your vendor to accountable for KPIs that should be outlined in your SLA.

I hope that the vendor(s) you work with have high standards and impeccable integrity; unfortunately, even those companies are not immune to subcontractors’ and employee fraud, so whether you have been bitten or not stay twice prepared.

Delivering Bad News

If you are running an offshore IT engagement you have faced bad news a few times by now. Not? Chances are you will soon. I am not being all gloom and doom; it’s just the nature of the beast. As a matter of fact working in IT guarantees that you will be facing bad news, offshore just expedites the matters. This post is not as much about offshore as about bad news in general –how to deliver them and how to receive.

The first thing to keep in mind whether you have to deliver bad news or are receiving them is that a bad news is like a turn in a road: it’s not the end of the road, unless you failed to make the turn.

Let’s start with delivery. Chances are that applies more to offshore providers. Internally offshore vendors face many challenges – delivery against insane deadlines, working with mediocre workforce, turn over, and so on. These issues are not much different from those most technology organizations face independently from their location. I do not often hear about over-budgeted and overstaffed projects or unusually loose timeframes. The challenges create issues, some of the issues are mishandled, and sooner or later mishandled issues materialize into a problem that becomes a bad news to be delivered to the customer.

The time of beheading bad news bears has passed yet I guess it’s deeply imbedded in our psyche. Not many of us enjoy delivering bad news, especially when it’s personal. BTW, that is an additional complication for many of the offshore providers as the ties between personal and business relationships in many of the offshore countries has been exceptionally strong for centuries and switching to “it’s just business” attitude is not an easy transformation.

To deal with a challenging transformation you need a methodology. I suggest the one I heard from my sailing buddy. He told me that every task on a boat includes three stages – Prepare, Execute, and Cleanup.

That is exactly what you should do to deliver a bad news:

Prepare. That is the most involved and the most important part of the process. The better it is executed the easier it is to deliver the news.

  • Get all the facts, supporting materials, and paper trail together. Organize your materials in a manner you can quickly access what you need.
  • List all questions you can anticipate and make sure you have answers and supporting materials for each.
  • Pick the best individual(s) to deliver the news. Your choice should be based on many aspects of the business relationship and in particular personnel aspects such as roles, hierarchy, and personality.
  • Identify potential outcomes and develop action plans for handling each one of them. You should have a proposed solution or several of them rated by your preference prior to arriving in front of your client. Few things would go worse in such situation than a “we got a problem” followed by a blank stare.
  • Decide on the approach / delivery techniques. This step should be based in a large degree on the items above and the gravity of the issue.

Execute. Aim for making this step as brief and concise as it could possibly be; there more you dwell on the problem the deeper it gets.

  • Deliver the news in a manner dictated by your selected technique / approach (see more notes below).
  • Provide your partner with information they may need. Suggest possible solution / proposed plan.
  • Define action plans and the next steps.

Cleanup. …unless you failed to make the turn… Your actions in the clean up stage are those final movements you need to exit a sharp turn gracefully.

  • Send follow up note / meeting notes / action plans / next steps / etc. to the client.
  • Follow through on each item of the action plan.
  • Follow up with the client to keep them abreast with the recovery progress.

There are many techniques you can deploy in the execution phase. Most famous are known as Punch in a Face, Love Sandwich, and Spinning (it also has a similar, more popular yet less appealing name).

Punch in a Face, delivering bad news without any sugarcoating, despite of its “straight shooter” appeal is a very delicate technique. It should not be used with people who take things personally or emotionally. More so even cold-blooded IT executives that never take anything personal may still prefer some cushion when it comes to very hard news. If you elect this approach make sure to deliver the news in the most concise manner and quickly move on to resolution plans, action items and next steps.

Love Sandwich works well with majority of situations and audiences. The idea behind it is quite simple: in order create a Love Sandwich place the bad news between two layers of “love”. The “love” could be an indication of commitment, general positive reinforcement, good news, etc. This technique is particular successful if information in love portions of the sandwich is relevant to the bad news. It is also important to make sure that love portions outweigh the negative filling.

Spinning is a very complex technique that requires mastery of word, sharp whit, above average diplomatic skills and has dubious results. Presenting a bad news as a good news is likely to be interpreted by an intelligent person as desperate attempt to avoid responsibility. If you measure spin in degrees (180 would be an ultimate spin presenting “bad” as “good”) I would strongly recommend never going being 45 degrees – presenting some “bad” news as “not too bad” one.

One item worth in-depth discussion is “anti-techniques”, the approaches one can use to exacerbate the problem instead of softening the blow. It’s amazing how often I have seen those while working with my offshore providers. My dear distinguished bad news bears, please never do the following:

  • Rush. Never hurry through the process. Rushing through the preparation will leave you vulnerable at the delivery point. Dashing through the execution stage is likely to leave client with impression that you are trying to dodge the subject. Speeding through the cleanup stage will put you back on the same track with a new bad news.
  • Procrastinate. The problem will not go away and with time the bad news is likely only get worse.
  • Overwhelm with excuses. As Brian Tracy put it “A disease of excusitis, inflammation of excuse making gland, is fatal for success.”
  • Announce your technique. Funny enough I heard it quite a few times – “Nick, I gotta tell you: we are in deep troubles, but let me put a spin on it…” What a silly thing to say, do you expect me enjoy watching your exercise in spinning techniques? And how does it alleviate the problem I have to deal with?
  • Use preemptive announcements. “Hey Nick, I have a good news and a bad news. Which one would you like to hear first?” I do not want to hear bad news to begin with. I do not want any bad news.
  • Use “preparers”. A technique commonly used by snake oil sales people: “Nick, I got a very bad news… our coffeemaker’s broken.” most of the time that means that the next thing will be a “not such a bad news” like “the car you came here to buy is $5K more expensive than our ad in a paper stated”. This technique is well known and chances are it will only irritate you partner.
  • Give the bad news first. If you do have a bad and a good news never, never, never give the bad news first. It will upset your partner or put him / her / them in some other irrational state. Your good news will not get enough attention. Starting on a bad note is a sure recipe for failure.
  • Change your techniques in the process. Just think about how you feel or what you think about a driver that indicates that you can pass and then cuts you off, puts a right blinker on and then turns left… Besides irritating the client, changing techniques greatly convolutes the message leaving your partner with feeling that the only thing you brought to the table was a bunch of excuses.
  • Lie. You can spin, omit some gory details, sugarcoat the message but deliver the facts. Unless you have absolutely no choice avoid lying to your clients. The value delivered by lies is typically transient the liability is huge and ripple effect could be devastating.

Let us switch to a short discussion of receiving a bad news. Unfortunately, that is something all of us have to deal with independently on what side of the table we are. Let’s use the same sailing technique – Prepare, Execute, and Cleanup.

Prepare. In this case “Prepare” has a very special meaning. Consider sailing a boat in strong winds; suddenly in a middle of a turn one of the shrouds (shrouds are steel cables that hold the mast up from side to side) snaps. That is a very bad news, which could mean broken mast and many other bad events to follow. The first step you need to take (and in this example immediately) is to get the control of the situation and prepare for your next steps. Get in control of the boat.

When you hear a bad news the worst thing you can do is to get emotional. Do not react – respond. You may elect to show your frustration to the partner and even appear emotional. As a matter of fact there is something to be said about doing it on purpose (consider it an exercise in Golden Rule of Haggling #6). It is through extremely important to keep your head cool. Just consider what Chesley Sullenberger had to do to ditch his plane in the Hudson River saving all 155 people on-board. Get control of the plane preparing to use remaining resources to execute a maneuver that you have never tried live. Fortunately in IT Outsourcing world our challenges typically do not put us under as much pressure and give us enough time to prepare.

Execute. Execution stage is very straightforward and may involve digesting the bad news, options, outcomes, etc. You may elect to brainstorm with your partner, or take their input and do brainstorming internally. One thing is important to consider. You do not have to make any decisions, agree on action plans, etc. right one the spot. More so it is better to do it after you had a chance to digest the news, go through what-if analysis, decide on your preferred actions and when you are not emotionally affected by the news or the presence of the partner.

Cleanup. This stage depends in a large degree on what you decided to do. It may vary from just simple follow up to termination of the engagement.

Wow, that ended-up to be a very long post and I have not even covered the most important aspect – how to minimize the probability that you have to deal with a bad news delivery. I guess I will put it in another post some time soon.

ESL Tips & Traps

In the stream of holiday mail an email from an old friend of mine stood out with its unusual greeting: “Hell Nick!” The missing “o” reminded me of many written and oral blunders I generated over the years and probably continue to without even knowing.

I arrived in the states in ‘91 with practically no knowledge of English. By the mid 90s my English skills progressed a bit; I also moved up from a back office developer to more managerial / client facing roles, so the demand on the skills quadrupled. Thanks to language tapes and a lot of time behind a steering wheel I eventually made it into the “fluent” zone. At least that’s what I thought. One day I was in a discussion with a client in a face-to-face meeting. At some point my good friend and colleague Lindsay Soergel called a quick break, she took me aside and said: “Listen Nick – it’s not “Grand Poopoo” but “Grand Poobah”. What you just did is that you called the CEO of the company Big S@#%”. Later that day over a few drinks we came up with a term “nixymoron” as a combination of “Nick” and “oxymoron”.

From that point on my team took twisted pleasure in collecting and reminding me about my idiomatic expression skills, the list of nixymorons was growing and included marvels such as:

That doesn’t fit, like square pigs in round holes!
You are such a Mister Smart Panties!
I am stuck now between the rock and a hard on!
I have been fool-time employed for over a year now.
I can’t stand him having those pissy fits.
Linda, I think this is really up your valley.
We need to rump up this customer fast!

While this is still far from saying at an exclusive black tie party “Up your bottoms!” instead of “Bottoms up!” (attributed to Mr. Michael Gorbachev) I think I could still put myself in one league with Ms. Malaprop…

Anyway, the reason for this post was to suggest a few tips on communication for those of us for whom English is a second language and still WIP. Just a few high points:

  • Turn your spell checker permanently on, use grammar checker as well. That will help you to eliminate some of the most embarrassing communication blunders. I recommend using MS Word as your email editor in Outlook, enabling spellcheckers on your browsers, using similar tools on mobile devices. It won’t help you with word confusion and you might occasionally call Brian “Brain” though.
  • Stay away from idiomatic expressions unless you’ve seen them in a written form and clearly understood what they mean and the connotation they deliver.  Take for example one of my gaffes – calling an exclusive fund raising party a “hash-hash affair”.  Or here is a classic example you might want to consider: there is a somewhat rare expression “The Hand That Rocks The Cradle” that praises motherhood as the preeminent force for change in the world. It was coined by William Ross Wallace, an American 19th century poet. This expression was used as a title of a movie and a few songs. With a certain stretch this expression could be used in a reference to a mother. There is also a story of a Japanese American businessman who was apparently in love with using idiomatic expressions and titled an obituary for his mother in a major newspaper “The Hand That Rocks The Cradle Kicked The Bucket”.
  • Don’t try to translate your native language expressions into English. For some reason that’s very popular among those with mastery in their mother tongue. Believe me that “to kill two rabbits with one shot” is not at all better than “to kill two birds with one stone”. More so, phrases like “Did you just fall off the Moon?”, “Stop hanging noodles on my ears!”, “You have no face!” (these are literal translations of common Russian idioms) are not likely to reach your audience.
  • Stay away from lingo, teen talk, etc. “Dude, Dis doc is totally da bomb! It’s so fresh my mamma could hang wid it…” is not the way to say “Nick, This is a very well written document. Everything is crystal clear and easy to understand.” even if you are native speaker. Coming from an offshore PM that looks completely ridiculous and instead of breaking the ice (what might could have been an intention) it may break your relationships.
  • Be extremely careful with the humor. Humor is one of the most powerful elements of communications and in good hands can achieve a lot. However that is a tricky weapon which is likely to backfire if mishandled. Shooting oneself in a foot while operating that weapon in cross-cultural environment is quite likely. Same as idiomatic expressions jokes, pans, and anecdotes do not translate well. I am not saying that you should stay away from humor, just saying, be very careful unless you enjoy listening to crickets chirping.

While many of us from ESL community greatly expand the boundaries of what could be done with appropriate misuse of English the problem applies even to native speakers. That’s why you might want to look at Commonly Misused Words and Phrases or more comprehensive List of commonly misused words from Wikipedia.

And let me finish the post with a (de) motivational quote Even if you do learn to speak correct English, whom are you going to speak it to? – Clarence Darrow

Outsourcing and Email Etiquette

Nothing made a more profound impact on business communications than email, and nothing probably ever will; well, unless telepathy is adopted by the corporate world, and that is probably not going to happen during my time. So it’s not surprise that there are 100s of books and web sources covering email etiquette, rules, techniques, tips, tricks and traps. Yet, I see again and again the lack of attention to email rules and etiquette ruins business relationships, creates communication problems, and dramatically affects project communications.

Email rules and etiquette is a general issue. I see it as a local challenge and go through communication training with my in-house teams (even though it seems kind of weird coming from someone for whom English is a second language and still work in progress). The importance of email is 10 times higher when it comes to outsourcing. It is impossible to overstate its significance, especially for vendors / providers. Given that a good portion of my audience is outsourcing providers this topic is worth investing into.

Let’s start with classic DOs of professional email, or The Keepers:

  • Keep it Short. I suggest keeping in mind a 10 seconds principal – write your email with expectation that the reader should spend not more than 10 seconds to read it. If you need to communicate considerable volume of information email might not be the vehicle to use. If that’s your target audience preference or some other reasons make it so put a 10 second summary upfront.
  • Keep it Simple. Write to express not to impress. That is particular important when it comes to outsourcing, you Harvard vocabulary won’t help much to ESL members on the thread. Here is one of my favorite examples which takes a few seconds to comprehend even if English is the only language you speak – “Unremitting fealty to his métier sans interludes of hedonistic deflection renders Jack a hebetudinous hobbledehoy.” Just in case see “translation” in the bottom of the post.
  • Keep it Personal. You should always mention recipient by name, use proper salutation and be polite.
  • Keep it Formal. No matter how close you are with the recipient if you are writing a professional email you are engaged in conversation between two professionals. See a few tips on professional email etiquette below.
  • Keep it Legal. Always be aware that you are talking on company behalf. In particular remember that there no such thing as email Security or Privacy. Business email sent to/from a company server belongs to the company and might be read by someone other than your intended recipient So, never put anything in email that you will not say in public

The next rule is the Brevity Principle, or the simple basic, and yet most frequently broken rule: Business email should be limited to a single topic. Sending email covering a variety of topics almost guarantees that some of those would be missed, lost or misinterpreted.

Very important rule is to stay away from clichés and limit your use of idiomatic expressions. Once in awhile you come across people who are just can not say things in a plain manner and the content of the message gets lost in a stream of expressions. “Let’s run it up the flag pole to see if it passes the acid test, or we’ll be back to square one. That ought to give us a ballpark figure beyond a shadow of a doubt what our bottom line will be. If we can’t hit the nail on the head we might have to bury the hatchet and get back to our original bread-and-butter issues.” I am still trying to figure out what this one meant.

There is more to it. Idiomatic expressions are dangerous traps in cross cultural conversations. Just a few weeks ago I was talking with a brilliant techlead of my team in Latin America. When closing the discussion I asked – “Javier, do you think we are on the same page now?”. “I am not sure Nick” – he replied – “what is the number of the page you are on?”

And now a few email etiquette rules / tips on keeping email professional:

  • Reply in timely manner. I recommend using 24 (business) hour turnaround time. In case you need more time to address the issue / etc. send a brief status email.
  • Answer all questions, and pre-empt further questions.
  • Use the fields correctly
    • From (make sure that your email client is setup properly)
    • Subject (40 char summary of the email body)
    • TO (intended receipt of the email)
    • CC (keep the number very small – do not spam people just for FYI reason)
    • BCC (avoid using it altogether)
  • Do not shout, in particular:
    • Do not USE ALL CAPS
    • Do not use excessive punctuation – Why???????
    • Do not use “teen talk”, IM lingo and other casual language – WTF!?
  • Do not get “personal”, especially “in public”, never:
    • Reprimand someone in email
    • Make someone look stupid
    • Question one’s credibility
  • Watch your attachments
    • Do not forget them (you may want to consider Outlook plug-in that does the attachment check)
    • Do not send files that are large (over 1 MB) or likely to conflict with email rules (e.g. *.exe files)
    • Do not use vCards and certification pics (they make every email appear to have an attachment)
  • Be extremely careful with
    • Humor (potentially huge communication trap in cross-cultural setting)
    • Reply All
    • Adding recipients to email thread
    • Message threads
    • Forwarding

I guess that covers high points. To see more on the topic just google “email etiquette”.

“Unremitting fealty to his métier sans interludes of hedonistic deflection renders Jack a hebetudinous hobbledehoy.” is just a fancy way of saying “All work and no play makes Jack a dull boy”

Outsourcing in the Light of Bribe Payers Index

Have someone offered you some funny smelling incentive package to close an offshoring deal? You may not be alone…  I just run across an interesting article, not specific to offshore outsourcing but very relevant though. Bribe Paying Export Countries by Daniel Workman talks about some unusual stats – “The 2008 Bribe Payers Index ranks the likelihood of importers receiving illegal monetary incentives from leading export countries.”  Here are the highlights

Countries Most Likely To Offer Payola

Final results from the 2008 Transparency International survey rank export companies from Russia, China, Mexico and India as most likely to bribe.

1. Russia … 5.9 (33% more likely to bribe than Canada or Belgium)
2. China …6.5 (26.1% more likely)
3. Mexico … 6.6 (25% more likely)
4. India … 6.8 (22.5% more likely)
5. Brazil … 7.4 (15.9% more likely)

Countries Least Likely To Grant Illegal Incentives

The BPI survey ranked Canada and Belgium as home to exporting firms perceived as more ethical and therefore apt to avoid illegal payoffs.

1. Canada … 8.8
2. Belgium … 8.8
3. Switzerland … 8.7 (1.1% more likely to bribe than Canada or Belgium)
4. Netherlands … 8.7 (1.1% more likely)
5. United Kingdom … 8.6 (2.3% more likely)

See more figures and supporting material in the original article TI Report: Emerging economic giants show high levels of corporate bribery overseas.

Offshore & Sexual Harassment

What a strange topic, it feels quite weird even to bring it up. After mandatory training, posted policies, and tons of wasted energy you’d say that is a dead horse. Alas, offshore-related sexual harassment could quickly grow into a real problem if not dealt with promptly. The trap is actually right one the surface: the standards of office behavior vary greatly across the world, with US culture being one of the most restrictive. Another aspect is a different social position of women in other countries, with US being one of the most advanced.

I am not about to get into insinuations about what’s right or wrong, my only objective is to highlight a potential trap. Many outsourcing companies, even large ones, with advance cultural training and extensive experience working with US companies do not get remotely close to what’s needed to prevent actions of their associates that could be considered sexual harassment by US standards.

Not so long ago I had a large group of offshore resources working onsite as an integral part of my team. In period less than a year we had three complains related to sexual harassment that required management involvement. One was a case of “unwelcome sexual advances”, another two related to emails with vulgar jokes and graphics. One of the cases resulted in associate being fired, all three demanded great deal of effort for resolution and dealing with unhappy employees from the core team… The most surprising thing about these cases was complete ignorance of senior members of the offshore team who were supposed to deal with the incidents on the topic; that was in particular alarming that the vendor was a top tier Indian outsourcing firm.

The right and easiest approach of dealing with this trap is tackle potential issues that may arise from vendor’s ignorance in standards of business conduct far before you face an incident. While that appears to be “vendors problem” my strong recommendation is to deal with it yourself, at least control / verify how vendor deals with this issue.

If you have a group of offshore resources working onsite the easiest thing to do is to put them through corporate s/h training. If you do not have one in place you should hire professionals or run one yourself. There are plenty of materials you can find on the topic; including below is a slide deck I use for training.

Another important activity you may want to consider is educating your employees about cultural differences and standards of office conduct they may encounter with. That’s especially important if you consider sending your employees to work as a part of offshore team.

Non-hire Trap

One of the first steps in most of offshore engagements, often even before you decide on the vendor is signing non-disclosure and non-solicitation agreements. NDAs and NSAs have become so common that often they are signed without understanding a potential penalties they may lead to. Below are a few fairly common tricky situations related to non-hire clause:

  • I had several situations when a developer brought to me by my offshore vendor for an on-site assignment approached me for a full time position. In every case that was a highly respected developer with in-depth knowledge of our products, etc. close to the end of their on-site assignment. In every case the developer had alternative offers and was not planning on going back to his original employer.
  • I’ve seen some tricky situations when top-notch employees of companies who did not make through selection project came to us looking for full time employment when the deal did not happen.
  • A few times I had to deal with the situation when a new vendor brings me resumes of the employees from the vendor that has been replaced.

There are many other scenarios with the common issue – you are interested in hiring an employee but can not do it without breaking NSA.

In many cases the non-hire situation can be addressed to both parties contentment. The typical approach I would suggest is considering hiring employee as if you were working with a recruiter. 15-30% of employee annual salary could be amount which would keep the vendor happy under certain circumstances. That has to be handled with great caution and respect to the vendor. Some companies put substantial investment in the resources on all fronts – from acquisition to training and benefits, for them 30% may not represent a sufficient amount. I find the wording non-hire clause as a great indicator. Here is for example an extract from NSA with one of very employee-focused organization:

During the term of this Agreement and for a period of two (2) years after the later of the date of this Agreement or the completion of any SOW under this Agreement, each party agrees not to, directly or indirectly, initiate employment discussions with, hire or use in any way the services of an employee or contractor of the other Party. The parties specifically agree that a material, uncured breach of this provision will entitle the non-breaching Party to agreed upon liquidated damages in the amount of two hundred thousand dollars $200,000 per occurrence with a maximum aggregate limitation of $3,000,000. Subject to the time limitation set forth in the first sentence of this paragraph 11, this provision applies to employees and contractors who are no longer employed by the Vendor or by the Client but were so employed at any time during the term of this Agreement.

You may consider he figures to be over the top, I did. However, the truth of the matter is that this particular company wants to do whatever it takes to prevent brain drain whether it’s instigated by the company or by the employee. And that’s deserves some respect and twice as much serious attention.

However, most of the time you do not find the NSA / NS clause worded with such might. Vendors understand well that in many cases they can’t do much about losing a particular employee, and losing him/her to a customer may play in very positive manner towards improving customer satisfaction / retaining the customer, etc.

Here are just a few obvious tips on dealing with non-hire trap:

  • Deal with NSA with consideration that you might be facing it’s bitter end.
  • Stay legal – do not solicit vendor’s employees, even they seem a prefect match, do not even give any clues or signs. If the associate comes to you that will put you in the best negotiation position with the vendor and with associate.
  • When facing the “situation” stay legal in all aspects and consider the hierarchy of importance: yourself, the vendor, the associate.
  • There is almost always a way to negotiate the situation with your vendor in a win-win manner. Consider “win-win or no deal” approach.
  • You may not always get what you want, in particular there will be situations that you just won’t be able to get a particular employee. Let it be.

The Myth of the Onsite Coordinator

One of the proven methods to improve quality of communications with the offshore team is to have a dedicated person to coordinate and oversee its activities from your site. This person should ensure the communication flow, act as liaison between the teams, and often interpret information from local to offshore language. Even if the both sides speak English fluently (e.g. outsourcing to India) there is lot of subtle differences in business lingo that need translation. More so the person could be charged with business analyst activities interpreting domain specifics to technical language of the development team. On my book offshore manager should have very solid PM/PMO skills, in-depth understanding of the processes such as SDLC, strong knowledge of the domain, and of course understanding of the offshore. The job description for the person quickly adds up to a very tall order. Add to it logistic challenges – this person typically ends up working long odd hours – and you realize that it’s not an easy task to find some who can do it.

Of course I am not the one who invented dedicated offshore managers, as a matter of fact even for a fairly small engagement your vendors would strongly recommend that you put a full time onsite coordinator on your team. The vendor is likely to have long list of Pros for adding the person to the team, not surprising it’s a very common add-on sold pretty much with every contract.

There are a few serious caveats here, if not to say traps. Something I have observed on multiple engagements:

  • Onsite coordinator could be just a slightly disguised sales executive with primary objectives that have nothing to do with real objectives of offshore manager.
  • Onsite coordinator could be grossly unqualified for the job but given it due to some internal reasons – for example as a holding position between assignments.
  • Most often the onsite coordinator is just that – a mere coordinator – far less than you need for the position.

Each of the scenarios above is guaranteed not to deliver on the objectives of an offshore manager and to prevent engagement failure you’ll need to invest in the manager as well, in that case why do you need coordinator?

More so, one of the biggest issues with offshore onsite coordinator is the mind set, is s/he going to have your interests at heart or interests of the company which pays him salary? When inevitable problems come up on what side s/he will be? Let’s say that problems are severe and you have to take your vendor to court, can you really count on onsite coordinator to be unbiased?

I can not tell you how many times I had this discussion with offshore vendors who continue to push for the “best practice”. Well, if that’s so helpful for you to deliver on the engagement objectives why don’t you do it on your own expense? That question typically falls on deaf ears.

When you consider expense, typically either offshore rate + per diem / hotel / car / etc. or onsite rate of ~$80 an hour you realize that it’s might cost effective to find offshore manager locally. Good offshore managers are not easy to find and they are not cheap but believe me, they are worth every penny.