One could (and I guess I am about to) argue that the various communication tools that are central to Extreme Programming -- namely the practices: small team; pair programming; co-location; daily-standups; continuous integration; on-site customer; and iteration planning game -- are aimed at producing a situation where everyone knows everything about the design and features of the system being worked on.
As the number of people on a software team grows, it becomes harder to accomplish this goal, and so there becomes a need for people who are what I term knowledge nodes: these people seek to understand the entirety of the design and features being worked on, so they can communicate relevant bits of that information to others who then have partial (but presumably sufficient) knowledge to do their jobs. Further, it appears common (and a function of both culture and team-size) to break the two areas of knowledge (i.e. design and feature-set) from each other and create specialized nodes for each of them.
The name of role such a person plays on the team varies, but Project Manager, Analyst, Lead Developer, Lead Programmer and Architect are all commonly used. Each of these incline toward the design or the feature (i.e. technical and business) aspects of the information on a project-by-project basis.
What do the people who are good at these roles have in common? In my experience, they are good communicators: they are skilled at gathering, explain ing and sharing knowledge about the design and/or the features of a software system.
The interesting thing (or at the very least: the reason I started writing this today) is that even very small teams need at least one such person. Even on a team with a half-dozen people or so (such as the one I work with now), if the knowledge of the system fails to reach a knowledge node -- it is less likely to get shared with everyone.
Right or Wrong I have always seen myself in this role. I've also (right or wrong) had a tendency to feel like if I didn't know something about the design or features of the system I was working on it wasn't known.
(and so, yes this entire analysis may be nothing more than ego gratification of my self-perceived role on software projects)
So now that I've found yet another way to describe my role on a software project, so what? Well, for those of you who also find yourself in this (or working with someone playing this) role, I have some advice:
That while you may think that things are not known (objective) unless you know them (subjective) remember that's your ego talking (but it still may be true if your team has come to rely on it).
If you are not someone who likes to talk endlessly (I've heard the word 'pontificate' a few times in my career) about design and feature ideas, get your thoughts to someone who does -- they'll make the rounds for you.
On small teams, one or two such people are more than enough (too many, and there will be no work, just talk) -- but you do need at least one to forge a team (otherwise everyone will just work on their bit without knowing about the rest).
Don't confuse knowledge nodes with knowledge creators -- good teams have both, and often the same person isn't good at both.
Particularly (as in my case) people are rarely good at both at the same time. I find that I can share design and feature knowledge, or I can create it, but when I am doing a lot of one, I am doing very little of the other. (team-size, iterations and pairing help with this -- as does some self-discipline on my part to keep it balanced).
Finally, the (presumed) XP goal of everyone knowing everything is in pratice accomplishable by making sure the knowledge node(s) of the team know everything and then get it shared around. If you are playing this role, you have to gather and share. If you are disinclined to do so, you have a responsibility -- at least -- to get what you know to such a person, so they can share what you know about the system with everyone else. This use of knowledge nodes may be (I don't know I just musing here) the key to an effective software team.