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.