Systems Decay When Shared

We're terrible at adopting the systems of others. A "defined" system should always be approached with skepticism and curiosity — and systems of the self most of all. Some of these might be in your life: Productivity has everything from GTD to Pomodoro; Knowledge has Zettlekasten to Cornell; Decision making has everything from negotiating frames (eg. ZOPA and BATNA) to niche domain-specific algorithms (like the Konmari method).

To frame up my belief here: systems are always interventions and contingent — nested within some broader experience. This means that barring what we can observe of the physical world, we're always shipping a derivative product when we talk about systems design.

Let's give a specific example. The control system a pilot uses to control a helicopter is a legible human interface for a human being to influence and control a complex mechanical system. The helicopter uses pressure and rotational control (and a bunch of other things) to generate lift and move around with the fluid properties of air. A pilot primarily uses a system of pedals, stick, and collective to control how the power exerted by the helicopter acts within that environment. The helicopter exists within a Newtonian system which defines its constraints, and the helicopter as a system is defined by the individual mechanical systems (thrust, weight, aerodynamic potential). The control system exists relative to those constraints, and is shaped by the physical characteristics and ergonomics of the human body.

The nice bit is that this nested set of dependencies also makes for some great characteristics we can exploit. The fluid properties of air allow for lift to be generated; the ability to independently control rotation (anti-rotation) from lift (rotor); and the design of the control system translates our physical qualities — and our capacity for kinetic learning — into something that can control a spinning top swimming through the sky. (I'm terrified of helicopters fwiw)

Derivative Bias

Intervening systems are a great thing because it makes things tangible. The problem is always understanding the system we're intervening in, and whether we're intervening in the way we intended. Going back to the previous helicopter example, a test pilot is someone who's highly skilled at interfacing with the systems in question — and understanding IMMEDIATELY if the system they find themselves strapped into is misaligned with its dependencies. Those that don't tend to find themselves as ex-pilots pretty quickly.

The problem with taking on an external system of self is that it's rarely... right. Take the modern Zettelkasten system. High level, it's a knowledge pipeline that filters reading notes and observations through a three step process of summary and synthesis into a kind of informational "node." The idea is that these nodes of knowledge accumulate and connect over time, so that when it comes to write or use that knowledge, you have a pre-made and searchable body of work to draw from. It's a great idea. Except, I invite you on a journey of folks' failed attempts at adopting a zettelkasten system by just googling "about my digital garden".

Unlike the test pilot, few of us are particularly adept at recognizing when we're engaged in a system that doesn't fit our needs. Zettelkasten works brilliantly for academics and writers who have a project in mind — and slows down the process of consumption and synthesis for the rest of us. Instead of facilitating recall, it distracts and undermines discovery. The Konmari system is a lovely approach to decluttering that's literally just a systematic cluster-and-sort of your domestic life, with an emotionally arduous step of engaging with each item in turn. It works fantastically for some, but catalyzes conflict and depression in other settings — where family is involved, where anxiety exists, etc.

Each of these systems emerges from the web of dependencies surrounding their originating systems and structures. Today's Zettelkasten has its roots in Enlightenment era interest in epistemology, just as the GTD framework emerged from the early internet and found its greatest adoption in the highly-tracked software dev world. These "systems" usually EMERGE first within a team or for an individual, and then become observed, described, packaged, and published to the rest of us. 37Signals is a good company to pay attention to when it comes to their domain-specific self-awareness around packaged productivity and process — whether its writing or products like basecamp.

The issue is that we often don't have the same dependency when we unwrap this newly packaged system. What needs to be acknowledged with this process of "adopting a system" is that we're not actually adopting that system. Something else is going on.

Compression Artifacts

Mostly, I think what's happening on the "failure to adopt" side isn't on the adoptee — it's shitty compression. I have a distinct memory as a kid seeing bootlegged Evangelion a friend had downloaded from IRC. 24mb and in a realMedia format, these little .rm files did a lot to bootstrap my high school nerd-ery and introduced me to a whole world of ideas. They also were barely legible, chunky, and had many scenes that disappeared into a cloud of 56k-facilitated data corruption.

Corrupt, illegible media can still be formative — but perhaps not in the way that it was intended. When a system like GTD, Zettelkasten, 37Signals 6-week sprints, etc. gets packaged for dissemination, that packaging necessarily compresses lived experience into something that can be meaningfully communicated.

Sometimes you get a system whose medium compresses brilliantly. Pomodoro is one of those: 25 minute work cycles with 5 min breaks, using a kitchen timer (the tomato clock). The idea and structure is simple to understand, simple branding, recursive, and has low dependencies.

Sometimes you get a systems communicator who is unusually effective at compression. John Boyd was one of those people, I think. Ideas like the OODA Loop are efficient abstractions of a very complex theory of decision making that can be built into broader theories of action.

But mostly, the compression algorithms fail. The system as outputted is not the system that served as the input. Take Jake Knapp's Design Sprint. Targeted at a broad market of product and leadership types, it is a fantastic design-driven, critically scoped, inclusive-to-stakeholders take on feature discovery and iteration that NO ONE actually implements. Why? Well, partially because its compression mechanism was a business productivity book. And partially because the system didn't need to be adopted effectively for the idea of it to spread. For the Design Sprint, these compression artifacts manifest as skipped steps, compressed timelines, and half-committed senior participants. For Konmari, its failing to unpack everything, failure of will, and misalignment of intent.

I think that all systems communication suffers from this fundamental risk, and its part of why all systems communication should be approached with skepticism and curiosity. So let me try to compress one of mine.

Case: Hydrologic Cycles

Energy, effort, and attention are cyclical, I think. But not all at once. And reflecting on my last few years of work — in startups as a contributor, in big enterprises as a consultant, as a solo SaaS founder, and as a writer of sorts — I've realized that I don't have a lot of control over the cycles themselves (my old essay on Sponge Cycles hits at this a bit). What I do have agency over is how I cultivate, exploit, and recover within my personal ecosystem. In a way, it feels like the grade-school drawing of the water precipitation cycle.

Let me to try to "compress" this and we'll see what happens.

1. Evaporation: As a quintessential generalist, my experiences and projects are represented by water that is continuously evaporating.
2. Convection: This evaporation is entropic (projects decay and get outdated) and productive (past experience opens up new experience) — eventually condensing into visible work through portfolio creation, social sharing, talks, media, etc. These are the convective forces that form our clouds.
3. Precipitation: Generally, this kind of work generates more work, with some sense of value having being communicated and interpreted. The weight of that work makes opportunity, and that opportunity is represented hear by rain or snow.
4. Collection: Work done and experiences had HAVE to be interpreted — hopefully in a generative way. Case studies, new methods, as well as new products emerge from THIS stage of the process.

Very tangibly, a past precipitation cycle for me was (descriptive):

1. Portfolio and networking to find consulting clients
2. Writing my newsletter, essays, and giving talks as a primary tool of sense making
3. Lots of consulting clients who were "design adjacent" and where my work was legible.
4. Reflection of these experiences resulted in the prototype of Knowsi, a tool for design researchers. Future cycles would become overly Knowsi focused, and would end up painting me a bit too-heavily as a researcher, and an increasing volume of research work.

Using this to "describe" through the cycle, I'm wondering if I can use this system to be a bit more intentional about what happens downstream.

• Evaporation = Marketing/Community: I need some way to be exposed to new communities and people, both from the professional "finding clients" side of things, but fundamentally to keep MY attention focused. I am motivated by the expectations of others, and my construction of that expectation
• Convection = Sensemaking: Sensemaking and synthesis is the key here. I need a way to go fairly deep on a topic or idea, and cultivate a specific opinion about it beyond guy feeling. The way to do this for me is prototyping, and one of the ways (though not exclusively) I can "prototype" a theory is through writing.
• Precipitation = Income-generating Work: Income. I need some way of making money — doing work that is trans-disciplinary, involves some complexity, has some urgency tied to it, and probably NDA'ed into oblivion. This makes it sustainable and realistic, since doing really interesting work in the open often doesn't happen in real-time.
• Collection = Projects: The previous stages have taken me on a journey, and the water returned to the reservoir is perhaps not the same water that left. The opportunity here is to cultivate something meaningful — but maybe not permanent — that serves as a foundation for a healthy ecosystem. What evaporates tomorrow needs to be of substance and value, basically.

This system then becomes the way that I weigh and assess what kind of work I do, when. It's basically a decision-making/effort-categorization heuristic that helps me think of my efforts in functional isolation, but structural co-dependence. Aspects can overlap, and occur at different tempos. It's also veryyyy specifically directional. Convection doesn't go straight to Collection — Rule 4: never get high on your own supply. Precipitation doesn't go straight to Evaporation — respect the NDA.

So how am I acting on this system? You're engaged with the evaporation (the newsletter) and convection (this essay) part of things right now. The main way I'm using it is as a mechanism for work estimation (how much client work can I take on) and project scoping (what projects can I realistically do and what has the maximum value for seeding other parts of the ecosystem?).

The biggest immediate effector has been rebooting this newsletter, or rather recognizing (as discussed two weeks ago) that I was missing something important to me. The biggest near-term effector is with regards to project selection: basically I'm on the cusp of committing a bunch of time to one of three projects, and this framing is helping me break down how each project might add value or extract focus from each other stage.

System, Interrupted

I don't think I did a particularly good job "compressing" that system, but assuming that it's about standard. A few things I noticed:

• I relied heavily on metaphor. It reduced the dimensionality, and introduced some core ideas like directionality, visual language, and relative states.
• I used concrete framing (examples and cases) to flush out the metaphor, since the metaphors stages aren't 1:1 to the experience
• I considered it with two different functions (introspective and prospective), which helped to answer a bit of the so-what.
• I relied on diagraming (both a known descriptive reference core to the metaphor, and an actual one) to frame up the communication of the system I'm using.

So, common systems communication is metaphor-based, provides concrete examples, is functional, and is visual. There's a lot more to look at here in terms of understanding what makes for effective systems communication. Considering figures like John Boyd (as mentioned), Dona Meadows, Heinz von Foerster, Richard Feynman, Abraham Maslow, to name a few. Also more contemporary systems communicators like Randall Munroe, Venkat Rao, Simon Wardley, etc.