Skip to main content

Expertise and Offshoring

While I was working as a senior manager in a Fortune 500 IT department, we went through a recession, and a few years later through the U.S. outsourcing offshoring trend.

During the 2001 recession, management reacted with reasonable downturn planning. Business management requested a certain level of cutbacks (say 7%) and IT listed projects that could reasonably be cancelled. Things difficult to cut back (without very serious planning) such as operations - keeping the lights on, normal systems maintenance & support operations, planned regulatory system work, and required upgrades (due to vendors end-of-support-life), these were all off limits. New development and system enhancements were on the line.

IT management also reacted in a normal downturn mode. Middle IT management had gotten a bit fat, so they trimmed middle management. For the remainder, they turned to their managers and instructed them to lifeboat. Those employees who weren't considered key - who weren't a subject matter expert, just a plain old team member - and who were lower rated in performance, were thrown overboard.

It was moderately painful as a manager to be judging people such a way, but the cutbacks didn't really bite as the method was focusing on trimming the least efficient staff (of course such judgements weren't always perfect). When the recession ended and business started picking up - with a resulting increase in demand to the IT department, the IT management made an interesting decision NOT to significantly increase staff but rather to try offshoring.

The offshoring calculus was interesting. The Indian vendors (such as Satyam, Cognizant, Infosys, Patni, and Tata among others) arrived offering offshore "resources" (people, but we never referred to them that way, just "resources") at a rate/cost of 3.2 : 1, meaning we could rent 3.2 consultants for the amount we paid to 1 full time employee (including all associated costs, taxes, equipment, office space, etc). Further, we could bring them onshore, directly replacing employees in our office, at a rate of 1.6 : 1. (While legally H1B and L1 US visa's don't actually allow for this beyond temporary role filling, in practice we consistently were instructed to use them for exactly that purpose.)

In theory, you're getting a massively larger number of people working on your software projects for the same amount of money, basically 3 to 1. Our IT department literally doubled in size, by pure number of staff working on our projects. But productivity did not increase. The output of the department did not double, rather it increased very marginally (maybe 25%).

What happened was systems expertise started dwindling. Every software system has some design patterns, both technical and business. Business goals, processes and rules are incorporated into the code and class/object structures. Algorithms and routines are selected and created to accomplish the software goals. And, like the layout of a city and the understanding of what it takes to get from one point to another within the city, the system gains it's own unique structure. Exactly like a large city versus a small one, bigger systems with many modules and functions take longer to learn to traverse than smaller ones.

People who spent significant time within a system become Subject Matter Experts - they understand the business goals which it is meeting (and which it's doing well or not so well), how it's doing it, which parts of the system are strong and which are weak, and when asked to modify the system have some idea of what it will take. Depending on the complexity of the system, it takes 6 months to 1 1/2 years to become a true Subject Matter Expert (SME).

Offshore teams do not arrive with any subject matter expertise. Further, there tends to be a lot of employee motion among such teams - staying on the same project for a year and a half is an unusually long engagement by their standards. (Not that an offshoring company won't be engaged on a project that long, but hot developers are moved to the latest hot project, lower level coders are brought in, and moving between jobs and companies has been a very frequent activity among Indian IT workers.) So the teams are constantly climbing the learning curve on the same systems, and losing the SME efficiency that long term IT employees have.

At the Fortune 500 IT shop, we did not solve this problem. Further, it seemed to be growing worse. Even though studies were showing offshoring value returns from 6% - 20% gains in value/reductions in cost (meaning though the number of people working on a project would be 2x or 3x versus having a local IT staff, the value returned was only a 6% savings over having that local IT staff), the offshore trend kept accelerating.

During a management offsite, myself and co-worker manager were asked to create a presentation on approaches to solving the problem. For having a small group of managers and 1 hour to solve the problem, I think we actually did present a number of good solutions. Here is that presentation...

Popular posts from this blog

Integration Spaghetti™

  I’ve been using the term Integration Spaghetti™ for the past 9 years or so to describe what happens as systems connectivity increases and increases to the point of … unmanageability, indeterminate impact, or just generally a big mess.  A standard line of mine is “moving from spaghetti code to spaghetti connections is not an improvement”. (A standard “point to point connection mess” slide, by enterprise architect Jerry Foster from 2001.) In the past few days I’ve been meeting with a series of IT managers at a large customer and have come up with a revised definition for Integration Spaghetti™ : Integration Spaghetti™ is when the connectivity to/from an application is so complex that everyone is afraid of touching it.  An application with such spaghetti becomes nearly impossible to replace.  Estimates of change impact to the application are frequently wrong by orders of magnitude.  Interruption in the integration functioning are always a major disast...

Solving Integration Chaos - Past Approaches

A U.S. Fortune 50's systems interconnect map for 1 division, "core systems only". Integration patterns began changing 15 years ago. Several early attempts were made to solve the increasing problem of the widening need for integration… Enterprise Java Beans (J2EE / EJB's) attempted to make independent callable codelets. Coupling was too tight, the technology too platform specific. Remote Method Invocation (Java / RMI) attempted to make anything independently callable, but again was too platform specific and a very tightly coupled protocol. Similarly on the Microsoft side, DCOM & COM+ attempted to make anything independently and remotely callable. However, as with RMI the approach was extremely platform and vendor specific, and very tightly coupled. MQ created a reliable independent messaging paradigm, but the cost and complexity of operation made it prohibitive for most projects and all but the largest of Enterprise IT shops which could devote a focused technology...

From Spaghetti Code to Spaghetti Connections

Twenty five years ago my boss handed me the primary billing program and described a series of new features needed. The program was about 4 years old and had been worked on by 5 different programmers. It had an original design model, but between all the modifications, bug fixes, patches and quick new features thrown in, the original design pattern was impossible to discern. Any pattern was impossible to discern. It had become, to quote what’s titled the most common architecture pattern of today, ‘a big ball of mud’. After studying the program for several days, I informed my boss the program was untouchable. The effort to make anything more than a minor adjustment carried such a risk, as the impact could only be guessed at, that it was easier and less risky to rewrite it from scratch. If they had considered the future impact, they never would have let a key program degenerate that way. They would have invested the extra effort to maintain it’s design, document it property, and consider ...