Why Is Domain Knowledge Not Valued

Many find it peculiar that DomainKnowledge - knowledge of a specific - domain (business) is not valued to employers nearly as much as technical skills (programming languages, OS's, database platforms, etc.) Companies often dump very experienced company people in favor of an expert in some new language or fad. For example, they may dump long-time COBOL'ers who know the company up and down in favor of web developers. What are reasons for this? [Note: This has nothing to do with domain names, "domains" in the Windows networking architecture, or various mathematical uses of the word "domain"]

BuzzwordCompliant? Um, in the sense that some HR departments will reject an applicant familiar with MS Office because "he doesn't know anything about MS Word".

Laziness - It is easier to test someone's familiarity with a particular technology than it is to assess how much their business or domain knowledge is worth. There are lots of ready-made tests out there for specific things (C++, Java, VB, DotNet, Corba, ...). By contrast, a superior set of abstractions arising from better business knowledge may end up finishing work far quicker, or changing the nature of the project altogether. But that's not something you can score out of 100 on a test. SovietShoeFactoryPrinciple.

Stigma - Often companies view people who have been engaged in maintaining legacy projects as somehow incapable of learning new technologies. Some seasoned developers, however, do put off new technologies, despite the advantages, until after they've been replaced. Sad and confusing, but sometimes true. It's often politically easier to get new people in for a new project than to break up existing teams, which can pick up inertia all of their own. Perhaps management is afraid the old guys know more than they do, and would keep pointing out flaws in a project. Many managers plan to move on before show time, and thus are not scared of project failure.

DomainKnowledge is too specific - In some cases, the knowledge required is specific to an organization or company - and thus almost impossible to get from the outside. In the context of hiring, domain knowledge is deemed to be an irrelevant factor, by virtue of the likelihood that no candidate will have the necessary domain knowledge on his first day on the job. Thus, other factors such as programming skill are considered instead. Of course, that doesn't necessarily explain why established employees with domain knowledge get downsized at the same rate as their peers (or more rapidly, if other factors - such as higher salaries or about to retire and cash out a large pension - make them more attractive targets for layoff). Difficult to ascertain - There are numerous certifications, tests, degrees, etc. which can be used to ascertain (to some approximation) skill in something which is domain-independent (i.e. skill in a particular language, a ComputerScience degree, etc.) Testing for domain experts is much harder. [EditHint: merge with "laziness" bullet above or refactor.]

Devaluation of DomainKnowledge in management training - This one is starting to change, fortunately. For quite a while, management schools and MBA programs liked to push the belief that technical skills (management, programming, etc.) were all that's required - and that a good manager (for example) could equally well manage an startup company, a McDonalds franchise, a department within a Fortune 500, a construction crew, or a government agency. Any necessary DomainKnowledge could be acquired on-the-job; or else the manager could rely on subordinates to supply her with DomainKnowledge whenever an issue requiring it came up. This is folly, of course. While many of the management tasks are the same within all examples (basics on personnel management, budget management, etc), DomainKnowledge is necessary for so many of the day-to-day tasks facing a manager. It is quite likely that this belief has been extrapolated to other fields, such as programming.

Quest for a desirable TruckNumber, and interchangeability - Dependence on key personnel with DomainKnowledge (or processes which require DomainKnowledge) adversely affects the TruckNumber of a department/project. By devaluing DomainKnowledge, and implementing policies and processes which de-emphasize it, it is believed that greater interchangeability among personnel can be achieved.

Or is it just that DevelopersHaveNoDomainKnowledge. Or, perhaps candidates don't emphasize it on their resume and interview, and thus reinforce the perception that techies only care about tech.
Also belief that the most important aspects of the knowledge are now available as software. As a programmer you are constantly in the position of DealingYourselfOutOfTheGame? since if the program works well, why are you needed once it is done? If you also have additional specialized knowledge which the software captures, you are doubly vulnerable. The temptation is to find ways to put "hooks" in that only you know and control, but I suspect that is an AntiPattern. One of the seeming ContradictionInTaoism (or was that ZaZen?) is "don't be attached".
Management already has the DomainKnowledge. DomainKnowledge held by the implementers is redundant.

KnowledgeManagement Systems will keep DomainKnowledge. Once populated and institutionalized, you may not need (engineering) managers either.

Customers have domain knowledge; we can ask them.

For situations with OnsiteCustomer, this seems especially tempting. If you're implementing an accounting system for the enterprise, the staff accountants ought to know how it works (according to this theory). In organizations that develop products for external sale, marketing is frequently chartered with being the repository of domain knowledge, often under the theory that a) they are closer to customers and b) are familiar with various market-research techniques. The problem with both scenarios is that someone needs to transfer design information from the customer domain (UserStories, requirements) into the software domain (code, design documents, UselessModellingLanguage?), etc. Programmers lacking in domain knowledge have a difficult time performing this transfer correctly.

Some think there may be a problem with scalability of developer maintained domain knowledge. Somebody has to have the domain knowledge. Why is it more problematic to leave it with programmers than some other kind of worker? Consider this scenario: you start with a small shop and develop domain knowledge and become very productive. Because of your success a tremendous amount of new business comes your way. As you grow rapidly your domain knowledge is diluted and/or lost. Is it because the programmer churn is high? Maybe because you are not paying them enough or mistreating them. You need more and more Java/Oracle/Net programmers and have no time to train domain knowledge. Next thing you know productivity falls to a level below even when you were a small shop. You business either stagnates or falls apart. If you have seen this situation as a manager then you might think that it is dangerous to build a business model on developers with domain knowledge. See WhyMyCompanyFailed.


I'm not so sure it is a problem of value as it is of cost and control. It is obviously easier to displace the "old-timers" with lower cost, malleable and willing cadre which is more receptive to the inevitable change forces which displaces old technologies and techniques with more modern approaches. It is often true that they are also more easily formed to "follow" the lead of a regime which is interested in conformance which they see as necessary for efficient performance. However if they do not find a way to carry forward the business knowledge in addition to employing modern techniques, they will collapse and/or be absorbed by the more efficient, and success oriented organizations. As to the fate of the "Cobolers" who have not seen the handwriting on the wall since the 1970's and 1980's, and who have failed to update and improve their skills and proficiencies, their cries will fall on deaf ears, since survival in whatever field, is survival of the fittest. -- MarkRogers
Most of my employers have valued domain knowledge enough to pay for my training. My current job uses domain knowledge (check processing) I acquired at a previous job. Some of my employers didn't value domain knowledge, but it wasn't because they were foolish. Either the work they needed done didn't depend on deep understanding of the business or they were willing to pay to train people who already had the technical knowledge. -- EricHodges

The last sentence shows that they value technical knowledge more than domain knowledge. In there mind it is easier to add domain knowledge to a techie than the other way around.

I wonder which is costlier - teaching a domain expert the required tech skills, or teaching a techie the required domain skills? Is age based discrimination an issue here also?

It appears the vast majority of companies would say tech skills. This is understandable to some extent. However, a better question IMO is whether it is considered costlier to train a techie with related domain knowledge a specific language/tool, or an existing language/tool expert the domain.

[Not that I know for sure... but I imagine the tech can learn domain skills far easier than the domain expert could learn tech skills. Techies are by their very nature some of the smartest people around, maybe that's why domain knowledge isn't valued. Maybe knowledge isn't as valuable as the ability to absorb knowledge, which is usually a skill techies have in abundance. That's my two cents anyway.]

On multiple contracts they sent me to "domain school", only to dump many of us contractors at the end of the project and start over with the next batch when there was a need for developers again. Hardly OnceAndOnlyOnce.


I think in general managers do not respect domain knowledge. There is the saying "a good manager can manage anything" implying it doesn't matter what you know about the domain, it will all work out. My response to this is that there are very few good managers, most managers are mediocre at best and some are outright dangerous.


Some people viewed that it is because DevelopersHaveNoDomainKnowledge

Well, when I do gain some, the companies don't seem to care. They send me to costly training, etc., but still do the usual pump-and-dump JIT-developer cycle dance. True, it does not make me a domain expert, but they don't seem to give much value to the bit I do gain. A new person that comes in when they later decide to ramp projects back up is going to have to go through all the same orientation, ask the same questions, make the same domain-newbie mistakes, etc. That cannot be efficient.
It's good to value a programmer's DomainKnowledge if it makes that programmer more productive. More obviously put, it's good to value productive workers, and one would expect that in practice this tends to favor programmers with DomainKnowledge. However, there are bad reasons for valuing DomainKnowledge. It is bad to value DomainKnowledge in the belief that:

These reasons can be treated one by one. (The last one, despite being the most common and powerful in people's minds, is a pretty mundane fallacy when you think about it.) However, rather than contemplating the logic of these reasons, consider the big-picture consequences of trying to use DomainKnowledge in these ways.

The simplest way to sum up this problem is that when a company relies on certain domain guru developers for domain knowledge, the irresistible tendency is for those developers to control design, architecture, and technology strategy. In other words, the developers with the least interest and expertise in software set the software standards for the entire company.

The answer is to adopt the attitude that domain knowledge must be constantly freshened by new research. Letting a fresh set of eyes start from scratch on a problem should be seen as an opportunity for innovation and competitive advantage, not a wasteful squandering of the old guard's experience. Indeed, it should be considered a necessary part of a company's intellectual hygiene. As an asset, DomainKnowledge should be maintained the same way a codebase is maintained. A codebase must be constantly reevaluated and refactored, and occasionally partly rewritten, to stay relevant and usable. Retiring portions of code is often necessary for the health of the codebase, and "losing" domain experts, or at least not clinging too tightly to their experience, may be necessary for the maintenance of a company's DomainKnowledge.

To carry the analogy with software a bit farther, a virgin employee can outperform an employee who has had too much much exposure to a domain, just like a brand-new application - unsophisticated, inefficiently coded, and suffering from high-level language overhead - can outperform an old hand-tuned application that performs data encoding conversions at every interface, spends half its time considering whether to perform functions that haven't been useful in ten years, and has a curious "optimization" developed to accommodate the usage pattern of your second-best customer.
See also: PlugCompatibleInterchangeableEngineers
CategoryEmployment, CategoryBusinessDomain

EditText of this page (last edited February 17, 2009) or FindPage with title or text search