Quite a few times I've hit with what I think is a serious problem in many companies.
Documentation is non-existant or outdated, code is uncommented or the comments are outdated and misleading, the person who wrote that component without any single comment has left the company... This is typical; The knowledge of the project (or maybe of the whole company) is distributed among "chosen" individuals who are either the creators of pieces, or the ones in charge of how those pieces should work.
This is the distributed knowledge. Is as simple to detect as thinking: "Can I do this task by myself just looking at the code and related documentation?" If the answer is no, there you have it ;)
This is a typical way of thinking of non-modern companies, where for example sales people are more valuable for what they possess (contacts) than for their skills.
It is also common in companies ruled with a vertical hierarchy: "You don't care what I do (and don't review anything else than the results), so why should I care properly docummenting my code?".
And finally, it is typical on small companies that evolve and grow to a medium sized one. When is just a start-up with a bunch of dudes coding, "everybody knows the code and can hack it", until you grow and other people inherit that undocummented legacy.
The problem? That if one "node" fails, you lose that piece of knowledge, and (hopefully) somebody has to learn or reverse engineer it.
In the opposite side, Wikis are becoming common to organize code-related documentation, and they represent a shared space in which everyone can add content.
People can be very good at doing a single thing (for example an athlete), but I am of the opinion that learning many things opens your mind and gives you a broader spectrum of ideas.
So switching/rotating positions can be a benefit for everybody: The company adds "knowledge redundancy" (now at least two people know how that obscure component works!), and the engineer learns new things. This is what I call shared knowledge.
It is also good to share the knowledge for your colleages, as the bottleneck of having to ask always you dissapears. You can focus on your tasks and "distribute the load" of questions and issues related with that component with the other people that know about it.
For a real-world scenario, at my job out of 6 people of our team, 5 know at least the basics of how Hadoop works. This allows us to leave the stats scripts tasks available for anyone; Whoever has time and wants, grabs the task and writes the scripts. And we can also easily do peer-reviews of those scripts.
You are not stronger for being the only one that knows something. You are stronger for being part of a team stronger than any individual.