Pragmatic Outsourcing

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.

If you are retaining a portion of SDLC in your organization code reviews would be great candidates for components to be kept internally. I saw a few “best” practices in implementation of code reviews with offshore development teams that were rather successful:

• Full / high percentage code review of the code by a senior on-site team member. S/he is typically assigned as a tech lead of the team and is in general responsible for technical integrity of the deliverables. S/he reviews (or produces) all high level architecture and technical design artifacts, and then reviews code produced by offshore developers. This model works particular well in waterfall models, with some modification it can be applied in more agile SDLC as well. There are obvious scale, morale and org issues with the model, most of them could be dealt with if tech lead(s) bought in the process and are qualified for the role.

• Using code review tools that help facilitate and manage the process. My team has been using Cruicible with an offshore partner in Brazil with a large degree of success. By the way one of the measures of success could be the sustenance of the process: if dev team is using code review without constant nagging and pushing rest assured that code review is working out for you.

• Spot check with follow up process could be rather efficient method of enforcing some specific development practices, e.g. coding standards. The idea is quite simple – if the code review reveals specific issue you need to follow up with the developer, after a little while you need to code review other newer artifacts and see whether the problem is addressed. When offshore resources are in ample supply I would exercise the rule of three – first time it’s your fault, second time it’s my fault, and there is no third time… Random spot check style of code review also offers great help in identifying skill / knowledge gaps and IQ issues.

In general code review only applies to organizations with a very high bar for code quality. And the bar should be held high for everyone independently of their location. Producing high quality code is not easy and it doesn’t happen by itself, it is quickly deteriorates if left alone. As one of my readers said – people do what you inspect not what you expect. In that light code reviews or code inspections play tremendously important role. Inspections by themselves are still not sufficient and must be supplemented with broad draconian measures of code quality that apply across organization. It is a matter of personal preference whether you use the rule of three or much softer measures, independently it is exceptionally important to link code quality to individual and individual performance appraisal.

I have to mention one rather controversial and very important point – high quality of code could be a luxury an organization could not afford, even more – in some cases it is an unnecessary extravagance. In today’s world producing code that doesn’t pass high standards is not at all as detrimental as it used to be in the days of PL/1 and C++ and even more so in the days of low performing hardware and memory limitations.

I remember having a long discussion with one of code quality evangelists – he was going on and on ad infinitum about how important is to write one beautiful line of code instead of three ugly ones. Very articulate and passionate about the topic he was impossible to win over especially considering my pragmatic and not so elegant position. We parted both even more firm with our original viewpoints.

When it comes to offshore it becomes even more important not to try to enforce quality of code that is above reasonable expectations. It is difficult to find high quality code producers even in this country with plenty of evangelists around. BTW, even the guy I mentioned before wan not fault free and left plenty of debris behind. So pick you battles wisely…

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.

Below are a few red flags to watch out for. While these flags in general work from both points of view (the vendor’s and the customer’s), some apply more to one side, some to the other.

o Team Dynamics. The first and the most important indicator of the relationship is the team morale. That is one of the best barometers you can use to forecast the partnership weather so to say. Use a simple rule of thumb – when the team morale is going down expect some rains in your partnership land or maybe worse. It takes a bit of experience to asses the team’s morale though. I suggest you take a simple observational approach – if people communicate a lot, have fun working together, connect at a personal level, and show impressive teamwork that means that spells great morale. You see a lot of finger pointing, team members being distant from each other, and not enjoying the work that is low as far as morale scale. One thing to keep in mind is relative state of morale from team to team / environment to environment. What you consider a high morale in team A could be a very low for a team B. So the key is to look for the changes in the team dynamics. If you see regular fingerprinting and CYA attitude turning to fights and backstabbing that means your barometer is falling…

• Communication Dynamics. Change in partnership relationships is usually preceded with changes in communications. If your contact suddenly stops returning your calls, if style of the email becomes much more official, if you notice increase frequency in communication gaps, etc. chances are you are facing a brewing partnership problem. It is common to see deteriorating communications, especially if communications are not explicitly managed – people attend fewer meetings, take longer to reply, miss replies, etc. – even when things are going fine. That masks the red flag. There are a couple ways to deal with it – manage communications on an ongoing basis (that’s the best) or revive / bring them back to expected level on a recurring basis. In any case it is exceptionally important to take a stock of the situation to understand whether there are any reasons for more profound concerns.

• Increase in turn over. That is a very telling indicator. Employees on your partner’s side often have a better knowledge of the relationships and the internal state of affairs even if they are not in the “executive loop”. When things get rough people try to find alternative places in the organization or outside of it. Basically the proverbial rats leaving the sinking ship. People won’t advertise the reasons for leaving and often conceal those behind regular life events “moving to a different city”, “taking care of sick family member”, or they “find an opportunity they could not resist”. No matter what the reasons are if the rate of turn over is going up it’s a serious red flag and time for in-depth analysis of the partner, relationship, and situation.

• Quality and Productivity. Serious internal issues on the partner side or with the relationship will inevitably find their way to employees and will affect their morale. Market or contract clause can restrict the employees movement, the remote nature of the contract may hide deteriorating team morale and group dynamics. There are couple outlets that will not make you wait long before red flags appear – quality and productivity. When employees’ morale falls and their motivation declines the quality of their deliverables deteriorates, and often their productivity tumbles as well. With some of the contributors quality and productivity fall slightly with some the decline would be substantial. Typically, the decline in quality and productivity averaged across the team is notable. You can see it in simple metrics like escape ratio.

• Financial Dynamics. The financial dynamics of the partnership typically settle after 3-4 billing cycles. The invoices comes on time / a week ahead / two weeks later; the are perfect / have mistakes; they paid exactly on time / after two past due notices are sent / etc. If that pace suddenly changes you need to check whether that is just a change in AP/AR department, new policies or indication of oncoming relationship disaster, unfortunately often that is the case.

I just added a new post to my new blog Common Sense Management – Laws 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?

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” –

• You have invested in building the relationship by going through the process of selecting the vendor and the pains of establishing the relationship. You might be in early stages of realizing ROI, so why stop?
• There are probably some problems with the vendor; there will be problems with the new one. Switch for the sake of a switch do not buy you a way out of problems, just changes the pain location.
• If the issues you experiencing with the vendor are lower than your threshold for them you can probably ignore them. At some point the pain become ambient and by all means you can go on as if it did not exist.

So after you regular What-If analysis and weighing in Pros and Cons the vendor seems worth keeping. What are the steps for keeping the vendor? Oh, I see another question coming. What do you mean by keeping? Where is the vendor going? There is a contract preventing them from leaving, plus why would they ever leave if I pay them regularly and more or less on time?

Well, there are reasons they might leave, but it’s not the point here. The question is what you should do, what steps you need to take to prevent the relationship from deteriorating to a degree you would have to break the engagement.

1) The first most important “step” you can take is to help your vendor with their “five steps”, in that light you have five “sub-steps” to start with, all of them boiling down to clear and open communications:

• The first step in Five Steps to Keeping your Business was focused on communications and in particular establishing and sticking to communication plan. That is one of the areas that require equal dedication of both parties. Work together with you vendor to define a meaningful communication plan and stick to it. As the landscape of the engagement changes you might need to revise your plan. To work the plan should be applicable to the current situation, efficient and agreed by both parties.
• While you can not really help your vendor to be more flexible or more prepared for change, you can keep them aware of changes in your needs, structure, requirements, etc.
• Helping your vendor with account management can be addressed in many ways, with the most important being allowing him / her to be the best AM they could be, manly through direct and open communications. Some organizations go as far as picking up the expense of AM, I don’t like that approach. I think paying for AM should be a part of vendor’s skin in the game.
• Consistently providing your vendor with a clear picture of your expectations and assessment of quality is exceptionally important. Do not ignore those surveys and questionnaires – they may prove to be more value than you think of them. Be honest in rating and prepared to substantiate your answers. If your vendor doesn’t bother you with quality survey – volunteer those at least on quarterly basis.
• When appropriate make you personal wins known to the vendor, position them appropriately as optional / secondary while still important. That should not be a tricky process unless your personal goals are in conflict with organizational; and in that case you may have much bigger problem to deal with… Anyway, isn’t it what the golf is for?

2) Get to know your vendor. Understanding your vendor’s internal driving forces and organizational dynamics can help a lot in forming the strategy and being successful in keeping the vendor in a long term. Learning your vendors’ organization both on macro level (at the organization level) and micro (team / individual) level is better done on their territory. It is also important to have the knowledge distributed through your organization, and one of the best way to do that is to acquire the knowledge through multiple channels, e.g. have multiple people from your team travel and work at the vendor site.

3) Help your vendor to become a stronger partner. Honest and timely feedback is just one of the ingredients. Technology exchange, methodology training, mentorship, etc. You organization can have enormous potential in helping your partners in building their expertise. Think about investing in your vendor the way you invest in your employees. There is of course important boundary here, you do not want to become overly dependent on your vendor or invest in them too much.

4) At some point, when you have established sufficient level of trust and experience with the vendor you can become a reference account. Helping your vendor on sales side plays in your favor in several dimensions – making your vendor stronger, making them more dependant on you as well. Don’t take reference account too easy and by no means let your vendor take it for granted or you can put your company’s and own reputation at risk.

5) And finally a step that might sound controversial nevertheless it is exceptionally important – stay with Disposable Outsourcing Model. There many reasons DOM helps you to keep the current vendor by removing the anxiety and reducing tension. Operating within DOM helps the vendor deliver to your requirements and deal with typical issues such as staff turnover. There is a lot to be said about DOM support in this case, but taking 180 degree turn I must say that if you fail in every aspect mentioned above and only did well on DOM implementation you are still golden since it doesn’t necessary that painful for you to fail in keeping the vendor, and in some perspective with ultimate DOM you can always keep the “vendor” while underlying provider changes…

While there are more steps / actions you can include in this list I think the main one are covered, as always I’d really appreciate your ideas though.

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 Diamond]

oDesk did a fabulous job giving me – the buyer – tools to oversee and control the execution. The tools in particular applicable for such tasks. Today I can go in my “team” room and see my team working, almost as if they were in the office next to mine.

Maybe even better. The tool gives me detailed time tracking, type / click rates and takes periodic screenshots so I can see what my money are spent against.

No FB browsing or chatting goes unnoticed and frankly for data entry and other similar projects that is a very big deal. Basically I can look over the shoulder of any person on my team and take almost immediate action all the way to termination. Actually not something I can do with local employees / contractors.

There other tools / features that oDesk offers, some probably worth discussion. At this point the ability to crack the whip across 10,000 miles is my favorite.

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…

It’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.

• Even the largest and the most conservative organizations are always in motion and all aspects of the engagement constantly change. Subtle changes aggregate and result in substantial shifts and turns. That affects all dimensions of the relationship – technology, staffing, roles, politics, etc. “It is not strongest that survive, nor the most intelligent, but the most responsive to change.” [Charles Darwin] If you want to keep the customer you need to learn to dance with your client following their changes and changing / reinventing yourself as the customer and the relationships change over time. Build your organization, team and the engagement structure in a way it can respond to change in efficient and timely manner.

• In offshoring engagement too many things can go wrong; as a matter of fact something always goes wrong. It could be a minor issue, a widening communication gap, or individual associate behavior. It could also be a change in the customer’s organization structure, budget reshuffle, or a competitor getting a shoe in the door. There is no day that passes by without some event relevant to the business. In that light keeping a hand on a pulse of the relationship is vital for the engagement. That translates to well known fact that dedicated account management is a must for offshoring engagements. And yet, for some reasons, many offshore vendors think that the account management is “nice to have” activity, that it could be done on ad hoc basis, or that it could be combined with other roles, sometimes putting the person in a conflict of interest. This is a topic worth serious discussion, for now let me just say that insufficient investment in account management is likely to cost substantially more than the investment itself.

• Any service provider has to deal with conflicting objectives that come from the very essence of any business – drive to reduce the cost and increase the revenue. To some degree it could be position as two forces that push quality in opposite directions. Maintaining the balance between this forces is exceptionally complex task and ability to do it right is the single differentiating factor that raises the winners above crowd of mediocre providers. This topic, even if limited to just my knowledge, would require very extensive and multidimensional coverage. There is an extremely important point though – measuring quality. You may want to increase or drop the quality depending on resources, clients, etc. But to do that you need a scale, a marker that points you to where the quality is. You can not control something unless you measure it. Trying to maintain quality balance without it is like trying to play pooling rope in a pitch dark room.

• Your customer (organization) is represented by a few individuals that play different roles in the organization and in particular in the relationship with your company / engagement. These roles could include sponsors, champions, business buyers, gate keepers, etc. These people are critical for you success and absolutely essential to keeping the client. Each of them has their organizational goals and personal goals. For example specific project success could be an organizational goal, getting promoted as the result of the project success is personal objective. Your goal as the vendor is to recognize and cater to both of these objectives. As a matter of fact a flawless execution on organizational objectives but failure to meet personal ones can result in a loss of business.

Here you go. Just take these five steps and you will never lose your business… Not… Alas, these are required steps, not sufficient. As a matter of fact steps towards keeping the business have been illustrated by Escher the best (the picture above).

Hey, nobody said the life’s fair.

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” :)

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?