Preparing for Offshore IT Labor
IT departments offshore specific functions for a wide range of reasons. Reducing costs, obtaining manpower "on-demand," or simply tapping into a broader pool of skillsets are all legitimate needs which can be satisfied with a managed services provider that has a strong offshore labor capability.
Yet graduating to an offshore model is similar to upleveling a mom & pop bakery-- one where every loaf of bread is made by hand-- to a factory clammering with industrial machinery that cranks out dozens of loaves by the hour. This increased scale, faster delivery, and low-cost bulk ingredient model may sound enticing for the overworked bakery owner. But this "industrialization" requires a new set of skills and possibly new positions entirely. Without them, the machines will not operate properly, and the baker may be worse off than before if bread isn’t bouncing off the conveyor belts at a steady pace
How Offshoring Is Different
Traditional IT teams are physically collocated together, and consist primarily of execution-centric roles such as programmers, sysadmins, DBAs, and so forth. As companies grow, they hire more more IT “doers” along with additional managers to oversee these individual contributors.
When offshore resources come into the picture, you immediately drive a wedge between the onshore and offshore people. This wedge is what I refer to as the “four Ts:”
- Timezones - As you may have guessed, the timezones are different! You’re working while your counterparts are asleep, and vise-versa. Real-time communication becomes limited to overlapping work hours, assuming those exist at all.
- Technology - Even with the advances in today’s tech, remote communications are still terrible. Crackly phone lines with garbled audio, choppy video, clumsy conference dial-in codes. I can go on and on. More importantly, email and chat technologies lack key human context (such as body language) that is critical for obtaining understanding and trust between colleagues.
- Translation - This represents both language and cultural barriers. Language should be obvious: if someone’s English is poor, other English speakers are going to have a tough time understanding that individual. But translation gaps occur on a cultural level, too. As an American English speaker, I’ve heard British English phrases that made no sense to me whatsoever. Likewise, I’m sure my “Californian” vernacular has confused plenty of my remote coworkers along they way.
- Trust - The end-result of all the other T-based challenges is lack of trust. It’s not that people don’t trust each other on a personal, moral, or ethical level. It’s just that people simply don’t understand each other's’ “full picture” of intent and motivation, which in turn creates hesitation, which of course stalls collaboration and productivity.
So, if your offshore teams are sleeping while your onshore teams are collaborating in active business technology discussions, how are the offshore folks going to contribute to the project? I can tell you how it won’t work: by having your onshore team of “doers” providing piecemealed tasks to their offshore counterparts. Remember, the offshore team loses significant project context by missing meetings, body language, and real-time conversations. Therefore, this critical context must be “reconstructed” somehow, and that somehow is through architecture, well-defined processes, and project management.
A simple way to think about projects is by decomposing them along the dimensions of why we’re doing the work, what we’re doing, how we’re doing it, and when it’ll be done. With outsourcing, we’re relocating the how piece to a team residing far, far away.
If we examine what happens to a human being when he or she loses one of their five senses, the other four typically enhance in order to compensate for total sensory. (E.g. you lose your sight, and your hearing and sense of smell becomes stronger.) With offshoring, we limit the ability to focus on how things get done locally, so we must bolster the following areas and positions to ensure holistic success:
Business Analysis - Why we’re doing this in the first place. Writing code or building a database is rarely successful when you don’t fully comprehend the wide range of use cases. Business analysts are key in conveying why we’re doing one thing versus another. Business analysts should also be able to “go deep” on various business scenarios and explain user stories in detail to the remote hands helping on the project.
Architecture - What we’re actually building. Solution architects are the ones who must compile designs with enough specificity so that the offshore team-- one that’s been absent in countless meetings-- can decide how to deliver a working solution which actually implements the design at hand.
Project Management - When the solution will be built, at what cost, and within what scope. Without dedicated project managers, the endless volley of inter-timezone emails between individual contributors will surely result in deadline slippage.
Of course, the offshore team completes the picture with the final puzzle piece: deciding how the work actually gets done.
Like our baker who must hire machine operators to work in the newly industrialized bakery, so too must the IT department staff accordingly with these new business analyst, architect, and project management skillsets. The main idea is that adding additional rigor in the “what, when, and why” domains will help out with the “how” domain. Without such roles, the road to offshore labor will be rife with challenges and confusion.