In my recent post on Verizon's corporate strategy, I explained that their plan to outsource 2,500 IT personnel to India-based job shop InfoSys "wouldn't end well." Because most companies depend upon software, I feel I must explain why Verizon is so much at risk so that you can avoid a similar blunder within your own firm.
It's pretty obvious that the main reason behind the transfer of Verizon's IT personnel is so the US-based erstwhile-Verizon employees can train their counterparts in InfoSys. This will theoretically allow InfoSys to accomplish the work previously done by Verizon's IT personnel but at a lower cost.
The reason this will not work is akin to the reason that voluntary layoffs don't work: the talented personnel will leave immediately. The situation is even worse, though, because the IT personnel who remain will inevitably become passively aggressive and frustrate the transfer of knowledge as far as possible.
I'm reasonably certain the situation will play out this way because I have closely observed programmers and IT personnel for over four decades and I've seen dozens of companies make mistakes similar to the one that Verizon is making. The root problem is the tendency of non-technical executives to treat technical personnel as replaceable resources.
That's unwise because programmers, engineers and IT personnel tend to create specific cultures based upon shared experience and knowledge. When that shared experience and knowledge is lost--a phenomenon I call "technical discontinuity," the result is usually chaotic and often disastrous.
Since technical discontinuity is a concept that seems to difficult for many non-technical executives to grasp, I'll try to explain it as clearly as I can, using the most extreme case, which is the transfer of responsibility for a computer program or system from one group of programmers to another.
I'll walk you through it logically, as a series of linked observations:
1. Code is a human-to-human communications medium.
While the primary purpose of code is to communicate what you want a computer to do (read, calculate, display, etc.) the secondary purpose of code is to communicate between programmers. This is accomplished in two ways.
First and most obviously, there are comments. Because programmers know that they (or other programmers) will probably revisit this block of code (either to debug or alter it), they include notes explaining the purpose and reasoning behind each chunk of code.
Second and more important, the code itself communicates the intention of the programmer to other programmers. In spoken languages, writing that communicates the same thing can be either clear/elegant or obscure/awkward. That's also true of coding.
2. Code reflects the individual coder.
While code is a universal language (in the sense that if everyone is coding in C++, they're using the same basic rules of grammar and syntax), code by necessity reflects the personality, education and ability of the coder.
In a tight-knit group, programmers can usually glance at a chunk of code and know immediately who wrote it, based purely on the writing style of the code. This allows them to more easily understand what's going on, which is essential if they're going to make changes like removing bugs or adding features.
Because code is itself language, programmers with disparate linguistic backgrounds (say a German and Malaysian) will be harder to mutually understand than code written by those with similar linguistic backgrounds. That's also true of comments, naturally.
3. Coders are not interchangeable resources.
It should be clear from the two items above that that coders cannot be swapped around without having an adverse impact on the potential ability of the code (and comments) to communicate between coders.
Even in cases where a brilliant coder creates pellucid code, that code may seem confusing to an equally brilliant coder from a different technical or linguistic culture. That's even more true if (as is common) the code is hastily-written and poorly commented.
Furthermore, this type of confusion (which I call "technical discontinuity") is exacerbated rather than alleviated by "throwing bodies" at the problem. Having too many coders inevitably spoils the metaphorical broth, especially if they're not entirely sure what they're cooking with.
4. Best case, coders support their own code.
Because of all of the above, it's well known among programmers that the best person to support a chunk of code is the person who coded it. Next best is having the coder who wrote the code and coder who must support it work in the same, tightly-knit group.
What happens all too often, though, is that code, once written, is handed off to a different group responsible for support. This need not create a disaster if the two groups are in regular communication and have a shared technical and linguistic culture. But it's not ideal.
It's often disastrous, though, when the original coders and support coders can't communicate because the original coders are no longer available. In that case, the support coders must depend entirely upon the legibility of the code and the comments to maintain or upgrade the code, a very difficult task when there's a wide cultural or linguistic gulf between the two groups.
It should probably be said that the developers of software that programmers use to create their own software have taken great pains to make it easier for programmers to create readable code that's more easily structured into well-behaved programs.
In particular, they've made strides in making it easier for multiple programmers to participate in the creation of a single piece of software and make that software more easily supported. None of this can complete solve the challenge of technical discontinuity, though.
5. Code rots if not well-supported.
Supporting code is important because, while it seems that code "ought to do now what it did previously," that's simply not the case. Code operates in an environment. Change the environment slightly or alter the code slightly, and it may behave in unexpected ways.
If very well-coded and very well-supported, code eventually reaches a steady-state where it's possible to fix bugs without creating additional bugs. Ideally, that is. In reality, most code exists in ever-fluctuating environments where support coders are engaged in a Sisyphusian battle against the gradual entropy that's inherent in complex software.
That battle is challenging when there's full "technical continuity"--where a tight-knit group of linguistically and culturally similar programmers are responsible for both the original coding and the ongoing support and enhancement of that code.
6. Technical discontinuity equals system instability.
If you're following all of the above, it should be obvious why it's a strategic mistake for Verizon to transfer their entire programming staff to another company with a different culture (corporate and technical) and do it in a way that virtually guarantees most of them will leave.
Returning to Verizon, while the work that their IT groups were accomplishing was probably not as complex as, say, developing an operating system, there was and is undoubtedly sufficient complexity to make technical continuity a priority, which is exactly what Verizon has failed to do.
Of course, unless you're a Verizon customer or employee, this strategic mistake is irrelevant. However, if your company uses software and especially if your company creates or customizes it, you're well advised to keep the concept of technical continuity in the forefront of your planning.
Let me explain. Suppose you're working with a small software vendor that gets acquired, there's a danger of technical discontinuity which, if it blooms into a full-on disaster, might damage your company's ability to make money. It's in your best interests to assess whether the acquiring firm will mitigate or augment that discontinuity.
If the acquiring firm is, say, private equity, it's highly likely that their inevitable attempt to loot the company's value will result in immediate and probably fatal discontinuity. Therefore, your wisest move is to immediately start moving to another vendor. As painful as that might be (due to customizations and peculiarities) in the long run it will be less painful than the gradual decline and probable collapse of your current vendor.
On the other hand, if the acquiring firm is a slightly larger software company in the same market and located in the same general geography, the discontinuity will likely be minimal. As long as there appears to be a plan for orderly transition and (especially) the retention of most of the coders, you should stand pat.
Similarly, if your company develops software and you're in business for the long haul, you should make technical continuity a high priority. The last thing you want to do is to, say, try to replace your middle-aged coders with ones that are fresh-out-of-college or just-off-the-boat. Much less located halfway around the world.
Please don't think I'm disparaging the engineering abilities of companies located outside the US. Far from it. Engineering excellence can be found anywhere. However, though excellence is obviously desirable it can't compensate for the damage wrought when technical personnel are heedlessly treated like plug-and-play resources.