What Dimitri Learned – Page 11

Customer-Vendor Loop

I’ve been sketching a bunch of compounding loops this week, and wondering if I am seeing a pattern. I am calling this figment of my imagination the Customer-Vendor Loop. I am not great at clever names. I briefly named it Maker-Taker loop, but after sleeping on it, decided to go with something more prosaic.

Before the pattern jumped out at me, I was playing with a convention for drawing a compounding loop. This convention insisted that when we document a loop, we draw it as a causal chain that contains the alternating sequence of nouns and verbs. I drew nouns as boxes and verbs as arrows. It’s that far from how we describe causal chains in English. “A confectioner makes ice cream, which attracts customers” follows the convention above quite nicely. Some of these nouns are people and others are things that people produce. Following this convention, we can now string more causal chains like “customers pay money, which supports the confectioner”.

Ka-blam! The money that the confectioner collects closes the feedback loop. However, whether or not this loop is compounding is not yet unknown. What would make this loop compound? Well, if the ice cream turns out exceptionally delicious, it attracts more customers, and perhaps the customers would be willing to pay more money, allowing the confectioner to make more ice cream. Every iteration of the loop begins to compound value and the cycle becomes virtuous.

Loops like this are always interesting, because each of their components tends to interact with another. If the ice cream is not that great, there will be fewer customers, attracting fewer customers, bringing less money to the confectioner, thus turning the cycle vicious. The causality remains the same, but the loop is no longer compounding. There’s still feedback, but it doesn’t accumulate value.

As I mentioned earlier, drawing a few of these revealed a general pattern. There are usually two parties: Customers and Vendors, who each produce two artifacts, each potentially interesting to the other party. In the case of our ice cream parlor, the two parties are 1) the confectioner and 2) the customers. The two artifacts are 1) ice cream and 2) the payment of money. Each artifact is produced by one party and is attractive to another party.

To turn it into a template, visualize a loop that consists of four boxes: Vendors, Products, Customers, Interactions. There are four arrows that connect them: Vendors make Products, Products attract Customers, Customers engage in Interactions, Interactions attract Vendors. This template basically asks four questions:

Who are the Vendors?
What are the Products they make?
Who are the Customers?
What are the Interactions that they engage in?

In different environments, the boxes and arrows will have different names. In a marketplace, it might be Sellers, Listings, and Buyers. When applied to services, it could be Provides, Services, and Consumers. For the software engineering team, I will use Developers, Products, Users, and Interactions, though the pattern remains the same.

For a typical engineering product team setup, filling out this template should be fairly straightforward. Our team is the Developers. Our shipping product is the Product we make. Our product’s users are obviously Users, and the Interaction is the outcome of our users’ engagement with the product, which will depend on the nature of the product.

The customer-vendor loop contains a few useful insights. First, it asks us to separate nouns and verbs, because action is something that can be influenced, while the noun is the outcome of the action. In the language of System Dynamics, verbs are flows and nouns are stocks.

To understand the state of the loop, we look at stocks (nouns). To find ways to influence the loop, we look at flows (verbs). For example, DAU will tell us about the state of the Users stock. To improve the quality of the product we ship, we must change the way we build it. If you are familiar with the OKR system, you can view Os (objectives) as our tactics to influence flows (verbs) and KRs (key results) as our means to measure stocks (nouns).

Second, Developers have direct agency only over the verbs adjacent to them: “attract” and “build”. There are two other verbs that can only be influenced indirectly. When a team commits to building great software, they assert that they will do their best to accelerate the flows they have agency over. This may or may not be enough to turn the customer-vendor loop into a compounding one.

Third, the two “attract” arrows are significant. The one that points at Users makes intuitive sense. After all, the whole notion of attracting users is fairly familiar to us. We promote our software, make it seem cool in commercials, we build reputation, and/or make onboarding as easy as possible – these are all familiar methods by which we attract users.

The arrow that points at the Developers needs a bit more discussion. How do Interactions attract Developers? In the simplest scenario, an interaction is a purchase of some sort, which makes the attraction obvious: revenue from purchases supports developers and funds further development.

However, there are many teams where the presence of this arrow is not as clear. What is the nature of the attraction for peeps who contribute to open source projects in their free time? If a team ships a free library, how does it close the loop? What is the source of energy that keeps them going? Answering these questions seems important, since if there is nothing that keeps developers coming back for the next iteration of the loop, there’s no feedback loop. Yet somehow, they continue to exist. What’s happening?

Puzzling over this often hard-to-see closure has been a really a really fun challenge, and I’ll keep you in the loop (ha!) on what I learn from the adventure.

Continuously Integrated Strategy

Here’s a possibly useful analogy when talking about strategy work with engineering leads.

It is considered a poor practice to write code without testing. No matter how brilliant we are as engineers, the bugs we produce will sooner or later have to be addressed. There’s even a practice of continuous integration, which encourages that every change, no matter how small, is to be tested as part of being accepted into the shared code repository. As engineers, we write code all the time – and continuous integration helps us account for all the intended and unintended behavior changes we cause while doing so.

Somehow, these amazing ideas don’t seem to extend to strategy. In the same engineering organizations, we appear stuck somewhere at the late stage of the waterfall model. There are annual cycles of strategic planning that march forward for a few months, culminating with docs and slide decks that inform organization’s leaders on where to focus and what investments to prioritize. Don’t get me wrong – these are often useful exercises. I remember the first earnest SWOT analysis I’ve gone through with my colleagues and the (alarming) clarity it brought. However, don’t they seem a bit like a throwback to the early days of software engineering? You know, the time when we still believed that we can ship perfect software if we just planned it hard enough?

Putting it somewhat bluntly, the brief annual focus on strategy feels awfully similar to New Year’s resolutions – all but forgotten by mid-January. Worse yet, the annual cycle naturally confines the perspective. Why think a few years forward when we’ll be doing this again next year? And who has the time? So, our strategic foresight ends up being crimped to a year – if that.

Lastly, the environment around us rarely stays in place. Even though our intentions may remain firm, how we see problems ahead of us changes all the time. When we sketch out our first draft of strategy, we actually know very little. Every step we take teaches us new things, and potentially – no, definitely – affects how we approach the situation. Just like in writing code, every action we take contains unexpected side effects. If we only account for them once a year, our strategies are unlikely to be useful. They aren’t just limited in time – they are also frozen in it. So we engineers just whiff on strategy work. Why waste any more time than absolutely necessary on a useless artifact? No wonder strategic planning exercises are usually just planning.

Perhaps we could choose to do something different? What if, borrowing from our well-learned engineering tricks, we reframed strategy as something that is practiced continuously, and developed a habit for that? Strategy is like writing code. It’s just a guess that mutates as soon as it begins interacting with reality. Why not give our strategy the same respect that we give to our code? What might a continuously integrated strategy look like?

These are the questions I am looking to answer. Take the same SWOT analysis as an example. I am playing with the idea of a “SWOT garden”, where SWOT is no longer something we do as a one-time thing, but rather keep updating as we recognize new threats, opportunities, weaknesses, or strengths. SWOT gardens live and are cultivated. When a new threat is encountered, we add it to the matrix and check to see how it fits with other threats, and reframe them as necessary. We also evaluate to see if the newest addition sheds light on other bits: what are our strengths and weaknesses that make up a threat? What are the opportunities that might exist alongside it?

I hope the SWOT garden concept makes sense. As a benefit, we get to have a continuously improving picture of the key challenges that our organization faces. And once we understand these challenges, we are in a much better position to make proper diagnosis, which will in turn help us iterate on our guiding policies and coherent sets of actions that follow.

Midjourney

I recently got an invite to play with Midjourney, one of the AI-generated art tools out there. It has been a fun adventure, and I am learning a lot. Here are some insights that goofing around with Midjourney produced.

First, I am very impressed with how they leaned into the power of Discord. Until this point, I suspected, but didn’t fully grok the importance of Discord as a developer platform. Midjourney relies on it for authentication/authorization, key workflows, cross-ecosystem reach, and obviously, community-organizing.

When I joined Midjourney, I was dropped into a Discord server alongside other newbies. Operating Midjourney is super-simple: just type the “/imagine” command with a prompt of your choosing into the channel. The result is a four-panel set of choices, arranged in a 2×2, with choices (as buttons) to create more variations for each choice or upscale them. This creates a rather simple, yet effective mechanism of steering: I can either tweak my prompt or iterate on the variation.

I found myself swimming in generated art, prompts constantly produced by my fellow mid-journeyers. The creativity was all abuzz and inspiring, with some folks trying to prevent their “Kermit meets the Governator” from melting , and others zeroing on just the right kind of perfect dystopian landscape. For some reason, Midjourney excels with post-apocalyptic and gothic art, as well as other kinds of unsettling visage.

Once I used up my allotted free computing power, I decided to subscribe, and found that once I became a paid user, I gained my personal Midjourney bot to interact with privately. That was a rather clever move: using Discord infrastructure to create tiers within the community. All in all, the way Midjourney uses Discord has that “just enough” kind of feel for this sort of a project. I can easily imagine myself trying to write a standalone PWA (or cross-platform app), struggle with authentication and ACL design, etc. It sounds like Midjourney folks asked a reasonable question: “do I need any of that?” – and gained strong community management tools in the process.

Second, after running up quite a bill with different prompts and steering the variants, I am hopeful that this kind of generative art is on its way to be the new creative medium. With Midjourney, I have this intuition that I am witnessing the birth of the next TB-303, a crappy toy bass synth that redefined dance music. It is usually these simple toys that dramatically lower the threshold of entry for people to create new, interesting things – and serve as catalysts for the new wave of cool stuff that inspires generations to come.

It is not a stretch to imagine that muzak and clipart will be generated using this method in the near future. “Want 5 hours of chill lobby jazz? Here it is.” It only takes a bit of squinting to see tools like Midjourney do a half-decent job here. What also seems likely is that in addition to prompt-tweaking and choosing four variants, there will be demand for more nuanced sculpting and crafting, guiding the generated art tooling. And once that becomes available, it is inevitable that new forms of art will emerge. I can’t help but be excited about the possibilities here.

To convey what I was seeing, here are some actual journeys to give you a sense of this tool. I asked Midjourney to imagine “What Dimitri Learned”. Initially – and somewhat in line with my expectations of its biases – Midjourney went straight into the Game of Thrones fanfiction territory:

Umm… Maybe save that one for when I decide to write a young adult novel? Imagine that, “What Dimitri Learned” is a fantasy novel about a forlorn young protagonist with a budding fire-starting superpower. Yeah. So I tweaked the prompt to be a bit more upbeat. Here’s the “What Dimitri Learned, optimistic” outcome:

Nice! But still, the 18th century Eastern Europe feel was not quite what I was looking for. After playing quite a bit, I ended up with this second-generation variant of “What Dimitri Learned, futuristic, optimistic”:

Alright, this I can get behind. A bit too techno-futuristic for my taste, but I’ll take it. To give you a sense of how this particular journey in the visual eigenspace progressed, here’s a handy chart:

The whole experience felt like a glimpse of something much bigger. There are definitely terrible downsides, and even thinking about them makes the hair on my neck rise. There are also possibilities for something beautiful. It is so uncanny how these two always come in pairs.

Blueprint, Compass, and Remodeling

Reflecting on some vision work that I’ve been doing recently, I am realizing that I can inhabit two different perspectives, two different mindsets to approach a vision: vision as a blueprint and vision as a compass.

With vision as a blueprint mindset, I tend to treat the imagined future as a sort of grand schematic of what needs to be created, an architectural plan to be executed on. Taking this mindset feels very clarifying. I can start staking out the ground and budgeting resources, I can plan timelines and craft processes around it. Vision as a blueprint can be an amazing source of organizational coherence. Provided the communication limits have been overcome, it can serve a clear intention that the team checks their work against. Metrics are easier, because they measure completion of the work, captured by the blueprints.

With vision as a compass mindset, my perspective shifts. I no longer see the vision as a grand plan, but rather as one potential future among many other possibilities. The only thing differentiates this particular potentiality from others is that it has some properties that I hold as valuable. These properties can come together in other combinations, forming a different vision, but this is the one I was able to discern while staring into the future. This mindset encourages me to remain open to the outcomes and allows a lot of flexibility in how to get there. Compass points toward something, but doesn’t plot the path. It is okay to deviate from where the compass arrow points for a little while, to walk around obstacles or explore unexpected treasure troves. When in this mindset, I tend to seek “preferred adjacent possible”: what is the change I can make today to things I am doing now to orient toward the vision?

Both mindsets have unproductive extremes. When in the blueprint mindset, I can fall into the NIH trap (or its cousin, “second system” trap), deciding that it will be easier to just start making the future from scratch. As an engineering lead, I might be tempted to start a new team that follows the vision’s blueprints, separating it from the team that maintains the boring old present. This can work pretty well in environments where the blueprints can predict the future with reasonable accuracy. After all, many engineering artifacts are based on blueprints. However, the environments that shift and change can invalidate the blueprints mid-build, turning the whole enterprise moot. By assuming predictability of the environment, viewing vision as a blueprint can lead to blind spots that doom it.

On the other side of what increasingly looks like a spectrum, the compass mindset can get me in trouble with its flexibility. Especially in large organizations, if everyone is walking around obstacles and exploring interesting caves, the path to vision may fail to converge. Worse yet, the sense of divergence itself can get rather uncomfortable. With the answer to “where is this all going?” getting blurry and anxiety rising, the organization may tip into the traps of adversarial adaptation variety. By assuming unpredictability of the environment, viewing vision as a compass can doom it by decohering the organization.

To help navigate this spectrum of mindsets while avoiding the extremes, I came up with this analogy of remodeling. Think of it as a third mindset that straddles the other two. Remodeling a house is usually a rather weird hybrid of the certainty of knowing what we want and the unpredictability of what will be uncovered during the remodeling process. The wall we thought was load-bearing may turn out to be free-standing, the beams in the attic may have all rotted out (true story!), yet tearing out the scuffed and dented linoleum reveals beautiful hardwood floors. When we remodel, we have to dart back and forth between the blueprint and the compass mindsets. We have to continuously reinterpret the vision as new evidence is uncovered.

Additionally, we are rooted in what’s possible. When we commit to a remodel, we don’t start from scratch. We think in diffs. Where will this beam have to move? What additional foundation will have to be poured? Where will the new window be cut in? When we think in diffs, we need to also consider what stays the same. Which parts will we find unchanged after our vision comes true?

My intuition is that this combination of thinking in diffs and reinterpreting the vision creates a bit more space for thriving in uncertainty while still imposing the boundaries of the blueprints. I’ve been looking for an example of a remodel mindset, and found myself coming back to the I/O talk that year that my colleague Alex Komoroske and I gave back in 2012. We pretended to come from the future, describing how the Web development will look like. Now that that future is in the past, it is easy to see that the vision was reinterpreted throughout the journey. Most of the technology bits we demonstrated evolved significantly in their syntax and names. However, if you look at them now as they ship in all browsers, you can clearly see the ancestral resemblance. Similarly, we thought in diffs. The talk didn’t propose a brand new language or dramatically different new ways of building Web applications. We just moved some walls and added a kitchen nook, leaving most of the sound foundation intact – making the vision more relatable and easier to reason about.

Stakes

This is not as well-formed as it could be, but felt worth capturing. I’ve been struggling to describe the limit of attachment in various ways, and the concept of “stakes” seems like such a good topic to explore.

There’s something about the phrase “a high-stakes situation” that paints a vivid picture of a stressful encounter. When stakes are high, we are alert, anxious, and ready to act. When stakes are low, we’re relaxed, chill, and maybe even bored. But what are these “stakes”? Where do they come from?

Trying to orient the concept within the problem understanding framework, I characterized stakes as the degree of our attachment to an intention. I am loading a few things into this burrito of a definition, so let me try to unroll it.

First, stakes are associated with an intention. In a world without intentions, there aren’t stakes. This seems important somehow, given that every intention represents a problem. Stakes are how we measure the significance of us finding a solution to this problem. It doesn’t matter if we find solutions to low-stakes problems. It matters a lot for the high-stakes problems.

Second, my use of the word “attachment” indicates a particular kind of limit of understanding being tested. The higher the stakes, the less likely we are to incorporate disconfirming evidence into our model and adjust it. When stakes are low, our limit of attachment is no longer impacting our process of understanding. For example, a brainstorming session or a generative meeting usually requires a low-stakes setting.

Why is it that we are attached more to some intentions and not others? Let me introduce a kind of intention that I’ve touched on briefly when discussing homeostasis: the intention to exist. The existential intention is something that comes built-in with our wetware. Even before we are capable of forming a coherent thought, we already somehow have the most primitive mental model that includes a “what is” with us in it, and “what should be” with us continuing to be in it. We are born into solving our existential problem.

My guess is that this existential intention is something that undergirds most of our intentions. Put differently, stakes rise when any of the mental models we contain start predicting outcomes with us not existing. Remember the predator wanting to eat me in one of the earlier posts? That’s a high-stakes situation. One of those “what should to be” outcomes had “me” replaced with “meal”.

Existential intentions have a firmly fixed “what should be” that is non-negotiable, which makes them a source of distortions to the rest of our mental models. Bumping into the limit of attachment will tend to do that. Especially in the early stages of our development, this can lead to our mental models getting to seriously weird states. A way to think of psychology might be as the entire discipline dedicated to untangling of the mental models tied in vicious loops of adversarial adaptation within one person’s mind.

Because of these distortions, existential intention often gets in the way of living joyfully. For example, whenever I feel nervous before speaking to a large audience, I am likely experiencing some entanglement with existential intention. Somewhere in the depth of my brain, there’s a mental model in my mind that is making a literal existential-scale prediction: that perhaps I may be mauled to death by the audience or some absurdity of the sort. Usually, the mental model takes several hoops before arriving at “and then I will die!” and may include classics like “everyone will laugh at me” and “this will be the end of my career” and “my family will disown me and kick me out to the street” so on. It may be only a teensy-weensy part of the overall mental model, a part that is easily overwhelmed by other, more mature and confident mental models. But the mere fact of me feeling nervous tells me that it’s there – freaking out and trying to avert my imminent demise.

Because our mental models are developed individually, we all have our own unique configurations of existential intention entanglements. Situations that are high-stakes for some may be totally chill for others. Though socialization brings a degree of sameness, our evaluation of stakes remains deeply personal. For example, when creating a low-stakes environment for a generative conversation, we may mistakenly presume that an environment works for us will for all of the participants. I’ve made this mistake a whole bunch of times. The best approach I know is to manage the stakes dynamically, staying aware of the participant’s engagement and helping them navigate their tangles of existential intentions.

Organizational cartography

I’ve been thinking about how to represent the important bits of the current state of an organization, and here are some preliminary musings.

My sense is that the artifact will be a map of sorts, designed to serve as a snapshot of the structural “what is” in the larger process of discernment of the organization’s sum vector of intention.

For the purpose of this story, by “organizational structure” I mean a detailed enough representation of the organization that allows an observer to understand how the organization sustains and grows itself. In other words, what comprises this organization’s motor?

Suppose there’s a thriving team that is riding a typical developer ecosystem compounding loop: attaining some critical mass of users, the ecosystem attracts developers who build products and services that in turn attract more users. If we study this team, we will probably find a part of it that cares about sustaining and growing the segments of that loop. There may be some folks whose responsibility it is to ensure that developers are excited to join in and stay. There may be some who work on maintaining a high quality bar of these products, so that they are attractive to the users. There likely will be those who are asked to help bring more users to enjoy these products – and so on.

Given that this team is thriving, the various units within it collaborate effectively, forming its structure. Using maps as an analogy, this structure is sort of like the terrain: the rivers, roads, and mountain ranges. They aren’t something that we imagine to exist, but rather have to exist, since we can clearly observe their effects.

At first, I thought finding these units would be just a matter of looking at an org chart, but it doesn’t seem to be the case. Several times now, I’ve recognized this pattern where the reporting charts reflect more of an emergent outcome of operational convenience, rather than represent its structural underpinnings. Org charts are akin to the administrative boundaries on maps: cities, counties, and districts.

In the example above, there may be the growth team, the product team and the infrastructure team in the org chart. These boundaries help immensely with managing resources and priorities. However, they say almost nothing about the nature of the compounding loop. There might be one group in the org chart that actually contains several structurally significant units, or conversely, multiple org chart groups that are actually one unit. Just like in topography, rivers can cross districts and a county may span multiple mountain ranges.

There tends to be a temptation to shoehorn structural units into administrative or vice versa. I’ve tilted at this windmill myself. If you worked on the Chrome Web Platform team in 2016-2017, recall the ill-fated “Programmification” project. I still cringe when I think of the matrixed-org diagrams I drew with that unhealthy high-modernist sheen in my eyes. Often, it is more productive to simply accept that structural units and org charts are two different things – and stay aware of the difference to not accidentally conflate them.

It also seems clear that the terrain and the administrative boundaries are not orthogonal to each other: they interplay. Watersheds often define county lines. Streets are organized into rectangular grids. Similarly, org charts both impact structure and attempt to reflect it. Conway’s law hints at how seeking operational efficiency may – often unintentionally – influence the overall intention of the organization.

When a leader is looking to get a big picture of the organization, what they are probably asking for is a map that shows both the terrain and the administrative boundaries, and highlights how they play off each other.

So the question I am facing is: how do I map the terrain within an organization? The org charts are accessible and convenient, yet the structural units are typically less so. I am still at the early stages, but my intuition is that this will be an iterative process. I am planning to arrange it as a dance between three parts: the org chart, the list of compounding loop hypotheses, and the list of structural units.

The org chart is basically an anchor among the three, with the other two developing through iterations. The dance goes like this: using the org chart as a guide, populate the compounding loop hypotheses list with some initial values. As best as we can discern, write down the hypotheses for organizations’ compounding loops. There may be more than one, some that are quite clear (for example, “this is where most of our revenue comes from”), and some so vague that all I can do is speculate that they are there.

In parallel, rely on the org chart to spot units. I am still working on a decent rubric here, but it feels like it will be something like this: look for groups that do something different from the rest of the team. In engineering teams, they might have different codebases or bug labels or components, different processes, release targets, and/or priorities. They would typically (but not always) come with a sense of identity among its members – a sense of togetherness that can survive the reorgs and changes in leadership.

A good marker that I am looking at a structural unit is that once it exists, any attempts to break it apart face strong headwinds. This is likely because it is a load-bearing part of the organization, and mucking with it tends to shift what organization does. Drawing an administrative boundary over the river does not stop the flow of water, unless we put a lot of effort into building a dam.

As another possible source of insight, talk to the team veterans. People within the organization tend to intuitively know this structure. They know where structural boundaries are drawn and don’t need the map to navigate them. This is tacit knowledge and something every new member has to learn.

Once the first pass for creating both lists is complete, the next step is to stare at both of them for a while and try to match the units to the compounding loops. Which unit seems like a segment of another? Which unit looks like a part of a compounding loop yet unlisted? What units should be there but aren’t on the list?

This process is likely to yield more questions — and optimistically, the questions that are more interesting — that I can use to spelunk the organization in another round of this dance. Fingers crossed, after a few iterations, the lists of hypotheses and units settle down, revealing the terrain. What do you think? Would this work? I’d love to hear your suggestions. And I keep you posted about this adventure of organizational cartography.

Intentionality and meaning

So far, I’ve been talking about intention as a fairly straightforward, singular thing. I have an intention, you have an intention, the bunny has the intention, and so on. As you probably suspected all along, this is at best a gross simplification of “spherical cow” proportions. I am pretty sure I can’t describe the full complexity of what’s actually happening. But here’s a story that tries.

We live in a world teeming with intentions. We are surrounded by them, we are in them, and they are within us. Intentions permeate us. Many (most?) of these intentions are not easily visible to us. When I was discussing mental models, I used this image of a massively multi-process computer, which might come in handy here. Imagine that our consciousness is a lone terminal connected to this computer. This terminal can only track a tiny fraction of the intentions at a time. Most of them exist in the background, without our awareness.

It would be nice if our intentions operated on some unified model of “what is” and “what ought to be”. But no, turns out that is way too much to ask of a good old human brain. Since mental models are diverse and inconsistent, they produce a dizzying array of intentions pointing in all different directions, creating tensions and friction amongst each other.

Sometimes we feel intense suffering of two internal intentions being at odds with one another — and it may take years to recognize that the conflict was entirely due to mental model inconsistency. We may even recognize with sadness that the intentions that caused us so much suffering were one and the same, just viewed through the lenses of two mutually inconsistent mental models. Worse yet, a particularly severe tension might trigger adversarial adaptation within ourselves, where two intentions form entire conflicting parts of us locked in a battle. Through this lens, bad habits and addiction are bits of the infinity-problem sprinkled onto us.

It’s like we are these cauldrons of intention stew, spiced with infinity. In this stew, intentionality is the practice of observing our own intentions, orienting them in relation to another, and deciding to act on some and not others. This description might trip something in your memory: these are the steps of the OODA loop, known also as the solution loop. And if there’s a solution loop, then there’s definitely a problem lurking about. What is this problem that the practice of intentionality aims to solve? Why would we want to understand our own intentions?

It is my guess that the problem behind the practice of intentionality is the problem of meaning. This is a big leap, and I am in a thoroughly uncertain territory here. I am definitely intimidated by the largesse of the topic I am gingerly stepping into. Yet, it seems useful to imagine that the more our internal intentions are aligned with one another, the more meaningful our lives feel to us. Conversely, when intentions within us are less aligned, we experience loss of meaning. Put differently, a sense of meaning in our lives is proportional to how well we can navigate the multitude of our internal intentions.

If we believe this, the crisis of meaning that many adults encounter in the second half of their lives might not be due to the lack of intentions, but rather due to their overabundance. If I lived long enough, I would have accumulated a great cache of mental models over the years. And if I didn’t practice intentionality, that would necessarily leave me with a boiling soup of intentions. The sense of being lost and without purpose emerges from every single intention seemingly conflicting with another, like a giant ball of spaghetti. What is up with all the food metaphors? I guess it’s spaghetti soup now.

Building on that, if I imagine an environment where compressed mental models are abundant and easily accessible, the crisis of meaning might be something that arrives much sooner than middle age – and becomes much more pervasive. Rapid acquisition of mental models without accompanying intentionality seems like a recipe for disaster. In the age where knowledge is so easily acquired, teaching intentionality becomes paramount.

If I click the zoom level up from individuals to organizations, I can see how the same applies to organizations. The challenges of coherence that manifest in large, mature organizations might be the result of an overabundance of individual intentions (teams, sub-teams, people, etc.) that do not add up to a single intention that brings the organization together. It is that intention that can only emerge through a rigorous practice of intentionality – both within the organization and individuals that comprise it. We can call this practice by many different names – be that self-reflection, mindfulness, or strategic thinking – but one thing seems fairly certain: without mastering it, we end up in a crisis of meaning.

A vision and a hallucination

Talking with one of my colleagues, we found this simple lens. We both arrived independently at the idea that one of the strongest ways to instill coherence within an organization is aligning on some more or less unified intention. After all, organizations are problem-solving entities. And as follows from the framework I’ve been going on about, intention is the force that brings an organization together. Put differently, emergence of an organization is the effect of imposing an intention.

How might this intention be communicated? We picked a well-worn concept of the “compelling vision” to play with. The distinction that we’ve drawn is that some visions, when articulated, appear to enroll everyone to align with the intention they communicate. And some visions come across more like hallucinations: we hear them and may even be fascinated by them, but little alignment in intention materializes. My colleague used Yahoo’s “get its cool back” from a decade ago as an example of such a hallucination. Some good things did come out of that endeavor, so there’s likely a spectrum rather than a binary distinction.

So what makes one story a vision and the other a hallucination? I am sure there are many possible explanations. I, however, want to mess with the newly-derived limits framing to explore the question.

To be compelling, a vision must be posed as a solution. That is, a vision is a prediction that is based on an understanding of some problem. A resonant vision captures the full mental model of the problem: the “what is” and the “what ought to be”, as well as a plausible path to the latter. Thus, communicating a vision is an attempt to share the mental model.

It is in this process of communication that the vision’s fate is determined. We share mental models through stories. And when telling such a story, the one who communicates it must overcome all three limits to understanding these mental models — both their own and those of their recipients.

To overcome the limit of capacity, I need to ensure that the story matches the mental model diversity of those I am sharing it with. There is a distinct upper and lower bound. The mental model behind the story needs to be within the limit of tolerance: not too complex and not too simplistic. If I tell you that my vision is that “we must do good-er”, you may recognize that my mental model diversity is lower than yours, turning my vision into a hallucination. Conversely, if I write effusively and at length about animating forces, lenses, and tensions (as I regrettably do), the mental model will bounce off of you, suffering the same fate. The limit of capacity is about the balance of clarity and rigor.

The limit of time manifests as the plausibility of the vision. We notice this limit when we see the “5-year” or “10-year” qualifiers attached to vision docs. When I communicate the vision’s story, I must have a sense of when this vision will come true. On their part, the recipients of the story, once they acquire the mental model behind the vision, will intuit its feasibility. They may go “yeah, that feels right” or balk at the overly ambitious timelines. I once suggested at the leads offsite that a product that hasn’t even shipped will have one million users next year. My colleagues were nice to me, but I was clearly hallucinating. A good way to remember this limit is to imagine me painting pictures of some clearly impossible future and folks quietly rolling their eyes.

The final limit — the limit of attachment — is the trickiest. Suppose I’ve told the story clearly. You get exactly what I mean, and see the respectable depth of the mental model. You also see that my vision is plausible. Yay! We overcame the first two limits. But… is it where you want to go? Imagine that, in playing with this mental model, you recognize with dread that pursuing it would negatively impact your career or perhaps compensation — or both. Or you might see some effect on the environment or surrounding community that is in conflict with your principles. Does my story contain room for flexibility? And if not, how might you work around it? In communicating our vision, we encounter the limit of attachment as the resistance to change – and always, always, any alignment of intentions means change.

It is here where the visions most commonly transmute into hallucinations. No matter how well-articulated and rigorous, no matter how plausible, if we are firmly attached to our particular outcomes, we won’t be able to align our intentions toward some common goal. What’s worse, there is very little that I can say in my story to overcome this limit. The limit of attachment is a structural property of the organization.

Lisa Laskow Lahey and Robert Kegan called this limit the “Immunity to Change”, and it is my intuition that most organizations and leaders have only vague awareness of it. My guess is that the limit of time is the best-understood of the three, while the limit of capacity is the one which most strategy-minded folks get exhausted and burned out overcoming. The limit of attachment shows up spuriously in conversations here and there (usually characterized as “politics” and “shenanigans” or “this team getting mad at us”), remaining almost entirely submerged in the vast subconscious of the organization. It is the embodiment of thousands of stories told and retold within the organization, a zombie horde against which no single new story stands a chance.

Limits

This story builds on the one I wrote a while ago, and adds one more leg for this stool. This third leg came as a result of examining the solution loop with the question of “What are the limits to finding a solution?”

This question has been on my mind ever since I wrote about infinity. Infinity and something very large, yet finite can be very hard to tell apart. I needed a way to make sense of that, so this additional module for problem understanding framework was born.

Looking at the edges of the loop one by one, I can see that our mental capacity is the limit for the number of possible solutions. In other words, the diversity of our mental models is limited by our capacity to hold them. The example of trying to explain calculus to a three-year old or adding yet another project to the overworked leader’s plate still works quite well here.

The limit of attachment becomes evident when we look at the rate of interesting updates to the model (aka flux). I will define attachment as our resistance to incorporate model updates. This one is a bit more tricky. When we’ve developed a model that works reasonably well, we start exerting effort to reduce outlier updates to the model to preserve the model’s stability. Often, we apply a comforting word like “noise” to these outlier signals and learn to filter them out. It is not a surprise that in doing so, we develop blindspots: places where the real signal is coming in only to be discarded as “noise”.

Limit of attachment naturally develops from having an intention. The strength of our intention influences how firmly we want to hold the “what should be” model. Some leaders have such strength of intention that it creates “reality distortion fields” around them, attracting devout followers. This can work quite well if the leader’s model of environment doesn’t need significant adjustments. However, high intention strength hides the limit of attachment. The mental model remains constant and the growing disconfirming evidence is ignored until it is too late.

The third limit is obvious and I am surprised I haven’t noticed it in retrospect. The edge between solution and outcome (what I called effectiveness) is limited by time. To understand how effective my solution is, I must invest some time to apply it and observe the outcome.

These three limits — capacity, attachment, and time – appear to interact with infinity in fascinating ways. When we say that the adversaries are evenly matched, we implicitly state that their limits are nearly the same. In such cases, the infinity asserts itself. While limits play a role, it is the drowning in recursive mental models that never reach a stable state that takes the center stage.

However, adversarial adaptation is no longer an infinity-problem if your capacity is significantly higher than mine. You can easily outwit me. Similarly, if you are able to let go of your old models with less fuss than I, you are bound to outmaneuver me. Finally, if you are just plain faster than me, you can outrun me. For you, it’s a solvable problem. I, on the other hand, will still be in the midst of an unsolvable problem.

Maybe this is why superior speed, smarts, and agility are much sought-after traits in conflicts. As an aside, capacity advantage seems to come in two forms in adversarial adaptation: both being smarter and just being more numerous. Both require the opponent to have significant mental model diversity, which pushes them against the wall of their limits. This quantity trick is something that we’ve all observed with insects. A couple of ants in the house is not a big deal, but once you see a tiny rivulet of them streaming out of a crack in the kitchen window, the problem class swings toward unsolvable.

Similarly, the presence of limits can give us an impression of facing an infinity-problem when the problem is indeed solvable, but beyond our limits to reach an effective solution. In the organization that is caught in the “reality distortion field” of their leader, continuing to push forward might seem like fighting an invisible foe (which is a marker of perceiving an adversarial adaptation), but in reality be a matter of hitting the limit of attachment. In such situations, the outside observers might classify the problem as solvable, but from inside, it will come across as unsolvable.

Put differently, limits create even more opportunities for problem class confusion. We may mischaracterize unsolvable problems as solvable – and then be surprised when the infinity shows up. We may mischaracterize solvable problems as unsolvable – and fight impossible beasts to exhaustion.

Ronald Heifetz and Marty Linsky have this lens of technical and adaptive challenges. To describe the distinction in terms of the problem classes, technical challenges would belong in the class of solvable problems, and adaptive challenges would situate in the unsolvable problem class. One of the key things the authors emphasize is how often the confusion of one kind of challenge with another is at the core of all leadership problems. It is my hunch that the interplay of infinity-problems and limits has a lot to do with why that happens.

Oh! Also. While you weren’t looking, I re-derived the project management triangle. If we look at the capacity, attachment, and time, we can see that they match this triangle’s corners. Time is time, of course – as in “how much time do I have?” Capacity is cost, with the question of “how much of your capacity would you like to invest?” And last but not least, attachment is scope, with the respective “how attached are you to the outcomes you desire?” This is pretty cool, right?

Archers, Captains, and Strategists

Talking with a colleague, I was trying to draw a distinction between the different kinds of questions people ask when looking for direction. A simple lens materialized. I hope it will be as useful for you as it has been for me.

Imagine a fun medieval-themed board game, where we all draw different cards. Based on the cards we draw, we want to know different things and want to see different parts of the overall picture. There are three archetypes: Archers, Captains, and Strategists.

When we draw the Archer card, we don’t really care about the larger picture or the depth of nuance within the situation. We just want to have clarity on what needs to be done. For Archers, the question is “Where do we shoot?” As an example, when I sign up for volunteer work, I tend to draw the Archer card. I just want to chip in, relying on others to organize me. Wash dishes? Okay. Clean tables? Sure. Stack chairs? You’ve got it. When I have the Archer card, my satisfaction comes from getting stuff done.

When we draw the Captain card, we are asked to see enough of a larger picture to make sure that all those arrows not just hit the target, but that each round of our game progresses in service of some sort of intention. Captains lead. Stepping into a TL role is like drawing a Captain card: you are given a broad mandate of some sort, and it’s on you to figure out how to organize your colleague’s collective capabilities to fulfill it. Captains ask the “What are we winning?” question. In my example of TLs, the clarity of that mandate is paramount. All their reasoning sits on top of it. If the mandate is loose, so are the winning conditions – which rarely leads to desired outcomes.

Occasionally, I get confused and, when given the Archer card, I try to act as a Captain. This can be somewhat stressful. When given a target, Captains aren’t content until they understand the problem being solved and make their own conclusion that this is indeed the right target at which to aim. And if it’s not, it can be quite draining to see everyone around me blissfully shooting arrows in what I believe is the wrong direction. I am guessing this happens to you, too?

Finally, when we draw the Strategist card, we are asked to situate all underlying intentions of Captains and Archers in the larger picture of the game. If we do indeed win, why is that significant? What happens next? What is the longer arc of this adventure? Strategists want to see it all. Strategists assume that targets will be chosen and rounds won or lost, skipping over to the effects of these moves on the larger environment. It’s the overall change in this environment that they are most interested in. Strategists discern a system of rules within the game and help Captains frame problems into mandates. The question Strategists ask is “What is the game?”

If I were to make such a game more life-like, I would employ the likes of that UNO Attack! shuffler, which tosses cards at us in handfuls. We’re always an Archer, a Captain, and a Strategist — and often, it’s hard to tell which card we’re currently holding. To add to the chaos, some of us lean toward Archer, and some Captain or Strategist, acting the archetype even if it’s different from the card we’re dealt. It’s a crazy game.

One of the many insights that this lens produced for me was that when communicating direction within an organization, it may be useful to structure it as a layering of these questions. We start with a brief answer to “Where do we shoot?”, then provide a more broad “What are we winning?” and close with the expansive “What is the game?” This way, when I am an Archer, I can quickly get my target list and go at it. When I am a Captain, I can dig a bit deeper and find clarity of my mandate. Last but not least, as a Strategist, I will appreciate the full rigor of exploring the system in which this particular direction is located.