Two wrongs do not make a right
In the software development business there's some well known currencies, these currencies are used to value an employee and the employee (dev, architect, QA or manager) struggle to achieve them as they make their employment more stable or more profitable, this fact goes probably for all work environments. Some more common is productivity (whatever way it's measured), proactivity, efficiency, leading, domain knowledge. Whatever the company values the employee will try to make himself/herself good at it.
Companies, whatever they value, have to pay attention to these values, misunderstanding what they mean and evaluating it wrong will lead to employees behaving as they're measured, which it turns out not to be the value glued in a beautiful frame on the wall.
One in particular that I want to focus is "domain knowledge". I've seem much misunderstanding of this skill inside big companies. Let's say that you work on a big company that develops software. Some old time folks would be considered valuable because the have a lot of "domain knowledge", which usually translates in knowing the technology stack and how it works and its implementations, that's supposed to be good, right?
An employee with this kind of knowledge is essential to help new comers to understand what is happening and how to deal with the application, how to improve it without breaking it and how to modify it. This is a good thing and companies are right to be worried about retaining such employees.
Gaming the system is easy though. This is where I find hard to deal with in legacy systems. Much of the systems that I saw are not so complex in essence but they are a bad coded software. Domain Knowledge experts know the way around it because they wrote the thing in first place but often do not know the business concerns behind it. It turns out that this "domain knowledge" is just a background of the past bad code written.
In such situations two wrongs do not make a right, bad code is bad code, knowing how was written doesn't make an expert it is just half of the knowledge needed, it is still missing the knowledge of the problems the software was trying to solve. I expect from an expert to know the problem and the current solution and be able to discuss new solutions for the same problems as well find out other problems. Companies have to be aware of that otherwise employees regarded as experts might be only gaming the system and holding the company back on innovative solutions.