Hi! I’m Andy Matuschak. You’ve stumbled upon my working notes. They’re kind of strange, so some context might help.
These notes are mostly written for myself: they’re roughly my thinking environment (Evergreen notes; My morning writing practice). But I’m sharing them publicly as an experiment (Work with the garage door up). If a note seems confusing or under-explained, it’s probably because I didn’t write it for you! Sorry—that’s sort of an essential tension of this experiment (Write notes for yourself by default, disregarding audience).
For now, there’s no index or navigational aids: you’ll need to follow a link to some starting point. You might be interested in §What’s top of mind.
👋 Andy (email, Twitter, main personal site)
PS: My work is made possible by a crowd-funded research grant from my Patreon community. You can become a member to support future work, and to read patron-only updates and previews of upcoming projects.
PS: Many people ask, so I’ll just note here: no, I haven’t made this system available for others to use. It’s still an early research environment, and Premature scaling can stunt system iteration.
Particularly in Silicon Valley, when one has a prototype or an inkling that works well, the temptation is to scale it out. Make it work for more people and more use cases, turn it into a platform, make the graphs go up and to the right, etc. This is obviously a powerful playbook, but it should be deployed with careful timing because it tends to freeze the conceptual architecture of the system.
General infrastructure simply takes time to build. You have to carefully design interfaces, write documentation and tests, and make sure that your systems will handle load. All of that is rival with experimentation, and not just because it takes time to build: it also makes the system much more rigid.
Once you have lots of users with lots of use cases, it’s more difficult to change anything or to pursue radical experiments. You’ve got to make sure you don’t break things for people or else carefully communicate and manage change.
Those same varied users simply consume a great deal of time day-to-day: a fault which occurs for 1% of people will present no real problem in a small prototype, but it’ll be high-priority when you have 100k users.
Once this playbook becomes the primary goal, your incentives change: your goal will naturally become making the graphs go up, rather than answering fundamental questions about your system (contra Focus on power over scale for transformative system design).
One huge advantage to scaling up is that you’ll get far more feedback for your Insight through making process. It’s true that Effective system design requires insights drawn from serious contexts of use, but it’s possible to create small-scale serious contexts of use which will allow you to answer many core questions about your system. Indeed: technologists often instinctively scale their systems to increase the chances that they’ll get powerful feedback from serious users, but that’s quite a stochastic approach. You can accomplish that goal by carefully structuring your prototyping process. This may be better in the end because Insight through making prefers bricolage to big design up front
Eventually, of course, you’ll need to generalize the system to answer certain questions, but at least in terms of research outcomes, it’s best to make scaling follow the need expressed by those questions. In that sense, it’s an instrumental end, not an ultimate end.
There’s an analogue to Gall’s law in system design: if you want a transformatively powerful system (e.g. Tools for thought) that applies in many contexts for many people, you probably need to evolve it from a system which had truly transformative power in some narrow context.
A system which seems only modestly powerful—no matter how broadly applicable—probably can’t be evolved in-place into something transformative. The primitive abstraction will need to change. It’ll be easier to figure out how to do that with a highly focused context of use (Effective system design requires insights drawn from serious contexts of use), and much harder if you’ve prematurely scaled (Premature scaling can stunt system iteration).
Pervasive norms in the tech industry seem to oppose this principle (Tech industry culture rarely produces transformative tools for thought). If you’ve got something that shows promise in some narrow context, the strong cultural impulse is to scale that to as many people/contexts as possible. The opposing impulse would be: no, linger in that space; keep pushing on the primitives; make the system as utterly transformative as possible for some small group of people. Once it’s life-changing, figure out how it might apply to more people or contexts.
Initially inspired by some pointed nudges from Michael Nielsen, 2022-11-16.