A chicken and a pig are together when the chicken says, "Let's start a restaurant!"
The pig thinks it over and says, "What would we call this restaurant?"
The chicken says, "Ham n' Eggs!"
The pig says, "No, thanks. I'd be committed, but you'd only be involved"
Book Agile Software Development with Scrum, page 42. 2001, Ken Schwaber and Mike Beedle
This is an strange fable. Not really easy to grasp or identify ourselves with it (I guess all fables suffer the same).
But it illustrates a recurring situation in software development (field where it was coined): not everybody in the team is subject to the same forces and not all those forces result in the same workload (more on this later).
In any technology-related scenario, the pig would be the one that truly knows how the thing works. The one to call if something fails when other (maybe operational) procedures have failed to cope with the issue. This person is committed: he cannot forget any detail because failing to do so might result in catastrophe or non-reversible consequences. For instance: if a computer stops working because its disks get fully occupied, this pig will be the one knowing which files are safe to delete and which not. Here this person is not following a well-defined procedure. Instead he is following the knowledge he obtained by being commmitted to the product or service at stake.
Chikens are everybody else.
They may suggest solutions (e.g. "delete this file" or "change this line") but they all count on the surveillance of the pig. They can be involved, choose between different choices that the pig may put forward, even be the nominal responsible for the technology. But they cannot make things really work; not without the capabilities of the pig.
Note that a chicken that starts pulling out things over a particular piece of technology, sudently becomes a pig. And with that comes all the pressure of being the last line of defense against misdoings.
The cognitive load due to details that make a technology or a project work is not directly related to the complexity of that technology, but to the evolution of that particular application of the technology.
For instance, a naming schema might include rules or placeholders for things that are no longer into use, but existed in some moment of the project. Even if now just one type of things are used, the existing naming schema is still as complex as when it accounted for more than one thing. Many times the project does not goes through a cleanup or simplification process (perhaps because those other things did not truly dissapear, but were left there simply because they could not be deleted).
The amount of memory required to account for all the details expected from a pig is huge; or huge in comparison to the knowledge from a chicken whose statements count on being filtered by the pig.
Hence, for a given set of technologies or projects, a person can only be a pig in an smaller number of projects than if he choose to be a chicken. Because being a chicken requires much less effort and always counts on the safe net of a pig.
That the devil is in the details comes back here. That extra mile to make understand a project and being able to make it work in hours and not weeks is the difference between pigs and chickens.
Many projects cannot afford to run out of pigs. Which may? Those where it happens that a) the technology knowledge is in the public domain and b) the history of the project has not affected the actual implementation.