When I tell people I have an anthropology degree, the response is usually a small wince followed by some version of "huh, that's interesting, how'd you end up in tech." Polite. Slightly puzzled. Sometimes condescending if the person is younger than me.
I used to be defensive about it. Now I think it was the most directly useful thing I did in college.
The branch I studied was cultural anthropology, one of the four classical branches of the discipline. The other three are biological, archaeological, and linguistic anthropology; they're great fields, but they don't bridge into a software career nearly as cleanly. Cultural anthropology is the branch focused on living people, social systems, and how groups actually make meaning out of the things around them. It's the branch that gave rise to applied anthropology: the formal discipline of taking ethnographic methods out of academia and into business, design, and technology.
That bridge isn't theoretical. UX research at most of the major tech companies has anthropologists in its lineage. Intel famously built a research org in the 2000s around cultural anthropologists like Genevieve Bell; Microsoft and Xerox PARC ran similar programs. The methods those teams imported (participant observation, contextual inquiry, interpretive interviewing) are still central to modern product research. The branch I happened to pick is the one with the most well-trodden path into tech, and I didn't know that when I declared the major. I figured it out in the field, literally.
The handoff from anthropology to web development happened at the Smithsonian Folkways digital archive, an internship at the Smithsonian Institution's Center for Folklife and Cultural Heritage in Washington, D.C., the summer before I knew I wanted to be an engineer. I came in with a BA and no career direction. I left with a personal website, working knowledge of WordPress, and the understanding that the part of the job I cared about (watching how real people interact with the thing in front of them) translated cleanly out of a cultural archive and into shipping software. That internship is the straightest line in my professional history.
Here's the unflattering truth about both fields: nobody learns to be a senior engineer in school anyway. The CS majors I work with had to learn the actual job after they got hired, same as me. What school gives you is a set of habits of thought that you'll apply to whatever you do next.
The habits cultural anthropology gave me, and the ones that have shown up the most in engineering:
- Take fieldwork seriously. When you walk into a new system (a codebase, a team, an enterprise client's organization) you are doing fieldwork. The thing that is true is what people actually do, not what they claim they do, and not what the documentation says. Senior engineers who skip this step get expensive surprises. Anthropologists are trained to default to fieldwork.
- Watch for ritual that nobody can explain. Every team has rituals. Some of them have reasons that still hold. Some of them are residue from a constraint that disappeared three years ago. The trick isn't to throw all of them out; the trick is to ask gently and see which ones get a real answer. The ones that don't are usually safe to retire. (FedNow had a fourteen-day review step that turned out to be fossilized residue from an audit requirement that had been resolved years earlier. Killing it saved us a third of the schedule.)
- Resist your own model. Engineers are trained to abstract. We see a problem and immediately reach for a pattern we already understand. Anthropologists are trained, painfully, to do the opposite: to hold off on naming what you're seeing until the data has had a chance to surprise you. About half the production bugs I've shipped were because I assumed I knew the shape of the problem before checking.
- Note the gap between what's said and what's done. This one is gold for working with stakeholders. People will tell you what they want. They will then behave in ways that contradict what they told you. The contradiction is the actual signal. If you can see it without judgment, you're already in the top quartile of cross-functional collaborators.
- Build for the actual user, not the PRD. The PRD and the acceptance criteria describe the artifact a team agreed to build. They don't describe how a person will actually try to use it: which keystrokes they'll get wrong, which step they'll skip, which empty state they'll stare at for thirty seconds and then close the tab on. If you only ship to the spec, you're shipping to a fictional user. The fine texture of how the real one moves through the product is where the difference between a passable feature and a genuinely good one lives, and that texture is exactly what cultural anthropology trains you to see.
I'm not saying every engineer needs an anthropology degree. What I will say is that holding the analytical, systems-shaped half of engineering and the observational, interpretive half from those anthropology classes in the same head (left-brain and right-brain wired into the same role) is what I think makes my work feel distinct. I tend to notice things on the human side of a project that a purely technical lens doesn't reach for: the small misuses, the workflow seams, the user behavior that quietly contradicts the spec. I bring those notices back into the code. That combination, more than anything else on my résumé, is the part that actually shows up in the quality of what I ship.
Engineering schools could stand to teach more of this. They mostly don't, because nobody's writing LeetCode problems for is this stakeholder telling you the real constraint. The good engineers learn it on the job and the great ones bring it in from somewhere else.
I happened to bring it in from anthropology. Other people bring it from theater, from the military, from years as a parent. The substance is the same. It's the part of the job that isn't code.