Actor Network Theory For Dummies

So You Want to Use Actor Network Theory Without Getting Lost

Actor Network Theory is a method for mapping how things stay connected or fall apart. It was built by Michel Callon, Bruno Latour, and John Law in the 1980s. The short version: everything is a network. A bridge, a bacteria, a policy document, a database—all of them act as nodes that pull other things into their orbit. The trick is not deciding which nodes are the important ones before you start. That's the part most people miss when they first try this. I picked up ANT around 2014 while studying how a hospital's digital record system changed the way nurses actually did their rounds. I thought I could just map the human actors and call it a day. The network had other plans. The barcode scanner on the IV cart quietly redirected attention away from patient names toward dosage confirmation. That small device became more influential than the head nurse in determining who talked to whom and when. I ended up spending three weeks just tracking why that scanner kept being repositioned or ignored by different staff members.

Actor Network Theory For Dummies: Where to Start

You don't need permission to use ANT. You just need to accept that you are starting from zero. No hierarchy. No predetermined key players. Start with the phenomenon you want to explain—something that seems stable, like a policy that "just works" or a technology that "failed." Then trace what holds it together. Here's a practical sequence that actually works in the field: Step one: Define your boundary loosely. Pick a case: a software rollout, a conservation project, a supply chain disruption. Do not fix the scope yet. Let the field pull the boundary closer or further away.

Step two: Identify all the entities involved. Humans count. Non-humans count equally at this stage. A server, a memo, a budget line, a piece of equipment—write them all down. I usually capture them in a raw list before drawing any arrows. Getting the list right prevents the classic error of retroactively fitting actors into a theory that already has a plot. Step three: Map the associations. Draw lines between every pair of actors that interact, influence, or depend on each other. Label each line with what kind of relationship it is. Translation is the keyword here. Callon's term for how one actor gets another to do something by redefining the situation. An engineer translates a regulatory requirement into a code module. A manager translates that code module into a workflow. Each translation changes who is bound to what. Step four: Look for obligatory passage points. This is where networks either lock in or collapse. An OPP is a chokepoint that every actor must pass through to achieve their goal. In my hospital study, the OPP was the barcode verification step. If the system rejected a scan, everything downstream—medication administration, charting, billing—broke. Once I identified that chokepoint, the rest of the map sorted itself into predictable layers around it.

Step five: Track stability over time. Networks are never finished. They are either stabilizing or unraveling. Write down moments when the network held and moments when it didn't. The pattern tells you more than any static map ever will. The whole process takes longer than a quick literature review because you are doing fieldwork, not just reading. In practice, a reasonable ANT exercise for a medium-sized case runs about six to eight weeks of active tracing. If you're doing something smaller, maybe three to four weeks. If you think you can knock it out in a weekend, you're probably skipping the parts that matter. One thing that trips people up: symmetry is not neutrality. ANT treats humans and non-humans as having equal analytical status, but that does not mean they have equal power in the network. A PDF can enforce a schedule the way a manager does. It just lacks a face. People often conflate symmetry with sameness and then get confused when the math does not work out.

Another counter-intuitive point: networks are not objects, they are processes. You are not mapping a network. You are mapping network-making. This distinction saves you from drawing pretty diagrams that mean nothing. If your diagram cannot show how it was made or how it might change tomorrow, it is not an ANT map. It is just a flowchart wearing a costume. I ran into a particularly ugly edge case once with a city infrastructure project where multiple contractors each insisted their vendor was the true actor holding the project together. The ground truth was that no single vendor could be isolated. The concrete, the scheduling software, the inspection permits, and the union agreements were all mutually constitutive. Trying to assign blame to one node was impossible because the network had no center. The workaround was to stop looking for a primary actor and instead map the translation chains between the competing claims. I documented how each party's definition of the problem shifted when confronted with the others' evidence. That shifted the analysis from "who is to blame" to "how did this configuration persist long enough to matter." It was slower but it actually explained the outcome instead of just describing it. If you want to practice, the data you need is usually already in front of you. Meeting notes, email threads, system logs, procurement records, incident reports. The trick is reading them as traces of association rather than as background noise. A change request email is not just a request. It is a translation event. Who redefined what, for whom, and through which material or symbolic medium? Answering that question for a series of events builds your map faster than any software tool will.

There are software options that help. I have used Gephi for visualization and NodeCanvas for iterative mapping. Neither replaces the work. They speed up the drawing phase after you have already done the hard part of finding the associations. Using a tool before you have a decent list of actors and relationships just gives you a prettier wrong answer faster. That is a common failure mode. Do not skip the manual phase. The main limitation of ANT is that it does not give you predictive power. It explains persistence and change after the fact. If you need to forecast what will happen next, you will need to combine it with something else—maybe institutional analysis, maybe complex systems modeling, maybe plain old statistical regression. ANT is descriptive and interpretive. It is excellent at showing you how things hold together and why they fall apart. It is not a crystal ball. Another limitation: the method can absorb an unreasonable amount of time if you let it. I have seen projects expand into three-year rabbit holes because the mapper refused to close the boundary. Setting a closure rule early helps. My rule of thumb is to stop adding actors when you reach diminishing returns—when new entities no longer change the pattern of associations you have already mapped. That usually happens between twelve and thirty actors for a typical organizational case. Beyond that, you are just collecting trivia unless the case is deliberately vast, like a national policy rollout across multiple jurisdictions.

If you want a lighter entry point, start with a single controversy. A product failure, a policy dispute, a technical migration. One case is enough to learn the method. Multiple cases come later. Jumping into a full comparative design before you understand translation and obligatory passage points is how people produce vague network descriptions that sound smart but say nothing. For further reading, Callon's 1986 scallop study remains the clearest early example of translation in action. Latour's Pasteurization of France shows how a scientific claim becomes a networked fact. Law's work on aircraft and organizational routines demonstrates the method on engineered systems. Those three will take you past the beginner stage without drowning you in jargon. The practical takeaway is simple enough to state without drama: ANT asks you to follow the actors themselves and let them define the network. Your job is to trace, label, and close. Do not impose a hierarchy. Do not assume stability. Document the translations. When you do that, the theory stops being a buzzword and starts being a working method.