By Shannon Mattern. Princeton University Press; 200 pages; $19.95
In 2016, Y Combinator announced it would build cities from scratch and asked Twitter what a city should "optimize for." The internet suggested fish tacos. This is roughly the level of discourse that Shannon Mattern, an anthropologist and professor at UPenn, pushed back against in 2021 with A City Is Not a Computer. The book started as a series of essays for Places Journal, and it reads that way—each chapter works on its own, the writing is more exploratory than prescriptive, and the footnotes are generous.
I like this book.
Its target is this technofuturist metaphor used by planners to treat cities as computers (sensors on, data in, optimal decisions out) that imports a whole set of assumptions about what counts as knowledge. It's a pattern we see at work, too: "If you can't measure it, it doesn't exist. If you can measure it, you understand it." Citizens become users, objects, or worse: rows in a database. Mattern traces this thinking through municipal "control rooms" covered in real-time dashboards, through Alphabet's failed Sidewalk Toronto project, through the digital twins that promise to simulate entire cities in code. In each case, she finds the same mistake: confusing the map for the territory.[1]
My favorite chapter is the one about libraries. Where dashboards watch, libraries serve; where digital twins model behavior from above, libraries grow knowledge from below. Libraries offer Wi-Fi, sure, but also librarians who can interpret a vague question, community rooms where strangers meet, and collections that no algorithm would assemble because they don't rely on advertising revenue, because libraries are built around care even at the cost of efficiency.
Her alternative is a gardening metaphor for systems that layer and grow together imperfectly over time. It's deliberately messier than the metaphor it replaces, setting up a conclusion that points toward maintenance and repair as values worth designing for. Care, maintenance, repair. I like those, and I'll be adding them to my personal library of design strategies worth using.
Why this book stays with me
I kept finding "our work" in these pages, even though Mattern is writing about cities and we spend our days thinking about organizations.
Dashboards
I've seen plenty of leadership teams stare at metrics that tell them everything except what's actually going on. The numbers are clean; the reality is messy. I don't think any of us, Mattern included, are trying to argue that measurement is bad, but rather that measurement choices are political, and they shape what we're able to notice.
Local knowledge
Mattern shows how smart-city projects repeatedly steamroll the people who actually live somewhere, treating residents as subjects rather than sources. The same thing happens when anyone parachutes into organizations with frameworks that ignore what people on the ground already know.
Care infrastructure
What might "infrastructure for care" look like inside a company? Probably actual spaces—physical and social—where people can learn, ask dumb questions, and help each other without being optimized. Office hours with no agenda. Slack channels where "I don't know" is a normal answer. Onboarding that's human-led. Documentation maintained as a commons. The library works because it's being looked after by someone who gives a shit about quality even at the cost of optimization.
Layered histories
Organizations, like cities, are layered. They carry old systems, workarounds, informal networks, and institutional memory that org charts struggle to capture, partly because they're hard to visualize in 16:9. I spent a long time discussing this yesterday with John Cutler: that venues John's played over the span of years, even under new ownership, carry on some sort of institutional or architectural memory. My feeling is that organizations are the same; even though the people are always changing, they remember their past, and this memory changes how they operate. Designing with that complexity, rather than pretending you can start from scratch, feels right.
This book is a reminder that we should not treat human systems as engineering problems, and that we shouldn't ignore our senses, our bodies, or our communities when we design. Whether you're redesigning a city or a team, the same questions apply: What are we choosing to measure? Whose knowledge counts? Who gets to decide what "better" means? These are political questions, and dashboards can't answer them for you.
The lineage of the control room is so fascinating. Stafford Beer, the British cybernetician, essentially invented the organizational dashboard in Chile between 1971 and 1973 with Project Cybersyn. Salvador Allende had just become the first Marxist elected democratically in Latin America, and his government was nationalizing industries at speed. They needed a way to coordinate a socialist economy without Soviet-style central planning, and Beer's answer was cybernetic: real-time data from factories across the country, transmitted via telex, displayed in a futuristic operations room with screens on every wall. Workers would send signals up; the center would maintain visibility without micromanaging. The system was never finished. On September 11, 1973, Pinochet's US-backed, Kissinger-designed coup ended the experiment—Allende died in the presidential palace, the ops room was destroyed, and Chile became a laboratory for the opposite ideology: Friedman, the Chicago Boys, free-market shock therapy. So whenever you stare at Tableau, I want you to remember that the prototype was designed for democratic socialist coordination, and tragically destroyed by tanks. (For the full history, see Eden Medina's Cybernetic Revolutionaries.) ↩︎