Discover more from Res Extensa
Monthly Reading, January 2023
Res Extensa #29 :: Thinking like a factory, merging design & complexity science, shipping work, and the definition of company culture
I wrote a while back about Factorio, a PC simulation game, sort of in the same vein as SimCity, where you build and automate massive factories from start to finish. You mine and harvest raw materials, power various machinery to build other parts, use those parts to further automate the factory. Along the way you learn to see how one resource works as an input to creating another. One output becomes an input and you stitch together an ever-more-automated system. With time, you begin to notice where bottlenecks crop up in the system and how to work around them.makes some interesting observations on Factorio's parallels to building products and running companies. As your factory in the game gets more tangled and complicated, it's critical to revisit elements and refactor them.
This metagame ends up giving players the habit of looking at every situation by asking: what's the best way to automate this, and what dependencies of other automations are threatened if I do? This is, for developers and for the many, many people whose jobs will involve more software development over time, a very good habit indeed. I tried to crank through some emails right after playing Factorio one time, and realized—I urgently need to write some email snippets. This just can't be allowed to exist in an un-automated state! But if I'm going to use a lot of email snippets, I need a consistent way to manage them lest I end up with five different iterations on "Yes, let's talk about that; here's my Calendly."
Factorio teaches a way of thinking about processes as systems, where refinement, refactoring, and automation can be worth it based on trade-offs.
I've been gradually making my way through Christopher Alexander's A Pattern Language. It’s a dense but fascinatingly-structured book describing through an interconnected collection of “patterns” (by which he means rules of thumb for, in his case, architects and designers) to follow for optimally designed spaces.looks at the value of Alexander’s work in bringing design functional design principles into the world of complex systems:
Though Alexander’s work predates the formal term “complexity science,” both describe the same fundamental patterns of complex systems. Both focus on interactions within systems where the whole is greater than the sum of its parts.
He also explores why the disciplines of design and complexity science have developed independently over the years:
I don't know exactly why designers have turned away from complex systems, but one possibility is that complexity challenges a central doctrine of design—namely, that it is the designer’s job to identify desirable outcomes and exert as much control over the process as possible towards those ends.
Operating in complex environments, designers have to design for emergent behavior, versus designing to dictate specific behavior.
My long-time friend and colleaguerecently started a Substack, and he’s already out of the gate strong. The tension between thinking, planning, and shipping work is something we talk about all the time, and this post is a great reminder that ruminating and worrying about details block you from putting things out in the world. And putting things out there is where all the learning happens.
The key here, as with most things, is striking a balance between giving something zero thought before doing it vs. thinking so much about all the possible outcomes that you don't even start the work. The goal is to ship. And to ship, you have to put something on the paper.
All the improvement happens in between shipping events.
Thanks for reading Res Extensa. Subscribe for free to receive new posts and support my work.
Another great post from Morgan Housel, chock full of gems. A couple of choice selections:
Multi-discipline learning: There’s as much to learn about your field from other fields than there is within your field. Most professions, even ones that look wildly different, live under the umbrella of “Understanding how people respond to incentives, how to convincingly solve their problems, and how to work with others who are difficult to communicate with and/or disagree with you.” Once you see the roots shared by most fields you realize there’s a sink of information you’ve been ignoring that can help you make better sense of your own profession.
When I hit a rut with anything I’m working on, one of the fastest fixes is to get out of my environment and dive into another area entirely. Go sit with a customer to see how they do their work. Spend time with a craftsman to learn how a project comes together. Learning about other fields activates untrodden neural pathways.
Your personal experiences make up maybe 0.00000001% of what’s happened in the world but maybe 80% of how you think the world works.
This is obvious on paper, but difficult to remember in the moment. Every single person comes off the shelf with this bias, and only some are good at getting outside their own tendencies (though not immune).
Companies talk about “changing their culture” as if it’s a project you can kickoff, a slide deck you can make, a line in the sand you can set where you can say in 3 months “We Now Have A New Culture.” But your culture is merely the set of attributes and behaviors that your organization exhibits at any one time. It’s a descriptor for the things that you do, and the type of company you are right now. It’s not a thing you change by telling people a “New Strategy”.
The way I always describe it is that your company culture is merely the sum of the decisions you make and the things you choose to work on and care about. If you want your culture to be different, start making the types of decisions that the kind of company you want to look like would make. Jason Fried has a succinct way of saying this same thing:
You don't have to let something slide for long before it becomes the new normal. Culture is what culture does. Culture isn't what you intend it to be. It's not what you hope or aspire for it to be. It's what you do. So do better.
HyperCard was truly the first GUI-driven application for building other applications. A proto-entry in what we’d now call “low-code” platforms. Creator Bill Atkinson described it as an “erector set for building software”. Lowering barriers to create and solving the enormously long tail of specific user problems are two driving factors of my work, too. It’s amazing how early Atkinson was onto something:
Atkinson once described HyperCard as “an attempt to bridge the gap between the priesthood of programmers and the Macintosh mouse clickers”. But even more than that, HyperCard didn’t compromise between the easily usable and the creatively powerful. All of that was to be found within its computational power for creativity. To use a phrase from the computer scientist Seymour Papert, HyperCard embodied the concept of low floors and high ceilings: technologies that are easy to begin working with but still have lots of open-ended potential. It provided space for both the beginner and the expert.
… And One Tweet
As companies get large, one of the first things to atrophy is true respect, understanding, and detail-orientation toward customers. Demand-side thinking. It’s tempting to wander away farther into the world of abstractions and cohorts and “segments” of your customers. But each one has their own story, their own unique set of circumstances worth hearing about to stay connected to the reality of what problems you solve (or at least set out to solve) for them.