Division of Labour

Over the past couple of months, I've been detailing some of the problems that come up in the outsourcing process. There are many more such issues, and I'll get to them as we go on. But I wanted to put in some thoughts on what conditions actually support outsourcing. We all know from newspaper reports and net articles how many companies are saving oodles of money by outsourcing, how the fiendishly intelligent and hardworking Indian workers are stealing US jobs. The underlying assumption now is that any white collar job can be outsourced (see http://blogs.law.harvard.edu/philg/2004/09/19#a6113 for a far out example). That is not true. There are very specific criteria that need to be met to achieve successful outsourcing.

Most of the problems I've outlined in my previous posts come up due to some wrong factor somewhere in the setup. I know it's impossible to get an completely perfect situation, but let me try explains the one most important factor (IMHO) that goes towards creating that situation : Neat demarcations of work. Organized division of tasks into in-housed and outsourced sections. If you can just do this one thing properly, your outsourcing project has a chance of going through.

Let me explain with a recent example from my company. The Development team of a project in the US has a pool of about 15 people. There are about 4 codeline branches, and the allocation of these people into these branches is fluid. The managers for each codeline are mostly fixed. When a customer requires a set of features or some bug fixes, URGENT, in a new patch for its installation, this info goes to the manager for that codeline. He looks to see who from the pool is free. There may be two or three 'regulars' for this codeline, and if they can handle this demand, all is fine. Else, he gets a few people from other branches allocated temporarily to his branch, and they all chalk out warplans, and roll out the new features in a couple of weeks time. During this period, inputs from the customer keep coming in, and temporary solutions which they propose to the customer keep getting rejected or modified, so each of the team could come to work the next morning to find himself working on something totally different - or even that he's now on another, even more urgent, codeline. Entire team is pumped up, totally into the code, and the manager is right there with them, co-ordinating everything. [Sadly, this is a pretty common situation in product companies]

Now these guys think, 24-hour productivity would be great, we could handle client requests even faster. Let's outsource some of our work. So, they hire 3 or 4 guys from a consultancy company in India, bring them to their office for a few weeks until they understand the bare basics of the code, then send them back. The outsourcers think, We'll start these guys working on small bugs initially, then move them onto bigger and bigger issues, until they're as good as we are. All set, right?

Wrong. Note that we're missing the most important piece here - the neat distribution of work. That means, even though our Indian team member has been given his work to do, the job is still controlled by the manager on the US side to an alarming extent. What happens is that, the manager, while going home, goes over the set of tasks he has, selects a few of them, and mails the Indian guys to do overnight.

The next morning he comes to work and finds his clients now want the team to do task Y instead of X, as scheduled yesterday. Hurriedly he IMs the Indian guys to say, "Stop the work you were doing yesterday, start work on this Y now." The Indians give him the status on the tasks they've been working on all day (Indian Time), which he duly notes. They are to go back to these tasks when things quieten down.

Except things never do quieten down in bleeding-edge product companies, do they? Over the next weeks and months, the co-ordination between the client's changing demands and the tasks allotted to the outsourcee team takes up more and more of the managers time. He's spending like half his day in clearing the outsourcee people's doubts and making sure they're up to date with the client's requirements - since they cant deal with the client themselves. If there's a manager devoted to the outsourcees, then the time is taken up in co-ordination between this manager and the other managers.

In short, the co-ordination and teamwork that is possible when an entire team sits in one office, in one time zone, is impossible if you have some people sitting at the other end of the world. Time and again, this simple factor has frustrated people on both sides of the globe, and led to the end of otherwise good outsourcing efforts.

The only solution here is to reduce the amount of co-ordination itself. And this can be achieved by proper division of work. Ideally, the work should be split such that the people in the outsourcee company do not depend on the outsourcer for any input - they only need report their status periodically, and present the outsourcer with the finished program when done. This is where software processes come into play - if properly used. They help define the work exactly, so that both sides can read the documentation and know exactly how much work is being passed on, how much effort is going to be needed to do it, how many people, etc. etc. This should be the only time when the manager frantically calls up the outsourcee people - to clear up doubts about the work assignment. Thereafter, the manager just keeps reading the status reports to make sure things are going right, and co-ordinates scheduling changes if the original schedule wasn't accurate enough. So the manager, at times, does spend hours of his time talking to the outsourcees. But that's when things go wrong, not in the normal course of things.

In precis form : The less the normal day to day co-ordination needed between outsourcer and outsourcee, the more chances are that the project will succeed.

An example: The famous Call Center jobs being transferred to India. Think about this a bit : How often does your normal call center operator get his routine changed through intervention of the American management folks? Hardly, hardly ever. The call center operation is almost self contained, all that goes from there to the outsourcer is a weekly report giving statistics. The American manager only works at a macro level, chalking out overall strategies.

Now go back to the URL above and see the idea the author proposes : Outsourcing University administration. Can this task be neatly demarcated so as to require minimal interaction with clients? Hardly. The task consists entirely of interaction with clients and other wings of administration. The idea is doomed even before it begins.

We dont need no steenkin' domain knowledge

"Domain Knowledge is what makes you a player"

Very recently, a colleague of mine was told this by a visiting client: "This C++ and java knowledge is all fine. But to really be a contributor, you need to learn about the domain you work in. Learn Domain1, and Domain2, read the mailing lists on those topics, ask questions and help drive those areas! Only then will you become a player in this profession."

Which is all fine, my colleague tells me, except that in the space of the past year or so, he's worked on three different projects, in three different domains. This was because the first project shut down suddenly (the clientside team's budget was exhausted) and the second project was a pilot that didnt find any customers. And there are any number of factors that could go into him changing the current project too. Which has left him with no inclination to study the Domain areas pointed out by the client.

This sort of thing happens if you were working with a product company, too. People working at, say, Microsoft do get shunted to different projects. But I dont think the way this sort of thing is handled at outsourcee companies is anything like those transfers. In a product company, there is some guiding principle on the kind of work you do. Microsoft is unlikely to make you work in Solaris. Oracle isnt going to make you write Image Processing tools. Even when moved from one project to another, the business principles that guide the movement are consistent across the company. They reflect some broad policy changes and focus shifts. In fact, your shifting has a lot to do with the domain wou work in.

Your typical outsourcee company has nothing like a guiding policy, or (if they can swing it) nothing like an area of specialization. It takes on whatever work comes its way. In whatever domain, platform, language, or duration. It knows that the relationship is going to be built up slowly, with simple work coming its way to start with. There is enough time for its employees to grow into the work. And when an employee is shifted, what usually happens is that the shift is because of budgetary constraints of the client, or urgent needs of some new client. There's no guarantee that the domains of both projects are the same... or even the platforms, languages, anything at all! The only requirement to join the new project is usually good analytical skills, computer science theory, and familiarity with the new programmming language.

So given that he could be shifted out of the project at any time, and that the domain knowledge he gets might never get used in life again, what incentive exists for an outsourcee employee to acquire more than the projects requirement? If he's lucky and stays in one project for several years, working his way into the core of the product, he'll pick up the domain skills. But at the outset, there's no professional motivation to be anything more than a code monkey.

A boss I worked under, years ago, once told me to develop domain skills in some area, any area I liked. It neednt be project related. It would give me some satisfaction as I went on. I followed his advice for a while. Today that stuff I learned is hardly ever used in my current project. I could, of course, continue to update myself in my chosen area, but that would have be done on my own time - my client wants every minute of my productive time for their work. And I do not ever see domain expertise being a reason for my getting some work (remember my point about about only easily-learnable work coming to outsourcee companies?). So why should I be putting in time into learning anything, when I can work overtime for my client, and get a promotion by fixing his bugs faster?

I'll say this again for those people who've done it : It is possible to become a domain expert here. You might be in one project for years. You might decide to put in an hour a day into following the mailing lists. You might really love some field enough to keep track without telling your boss. But all these are your own efforts. The company doesnt gain from them, so the company will not invest in them. Your average employee of an outsourcee company is not a domain expert on anything, except maybe some programming languages. Nor does the work that comes to him require domain expertise, mostly, so it fits fine.

A friend of mine recently realized this while on assignment at a client's site. He came back and told his boss, that it didnt look like we were ever going to get any core work. Him and his team mates would be doing only peripheral work that required no domain skills. The boss's reply was, "That works for us - keeps things manageable." Q.E.D.

P.S. Thanks for all your good wishes when I was off sick. This article was written partly before and partly during my off period, so it might be a bit disjointed. Still makes the point clear, I hope.

Off Sick

Hi People,
There havent been any updates to the blog in a while, and there's a simgle-word, foolproof explanation - Typhoid. I've got it, that is.
Managed to drag myself out of bed for half a day of work today, and will be hopefully coming up with updates more often now.