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.

Force Majeure

Force Majeure (French for “superior force”), is a common clause in contracts which essentially frees both parties from liability or obligation when an extraordinary event or circumstance beyond the control of the parties, such as a war, strike, riot, crime, or an event described by the legal term “act of God” (e.g., flooding, earthquake, volcano), prevents one or both parties from fulfilling their obligations under the contract.

While working with offshore teams, in particular in countries that are subject to severer environmental conditions such as Bangladesh or Philippines you should never forget about how real Force Majeure is. For my pet project wwhow.com I use support of freelancers from Philippines in SEO and data entry tasks via oDesk service. Here is an email I just received from one of my providers –

Dear Nick,

We had experienced a typhoon Ketsana that hits our area tremendously last Saturday morning since then our power was cut due to heavy rains and floods. Floods were everywhere including in our home. Power was restored last night. In this regard, the two accounts were not able to finish the working hours load for the week.

Rest assured this week, we will continue to post quality deals and able to finish work load. I apologize for this unavoidable circumstances.


Kind regards,

Jennifer

Continue reading

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

At Doorsteps of a New Engagement

I finally started working in my new role, VPE / CTO of PDR Network. It took almost a full year of non-stop activities on two complex M&A projects to get to this point. Medem and its assets moved on to two different organizations and I followed one of those assets. “Asset” in this case meaning product, resources, customers, etc. – basically a business unit. Fortunately, I was able to keep some of my top contributors even though far not everyone.

This economy put a huge strain on teams. I had to let go some people who I immensely respect and enjoy working with. Hopefully the new place will provide an opportunity for some of the guys I lost along the way to rejoin. Well, it remains to be seen; at this point I am facing couple disentanglement and technology merge projects that include working with new offshore partners.

dataquest-idc

PDR Network was formed by merging two assets acquired by a prominent equity firm: Physicians’ Desk Reference, acquired from Thomson Reuters, and the Health Care Notification Network, acquired from Medem. Medem had its offshore partners and Thomson Reuters many of their own. Naturally Medem partnered with small companies and TR with fairly large ones, even though to my surprise not tier 1.

At this point I do not know practically anything about my new outsourcing partners and the challenges they will bring. It feels like you are standing in front of doors to someone’s house and ringing the door bell. From behind the doors you hear a dog barking. What kind of dog is it? Playful Yorkshire terrier, English Bulldog dripping saliva, huge Newfoundland eager to lick you off your feet, vicious Presa Canario ready to rip you apart? It would be great to know before the door opens.

So let me guess what the new vendor will bring to my plate… At this point your guess is as good as mine, the only thing I know of the vendor that they made it to top 20 Indian IT list. Well, I know a little bit about the history and track record, but not much and only at high level / in general terms… So let me put my expectations in writing and see how the actuals pan out:

  • Turnover not less than 30%
  • Majority of the resources would not pass through interview by on-shore team
  • Poor track record of deliverables (late, over budget, low quality)
  • Low quality of code (no comments, inefficient code, etc.)
  • Low quality of the processes (incompliance with SDLC in many aspects)
  • Very inefficient / over-engineered architecture / designs
  • Waterfall SDLC with cushy estimates, slow start and high pressure in the end of each engagement

OK, that’s enough for now. I will keep you posted with what I find out discover over next few months.

Herding Cats

You most likely have seen that commercial.

I think EDS has a great point here, managing software organizations is very much like herding cats. Managing software teams with outsourced distributed components take herding cats to a profoundly higher level – doing it on steroids… or should I say on drugs?

How can one survive the ordeal of getting a product out in multi-sourced distributed environment? Language barriers alone brought the Babel project to its fiasco. And you know that language barrier is often much easier to deal with than with communication barriers or cultural differences.

Well, it’s been done, as a matter of fact many times… on time, within budget and over-delivering on customer’s expectations. Is there a recipe I can offer? Probably not, at least not a panacea that will fit any project or organization. As a matter of fact specific combination of project / team / environment demands its own methodology, approach, techniques. Let me offer just one of those, five C’s of distributed project delivery:

  • Casting. That is the first and the most important element – select right tools for the job, find the right providers for the task, put people in positions that match their skills and aspirations.
  • Compensation. Make sure that resources on your project are properly compensated for what they do, that applies to everyone from your in-house architects to offshore worker-bees. Considering that working with offshore throws a huge monkey wrench in your ability to control compensation you may need to start early – when establishing your relationships with providers.
  • Communications. Put a well thought out communication plan in work and enforce it with the vengeance, at the same time review it and improve with every opportunity. Make sure that you cover all channels and take advantage of multiple media.
  • Culture. Cultural differences derailed many projects and engagements. At the same time it is not necessarily as difficult or complex of an issue. Here are just a few things consider – acknowledge / recognize cultural difference, educate the team about them, and keep attention on cultural aspects, in particular when it comes to communications, estimating and delivery patterns.
  • Control. Control execution on an ongoing basis in every aspect of the project – schedule, budget, quality. That is a large topic partially covered in the blog already (see for example Peace in Metrics). I will talk more about it in future posts.

Peace in Metrics

Agile techniques and approaches are marching across the software land conquering more and more territories. It was not a blitzkrieg forefathers of agile has dreamed of but it is a successful invasion. Along with true agile aficionados with their well thought out and understood processes the crowds of software anarchists disguised as agile evangelists are capturing organizations by storm. Picking selected items from the agile menu they bask in glory of self-respect enjoying coding / refactoring dance leaving aside schedules, deliverables, and milestones. While religiously following 40-hour work weeks and iteration retrospectives they enjoy weeping sounds of deadlines as they fly by.

While agile made a huge positive impact on software development as any other broad initiative it created some serious problems and could not avoid significant collateral damage. One of the first victims to the new brave world were the software metrics. Indeed, why do you need metrics in a self-monitoring organization with a clear measure of success – the working product? Even Tom DeMarco backed off from some of his ideas, why should not you? … And maybe that’s why it took agile community such a long time to figure out that test-driven development is ridiculously expensive…

Combining agile and offshore is not at all impossible. It is however complex and requires a plenty of prerequisites, including serious agile maturity of the on-shore team. You should think twice before eliminating “overhead” of the waterfall on your offshore projects. And specifically, forgoing the metrics can be detrimental / border line juvenile delinquency.

Of course the topic metrics is also complex and rather controversial. What to measure? How to measure? What to do with the results? Here are a few tips to consider:

Continue reading

Charting a Map to Disposable Outsourcing

Have you heard about PMBOK? In case you did not – the acronym stands for Project Management Body of Knowledge. PMBOK is a very comprehensive document that covers PM processes, procedures, methodologies and techniques promoted by Project Management Institute (PMI), a very well respected organization…

A few months ago I asked two PMs on my team to develop a road map of ensuring that offshoring relationships we have in place are indeed 100% disposable. A very aggressive goal considering a small size of our on-shore organization in particular juxtaposed to the size of our offshore operations. Almost instantly the project was nicknamed OCBOK – offshore contingency body of knowledge. Of course building a real OCBOK would take much more than two part time project managers (even exceptionally good ones) and a couple of offshore teams. So we can only start outlining its structure and put some preliminary content in a few chapters. It would be great to get it to the PMBOK level at least some approximation. To that I need all help I can find – if you have any resources / ideas / suggestions that you think could be applicable please send them my way. Feel free to comment on this post or email me at – krym2000-po@yahoo.com

In meanwhile here are a few interesting observations from writing the first chapter of OCBOK which would be called “You are more dependent than you think” –

Continue reading

Offshore and Code Review

Code review is a rather controversial subject. On one hand many SDLC gurus, tech leads, and architects agree that it could present an incredible value, on the other hand it’s one of the last quality procedures to be exercised in a majority of organizations. There are many reasons code review often takes the back seat, one of the most important ones is morale impact of code review. If let unmanaged code reviews can often cause tension in the team, things quickly become personal and instead of improving quality of code generate turmoil and finger pointing. Another reason of code reviews’ lack of popularity is their complexity in process sense, in particular timing.

I am in general a big proponent of code reviews and when it comes to offshore I found those irreplaceable. Specific implementation of code review depends largely on SDLC and outsourcing model used by the team.
If you fully outsourced your SDLC to an offshore partner you in a large degree will be at mercy of their internal SDLC. If you have an ability to influence your vendor’s processes you may want to request code review as a mandatory step and hope that it will be performed according to the best practices that are generally well known nowadays.

Continue reading

Red Flags to Watch Out For

How do you know that a relationship with your vendor is going south? Of course if all your partner’s employees just do not show up for work you know that something is rotten in the state of Denmark. That would be somewhat unusual event and probably irreversible. The goal here is to identify early symptoms of a fatal disease of deteriorating partnership. In techno world we call them red flags.

The earlier you identify developing issues with the relationship the higher the chances that you can nip it in a bud and return to a mutually beneficial rewarding relationship. Small companies typically offer a high level of transparency and short communication channels. That makes identifying issues much easier task. In large companies the issues can develop without knowledge of many stakeholders, that’s why watching the relationship dynamics is especially important for those. Continue reading

Offshore Technical Due Diligence

A couple years ago I went through a technical due diligence (TDD) of several relatively small offshore vendors. The vendors were providing product development services for one of my clients, the vendors also supported operations of the SaaS for all of the products. The client had fully outsourced s/w product development and support to those vendors and retained practically no technology resources internally with exception of MIS / SaaS IT support.

The goal of the TDD process was to asses whether the vendors are efficient and can continue performing fairly complex projects involving working with sensitive information. There are a couple important distinctions here:

  • The vendors were in large degree focused on the product development for my client and the rest of their business was relatively small.
  • The vendors have been performing services for a number of years with very light oversight from the client’s side.
  • The quality of work to date has been on a low side yet deemed sufficient for the money.

Continue reading

Laws of Nature

I just added a new post to my new blog Common Sense ManagementLaws of Nature and the Need for Management. It touches upon one of my favorite metaphors – application of the Second Law of Thermodynamics to management and offshore outsourcing (see also Fundamental Laws of Outsourcing). The message common to these posts is quite simple – you must stay on a top of your projects, resources and engagements otherwise they would quickly deteriorate.

Having said that I have to admit I should pay more attention to what I preach and follow my own recommendations. Just a few days ago I was going through a small project that seemed to be falling behind. The issues became clear in a few minutes after I walked in the meeting discussing the project status.

The objectives for the project I stated about two months ago were lost and the void was filled in by something substantially more complex (And that illustrates another law – “nature abhors a vacuum”). My offshore team was happy to work on more challenging projects, estimates appeared too high, that required in-depth analysis, more people were getting involved, more issues discovered, that generated substantial amount of R&D that increased the complexity by an order of magnitude… Involved in the meeting there were six people from onsite and almost as many from offshore.

For me, at this point an unattached side observer, it was obvious that the efforts being extended to address the project exceeded the value of it by a great margin. It was not at all clear to people so passionately involved in resolving the problem.

About an hour later it was all over. The vicious circle was broken as the proverbial Gordian Knot. The projects objectives were not only restated but addressed. It required 15 minutes from an engineer who had not been even aware of the discussion. Yet the sunk cost of the project was unrecoverable, exceptionally high and not justifiable by any means. Is there anyone to blame for it except the manager (me) who abdicated the project to those who did not have enough technical depth to cut through the distractions of secondary objectives?

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

Five Steps to Keeping your Vendor

I started my earlier post Five Steps to Keeping your Business with comparison of an offshoring engagement to a bad marriage: courting, expensive wedding, honeymoon, initial struggles, mundane irritation, aggravated frustration, and bitter divorce. The post touched upon the most important steps vendors should take to keep their business. Now let me cover the buyer’s side. And first let’s discuss a couple reasons for keeping your vendors. Of course if a vendor fails your expectations by a large margin there are not too many reasons for keeping that vendor, if any. If the vendor is perfect the thought of changing them is rather unlikely. (Please do let me know what your vendor is in this case, so far I fail to find one!) The question is relevant to vendors that in general deliver on expectations and sometimes exceed them and yet are in many ways imperfect, sometimes even worse than that. To some degree these reasons for keeping the vendor summarize to “Don’t fix if it’s not broken” – Continue reading

Data Entry Gig: Execution Control

In my earlier post Notes from a Data Entry Gig I covered a few areas related to a small data entry project. There were several areas that were left untouched, one of them – execution control, is worth covering by itself.

There are many things you can do to get execution under control on medium to large scope engagements. Project/program management, account reviews, etc. That’s not the methodology to be used on a small gig such as limited scope web research, data entry, SEO, etc.

Considering that discipline and control issues associated with freelancing have to do with a lot of its Cons I was rather skeptical farming out data entry to a few gals in several small cities in Philippines. One would say “it’s a small data entry, what can go wrong”, yet you and I know the possibilities to screw it up are endless. “And then I saw the tool, Now I am a believer.” [almost from Neil DiamondContinue reading

Five Steps to Keeping your Business

Offshore teams delivered a significant portion of the products and services for the companies I worked for. My experience in utilizing offshore whether it is measured in years, number of projects or dollars sent offshore is rather substantial. You would think that by now I should have settled on a couple partners who I use on the majority of my engagements the way most VPEs settle on DB platform, app server, language, etc. Actually that is not the case due to many reasons, the main being different needs call for different partners. There is however another reason worth serious discussion – many vendors lose their clients mainly by not doing good enough of a job of keeping them. Whether you look from the vendor’s or buyer’s side that’s a shame…

escher_ascendingIt’s a common knowledge that in the service industries the cost of a dollar earned from a new customer is substantially higher than from an existing relationship. Yet for some reason that rule is ignored with unexplainable consistency. In particular I see it common with some of my offshore vendors. All too often a relationship with an offshore vendor goes through typical stages of a bad marriage: courting, expensive wedding, honeymoon, initial struggles, mundane irritation, aggravated frustration, and bitter divorce.

It takes two to tango, and being unbiased marriage counselor I should offer my connubial advice to both sides – buyers and sellers. I will, with this post focused on the vendor’s side:

  • Communication is critical element of any engagement and in particular distributed. Even two people who know each other exceptionally well and live under one roof are known to have communication problems, it’s no surprise offshore engagement fall apart due to communication problems. Communication problems have a cumulative nature, meaning that small issues accumulate and result in large scale problems. There is much to be said (and I will do that) about improving communications in offshoring engagements, for now just one critical aspect: You should establish and follow communication process. You should treat communication process as you would treat a manufacturing process. In particular consider no missed steps or other changes to the process unless you expect substantial improvement in efficiency AND the changes are agreed upon by all stakeholders. Continue reading

Notes from a Data Entry Gig

Large pool of cheap resources sometimes is enough of a motivation to outsource tasks. Sometime even those that you might not have done in the first place ;) It also is very tempting to engage manual labor rather than create, debug and use tools. Those reasons along with some business drivers were behind a data entry project I started a few weeks ago. While small and fairly simple the project offered a few interesting lessons to learn and a couple of interesting points to share.

  1. There are many places where you can find freelancers. Most of those places offer offshore labor. Even local resources such as craigslist will generate more response from offshore than from locals, even if you specify “locals only”. In my case I was specifically looking for offshore resources and the rock bottom rates. I knew that every site has its own community of freelancers, what was somewhat surprising is how substantial the difference in response would be. Response to my ad from 5 sites I tried in the first 3 days was 0, 2, 3, 6, and 78. The last figure was the response from oDesk community. It’s no surprise that the best candidates also came from oDesk. As a matter of fact I ended up to picking all providers from oDesk (I was looking for 5 people).
  2. The rates diversity was quite surprising as well. My project which was a basic internet research and data entry attracted freelancers from all over the world with majority of applicants from India, Pakistan and Philippines. There were a couple bids from USA (I frankly doubt that the work was planned to be performed by USA resources though). The lowest bid was $0.78 an hour (Bangladesh), the highest was $26 an hour (India).
  3. The quality of responses varied greatly from thoughtful and professional to “Need a job!”, the last one incidentally was one of the highest bids as well.
  4. Fit between the job and skill set was decent with a few exceptions even though I had somewhat of a difficult time categorizing my project – fitting it into one of the categories / subcategories provided by the sites.
  5. Each of the sites has its own idiosyncrasies and proprietary conventions; that makes search for freelancers across several sites rather cumbersome. In this case I did not have to work across the sites – the difference in response clearly made oDesk a better place to seek for my resources. That is not always the case though. In particular many type of projects such as web design, graphical arts, etc. would find equally strong support on many sites.
  6. For this project pruning candidates was not complex – I cut off everyone with rate above $5 an hour and those who did not appeared to put any efforts into their bid. That still gave me about 25 candidates, at that point ratings and hours worked helped me quickly pick top ten.
  7. I did not put a lot of efforts in the “Interviewing”; a quick email exchange quickly showed whether the person appeared professional and responsive enough. A few of candidates requested Skype conversations, that was a bit more time consuming and I am not sure whether for this kind of project the time is justified.
  8. I picked 7 suppliers (my target was 5). Can you guess why? Of course the quality of suppliers, especially when you scrape the bottom of the rate barrel is a hit or miss. One of them “did not show up for work” after the bid was accepted, one turned out so dense that I had to stop working with her after two days into the project.
  9. I now have only three suppliers left. All three are from Philippines and all are doing a decent job. The rates are 1.11, 2.78 and 3.33 an hour. The communications are sufficient. Productivity as expected or even better. I think so far I can call this project a success.

If you are facing a data entry, web scraping, email response, etc. project here are a couple tips I suggest for you to consider:

  1. Using freelancing sites saves time of sourcing candidates, simplifies management, and helps with payment aspects.
  2. Today the rate target could be $3 an hour plus / minus a buck.
  3. Have a very simple, concise and unambiguous project description. A step by step operating procedure should be developed. (remember the 3rd fundamental rule of outsourcing?)
  4. Do not invest too much effort in selection of the candidates; it’s easier and faster to start another project and get a bunch of new candidates than try to pick just the right ones. Using the project above as example – the candidates I thought were the best are no longer on my team, one of them was the no-show.
  5. Use the site communication methodology rather than your own email. That reduces the clutter in your own inbox and helps with categorization of email and follow up.

I guess that’s as much as this project deserves. I am kicking off  a SEO/SEM project shortly. It will be a bit different will see how it pans out and whether there is much to learn from it.

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

Basics of Non-verbal Communications

I started talking about body language and non-verbal communications (commonly referred as NVL) a while ago kicking off the discussion with a picture of consummate liar. NVL is a general topic that applies across industries and domains, the reason I bring it up here is that NVL is exceptionally important during face to face interactions with your partners. The cross cultural aspect of offshore relationships introduces whole another layer of complexity to NVL, often complicating already perplexing aspects of communications. To understand it you need to have a solid grasp on basics of NVL. Crawl before you run so to say. Of course understanding basics of NVL will help you in many other aspects of communications both professional and personal.

Of course this post is only a few brash strokes on a canvas – if you find NVL topic of interest you may want to look into a few books which I found helpful. Anyway…

Body language or non-verbal language refers to conveying messages without words. We are accustomed to use common gestures which are the “words” of NVL for example nodding your head in agreement or shaking it in disagreement, facial expressions – smile, frown, disgust, etc. Many or NVL “words” are much more subtle though. They do communicate message to outside world sometimes much louder than plain words would.

In a personal spoken message according to Albert Mehrabian (Psychology Today, 1968) the total message is communicated via:

  • 7% is conveyed by the words
  • 38% by the vocal tones, and
  • 55% by facial and body expression

How about that? More than half of the message comes across via body language! Talk about the Cons of outsourcing! When you work with someone and do not see him or her the chances are you will miss half of what they are saying or it will take twice as long.

More so the body language is less controlled by our conscious mind and often radiates the true message. Just look around and you will see plenty examples of it. I started writing this post while on my way to the office in BART, as on purpose to help me with an example a couple walked in the car and sit across. The couple was having one of those discussions: her eyes were red and full of tears; they sit on the bench at least a foot apart, her fist were clinched and body pasture uptight / uneasy. He was much more relaxed and appeared in control, he was the one doing all the talking in very persuasive somewhat mechanical manner, the topic was apparently very emotional and she was hanging on his every word, looking deep into his eyes. I could not hear a word yet it was somewhat clear that he did something that had hurt her and now was explaining / asking for forgiveness. By the Fruitvale station there was no more distance between them, his arm was on her shoulders, at the West Oakland they kissed lightly, by the Embarcadero station the kiss was real, the fight was over, and the guy was forgiven. She relaxed as if the seat suddenly became 100 times cozier and looked so much happier, so did he… What she did not see during the conversation, as she was maintaining that rare unbreakable eye contact, was his body language and all classical signs of deception. For me as a side observer sings were obvious as if I was watching an NVL training tape – here is the hand to mouth move, now he’s rubbing his neck, and here goes that proverbial blinking… As I was walking out of the car I saw her happy smile. Isn’t love grant?

There are a few very important elements to reading NVL:

  • North American gestures do not necessarily represent gestures correctly in other ethnic cultures. As a matter of fact you need to make sure to read up on foreign NVL before getting involved in face to face communication with your offshore partners, innocent or positive gestures could be offensive in other cultures, e.g. infamous American feet on the table the gesture that is extremely impolite in many cultures and exceptionally offensive in the Middle East.
  • Many people can easily control what their NVL broadcasts to the outside world in an initial stage of conversation or its “static” stages. For example anyone can start a conversation with a smile, specific body position, etc. As the conversation moves along and becomes more engaging / more emotional the mind loses its control over NVL. If you are trying to read NVL pay specific attention to changes in NVL. Changes in NVL are significantly more important than “stance” or specific elements of NVL displayed for a period of time.
  • You are probably not the only one who is NVL aware. More so some people put substantial effort in mastering in NVL outbound communications and use it as powerful deception or influence techniques. For example a powerful technique taught in many sales classes is mirroring – mimicking conversation partner’s body language. Mirroring is known to increase chances of positive outcome of the conversation – closing the deal; it comes from one of core principals of influence theory; that’s a whole another topic for discussion.

Well, that probably covers the main elements of the foundation.

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

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

10 Annoying Things Freelancers Do to Destroy their Business

I have been working with freelancers through out my career and recently, thanks to services like oDesk, I find myself doing it more often. So you might think that I am happy with what I get, at least in general. Well, one of the reasons I continue to stay engaged is my high tolerance for pain – I am prepared to go through piles of hay to find that needle. And I have to tell you, looking for freelancers is very much like digging for gold – you literally have to go through tons of dirt to find it.

Interestingly enough many freelancers who have skills, knowledge and maybe even talent often torpedo themselves, aggressively sabotage their chances of getting customers right in the begging of the process. They make simple yet lethal mistakes that turn off clients before they got the chance to learn about freelancer’s ingenuity. Of course many mistakes could be made during execution of the project as well as its closure. I am not talking about technical or skill set issues though, my focus is on soft behavioral aspects of your communications with the client. Below are some of those mistakes:

  • Not reading my project description before replying to it. Your three page long template proposal will get in a recycle bin faster than you would think. At least adjust your opening statement, show me that you read the post…
  • Not using proper grammar and spelling. English is my second language and still a work in progress; I still struggle with grammar myself, yet many proposals I see push that envelope way too far. Grammatically poor introduction screams in my face “Communicating with this freelancer will be a real pain!” Spelling mistakes are even worse – how can I entrust my project to someone who doesn’t even make an effort to turn on a spellchecker?
  • Talking with me like I am a teenager. Your slang (especially when combined with ESL marvels) comes across as complete lack of intelligence and class. By the way, spellchecker is not likely to recognize your “gonna”, “wanna”, “gimme”, take a hint. Let me clarify this point – after you established rapport you may find that your client is using colloquial language and slang, following the suite in this case could be OK, still not when you put your words in writing.
  • Being excessively polite. Your culture and language might require twenty minutes of praise and compliments before you get to business but I am an American, cut to the chase guy. More so, being overly polite and using somewhat unusual forms will telegraph a wrong image, your mentioning my “ultimate wisdom” only makes me think of a snake oil salesman.
  • Not being punctual / prepared for your interview. I think of proposal / interview stage as a “honeymoon” in a relationship with a freelancer, it all goes downhill from there. Late for your Skype call? Having troubles finding your headset? Can’t introduce yourself? Chances are that’s the last time you’ll hear from me.
  • Bidding too high or too low. Even though I can understand motivation of people bidding high or low, I typically ignore the bids that stand out in that respect. It’s probably clear why high bid is a losing proposition: unless you got the market cornered the price does matter. Less obvious is a low bid. The main issue here is trust and the fact that we as buyers have been conditioned to expect a “catch” or “bait and switch” with a low bid. Maybe $2 an hour is a perfect wage for combination of what you sell and your standards of living, yet if everyone else bids $15 or higher you should stay in ballpark otherwise the chances are your bid will be ignored.
  • Not following though. Few things annoy me more than a freelancer responding to my post and then dropping off without note / returning my questions. Maybe you realized that I am not the right customer / the project is not in your sweet spot / whatever. It’s perfectly OK to bail out from bidding process, just don’t forget let you customer know. A simple “regrets” note can do a lot for you on a next opportunity that could be exactly what you are looking for.
  • Telling me that you know what I need better than I do. That for some reason is particular common for developers from Eastern Europe and particular from my motherland Russia. If you indeed know (which is highly unlikely) suggest, illustrate, propose – don’t push, don’t fight with me, I get enough fighting when I tell my clients that I know better.
  • Playing games with scope / rates / budget. For many of us on a buyer side many of these games are transparent, most us who’s been in the industry for over 5 years seen at all – “bait and switch”, “low ball”, “door in a face” – you name it. As a matter of fact we make purchases and are being sold on daily basis. We get occasionally burned, sometimes badly. In stock market, real estate, cars, utilities… And when we come to work last thing we want to see is someone trying same techniques…
  • Leaving debris behind. That is my personal pet peeve. Just a few days ago I was looking through code deliverables from a freelancer who just finished a small RoR project for me. Looking through the code I found plenty of loose ends such as hard coded ID addresses, uncommented debugging code, etc. That was the first project this particular freelancer got from me and it is the last one.

I can go on and on, ad infinitum ad nauseam, but I’ve reached my self imposed limit of 10 bullets. I might revisit it later though.

BTW, an initial version of this post posted as a guest blog at oDesk blog got some harsh critique for grammar and other language mistakes I made from Nancci Maloney, probably on of the oDesk freelancers:

Sir, I understand some of your frustrations, but –

If you are going to criticize someone, you need to be sure your own house is in order. You state your second pet peeve is not using correct grammer and spelling.

Look at your 1st bullet – it’s a recycle ‘bin’ – been is a verb. If you had ‘read’ through your post you would know ‘red’ is a color.

2nd bullet – your English is ‘a’ work in progress – sort of changes the meaning of the sentence. If you still ’straggle’ with concepts then you need to look up struggle in the dictionary.

Why would I entrust my paycheck to someone who can’t use spellcheck?

There are other lesser grammatical errors in your post but I think you get the idea. My mama always said people in glass houses shouldn’t throw stones. It’s pretty sound advice.

Not sure if you noticed there are two spelling errors in Nancci’s comment.

So let me apologize in case some of those niximorons are still in this post and suggest that you should “do what I say not what I do” :)

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

Twitter – a New Tool in my Offshoring Toolbox

Eric Pan asked an interesting question on Linkedin – “Other than IM, email and phone call, I am thinking if twitter can improve communication with offshore teams in software development. Do you have any success story to share?”

The immediate reaction of the community was quite negative, e.g. “…the security is horrible and the 140 character limit (as noted in other answers) precludes its effective use… ” or “ … It will be a big distraction. I am not sure how you envision project communication…” I am afraid people behind these answers totally missed the point. I found the question rather thought provoking and after giving a few minutes of attention came to conclusion that twitter could be a rather helpful tool in some type of outsourcing / offshoring projects.

Twitter is quite a new phenomena and in its buzzpower its is successfully wrestling with Facebook and Google, it remains to be seen how rich he’s going to make its founders and whether it will stay for a while or fade away like many fads of the net era.

So far I had a few attempts to become a regular twitter and found neither pleasure nor purpose in it. Some say it could be helpful for my blog promotion, some suggest that it’s mandatory for building your personal brand. Not sure, I will probably give it another try… but that is not the topic here.

On the other hand communication is a backbone of offshoring engagements. One can not overestimate importance of communications for running teams of all kinds, 100 fold so for distributed ones. So if there is a tool that helps in communication processes it at least is worth careful consideration. There are plenty of tools we already have at our disposal – face to face meetings, phone conf calls and one on one discussions, email individual and group, intranet, wiki and sharepoint, chats, do we need another one? Well, is there a gap that needs to be covered? Probably there is none. Is there some way to improve current coverage, I bet!

Going back to twitter origins – it is all about status reporting. What are you doing? In technolingo that translates to What are you working on? Or What is your current status? That makes total sense. Skype chat is for discussions and instant updates. Twitter provides a vehicle of distributing status updates to a group of people in rather non-invasive form without clutter and overhead of email. The follower model is a solid alternative to to:/cc:/bcc: where the sender has to determine distribution list, putting the distribution in the hands of the receiver makes a lot of sense in a group setting.

Are there limitations to twitter – oh boy, where do I start? – but that’s not the point, if instead of nixing the idea for the tool limitations you take a proactive positive look you suddenly find many features that could be indeed very helpful.

I see a good fit to use of twitter in several areas of my offshore SDLC, for example milestone notifications on regression test runs, build reports, etc. There are also multiple possibilities in other areas, take for example production support / uptime notifications…

Not too long ago tools like YIM or Skype were considered bad practices and were banned from corp. IT world, for exactly the same reasons my distinguish LinkedIn colleagues are bashing Twitter today. Will see how this one pans out… let’s reconnect in a year or so?

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