Epistemology Ate My Project

If You Don't Agree on How to Know,
You'll Never Align on What You Know

...epistemology is always and inevitably personal. The point of the probe is always in the heart of the explorer: What is my answer to the question of the nature of knowing?

Gregory Batesman

Truth, Beauty, et. al.

I didn't use to think about epistemology.

Of all the things that go into team alignment: roles, communication, availability, accountability, processes, etc. etc., the last thing I would have expected to come back to haunt me was theory of knowledge. When considering philosophical differences, teams might think about, "When you ask someone a question in chat, do you say 'hi!' first?" or "Do we have to turn on our cameras in video meetings?" not "What are the conditions required for a belief to constitute knowledge?"

And yet.

Unexamined assumptions are the bane of many a team. What is more fundamental to knowledge work, than knowledge? In my more pretentious moments, I've referred to design and development as "reified opinion" because the act of design, the act of development, can both be thought of as transforming our point of view into real, concrete things in the world. When this is a team effort, what happens when there are fundamental differences in how to reach, in epistemological terms, a justified opinion?

But What's That Got to Do With Me?

Consider these statements:

User research is necessary for a successful product.
The design team should A/B test the color palette.
Prototypes are a waste of time.
A usability test with five users is enough.
Only quantitative research can be relied upon.
Time estimates should be accurate within a 3% margin of error.
Personas are the best tool to represent our users.
We can't anticipate or mitigate all of our risks.
Users can tell us what they want.
That meeting could have been an email.
It works on my machine.

I don't, or expect anyone else to, agree with all of the above, though I have encountered all of them more than once. Every one of these is based on an epistemological position.

Is it possible to estimate who long work will take? Can designers rely on experience and instinct to pick the right shade of blue? If you only talk to five users does that even count? Answering questions like these means taking a position on how knowledge is acquired and whether it's even possible under the circumstances. Misalignment on any of them could lead to serious problems as your project progresses. Turns out, epistemology, like ethics, isn't an abstract philosophical subject, but something that we're immersed in day-to-day. Everyone on your team and everyone you report to has an epistemology, whether it is articulated or not.

What happens when there are conflicting epistemologies? In one past project of mine, an otherwise well-aligned, well-organized team ran into serious breakdowns because of fundamental differences in whether the team could make decisions without statistically significant quantitative research, when design could begin, tolerance for uncertainty and risk, and whether design itself could be research. It wasn't until the team looked deep and realized there were differences in knowing what is true that the team was able to work things out and realign.

Closing the Gap

Misalignments, especially subtle ones, can cause a lot of harm within your team. Misalignment of this type can be even more difficult to correct, because the differences can remain hidden until things blow up. Conflicts of this kind will show up most sharply in decision-making and information-gathering, so look closely at how your team approaches these activities. If you are seeing pushback against certain types of research or user testing, or if decisions treated as final by one group and provisional by another, it could be a sign of epistemological differences. If the team expresses frustration that they don't know enough, it can mean they are not getting information aligned with their epistemology. Start with your own positions, and articulate them to your team. Being open about your epistemological positions is a good way to surface opposing views that would otherwise remain hidden.

Known Knowns, Known Unknowns, Unknown Unknowns

Every project involves a balance of knowns and unknowns. How your team learns and whether those lessons constitute knowledge, informed guesswork, or wild fancy are fundamental questions that need to be answered. If there is not agreement on these, it puts strain on the team that might not be seen until things start to fall apart.

Don't let epistemology eat your project!