Emic and Etic Approaches to Explaining Team Behaviour

The software world borrows heavily from manufacturing when trying to find good ways to build stuff that works, and it borrows from psychology when trying to figure out what makes people tick. That’s well and good, but there are other models out there, most notably provided by sociology and anthropology. In my continuing mission to introduce the software world to more useful concepts from my domain, today I’ll share two ways of describing team behaviors.

One of the things I admire about anthropology is that it is unique among the sciences in the way that its practitioners try to remain paradigm-agnostic. Rather than choose to follow, for example, the structural-functionalists with their assumptions, goals, and methods, and disregard the post-modernist school of thought, an anthropologist will use her knowledge of the multiple ways of interpreting the world and choose the ones that are most suited to the study.

Ethnographers (a branch of anthropology) describe culture, which is the learned behaviors and beliefs of a group of people, and fundamentally there are two ways to describe what you see when looking at a group of people. You can compare what you see to what you know about how other groups of people behave. For example, “This team holds daily standups during timeboxed iterations as defined by the Scrum guide and practiced by other Scrum teams around the world.” Anthropologists call this an etic approach. You can also describe a group’s behavior from the point of view of the group. “The team has found that they can achieve their best productivity to date by using four pairs of programmers rotating members daily with two pairs of testers.” This is an emic description (sometimes referred to as an “insider’s” approach). It describes the team’s behavior as they would describe it themselves, without reference to external norms or standards.

The mnemonic I used when I first learned about emic and etic descriptions is that the M in emic refers to Me, and how I’d describe myself and the T in etic refers to Them, and how I’d describe others. Therefore an emic description is how someone describes themselves, and etic description might be how that person would describe others.

I recently read a striking contrast between the two approaches in an ethnography on a community in Central America which practices infanticide. The ethnologist points out that infanticide is a practice that allows impoverished families to maintain a minimal living standard without the burden of children who for one reason or another are unlikely to contribute to the family’s economic well-being. That is an etic description. Mothers in this group describe such children as being “born without a will to live” and therefore they might feed them last, or not at all, or deny them medical care that the family can’t afford. That is an emic description that serves to remind us that what one calls murder is rarely considered murder by the people involved. Being proficient at using both emic and etic approaches is often the key to achieving the understanding required to encourage change in a group’s or team’s behaviors.

Let’s look at an example closer to home for us software folks. You’re an agile coach, arriving in a new environment with a mission from management to “make this team more agile.” If you, like so many consultants in most every field, favor an etic approach, you will begin by doing a gap analysis between the behaviors and artifacts that you see and those with which you are most familiar. That’s useful, and practically inevitable. The next natural step, however, may be less helpful. That is to judge the gaps between what this team is doing and what you consider to be normal as wrong, or indicative of some organizational pathology. This might be a good moment to recall that agile development prescribes no practices at all. It’s about principles. Principles can manifest themselves as practices, but one cannot reverse engineer principles from practices at a glance. Figuring out what motivates a team to act as they do requires a deep understanding of the people and their environment (I feel a blog post on “participant observation” coming on). Here’s where an understanding of emic versus etic descriptions comes in handy. By deciding, as a consultant or coach, to now attempt to prepare an emic description of the team’s behaviors, you force yourself to set aside your preconceptions and engage in meaningful conversations with the team in order to understand how they see themselves. Now you have two tools in your kit, where you might before have had one, and more tools prepares you for more situations.

Neither approach is right or wrong. Both are valuable in different circumstances. Always favoring one or the other will cripple a coach trying to help a team, because the one will constrain him to the limits of the team’s experiences and the other is inclined toward dogma over results. You’ve probably seen both scenarios. Understanding that there are two valid and complementary ways of describing team behavior is a useful step toward avoiding the fallacies of favoring one over the other.

For another model that can be used to describe team culture, also borrowed from anthropology, see my blog post about QAME.

Visit the Wikipedia entry for more information.