Growing dandelions

A couple of weeks ago, I talked about r/K-selection and mentioned two kinds of ideas: the mutate-through-replication dandelions and capacity-preserving elephants.

I remain curious about the conditions in which dandelions thrive. Here are some initial thoughts on the subject. To narrow the broad designation of “ideas” a bit, I am going to focus on a special case:  innovation on top of APIs. That is, new ideas that emerge while writing code that consumes some set of APIs.

Let’s suppose we’re just starting down the process of designing a new API. Very early, we decided that we want this API to spur dandelions. We did a lot of thinking and realized that our fledgling enterprise will benefit greatly from employing the r-selected strategy.

Why would we want to do that? Primarily, the r-selected strategy works best in environments that aren’t (yet) predictable or stable, where the rate of change is high. For example, we might be entering some new problem space and we want to lean onto the “wisdom of the crowd” to explore it. Or perhaps we’re a newcomer and we would like to convert the budding enthusiasm in the problem space into as many dependencies on our services as possible (if you’re looking for a case study on both, check out Stable Diffusion playbook).

What are the conditions that we need to grow dandelions? How might we design APIs that encourage dandelion-like innovation?

Using the r/K-selection in biology as our guide, we see four key conditions: high reproduction rate, small size, short generation time, and wide dispersion radius. Yes, just like dandelions.

Translating these conditions from plants to ideas, I came up with: interest, legibility, velocity, and access. Let’s go through them one by one. You know me. I love my “let’s go through them one by one” bit.

✨ Interest

First, this API actually needs to promise to unlock exciting new opportunities. This leads me to the first condition: interest, which roughly matches the “high reproduction rate” in biology. Exciting  ideas are contagious. They spur lots of new ideas, churning them out at a high rate. They don’t even have to have concrete value behind them – just a promise of something big and potentially groundbreaking. This sometimes leads to formation of a bubble of hype around them, like with Web3 and the NFTs. Such bubbles, while not healthy in the long term, are a strong sign of the interest condition being met.

Interest is not an intrinsic property of the API design, but rather the property of the technology behind it. Researchers teased the developer community with the tantalizing potential of AI-generated media for years now, building up the interest in the underlying technology. It was OpenAI and then Stable Diffusion who capitalized on this interest and shipped first publicly-accessible APIs that enabled developers to actually play with technology. The resulting wave of innovation was nothing short of astounding – and it keeps going. There ought to be a clock of “days since Stable Diffusion was released” somewhere, because the quantity of interesting new ideas born out of that event feels unbelievable when put in the context of the little time that had passed. Again, a great example of the interest condition being met.

To give you a counter-example, consider OpenSocial,  a cool idea from way back in 2007 that started with much fanfare at Google and ended up dying quietly in the W3C effort graveyard. Even though yours truly did end up playing with it, very few others did. Was it ahead of its time? Was it too obtuse? Was it the XML thing? We will never know. But if your API adoption patterns are looking like those of OpenSocial, check the pulse of the community interest.

🔮 Legibility

Another significant condition is legibility. To allow an idea to spark imagination and produce new ideas, it must be easily understood – even if partially. I correlated this one with the biological counterpart of “small size”. Metaphorically, think of it this way: an idea that is light and small like a dandelion is much easier to grasp than the weighty idea-elephant. A litmus test: can a useful program built with our API fit into a tweet? The deca-LOC framing is useful here, though it’s not just the number of lines of code. 

One of the key tenets of the WebKit open source project at one time was the idea of self-explanatory code: is your change making the code more or less easy to read? There were some who even suggested that adding comments is somewhat of a code smell: if you have to explain what it does, then perhaps maybe you could write it more eloquently instead? 

While I don’t take this extreme point of view, I appreciate the sentiment. Choosing the idioms and concepts that make the code concise while capturing the key thrust of the idea behind the API is difficult work and is full of difficult trade-offs. Sometimes it takes several iterations to arrive at a mental model of the API that clicks with most people. When designing for dandelions, opinion is front and center, and the easiest-to-grasp concepts win over the more obtuse ones – even if the latter are more powerful and flexible.

Speaking of WebKit, and similar large codebases. A key ingredient of legibility is the ease with which an idea can be separated from other ideas. How discrete is it? How easy is it to spot this idea and lift it out? WebKit has a ton of great ideas in its code. I know, I lived in that repository a few years back, and I bet there are even more flashes of brilliance now. However, to spot them as separate ideas, we have to spend a bunch of time understanding how all the surrounding neighboring ideas fit.

This is one of the challenges of implementing r-selected strategies in large code repositories. Now matter how we try, our dandelions end up being somewhat elephant-like.

🚀 Velocity

The third condition has to do with how quickly the ideas borne out of interacting with our APIs can turn into other, new ideas. This is not necessarily a property of the API itself, but rather a setting into which it is born. Loosely, it corresponds to “short generation time” in biology. Velocity is commonly called “tight developer feedback loop” in developer experience jargon, and yes, it’s that, and a bit more. I see it as somewhat two-fold: time to result and effort to copy.

Time to result is the time it takes between making a change to the code and seeing the results of the change. Back when I first started using computers, I remember working with a particularly old piece of equipment that provided the output of my program only as a paper printout – and the printer was across the hall from the monitor and keyboard. Time to result included jogging out of the lab and into the computer room, where massive printers hammered out loudly our many failures and rare successes. Paper jam? Well, you might have to run that job again. Even just capturing the simplest idea into working code was a multi-hour (and sometimes, multi-day) process. That mini-computer was from the pre-dandelion era. The shorter the time to result, the better velocity of an idea.

Effort to copy is an adjacent concept. How much effort does it take to copy an idea? Is it a complicated process? Or is it just one click? A somewhat unexpected, yet obvious-upon-inspection factor here is organizational boundaries. 

Back when I worked on Google Gears as an external-to-Google contributor, I was puzzled at the weird phenomenon: to land, my patches would need to be sent over email as diff files. The open-source directory did not contain any commits from individuals: instead, every commit was made by a bot. After a couple of days of submitting the patch, the bot would dutifully add my commit to the repository. What the heck was happening?! As one of the engineers explained, the actual source of truth was on the other side of the wall that separated the inside of Google from the outside. To land the code, a Google engineer had to patch it in, have it reviewed, and then let the bot take it outside. What I was working with was a mirror, not a real thing. Sure, the automated bot made things easier. But across the wall like this, the effort to copy is still high – and not just for the code going out. If there is some really cool new innovation on the outside of the wall, an organization has little choice but to rebuild it – often from scratch – on the inside. 

On the other side of the spectrum, Github’s “fork” button is a great example of intentionally lowering effort to copy. Want to play with an idea? Click and start making it yours. As another illustration, both effort to copy and time to result are combined delightfully into various read-eval-print loop (REPL) tools that sprouted all over the place in the past decade. Though my first love was JS Bin (hi Remy!), one of my favorite ones today is Replit, which seems to be designed by someone who deeply understands the concept of dandelion gardening.

🔎 Access

The final condition is access. It seems that, to stimulate r-selection, we need a large pool of minds that our APIs can come in contact with. To generate many ideas, we need many minds – or to have a “high dispersion radius”, speaking biologically.

What does it take to start using our API? What are the barriers that the person must overcome? For example, if we decide to provide our API in some programming language that nobody ever heard of, we are increasing the barrier. To access our APIs, people first have to learn this language. 

As perhaps a somewhat controversial example, in the very early days of Flutter, we had this contentious debate whether the engine would rely on Javascript or Dart. Though Dart won in the end, I wonder how much more widespread the use of Flutter would have been had we stayed with Javascript. In other words, is Flutter successful because of or despite Dart?

Dandelion-growing needs space. If we’re planning a small group within our organization as the potential users of the API, we are unlikely to get any benefits of the r-selected strategy. This is often counterintuitive in organizations that pride themselves on engineering excellence. It feels like we should be able to just get a couple of really smart folks to play with the API, and they will figure out some interesting possibilities… right? Well, maybe. 

But if we are aiming to harness the r-selected strategy, we need to stop looking for experts who might give us great insights. Instead, we need to open the API up as broadly as possible and let the wave of hobbyists and enthusiasts wash over it. When growing dandelions, think quantity over quality. Skill and expertise are a barrier.

Additionally, to maximize the number of ideas connecting with each other, I need to make them easy to find and browse. Can a seed of an idea be easily discovered? Can I trace its heritage and find earlier seeds on which the idea was based? Can I see who else is playing with it currently? And no less importantly, who can find my idea?

A gardener’s guide

Putting these all together, we can build a simple compass. The four conditions form an arrow that points us toward dandelion-like growth:

  • Is the underlying technology that the API exposes interesting? Do we anticipate developer buzz around it?
  • Is the API mental model easy to grasp? Can developers’ ideas be expressed in simple, elegant code? Is it free of dependencies that developers might be unfamiliar with?
  • Is the setting into which we release the API offer REPL-like iteration speed and one-click copying of ideas?
  • How large is the pool of people who could conceivably use the API? Is the cost to entry minimal? Is the list of prerequisite learnings short? Is it easy to find similar or different ideas and understand how they came together?

There are a handful of folks that I know who seem to intuitively understand these conditions, and their approaches to API development reflects that. For the rest of us – myself included – here’s hoping that this compass will serve us well in our dandelion-growing pursuits.

A crutch

Thinking some more about organizational pathologies, I realized that there is another way to spot and potentially face the challenges presented by them: a crutch.

A crutch is a kind of organizational myth that had served this organization well in the past, and as a result of its own success, became so overused and over-relied upon that it’s actually doing more harm than good.

Crutches come in various forms and shapes. They could be processes, like the “Success Score Cards” and “strategic commitments” in the “Royalfield” story from Rumelt’s book. They could be strong cultural beliefs that, as they age, become effigy husks of their former selves, yet still capture enough imagination of the team to stick around. They could also be individuals. If a team can not make any significant decisions or forward progress without their leader in the room, this leader might be their crutch.

Crutches are rarely seen as crutches. They are typically viewed as foundational, immovable parts of the organization. How could we possibly do something other than Success Score Cards? That’s preposterous! Even when challenged with the mounting evidence of the pathological processes burning through the organization’s body, crutches are often viewed as the cure – sometimes leaving to weird instances of iatrogenesis, where the use of the crutch becomes the source of the problem (“Let’s do Success Score Cards harder!”)

If we are suspecting that our organization had developed a pathology, we could start looking at the bits of norms, culture, org charts, and processes that we hold in the highest regard and/or haven’t examined in a while. To know that we’ve found a crutch candidate, listen to how people react to our gentle poking at it. If the response is along the lines of: “What do you mean?!” or “Sure, it has flaws, but what else is there? I don’t know of anything better!” – we might have found a crutch. If closely examining a potential crutch suddenly feels like a career-limiting move, we are likely getting very close to the source. When spelunking for crutches, we are better off wearing a helmet and protective gear.

It is not hard to infer from this description that pathologies have a strong staying power precisely because spotting and pointing at a crutch is so deeply uncomfortable for the organization. Almost by definition, crutches are part of an organization’s embodied strategy. While spotting one is a significant breakthrough in itself, it is rarely sufficient to cure the pathology. Just pointing at it and loudly yelling “Look! I found it! Here it is!” is more likely to get us shunned than celebrated. Even if we are the leaders of this organization, our decisive attempts at surgery are likely to backfire.

Instead, my guess is that our approach might be the same as in any change of embodied strategy: nudging. Pathologies inflict suffering, and with suffering comes the innate desire for change. And that might just be the potential energy that our nudges need to succeed.

Organizational pathology

I was reading the latest book by Richard Rumelt, The Crux, and something clicked that I just had to write down. 

One of the reasons I enjoy Rumelt’s books, aside from that fiery, witty style, is that they are always packed with a wide variety of examples. This book is no exception, and, after a little while, a pattern emerged in my mind in all of the examples of failed applications of strategic thinking – and action. It’s a special case of “solving the wrong problem”, which I am giving a somewhat clinical term of a “pathology”. Here’s what I mean by it.

We all make mistakes. Making mistakes is an essential part of being human, and part of every organization. If we don’t make mistakes, we don’t learn, as I illustrated in the learning loop bits of the problem understanding framework. However, making mistakes in itself is a neutral activity: it can be either used to learn and create a better mental model of our environment, and it can also be used to lead astray, reinforcing a mental model that doesn’t generate accurate predictions. 

It is the latter case that piqued my interest, because in my experience, this is the one that most organizations – and people – struggle with. A pathology is a kind of unproductive mistake-making process that emerges under the following conditions:

  • There’s an obstacle that we believe we will encounter in the future. 
  • The expectation of this encounter makes our current situation discomforting.
  • There are two discernible classes of actions available to us: a) one that alleviates the discomfort of the current situation, and b) one that reduces the size or the likelihood of encountering the obstacle
  • The obstacle-reducing actions do not alleviate the discomfort.
  • The discomfort-alleviating actions grow the size of the obstacle or create an entirely new one.
  • Finally, – and this is key – under pressure to act, created by our discomfort, we consistently choose actions that alleviate that discomfort.

Whoa, that’s a lot of bullets. Let’s unpack them. 

I called this process a pathology because it often feels like a sort of thinking disease: it’s a thing that takes hold of us. Even when we are fully aware of what is happening, we still struggle to make it stop. Usually, an external intervention is necessary to make a change.

As I mentioned before, pathologies are part of the larger corpus of “solving the wrong problem” situations. It is not fun when we end up in a place where our diagnosis points us at something that we later realize is just an effect, not the cause of the problem. 

Borrowing a story from my past as a software engineer, I might assume that the rise in the latency metric in my code is due to some new regression. I would then spend a bunch of time – like a week! – trying to unsuccessfully hunt down this regression, only to notice that the metric suddenly moves back within acceptable threshold without any action on my part. It’s a heisenbug! After much more searching, I realize that my colleagues on the infrastructure team have been moving their code around and accidentally shifted how the metric is computed. Oops. Well, at least they put it back! Sure, I did get to “about to pull my hair out” state in the fruitless debugging session. But ultimately, once the culprit was found, I learned about yet another where problems can arise, and moved on. “Solving the wrong problem” of this kind tends to be frustrating, but highly educational.

Where pathologies differ is that they add an extra twist: solving the “wrong” problem both exacerbates the actual problem over time and provides a false sense of doing the opposite. These two factors often interlock. 

The exacerbation bit can come in many different forms, but here are the most common LEGO bricks they’re made of:

  • Backsliding, when the action taken as part of solving literally takes you in the opposite direction.
  • Entrenching, when the action reinforces some existing process or practice that needs to change to solve the actual problem.
  • Delaying, when the action is that of putting off dealing with the actual problem.

The false sense of moving forward often builds on these. For example, an entrenched habit can be rather comfortable. Sometimes the mere fact of doing something is, too – as the Politician’s syllogism goes: “we must do something – this is something – therefore, we must do this”. The key attribute to look for here is pain relief: something that reduces the discomfort of being presented with the problem.

The “Royalfield” case study, one of many in Rumelt’s book, particularly stood out for me as an example of a pathology. The author describes a multi-day strategic planning exercise that he attended. At this exercise, he observes folks following a well-entrenched process that involves “Success Score Cards” and “strategic commitments”. 

As the author interviews the executives, he starts realizing that none of the actual strategic challenges are being discussed. Instead, the rote motions of the process are driving the event. When he tries to raise the issue with the CEO, he’s chastised for distracting the participants from their Success Score Cards. The author notes that since that event, the company’s fortunes continued to dwindle in an unfortunate, but predictable way.

Here, we have all the elements of a pathology. There’s definitely an obstacle that the executives perceive and the discomfort they experience – aka “the problem”. Otherwise, they wouldn’t be holding this exercise in the first place. There are two kinds of actions they can take: start examining actual strategic challenges of the company, or follow the existing planning process. The process is already here and everyone already knows it, so the executives choose to follow it. So far, this looks like a “solving the wrong problem” scenario.

The pathology locks in when we add two final ingredients: first, the “Success Score Cards” and “strategic commitments” act as a powerful analgesic, giving executives the permission to stop worrying about the obstacle for a little while. “We did this planning thing, didn’t we?”

Second, we can clearly see how entrenching and delaying are in full force. The CEO’s nearly allergic reaction to even an idea of considering something different indicates that change will be exceptionally difficult for this company – and each such planning session delays the moment when the team must come to terms with the reality of the situation.

I imagined how even now, the executive team is still trying harder to make better, more effective Success Score Cards, and going to great lengths to ensure that the strategic commitments slide deck is breathtakingly dramatic – stuck in the pathological case of solving the wrong problem.

Now that I have this pattern outlined, when (or if) you read the book, I am guessing that it will be nearly impossible not to spot it, over and over again. And it is also my sincere hope that when you look around your team and organization, you will have a fresh way to notice this pattern around you. I even have this simple template for you:

  • What is the obstacle that is in front of your organization that perhaps evokes some discomfort?
  • What are some of the actions that your organization commonly takes to relieve this discomfort?
  • Are they the same actions that will also help overcome the discomfort?
  • If not, which ones seem to increase the size or the likelihood of encountering the obstacle (backslide, entrench, delay) or maybe creating a new one?

If there are items in the last list, it’s worth giving them a careful look. They might be one of those bad habits that subvert your team’s process of learning from its mistakes.

The Perspective Ladder

I’ve been trying to come up with a better way to illustrate the concept of mental model flattening, and realized that one way to do this is by describing it as I experience it.

Imagine a scale that reflects our relationship to a perspective: a self-coherent worldview. This worldview is possible because of the network of mental models we possess, helping us orient ourselves, see choices and possibilities, and act on them. 

This scale is arranged as a ladder of sorts, with the mental model complexity is at its highest at the top, becoming progressively simplified with every rung down. As the model gets simpler, our capacity to relate to a perspective diminishes. As we proceed through our day, we climb up and down this ladder multiple times a day, sometimes moment to moment. Even though all rungs of the ladder may be accessible to us, we aren’t sitting still. We run up and down, sometimes intentionally, but most often not.

Just like real-life ladders, ours is subject to gravity. Climbing to the upper rungs seems to require effort. Conversely, all it takes is a little stress, fatigue, or a particular triggering experience, and down the rungs we go. Picture the process of mental model flattening as this sliding down the ladder.

Understanding which rung we are at any given moment is, in itself, a form of acquiring a perspective. It serves as an extra boost upward: pausing to understand where we are might serve a useful trick to start climbing.

So, the ladder. I’ll start at the bottom and we’ll clamber up together. I’ll describe each rung as my own experiences – I hope they resonate and help you reconstruct the picture that I am seeing in your own mind.

🌪 Detached from a perspective

The ladder’s lowest rung is what I call “just stayin’ alive”. Here, I am thoroughly disoriented and lost, mostly just reacting as best as I can. My impulses are in charge. Whether positive or negative, my experiences at this rung are intense.  If you’ve ever felt that panicky feeling of just trying to find bearings – or perhaps get that insatiable craving, then you know what I am talking about. At this rung, when the notion of a perspective is suggested to me, I will typically react with bewilderment, struggling to remember what it might mean. It may feel like a lifeline when a perspective – any perspective! – is offered. The particular strength of this rung is in the rush of adrenaline it provides, the extra kick for powering through a particularly tough situation. At the same time, these hormone baths are taxing for our bodies and aren’t great for our health in the long term. And well, there’s this whole “lost” thing.

When detached from a perspective, it’s not that I don’t have any of my mental models. It’s that they all appear to have this squeaky, slippery rubber feel to them: grasping at them just makes them pop out of my hands and float farther away. The only ones that feel accessible are primitive and atavistically simple: “they bad, I good”, etc. This is the extreme of mental model flattening.

🩹 Sticking to a perspective

Just above is “sticking to a perspective” rung. I am firmly attached to a particular way of looking at what’s around me. I am no longer as disoriented, but I ain’t seeing much outside of the very specific window of the perspective. I can feel pretty comfortable in this state, aside from the occasional nagging feeling that something is missing. When someone suggests that they have different perspectives, I may look at them like they are messing with me – or trying to deceive me. While stuck to a perspective, irritation and anger are common reactions to the evidence that doesn’t fit into that perspective: I am part of the perspective and a threat to it is a threat to me. The gift of this rung is followership: I will happily roll up my sleeves and chip in to help with a problem when asked – as long as it fits into my perspective window.

While sticking to a perspective, the mental models tend to appear as crisp and simple causal chains that are unburdened by any fuzzy notions. If this, then that. Even when well-familiar with loops in a network of causal relationships, any notion of them will be neatly elided from my thinking. Mental models of others are either “exactly like me” or some overly primitive caricatures. 

At least for me, this rung serves as sort of a defensive crouch. When I am distracted or tired, this is where you are most likely to find me. I’ve been looking for a sample of my writing at this rung of the latter and the Agony of a Thousand Puppies comes pretty close:

Hiding Javascript behind another language’s layer of abstraction is like killing puppies.

Yep, it’s the grumpy-pants Dimitri.

🔨 Holding a perspective

Another rung up is “holding a perspective”. My attachment to the perspective becomes more or less intentional. I hold the perspective, as opposed to it holding me. It is the only perspective I know, but I know it well. This perspective is particularly helpful when I am asked for loyalty or need to commit to a certain course of action.

When I hold a perspective, I can wield it like a sword and find clever ways to destroy perspectives of others. Even when I am clearly shown blind spots of the perspective I hold, I remain unfazed, retreating into the realm of magical thinking and conspiracies if necessary. I may not even be upset with people who have different perspectives. I just would have this calm sense of boundless confidence that they’re wrong.

This rung is populated by mental models that we’re experts in. The sheer depth of experience does the heavy lifting. These models may be fairly intricate, but tend to have this mechanical quality. When holding a perspective, we view all things around us in terms of precisely, pain-stakingly crafted mental models. Unlike at the previous rung, our mental models of others expand quite a bit in their sophistication. They have gears and springs that move them — and we feel like we know exactly how they tick.

It pains me to admit how familiar this rung is to me. Some of my biggest blunders were rooted in this mechanized world – yet it remains to be somewhat of a default notch for me. If you want to hear how I sound at this rung, here’s a post from 2007, written in “holding a perspective” voice, where I propose an alternative to Apple’s iPhone SDK.

🌳 Having a perspective

The next rung up is “having a perspective.” It is characterized by this sense that I do indeed have a particular perspective, and I know why I have this perspective. I can look around and see ample evidence that the way I am seeing is self-consistent and coherent. I can discern my own work of constructing this perspective. When someone talks to me about it, I can describe my perspective (and the reasoning behind it) in detail. I can take the perspectives of others, understand them, compare them, show flaws and benefits in them, and even adjust mine to make it more robust. 

When at this rung, I am not trying to answer the question of “why is this perspective true/false?” but rather “why is it so?” The growing depth of understanding of my perspective helps me maintain the clarity of direction, which frames the main strength of this rung: the capacity to lead others. 

It is my experience that leadership and commitment are at the different rungs of the ladder. Especially in fluid environments, these are two different activities. One is patiently staying a decided course of action, and the other is looking to navigate a changing terrain. The latter requires flexibility and rapid changing of the mind, which can appear like lack of conviction at the “holding a perspective” rung.

The sense of organic flexibility, like weeds, permeates our models at this rung. The models open up, no longer precise and mechanistic, allowing for ambiguity and tolerating clusters of unknowable. When we have a perspective, we recognize that it’s just a snapshot of some much more complex thing that we aren’t yet seeing, and are able to be okay with our model’s inherent incompleteness. The source of groundness at this rung emerges not from the confidence of “knowing the world”, but rather from the sense of awe of the complexity of the world and the deep desire to glimpse the whole picture. 

A post from 2014 about Web platform deprecation might be a sample of how I sound at this rung. There’s a patient and thorough analysis of the situation, admission of its gravity and high ambiguity, and an optimistic call to action. It is the voice of most of my writing at work. 

🌀 Visiting perspectives

The “visiting perspectives” rung is at the top of our ladder. In addition to seeing perspectives of others, I can shift to inhabit them. I can step out of what I believe to be true and temporarily adopt someone else’s ontological realm. I do this without judgment and temptation to evaluate it against my perspective, accepting that this someone else also has a rich life experience and a lot to teach me. I am a traveler who’s visiting perspectives, and the less I hold on to mine, the more depth of other perspectives is revealed to me.

This ladder might actually be one of those spiral staircases. In a weird circular fashion, the last rung resembles the first one: in both, I appear to have no attachment to any given perspective, and may even seem lost. The big distinction is that in the first rung, I can see very little. In the last one, I have the full capacity to see perspectives of others around me. This process of perspective examination is deeply enriching, and offers the gift of being able to see blind spots that nobody else can. When I am able to stay at this rung at the ladder, it almost feels like I can see around corners. When I say “systems thinking”, I usually mean not a particular discipline or methodology, but rather the experience of gaining access to the complexity of mental models at this rung of the ladder.

For me, writing rarely happens at this rung, because the moment is so fleeting. I could try and plead the case that most of my recent posts are written in that voice, but I suspect it’s just skill. I have learned to emulate the gentle, curious voice of this rung, even though I am not actually inhabiting it.

However, I do have a few posts that I remember writing immediately after touching that top rung. They have this nearly delirious delight of briefly seeing something much larger than what I can typically afford. My Decoherence post from 2020 post is one of those. The first sentence reaches for a galactic horizon: “There is no past or future”.

Perspective ladder mini-case study

To give you a sense of how traveling up and down the ladder feels, I’ll describe my experience at a meeting I’ve been at just last week – here it goes, with commentary.

We were discussing a subject that I knew a lot about, and I was pretty sure about that. I was also pretty sure that we were all on the same page. I started getting a little bit distracted, checking my email, and thinking about something else. Only a bit of attention remained on the conversation. 

At this point, it is unclear if I am sticking to a perspective, holding it or having one. All three feel the same. However, the “partial attention” bit points at the sticking to perspective: letting it hold me.

Then, one of the participants spoke up, revealing a different perspective that was incongruent with mine. My first internal reaction: “Wait, what? What’s happening here?” 

Aha! Indeed, it looks like I was at “sticking to a perspective,” rung, and my colleague’s confident voice triggered a dip into the “just stayin’ alive” rung. The disorientation is a telltale sign in such cases.

Then I immediately had this sense of irritation come over me. I was feeling disheartened and disappointed.

It sounds like I quickly escaped out of the lowest rung and climbed to “sticking to a perspective.” There could have been two alternatives here: one of me sticking to my colleague’s perspective, immediately adopting it, and the other is of me remembering that I have a lot of expertise in this area, and sticking to that. It looks like I picked the latter.

One interesting marker for “sticking to a perspective” rung is Should-ness. If I feel strongly that I should be doing something or acting in a certain way, and/or others around me should be doing the same, or something I expect them to do – that’s a sign that I am at this rung of the ladder.

After fuming for a little bit, but not saying anything, I noticed that I was feeling irritated. I tried to reorient and did a breathing exercise to release the tension. Once I settled down, I started noticing that my colleague was just wrong: they clearly didn’t understand the problem as well as I did.

This indicates that I am currently climbing upward, likely at the “holding a perspective” rung. There’s usually a sense of relief that accompanies reaching this rung, when I realize that all is well and it is the others who are lost, not me.

I started asking questions trying to better sense where their misunderstanding originated. To my surprise, I realized that my colleague had good insights that I could build on to improve my knowledge.

I am now at the “having a perspective” run. There is a subtle shift when climbing up here: other people’s “wrongness” becomes a parts bin for ideas. Instead of being a protector of my perspective, I become a savvy gardener who eagerly improves it once novel insights are uncovered.

The meeting ended on a good note, and I felt pretty excited about learning new things, though I wasn’t quite sure what to do about the difference of perspectives between my colleague and I that we encountered.

It was only next morning that I realized how neatly our perspectives cover a larger problem space that I haven’t seen before, and how their view is not only valid, but also overlays a blind spot that I suspected was there, but couldn’t quite see (because that’s how our blind spots typically behave). The idea of how we could collaborate immediately became obvious and got me excited and fired up for the day.

This flash of insight is a result of briefly reaching the top rung of the ladder. I could swear it feels like it’s accompanied by the angelic choir sound: that’s how clarifying and revealing the insight that arrives. I wish I’d spend more time at this rung, but I only seem to reach it ephemerally and in certain conditions. Things like having enough rest and sleep, for example, are a large part of the equation.

The excitement that followed is a drop to “having a perspective” rung: learning and incorporating the new gems into my garden of mental models. It is followed by the commitment and determination (“I am fired up!”) that tells me I clicked into the “holding a perspective” rung.

What I learned so far

I hope this illustration has been helpful. I have been using a less kempt rendition of this framework for a while. Here are a couple of things I’ve learned along the way. 

  • Fake it till you make it. When at the bottom rungs, it seems that the key is to remember that there’s a ladder at all. At these rungs, it’s just trying to cling to the framework itself as a perspective (there’s literally a stickie with the words “Remember the Ladder” on it), and being patient with myself. Have faith that the model flattening is a temporary effect, and the disorientation and the limited sight being experienced will pass.
  • Different gifts at different rungs. Each rung is useful for unlocking its particular gifts, though these gifts tend to be mutually exclusive. There is no rung where I can both follow and lead. To do both, I have to be consciously switching between the two, and that is an effortful process. If I want to see around corners, but am also looking to commit to one particular perspective, I need to anticipate a lot of climbing up and down. Similarly, if I am “just stayin’ alive” at “detached from a perspective” rung, any attempts to lead or even follow will be highly unproductive.
  • No free pass. Going down can happen quickly (gravity makes things fall), but going up, the rungs of the ladder don’t appear to be bypassable. Even if very quickly, it looks like I have to travel through the rungs to reach the ones I need. Be it reading a book or watching an interview, the travel from “well, that’s just preposterous!” to “ah, yes – I see how they’re wrong” to “huh, these bits are insightful” is something I am learning to anticipate. At this point, I’ve gotten to the point where I can sometimes feel the clicking of the rungs happening – which helps to orient.
  • Bottom rungs are trappy. The “sticking to a perspective” rung is, well, sticky. I have to be fairly vigilant about not getting trapped in the not-learning cycle that lives just between it and the “holding a perspective” rung. Both rungs have a very satisfying feel of not having to change anything about myself. On too many occasions, I would recognize that I’d spent a chunk of my time just going up and down between these two rungs, trapped in the cycle.

The story above might sound familiar, because it is a loose, more flexible re-telling of the adult development theory. I’ve been unsatisfied with how, in conversations about ADT, the stage-like progression aspect of the theory takes center stage, displacing another useful aspect of it – the fluidity of how we show up in our daily lives. It is tempting to imagine that once a person reaches a certain stage, they just kind of stay at it.  Since my experience is a bit different, viewing it as a one-way stair step progression felt too static. However, when combined with the concept of model flattening, it seems to gain this dynamic flavor.

r/K selection and innovation

I’ve been thinking about the different conditions under which innovation emerges, and how the environment influences the kind of innovation that happens.

To set the stage, I am going to do a very brief detour into biology (I am not a biologist, so will definitely make a mess of it) and use the r/K-selection lens to guide this story. If we observe various organisms, the theory goes that all fall somewhere in the spectrum between r-selection and K-selection. The r-selection is a strategy that’s focused on reproduction: make copies of my kind as quickly as possible, and mutate generation to generation. The K-selection is a carrying capacity strategy: stay alive as long as possible, learn and teach my (usually very few) offsprings the necessary tricks to thrive. Both are viable strategies, depending on the environment.

Typical examples used for r-selection are dandelions and for K-selection – elephants. To bring it closer to home, we can have the coronavirus represent the side of the r-selection, and us humans the K-selection. The battle of pandemic/endemic we’re still locked in shows that humans are likely to win, but oh boy is COVID giving us the run for the money.

Turning to the realm of ideas, it seems that some of them are r-selected. In the most basic form, ideas are memes: easily transmitted, rapidly spreading earworms. Each transmission is an opportunity for mutation. As they inhabit our mind, ideas fall in the fertile ground of other ideas and the next time we communicate these ideas, we – nearly always – change them. They mutate into something different. As the r-selected strategy suggests, ideas evolve as they are copied.

Other kinds of ideas are K-selected. These are usually larger, self-coherent entanglements of smaller ideas. They live in our minds and they evolve over time, growing and maturing. Just like K-selected organisms, these ideas reproduce with pain and effort. We can’t just give them to others. We must garner our patience and engage with them in the process of teaching, smuggling them across the often unreliable medium of interpersonal communication, one tiny elemental bit at a time.

My fellow FLUX-er Erika pointed out that by putting these two strategies into a spectrum, a framing of pace layers pops out. There are simple ideas boiling afroth at the top layer in a pure r-selected strategy. As they connect with other ideas, their strategy becomes more and more K-selection-like, forming layers that move at a slower pace. Learning Newtonian physics? Welcome to the lower layers. Reading the latest memes on Twitter? That’s at the top.

This pace layering offers us a neat way to look at the kinds of innovation. Since innovation is powered by ideas, we can see it manifest in different ways at different pace layers. The higher, more r-selected layers are great for rapidly exploring new spaces, where there are lots of unknowns and possibilities. The lower, more K-selected layers are incredibly effective for optimizing and refining existing ideas. As ideas mature, they traverse the pace layers, descending from r to K.

Using this lens, an organization that desires to innovate can act more intentionally by picking the idea selection strategy. If we’re looking at a new wide-open space, or searching for the next frontier, we would want to create conditions where ideas can spread rapidly and replicate to mutate. 

A recent example of this happening is the release of Stable Diffusion, an AI model for generating images from prompts. Simon Willison has an insightful write-up of the phenomenon, and we don’t have to squint to spot application of the r-selected strategy: the model and the surrounding tools are open source, and the process of setting up your own instance is fairly straightforward. 

Combined with rising interest around the future potential of generative media, this caused an immediate explosion of innovation: people messing with it for fun and/or quickly putting together possible business ideas. Given that no other contenders offered such an opportunity to the interested crowd, I would not at all be surprised if Stable Diffusion, no matter how well it fares in its comparative quality today, becomes the de-facto engine for generating pictures from text.

On the other hand, if we want to climb the gradient hill and improve upon an existing idea, we are better off picking the K-selected strategy: invest into apprenticeship practices to facilitate tacit knowledge transfer, and ensure that idea refinements are carefully curated. 

I will once again lean onto browser development to illustrate the K-selected strategy. The modern Web rendering engine, which is the thing that interprets text, images, and code as a visual, interactive composition on your screen that we call “Web sites” is a prototypical outcome of descending down the pace layers.

A wild-haired idea at first, it eventually grew into a massively complicated and often self-contradictory tangle of ideas that is captured in code. There are only three distinct instances of that code: WebKit, Blink, and Gecko. These instances try to interoperate, and there is an incredible amount of knowledge — both tacit and described in long, dry documents called specs  – that need to be grokked before proceeding with constructing another instance. If Stable Diffusion is a dandelion, Web rendering engines are elephants. 

One does not simply create a new rendering engine. To move forward, a K-selected strategy is called for. When we look at the efforts surrounding creating a rendering engine, we can see extensive documentation and education that helps aspiring Web browser engineers climb the learning curve, as well as rigorous processes to ensure that every change that is being made to the codebase carefully, yet purposefully evolves the project.

Similarly, we can anticipate mismatches in the kind of innovation we’d like to see and the strategy that we have at our disposal. We can’t expect to explore a new space with data-driven analyses and an elite team of experts — just like we can’t expect to see consistent results aimed toward some goal if we’re set up for rapid, unbridled experimentation.


I’d like to introduce a metric for developer APIs that I call “e-LOC”. I am not great with names, so it’ll just have to wait until someone gives it a better one. Meanwhile, let’s explore it.

The definition of e-LOC is as follows: e-LOC of a technology is the order of magnitude of lines of code that one needs to write to get to a working product prototype using this technology. Applying the usual metric prefixes, we get ourselves a nice scale: 0-LOC, deca-LOC, hecto-LOC, kilo-LOC, mega-LOC, and so on. 

Various APIs reside on different parts of this scale. A finished, functioning product is 0-LOC. On the other side of the scale is a developer surface that requires gazillon of lines of code to produce something that we can reasonably offer to our friends and colleagues to try out. Want to build a web-based product prototype? It’s probably going to be hecta-LOC. A brand new Web rendering engine? You’re likely looking at a mega-LOC.

The order of magnitude serves as a decent measure of developer barrier to entry. For a deca-LOC, it’s just a handful of lines of code, so the barrier is very low. For Web rendering engines, only a skilled, determined, and well-funded team of developers can overcome it.

Because of this barrier to entry property, the e-LOC can serve as a leading indicator for the amount of innovation that will happen around a given technology. Put differently, e-LOC can be used to measure innovation potential of a technology. 

New OSes and rendering engines are one-shot, lonely affairs. They undoubtedly innovate, but the fruits of this innovation are singular and rare. On the other side of the scale, if it takes 60 lines to make a working Discord bot that generates pictures using Stable Diffusion, nearly anyone can do it. Expect a lot of people to be messing around with these APIs and trying to build something interesting with them.

Another useful property of e-LOC is that it also indicates how much opinion is contained within the API or technology. More opinionated APIs will tend to have lower e-LOC, while the less opinionated ones will trend higher in numbers. Of course, lower e-LOC doesn’t make the API good. That’s not what this metric measures. Some of the most troublesome, gnarly APIs are deca-LOCs.

The opposing directions of opinion and developer barrier to entry present an interesting tension in innovation potential. A 0-LOC technology is fully opinionated and requires zero lines to use. Because of that, it also has zero innovation potential. The innovation potential increases proportionally to the amount of opinion that could still be added, yet the barrier to development tapers it off as the e-LOC scale increases.

Advancing the state of my earlier developer funnel framing, we can draw this as a curve to illustrate the relationship of technology innovation potential and e-LOC. The curve starts at near-zero at the beginning of the scale, then rapidly expands to its maximum value at around deca- and hecto-LOC, then drops off in a power law fashion as the magnitude of lines of code keeps increasing. The near-zero at the start is significant: in my experience, even finished products end up growing APIs, whether they want it or not.

This metric gives us a nice way to orient our thinking around the purpose of the technology we might be building. How much innovation do we want it to spur? If we want to minimize it, we ship only finished products. If we want to maximize it, we must relentlessly drive our APIs to be in deca-LOC range.

Making Fifty

This one will be a bit unusual. Instead of my typical sermons on  strategy, ecosystems, and development, I want to talk about another hobby of mine: making music. I recently published a new track called Fifty, and figured that it might be fun to write about how I went about creating it.

My experience is that electronic music-making is a lot like software development. There’s tinkering involved. There’s always a new technique to be discovered, some new trick that I didn’t know about. There’s skillful practice that feels very much like flow — at least after one has done this for a while.

At least for me, it is also different in that I start with a very generic intention of “let’s make music”. I don’t have an idea of what this next track will sound like. Unlike with software, I don’t have any concerns about whether the final product will be useful or interesting to someone or whether there’s going to be a market for it.  There are no timelines or cost concerns to worry about. I make music for the sake of making music. And just like with any sort of craft, I settled into a fairly stable process.

My process seems to follow a double-diamond diverge-converge structure, bookended by the finishing step. The first diverge-converge diamond is about finding the sound, and the next one – about finding the track. They can sometimes stagger, but they rarely go out of sequence.

First phase: sound-making 

In the first phase of the music project, I seek the sound. I want to understand what the feel of the track will be. I love starting with some raw material to shape and muck about. For example, I may take a friend’s excellent karaoke performance as my starting point, or the sounds of a city, or perhaps a favorite event. This is the maximum serendipity phase. I float around between ideas, and it can take quite a while. Since there’s no time pressure, I can spend several months in this state. In some cases, I get close to the point where I feel like I have something, but I can’t make any more progress on it. Sometimes, nothing interesting happens for a while. Until serendipity finds its way.

For Fifty, this moment came with the discovery of the sound you first hear at about 2:02 and it’s this epic chord/clang that is kind of hard to describe. The long reverb and shimmer effects make it go seemingly forever, evolving and shape-shifting. This sound is the defining terrain for the track, permeating it and giving it this trance-like floating quality. 

The sound started rather prosaically. I was experimenting with layering slightly discordant tones, intentionally putting them out of tune. It wasn’t going anywhere. Here’s one early bit:

Keystone sound dry

And here’s another iteration, with a bit more reverb. It was all kind of meh:  

Keystone sound with reverb and delay

I was about to give up when, on a whim, I decided to stick it into a cabinet. The Guitar Rig has this amazing collection of authentically sounding matched cabinets that emulate those massive Marshall rigs that we all remember from the rocking stage performances. They are the ones that give electric guitars that massive sound. And I thought: I need me some massive sound. And – BAM! – the track was born. 

Keystone sound amped

The guitar amp couldn’t get enough of the extra harmonics created by the disagreeing oscillators. It was that magic moment of convergence: finding the sound that digs deep into my imagination that spurs the progress of the track. One moment it’s just a random four bars and the next, it starts to feel like a track. I now can hear the final thing before it’s even created. All I need to do is recreate it in real life.

What I heard was this epic, almost outlandishly bombastic track. I quickly threw together this classic slightly-detuned saw to go on top of the keystone sound.

Detuned Saw

When I played it to my wife, she said: “sounds like one of those sports broadcast intros.” I was like, “YESS!!” – that’s exactly the vibe I was going for. 

Second phase: putting together a stem

In the second phase, the sounds start to come together into something like a stem, and I start literally hearing the final track, even before it’s done. Usually, at this point, I only have eight bars of various instruments loosely strewn together, but it comes alive in my imagination. This is the convergent phase of the process and it is characterized by the original eight bars rapidly accruing additional instruments and sounds. Drums and percussion usually come around here, as well as various pads and plucks. At the end of this phase, I have this massively overloaded sonic nightmare of all instruments playing at the same time across the same eight bars. Here’s one for “Fifty”:

The Stem

Third phase: making track fodder

The third phase is another divergent phase. I pull the instruments apart into stems and start working on them separately, creating more and more distinct patterns out of the original eight bar cacophony. 

Here, it is a matter of improvising over the repeating eight bars. I just keep playing and listening to what feels in tune with what I am looking for. Here’s a small part of the “just playing melodies” session that didn’t make into the final track:

Unused Melody

Not uncommonly, the new stems want to become their own tracks and run away from me. I may start thinking: “hey, that’s a neat little side riff” and a month later this riff becomes the main theme of the track. 

For Fifty, what sounds like a main theme was actually a late addition. It started from a random riff and grew into the piano-like melody you hear in the track:

Riff from which Main Melody grew

I call this phase “making fodder”, because it creates the sonic space that I can then mix into a sequence that becomes the track. At the end of this process, I usually have a large grid of patterns that can be played in various combinations:

Fourth phase: stitching together

The fourth phase of the process is finding the track within that grid. I can go about it in different ways. Often, I hit “Record” and just trigger these patterns to see if a sequence comes up. This is the moment when a “chorus” or a “verse” cadence emerges. One of the combinations jumps out as the main theme, and others line up to support it. This usually takes a while, but I’ve learned that rushing this process results in boring music. I try to let combinations surprise me and not hold too firmly to my original preconceptions of the track. 

Finishing step

The final, finishing step is pretty much what it sounds like. It’s about sprinkling additional movement: extra drum breaks or variations, tweaking the filter knob on a synth or effects, adding a rise here and there. Often, a new instrument can come in to echo and support others. The intro and outro crystallize and become real. And of course, mixing. Mixing is hard. Mixing is the most interesting part of the finishing process. Trying to balance the overall energy across frequencies, ducking the volume on some instruments to clear the way for others, gluing sounds in groups to create distinct lanes of sound. Panning. Trimming echoes that are too long. It’s ridiculously enjoyable.

This step may sound like mostly spit and polish, but I find that most of the exciting moments of the track originate here. 

Let’s take for example the intro in Fifty. It starts with a weird buzzing sound that might be familiar to you.  A while back, on a whim, I recorded the sound of an Apple watch desperately trying to alert me of the expiration of some timer. The device was sitting on a glass surface, and its tiny vibration motor was making a noise that seemed like a beat.

Apple Watch Buzz

Later, when starting this track, I thought I’d incorporate it as percussion, but that didn’t go anywhere. The inspiration struck at the finishing step. I wanted to somehow capture the joy of messing with sounds. So I decided – what if I start this track with play-acting the process of building a sound? I say “play-acting”, because a lot of trial and error goes into the actual process, and that would be too tedious to listen to.

So I took the recorded sound, cleaned it up a bit, and stuck it into the ingenious instrument by Ableton called “Simpler”. At C0 (the low octave), the Simpler produced just the watch buzz repeating. With each next note, the buzz will repeat faster, and faster, and faster – until at C8 (that’s eight octaves upward), the buzzes are so close together that they form their own sound wave:

Apple Watch Buzz as a Note

Then, I dialed up the portamento and played C octave-to-octave, which is more or less what you hear in the first 38 seconds of the track:

Along this upward slide, the sound hit a few harsh (2.6K-ish kHz) patches, so I put in a bit of EQ work to smooth the noise out. Automation lanes are amazing. Back in 1993, I turned the filter knobs by hand as we were recording! It was fun, but oh boy it is so much nicer to be able to just draw the values on a timeline:

The next 40 seconds or so of the track sound very similar to what I typically do when hunting for an interesting sound: I set some pattern of notes to on repeat and twist synth knobs until something surprising pops out. 

You get the “build” version of events: I began with all dials at zeron and gradually added them up. This is a very common layering/additive synth approach, and I love listening to how the layers of sound interact and enrich each other. Within this seemingly simple bass drone is a choir of sounds, and the build reveals the multitude of voices.

At the end of the finishing step, I have a finished track. Here’s Fifty at that moment:

In the past, I had this temptation to keep tweaking the track and improving upon it, but nowadays, I just publish it on SoundCloud and close the file. It is time for the music-making process to repeat itself.

The Plumber Age

This framing jumped out of a conversation with the fellow FLUX-ers and I just gotta write it down. It appears that every software project, upon hitting its stride of success, eventually arrives at what I call the “plumber age”. Here in this story, I use “plumbing” to refer to the work of improving the quality of the code – as opposed to “feature work” that adds new functionality.

The Plumber Age according to Midjourney

The Plumber Age is the period of time when making further progress depends primarily on the quality/velocity of refactoring and cleaning up the code base.

I like to think of it as a season in the lifecycle of a software engineering adventure. This season is characterized by the rapid rise in importance of refactoring and rewriting existing code. At some point, a software project encounters this interesting moment, where the number of new features and capabilities slows down to a trickle, because adding them takes longer and longer. Everyone on the team wants to keep going, and there’s a lot of frustration and tension, but the code seemingly begins to actively resist being changed. Every new bit of code breaks some existing behavior, blows up performance metrics, or other shenanigans.

Most useful software is born out of a bunch of hacks. Sometimes they are really solid hacks, and sometimes they are nearly literally scotch tape and popsicle sticks. And it makes sense. We want to go fast, get something in the users’ hands, and iterate like crazy, listening to what our users tell us. In the process, we accumulate hacks – also colloquially known as “accruing technical debt”. Sometimes, the hacks aren’t born as hacks. We might conceive of a rather elegant design at the start, but the contact with reality unveils our modernist naivete, and what seemed like a paragon of software engineering turns rapidly into an annoying vestige – now covered in hacks.

At some point, the hacks congeal into a solid mass that becomes nearly impossible to reason about. Veteran engineers will stare carefully at the code and move with artful precision, only for the code to laugh back at them. Often, crossing into the Plumber Age happens rather suddenly, almost like being locked out of the house. It feels like just yesterday we were able to land new bits and then – bam! – a Cthulhu is staring back at us through our code editors. The pile of hacks filigreed into a tangled network and now, this network transitioned into its next phase.

Enter the Plumber Age. When embraced, this season is marked by the emergence of the demand for, well, plumbers. People who enjoy (or at least tolerate) moving the code around become more and more common – and sometimes prominent – within the organization. The nature of the project changes. That crazy idea of tests and test infrastructure, previously mostly ignored, is considered a critical investment. Talk of build and development metrics crop ups everywhere. Words like “services” and “layering” start showing up in everyday work conversations. Plumbing becomes a full-time job, and there may even pop up a team whose job it is to maintain and modernize some stable “core” of the software. They allow other teams to continue to move forth with feature and capability development.

Most interesting to the leaders of an organization that needs to embrace the Plumber Age is the change in how the teams are structured. The loose and free-spirited flat setup that works so well to get our enterprise going becomes a hindrance. In the Plumber Age, code ownership and clear delineation of roles and responsibilities becomes a necessity. Hierarchies and RACI matrices start popping up all over the place. This may give us a queasy feeling – are we becoming a rigid bureaucracy?! Not necessarily. If we are to continue on this path and keep increasing the user value of our software, a more structured organization is needed. How carefully and thoughtfully we structure it is up to us. My intuition is that it is the fear of becoming bureaucratic that actually turns engineering organizations into bureaucracies. Adding more structure intentionally is not bad. However, pretending to not be bureaucratic will guarantee the feared outcome.

Some organizations try to reject the Plumber Age, and attempt to skirt around it in various ways. Few build second systems, and are rarely heard from again. It’s hard to see all the miracles that led our horrifying pile of hacks to become a successful first system. Others push brashly forward, chewing through talent and becoming more and more challenging to move – until they keel over and die. There are probably other paths and combinations, each leading to similar outcomes.

My guess is that the Plumber Age is inevitable. It is something that every team will encounter in due course. And just like the seasons, it is best experienced when prepared. This does not mean that each new team must start with a thoroughly designed infrastructure or hire a cadre of plumbers. That’s a whole other trap that I will save for later discussion. However, as the team starts to feel the lift of successful engagement with its users, it needs to anticipate the transition. Start having regular conversations about architecture and layering. Draw sketches of where the core of the system begins and feature work ends. Consider how features and capabilities can be added without affecting the core. Think about how the team might be structured. Are there tech leads emerging who could lead the sub-teams? Oh yeah – almost forgot: teach your code to be testable. All of these will come handy, kind of like those coats and hats you’re storing for winter.

The Starship of Theseus

This framing of the Starship of Theseus has been on my mind for a little while, and I finally decided to write it down. Basically, in a marketplace with any sort of selection pressure, organizations vie to both retain their identity (what makes them the organization) and adapt to changing conditions. A possible path to resolving the tension of these two opposing forces – stay the same, yet evolve – is aptly described by the “Starship of Theseus” analogy.

In FLUX issue 51, we had this really nice riff on the Ship of Theseus experiment. If every part of a ship is eventually replaced, is it still the same ship? Or something entirely different? 

The “Starship of Theseus” kicks the experiment up a notch. What if, in addition to replacement of parts as part of the routine maintenance, the process must incorporate improvements?

In this metaphor, the ship is seen as a collection of capabilities. Some of these capabilities are transient and some essential. Transient capabilities can be substituted for other, different capabilities without affecting the distinguishing quality – the “shipness” – of the ship. Conversely, essential capabilities are those that constitute this quality. Exchanging them for another capability means destroying the Ship of Theseus.

For instance, we can confidently state that the hull, crew quarters, and navigation are essential, while the material of which the hull is built or its particular shape are transient. Yet some capabilities that we thought of as essential are revealed to be transient in due time. We might believe that the proud sails of the Ship of Theseus were its essential capability for many generations. When the vessel is finally fit with the powerful steam engine, we recognize that the sails were transient.

To keep the ship afloat and continuing to fulfill its purpose in the changing environment, we must continuously replace its obsolete transient capabilities with more technologically advanced alternatives, while preserving and maintaining the full efficiency of the essentials. If we are successful, the steam engine is replaced by a diesel one and later, a nuclear reactor, while the hull graduates to steel, with aluminum not far behind.

Technological progress guides our understanding of what the essential capabilities are. And conversely, this understanding is guiding the evolution of the ship. A repeatedly, doggedly asked question: “What are we really about?” spurs the transformation. We resolve the tension of “stay the same while evolving” through a dynamic inquiry: the answer to this question changes over time.

If we initially thought our particular “shipness” was about the number of masts and a distinctive figurehead, we revise our answer as we adapt. And a couple of millenia later, it is the spirit of frontier exploration – the unchanged essence of our ship – that compels us to take the vessel to the stars.

Here’s my guess. Intentionally or not, any large organization that perseveres through time follows the pattern described by the Starship of Theseus story. And I wonder: would such an organization benefit from leaning into this pattern more consciously?

First, this dynamic nature of the inquiry tells us that we do not have to know the ultimate purpose of our ship. Put it even more forcefully, we must not try to have the essential capabilities captured and solidified, for an organization that knows with certainty what it is about has already sealed its fate. It will never get to orbit, let alone see other galaxies.

Second, we might be better off viewing a portfolio of our capabilities as something that will evolve over time. At any given time, we also might want to have a good sense at which capabilities are essential and which ones are transient. This sense would need to be grounded in an understanding that the essential/transient breakdown will change over time.

Third, it would have to be our collective responsibility to think in multi-year timelines. We must dream of starfaring even when we’re still powered by sails. Unlike a static vision, the vision formed as the question – “How will we go to the stars?” – can adapt to the changing environment in productive and inspiring ways.

Strategy and FOMO

There’s this really fun neologism that the cool kids use: FOMO, or fear of missing out. It’s a useful snapshot of feelings we experience when our friends are doing something awesome and we are somehow left behind, literally or figuratively. I found that it can serve as a useful handle in strategy work as well.

It seems that organizations collectively experience FOMO. There is a lot of amazing, disruptive innovation happening out there in the world. In the information-dense environment, new and possibly groundbreaking stuff shows up in our various feeds every day – and sometimes more than once a day. Is this the next big thing? Or just hype? How do I know? Strategists fret every day, taking a mental diff between their organization’s course and the potentially significant new thing that just dropped in the Twitterverse. At the age we live in, the fog of uncertainty creeps up the runway of business.

For teams with a narrow cone of embodied strategy, spotting that new significant thing early feels ever more important. Given the limits of motion, a lot of time and effort needs to go into shifting trajectories if that suddenly becomes necessary. The lead times on change are long. So… Was that it? Did we miss the turn? Are we too late? FOMO intensifies.

It is my experience that, just like with us humans, organizations are better off creating space between their feelings and the actions that follow. 

In itself, feeling fearful about missed opportunities is not a bad thing. It implies that we have enough awareness of the different possibilities and – perhaps implicit – practice of playing out various scenarios. This is all good stuff, and any strategically-savvy organization will (and must) have a bunch of people worrying about the future.

However, where things typically get sideways is when we, spurred by our fears, are compelled to act. FOMO tends to trigger a spectrum of reactive patterns. For example, after seeing a new potentially big thing emerge, we might decide to immediately start building an alternative that rivals it. The reactive patterns are rarely rooted in rigorous strategic thinking. Instead, the urgency of the moment causes the organization to fall back onto its embodied strategy. The outcomes can still be favorable, but they will have more to do with luck and brawn, rather than clarity of thought.

However, if we choose to take a collective breath and pause between the next onset of FOMO and our habitual reaction, we can create a space where new, yet unseen opportunities can emerge. In this space, we need to ask – sometimes fighting down the urge to “just jump” – ourselves fairly basic questions, like “what are our capabilities and strengths that might intersect with this new emerging thing?” and “what are the surrounding areas into which the momentum may expand?” and “what are the second order effects of this momentum? What happens when the hype cycle concludes?” 

These questions may require some extra effort to answer honestly. But in my experience, the answers they bring reveal insights that could help our team plot a path that is not an instinctive response. And hey, it might still go up in flames. But at least we won’t be backing into it without looking.