Learning from the nadir

I’ve talked before about traps: how to get into them, what they might look like, and even how to get out of them. This little story is about the developmental potential of traps.

To frame the story, I will draw another two-by-two. The axes signify our awareness of our limitations and our capacity to overcome them. To make things a bit more interesting, I will also turn this two-by-two 45 degrees clockwise, because I want to map it to another framing: the hero’s journey.

The axes form four quadrants that loosely correspond to the key segments of the hero’s journey. 

In the top quadrant, we are the happiest and perhaps even bored. We aren’t aware of any of the limitations that hinder us and we feel generally content with our abilities.

It is that boredom that gets us in trouble. At first reluctantly, but eventually with more gusto, we engage with a challenge and traverse into the right quadrant. This quadrant is characterized by weirdness. Campbell points out all kinds of odd stuff happening to us, from being visited by a quirky wizard to being tested in ways that make us unsure of ourselves.

In the right quadrant, we aren’t yet aware that the challenge exceeds our capacity to overcome it, so things feel bizarre, random, and generally not right. We might start a new job with enthusiasm, and after a few meetings, have our heads spinning, encountering unexpected politics and/or gargantuan technical debt: “What did I just get myself into?”

Eventually, as we puzzle things out, we arrive at the nadir of our journey, the bottom quadrant. We become aware of the fact that we’re in way over our heads. We are aware of our limitations and do not yet have the capacity to overcome them.

The bottom quadrant often feels like a trap. My colleagues and I sometimes apply the word “infohazard” to the insightful bits of knowledge that finally clear our vision and thrust us into this quadrant. It almost feels like it might have been better if we didn’t acquire that knowledge. Yeah, the previous quadrant was super-weird, but at least I didn’t feel so deficient in the face of the challenge.

This quadrant is also the most fertile ground for our inner development. When we have the right mindset, the awareness of our limitations creates a useful observation perch. Only when we are able to see our own limitations can we contemplate changing ourselves to overcome them.

This is not a given. Way too commonly and tragically, we never get to occupy this perch. Falling into the vicious cycle of not-learning, we form an inner false loop inside of our hero’s journey, spinning round and round inside of the bottom quadrant, and truly becoming trapped.

Whether we grasp onto the perch or not, one thing is guaranteed. The bottom quadrant is full of suffering. Even when we believe we’ve learned all there is to learn about self-development, and have all kinds of tools and tricks (and perhaps even write about it regularly) – the moment of discordance between what we’re seeing and what we believe will be inevitably painful.

It is on us to recognize that this pain can be processed in two ways: one is through the habitual entrapment of the not-learning cycle and the other one is by choosing to learn like crazy. Hanging on to a dear life to the perch of observation and examining our beliefs and recognizing flexibility in bits that we previously thought immovable.

Only then can we emerge into the left quadrant, where we are both aware of our limitations, but now have the capacity to overcome the challenge – and bring the boon back to the land of living, as Campbell would probably say.

How we engage with LLMs

It seems popular to write about generative AI and large language models (aka LLMs) these days. There are a variety of ways in which people make sense out of this space and the whole phenomenon of “artificial intelligence” – I use double-quotes here, because the term has gotten quite blurry semantically.

I’ve been looking for a way to make sense of all of these bubbling insights, and here’s a sketch of a framework that is based on the Adult Development Theory (ADT). The framework presumes that we engage with LLMs from different parts of our whole Selves, with some parts being at earlier stages of development and some parts at the later. I call these parts “Minds”, since to us, they feel like our own minds, each with its own level of complexity and attributes. They change rapidly within us, often without us noticing.

These minds are loosely based on the ADT stages: the earliest and least complex Opportunist Mind, the glue-of-society Socialized Mind, the make-things-work Expert Mind, and the introspective Achiever Mind.

🥇The Opportunist Mind

When we engage with an LLM with an Opportunist Mind, we are mostly interested in poking at it and figuring out where its weaknesses and strengths lie. We are trying to trick it, to reveal its secrets, be that initial prompts or biases. From this stance, we just want to figure out what it’s made of and how we could potentially exploit it. Twitter is abuzz with individuals making LLMs act in ways that are beneficial to illustrating their arguments. All of those are symptoms of the Opportunist Mind approach to this particular technology.

There’s nothing wrong with engaging an LLM in this way. After all, vigorous product testing makes for a better product. Just beware that an Opportunist Mind perch has a very limited view, and the quality of insights gained from it is generally low. I typically steer clear from expert analyses engaging with LLMs from this mind. Those might as well be generated by LLMs themselves.

👥The Socialized Mind

When the LLM becomes our DM buddy or a game playing partner, we are engaging with an LLM with a Socialized Mind. When I do that, there’s often a threshold moment when I start seeing an LLM as another human being, with thoughts and wishes. I find myself falling into habits of human relationship-building, with all of the rules and ceremonies of socializing. If you ever find yourself trying to “be nice” to an LLM chat bot, it’s probably your Socialized Mind talking.

At the core of this stance is — consciously or subconsciously — constructing a mental model of an LLM as that of a person. This kind of mental model is not unique to the Socialized Mind, but when engaging with this mind, we want to relate to this perception of a human, to build a connection with it.

This can be wonderful when held lightly. Pouring our hearts to a good listener convincingly played by an LLM can be rather satisfying. However, if we forget that our mental model is an illusion, we get into all sorts of trouble. Nowadays, LLMs are pretty good at pretending to be human, and the illusion of a human-like individual behind the words can be hard to shake off. And so we become vulnerable to the traps of “is it conscious/alive or not?” conversations. Any press publication or expert analysis in this vein is only mildly interesting to me, since the perch of the Socialized Mind is not much higher than that of the Opportunist Mind, and precludes seeing the larger picture.

🧰The Expert Mind

Our Expert Mind engages with an LLM at a utilitarian level. What can I get out of this thing? Can I figure out how the gears click on the inside — and then make it do my bidding? A very common signal of us engaging LLMs with our Expert Mind is asking for JSON output. When that’s the case, it is very likely we see the LLM as a cog in some larger machine of making. We spend a lot of time making the cog behave just right – and are upset when it doesn’t. A delightful example that I recently stumbled into is the AI Functions: a way to make an LLM pretend to execute a pretend function (specified only as input/output and a rough description of what it should do) and return its result.

Expert Minds are tinkerers – they produce actual prototypes of things other people can try and get inspired to do more tinkering. For this reason, I see Expert Mind engagements as the fertile ground for dandelion-like exploration of new idea spaces. Because they produce artifacts, I am very interested in observing Expert Mind engagements. These usually come as links to tiny Github repos and tweets of screen captures. They are the probes that map out the yet-unseen and shifting landscape, serving as data for broader insights.

📝The Achiever Mind

I wanted to finish my little story here, but there’s something very interesting in what looks like a potential Achiever Mind engagement. This kind of engagement includes the tinkering spirit of the Expert Mind and enriches it with the mental modeling of the Socialized Mind, transcending both into something more.

When we approach LLMs with the Achiever Mind, we recognize that the nature of this weird epistemological tangle created by an LLM creates opportunities that we can’t even properly frame yet. We can get even more interesting outcomes than the direct instruction-to-JSON approach of our Expert Mind engagement by considering this tangle and poking at it.

The ReAct paper shone the light at this kind of engagement for me. It revealed that, in addition to direct “do this, do that” requests, LLMs are capable of something that looks like metacognition: the ability to analyze the request and come up with a list of steps to satisfy the request. This discovery took someone looking at the same thing that everyone was looking at, and then carefully reframing what they are seeing into something entirely different.

Reframing is Achiever Mind’s superpower, and it comes in handy in wild new spaces like LLM applications. Metaphorically, if Expert Mind engagements explore the room in the house, Achiever Mind engagements find and unlock doors to new rooms. The unlocking of the room done by ReAct paper allowed a whole bunch of useful artifacts, from LangChain to Fixie to ChatGPT plugins to emerge. 

This story feels a bit incomplete, but has been useful for me to write down. I needed a way to clarify why I intuitively gravitate toward some bits of insight in the wild more than others. This framework helped me see that. I hope it does the same for you.

Sailors and Pirates

Here’s a fun metaphor for you. I’ve been chatting with colleagues about the behavior patterns and habits of leaders that I’ve been observing, and we recognized that there are two loose groups that we can see: sailors and pirates.

The sailors are part of the crew. They are following orders and making things that have been deemed important happen. Ordinary sailors have little agency: they are part of the larger machine that is intent on moving in a certain direction. Sailors higher in the power structure (and there is usually a power structure when sailors get together) have more agency. They have more freedom in how the things happen, but they are still held responsible for whether they happen or not.

Organization leaders who are sailors are subject to the primary anxiety of things being out of control. Their catastrophic scenario is that all this wonderful energy that they have in the people they lead is not applied effectively to the problem at hand. They wake up in cold sweat after dreaming of being lost or late, of being disoriented and bewildered in some chaotic mess. 

This makes them fairly easy to spot. Listen to how they talk. They will nearly always speak of the need to align, to make better decisions, to be more efficient and better coordinated. Sailor leaders love organizing things. For a sailor leader, neat is good.

Every organization needs sailors. Particularly in scenarios where we know where we are going, sailors are who will get you there.  They are the reliable folks who feel pride and honor to drive their particular ship (or part of the ship, no matter how small) toward the destination. Sailor leaders don’t have to be boring, but they prefer it that way. Excitement is best confined to the box where it doesn’t disrupt the forward movement.

Pirates are different. The word “pirate” conjures all kinds of imagery, some vividly negative. For our purposes, let’s take Jack Sparrow as the kind of pirate we’re talking about here.

As I mentioned, pirates are different. They loathe the orderly environment that the sailors thrive in. They yearn for a small ship that can move fast and make unexpected lateral moves.

Pirate’s driving anxiety is that of confinement. Whether consciously or not, their catastrophizing always involves being stuck. Their nightmares are filled with visions of being trapped or restrained, with no possibility of escape, of being pressed down by immovable weight.

Pirates seek options and choose to play in environments where the options are many. This is why we often find them in chaotic environments, though chaos is not something they may seek directly. It’s just that when there’s chaos, many of the variables that were previously thought to be constant become changeable. It’s that space that is opened up by the chaos-induced shifts that the pirates thrive in. And sometimes, often unwittingly, they will keep causing a little chaos – or a lot of it – to create that option space.

Pirate leaders are also not difficult to detect. They are usually the weird ones. They keep resisting the organization’s desire to be organized. They usually shun positions of power and upward movement in the hierarchies. For the saddest pirate is the one who climbed through the ranks to arrive at a highly prestigious, yet extremely sailor position.

Pirate leaders are known to inject chaos. If you’ve ever been to a meticulously planned and organized meeting, where its key participant throws the script away right at the beginning and takes it in a completely different direction – you’ve met a pirate leader.

It’s easy to see how sailors and pirates are oil and water. Sailors despise the pirate’s incessant bucking of the system. Pirates hate the rigid order of the sailors and their desire to reduce the available options. 

Then, why are pirates even found in organizations? Aren’t they better off in their Flying Dutchman somewhere, doing their pirate things?

The thing is, pirates need sailors. A shipful of pirates is not really a ship. With everyone seeking options, the thing ain’t going anywhere. Pirates need sailors who are happy to organize the boring details of the pirate adventure. And the more ambitious the adventure, the more sailors are needed.

Conversely, sailors need pirates. A ship that doesn’t have a single pirate isn’t a ship either – it’s an island. The most organized and neat state of a ship is static equilibrium. When a pirate captain leaves a ship, and no pirate steps up, the ship may look functional for a while, and even look nicer, all of the cannons shining of bright polish and sails finally washed and repaired.

But over time, it will become apparent that the reason for all these excellent looks is the lack of actual action. The safest, neatest course of action is to stay in place and preserve the glorious legends of the past.

The mutual disdain, combined with the mutual need creates a powerful tension. Every team and organization has it. The tension can only be resolved dynamically – what could have been the right proportion of pirates and sailors yesterday might not be the same today. Sometimes we could use fewer pirates, and other times, we need more of them.

To resolve this tension well, organizations need this interesting flexibility, where pirates and sailors aren’t identities, but roles. Especially in leadership, the ability to play both roles well is a valuable skill. Being able to assume the role flexibly depending on the situation gives us the capacity to be both pirates and sailors – and gives the organization a much higher chance of acting in accordance with its intentions.

The most effective pirate is a meta-pirate: someone who can be both a pirate and a sailor in the moment as a way to keep the opportunity space maximally open.

We all have this capacity. The reason I described the nightmare plots for the sailor and the pirate is to help you recognize them in your own dreams. Experienced both kinds? You are likely both a little bit of a pirate and a sailor at heart. If one is more common than the other, that’s probably the indicator of where you are leaning currently. So, if you’re looking to become a meta-pirate, that’s an indicator of where to focus the work of detaching the role from your identity. 

Nudges, boosts, bumpers, and tilts

The quartet is finally complete. I’ve written about nudges separately, and already had bumpers, boosts, and tilts grouped. Now they are all united into one simple framework that helps me better understand the environment in which I am operating and reason about imparting change on this environment.

To better understand an environment, we evaluate two of its properties: degree of inter-part alignment and degree of inter-part friction.

The inter-part alignment tells us how much the parts are aligned with each other. The inter-part alignment is not a static property, but rather an evaluation of how much the various moving parts of the environment choose to act. Since I mostly work with teams, these parts are typically people. The inter-part alignment is our guess at how much the people within the team are aligned along similar goals and objectives.

The inter-part friction tells us how much attachment the parts have to each other. If they are strongly attached, there’s a lot of friction between them. If they aren’t, there’s nearly none. Highly interdependent environments are usually the high-friction ones. In organizations, this friction is experienced as the degree to which people feel constrained by other people in their actions.

Using these two properties as axes, we can draw a nice – what else? – two-by-two. For each quadrant in this space, there’s a technique that, when applied, is most likely to result in desired outcome. Let’s walk around the quadrants, clockwise, starting from top-right.

One thing to remember: teams are almost never easily assessed as exemplars of one particular environment. They flex and shift, changing from one kind to another. Environments are also scenario-specific. The same team might look like one environment for a particular problem, and a completely different environment for another problem.

🚗 High alignment, high friction

In the top-right quadrant of two-by-two reside the high alignment and high inter-part friction environments. A good metaphor for this environment is a car that’s stuck in a ditch. It wants to go, but does not have the power to overcome the friction of the ditch.

For an organization, this might be the scenario where everyone agrees on the importance of the problem and there’s agreement on the solution, but the mustering of the actual resources to do the work is an issue.

This is where a boost is the most effective technique. Everyone lends their shoulder and leans in to get the car out of the ditch. Boosts are fairly straightforward, since they are a prioritization exercise. Just decide what is most important and go for it.

🌊 High alignment, low friction

In the bottom-right quadrant, we find environments that have high alignment and low inter-part friction. These will feel like water: parts move freely, but also simply seek static equilibrium. These are the “just tell me what to do” scenarios.

A good example of this scenario is an organization that needs direction on some specific issue that is widely recognized as existentially critical, but does not have strong opinions on the solution.

In my experience, these situations are rare and I usually see them in the realm of complex policy decisions that an organization needs to make, with only a handful of recognized experts who actually know how to make them.

The technique to use in high-alignment, low-friction situations is a bumper. Just draw the line not to be crossed, clearly articulate the consequences of crossing it, and firmly enforce it. Just like water is content to be in a glass, high-alignment, low-friction environments will be happy to abide by our bumpers.

🐈 Low alignment, low friction

Moving on to the bottom-left quadrant, there are environments with low alignment and low friction. These are the “herding cats” environments. There is literally nothing one can do through direct influence – no matter what we try, the energy from our actions seems to be rapidly absorbed into the whole without any discernible change. I wrote a little essay called “The Fractal Dragon” to describe this environment using a more dramatic metaphor.

In organizations, low-alignment, low-friction environments are typically full of smart, yet self-interested people. If we’re very technical about these teams, they are not technically teams, but rather markets. Open source projects and standards bodies can be good examples, though I’ve seen actual engineering teams that have similar structures. A good marker here is a loose relationship between funding and fitness function.

In a low-alignment, low-friction scenario, the go-to technique is tilts. Changes can only be made by carefully crafting incentives to tilt in the direction that we want and be patient with the organization eventually following the slope of the tilt. Despite the temptation to “do something”, it is important to recognize that any attempt at direct action is likely a waste of energy – or worse, an introduction for further chaos into the environment, with all of the unintended consequences that follow.

An effectively executed tilt has a nice positive side effect: it acts as an alignment function. When it’s working, the slope of the tilt also aligns the environment. Everything is roughly moving in the same direction. 

🧱 Low alignment, high friction

In the remaining top-right quadrant, we have environments that have low alignment and high friction. A good example of such an environment is an organization that is stuck in a dynamic equilibrium: parts of it (be that individuals or teams) are deadlocked, none willing to budge. A significant amount of energy is expended on all sides, yet there is no progress. This can happen for multiple reasons. One team might have strong incentives to not let go of a project. Another team might be firefighting, unable to spare any attention to unblock others. Yet another team could have strong, uncompromising opinions about the way things need to be done.

In such a situation, the appropriate technique is nudging: looking for key leverage points that are most susceptible to change. These are typically going to be found in critical juncture points that don’t have a single party to resolve them. I have done a bunch of nudging like this. Sometimes a single meeting is enough to move things along. Or as I described in “Nudging Embodied Strategy”, setting up a chat room.

Low-alignment, high-friction environments can be rather frustrating to work with. It may take several nudges – and a lot of trial and error –  to make a change that would have been effortless in any other environment. Keen observation of the overall environment and spotting the leverage points is the key here. Come equipped with a lot of patience and time.

🧭 Yet another compass

At least the way I see it, for each of the quadrants, there seems to be a fairly clear match of a technique. Mismatching technique to the quadrant tends to lead to unproductive outcomes. 

For instance,  when we find our bumper technique being ineffective, we might have confused our quadrants. In this case, we’re likely in a low-alignment, low-friction scenario where a tilt will be much more effective. This is a common error in designing processes. Folks assume that they are in the bottom-right quadrant and devise a clear policy, only to see the team find ways to dull the policy with workarounds and generally make a mockery of it. Bumpers only work when there’s high alignment.

Similarly, if we find that our boosting and prioritization is ineffective or has at best temporary effects, we might be experiencing another instance of quadrant confusion. We are likely in a low-alignment, high-friction environment. The problem with our car is not that it’s in a ditch. It’s that it isn’t sure it wants to leave it. I wrote about my personal experience with such a confusion in “Behavior over time graphs and ways to influence”.

This matching (and mismatching) works both ways. The effectiveness of techniques tells us about the nature of the environment we’re working with – and can help us better understand it. If we start with a tilt, predicting a low-alignment, low-friction environment, and see little evidence of the tilt working, we might reconsider – perhaps the friction is not as high as we thought it was? Or maybe the alignment is higher than we surmised? By guessing the quadrant and applying the technique, we get more information about the environment we’re operating in, giving us insights for future actions.

In this way, this little framework of mine might be used as a navigation tool for us inspired process engineers. Give it a try and tell me how it works for you.

Receiving negative feedback

Negative feedback is rarely fun, but can show up in varying degrees of intensity. Sometimes it might seem like a nice suggestion to improve, and some might feel like a crushing blow. It is the latter kind that I am focusing on in this essay.

It can be rather discomforting to hear someone talk poorly of us – or things we’ve built. However, not receiving negative feedback leads to self-delusion, so we’re much better off with it than without it.

Our body’s intuition will fight us on this conclusion tooth and nail, constantly trying to convert us to the notion that negative feedback is just a bad thing and something we could live without. But we really can’t – and much of the modern human’s struggle could be framed as learning how to receive negative feedback in a productive way.

Here are some framings that I’ve learned that help me get the most of this uncomfortable experience. To make them a bit more concrete, I will situate these framings in a hypothetical scenario of a team receiving strong negative feedback on the launch of their product. However, most are applicable to a broad range of scenarios. 

🌀 Their feedback, our emotions

So we have some stinging feedback from our users. The first important thing about receiving strongly negative feedback is to recognize that this is a phenomenon that involves our emotional response. This response is a process inside of us. It is highly individual and varies greatly from one person to another.


You may have seen some people being more affected by negative feedback than others. One person may describe a negative tweet as “poisonous vitriol” where the other may chuckle at the pun the tweet makes. The intensity of the negative feedback is measured by our own emotional response to it.

We are not our emotions. We have them. Too often, it seems like they have us. If we want to learn from negative feedback, we need to learn to separate our emotions from ourselves. This is why we must learn to separate our individual response to negative feedback from the feedback itself.

⛓️ Why does this happen?

Why do we have strong emotional responses to negative feedback? I really like the framing of attachment here, specifically the attachment of identity. 

When we make something, we put ourselves into it. This tiny bit of ourselves could be our engineering pride, attached to our identity of “a good software engineer”. Or it could be our sense of fulfillment, attached to our identity of “someone who does good in the world”.  When people criticize our product, it will feel like they challenge these bits of identity that we embedded in our products. Behind a strong emotional response, there are nagging questions like: “Perhaps I am not as good of a software engineer as I thought I was? Am I really someone who does good in the world?” Whether we want to admit it or not, these questions were already there in our minds. The additional evidence of our failings often puts these front and center.

Being passionate about things we make is an important part of creating good products, but this passion comes with a shadow of identity attachment: when our users disagree with us about the goodness of what we’ve made, this passion will do a number on our emotions.

When we have a strong emotional response to negative feedback, we can’t process this feedback productively. Instead, we will react to our emotions. And that is often worse than not receiving feedback at all.

🧭 Orienting amidst emotional response

How do we separate ourselves from our emotional response when receiving negative feedback? This can be quite challenging. Especially when our response is strong, we often can’t even see that we’re subject to them. Our emotions become us. What we need is some sort of orienting tool that helps us step back and reflect on the soup of emotions we’re feeling.

Thankfully, Dr. Karen Horney has a great framework for this occasion: the moving toward, against, or away. We can use it as a compass to identify where our emotional response is currently taking us  — and hopefully, pause and reorient. 

Think of it as three paths we instinctively take when reacting to our emotions in response to negative feedback. Each has a certain story that plays unconsciously in our minds as we go down this path. Each story takes us away from processing negative feedback and applying insights from it to our future actions.

Our ability to separate ourselves from our emotions lies in being able to spot the general plot lines of these stories. I will list each path with its typical story and the extremes these stories take us to, if unchecked.

💨 Away

The first path we commonly take is the “away” path. The plot line here is that of avoidance and usually goes like this: “yikes, everybody is upset, maybe I should just go back to doing my thing and never ever listen to people criticize me or my work. This is fine.” The avoidance story is likely the most common of the paths. It can feel like the easiest way to deal with negative feedback – just avoid ever hearing it. While going down that path, individual engineers and entire engineering organizations can go into great lengths to reduce any exposure to actual users. Avoidance increases the disconnect between the reality inside of the team and the reality outside, which tends to end up in a total breakdown, when the difference is too great to ignore.

⚔️ Against

The second path is the “against” path. Along this road, there’s the adversarial story of being attacked – along with the urge to fight back. “These jerks, they don’t get how hard this was to get shipped” or “These people are just trolling us, they are here to cause chaos.” Somewhere, somehow, we cross the line from thinking of our users as those who we want to delight to the mob that’s out to get us. Compared to the stories of avoidance, antagonizing stories are also quite common, and they are usually easy to spot: look for a brawl, be it in meetings or chats or docs comments. Unlike the “away” path, this one feels like action. It gets the adrenaline pumping, and creates the sense of doing something. Unfortunately, it is just as unproductive. Because we are merely reacting to our emotions, we’re not actually listening to the feedback. We’re fighting the vandals who dared to deface our sacred grounds. Since the actual vandals are hard to pinpoint, there is usually a tendency for a team to splinter into fiefdoms, each with their own conception of “the enemy”.

🏳️ Toward

The third and final path is when we move “toward”. When we go down this road, the story that plays in our minds goes something like this: “omg, we’re so screwed, that twitter guy is totally right, we are losers, and everything we do is horrible”. This story sounds most similar to actually receiving feedback, though it’s anything but. This story of accommodation is a pure reaction to the avalanche of self-doubt that overwhelmed all of our senses, forcing us to grasp on for any strong opinion, even if it’s that of a random Twitter guy. Many, many bad decisions were made as the result of following this path. They all have a flavor of “we should do this (or not do this) because someone else thinks it’s the right (wrong) thing to do”. In teams, the most visible effect of the story of accommodation is a rising feeling of collective self-loathing. Vibrant and unique team cultures disintegrate in the loss of self-confidence and the disorientation that follows.

🦠 The viral load

Have I mentioned that these stories also happen to be super-contagious? There’s something about our human psychology that makes us particularly susceptible to these three stories. We might prefer one over the other, but there’s definitely one that will catch us. Some of us might be reasonably immune to the “toward” or “away” paths, but oh boy, even a hint of the antagonizing story can cause us to jump, knuckles up. Some of us might be highly avoidant, and have all kinds of tricks to prevent feedback from ever reaching us. Some of us might immediately move to accommodate, revealing lack of confidence in our own decisions.

Upon receiving negative feedback about our product, our team will likely experience all three of these, simultaneously. Each individual will take their own path, contributing to the boiling soup of emotion-laden stories. If we let these stories run amok, they will wash over the team as multiple waves of viral spread, inhibiting our ability to process this feedback.

The weird part is that these stories are often based on truth, which often makes them hard to untangle from. Sometimes our users really are just trolling us. Sometimes that twitter guy is actually right. And sometimes all this negativity is just too much and we must take a break to preserve our sanity. 

💪 Practice 

We are better off accepting that a mix of the three plot lines will always play out in our minds in response to negative feedback. We can’t wish them away or somehow reach the plateau of perfect rationality where we never have them again.

But if we practice noticing the stories and familiarize ourselves with the paths where they take us, we can start opening up a bit of space between ourselves and our emotions. And as we do, we increase our capacity to receive and process even the most crushing criticism.

We also don’t have to do it alone. A useful tactic that worked for me is asking someone who is less attached to the project to help me interpret the feedback. It can be quite puzzling, yet liberating to see someone else not have the same emotional response. It helps me see the story that I am trapped by – and is usually enough to get unstuck.

Putting all of this together into bullet points:

  • Accept that we will all have our individual emotional response to negative feedback – and that our first instinct will be to react to our emotions, not the feedback itself.
  • Have tools to orient ourselves in the midst of the response, to detach from what we’re feeling and bring our attention to the actual feedback. Dr. Horney’s framework is just one example.
  • Practice using these tools as a team to reduce the spread of emotional contagion. Even the basic awareness of the underlying process could do wonders to how the team reacts to negative feedback.
  • Grow a network of trusted friends and colleagues from diverse backgrounds and environments, with whom we can share the bits of feedback we’re struggling with and count on their support to help process it.

Whew, this was long. But here’s hoping that my ramblings will help you and your colleagues navigate the uncomfortable, yet ultimately essential process of receiving negative feedback. Let me know how it goes.

Deep Stack Engineer

Riffing on the idea of layer gaps, we can surmise that pretty much every layer we ever get to write code for has gaps. If that’s the case, then anticipating layer gaps in our future can lead to different ways to build teams.

A key insight from the previous essay is that when we work with a layer with gaps, we need to understand both this layer and the layer underneath it. For if we ever fall into the gap, we could use that knowledge of the lower layer to orient and continue toward our intended destination.

Which means that when we hire people to work in a certain stack, we are much better off hiring at least one person who has experience with the stack’s lower layer. These are the people who will lead the team out of the layer gaps. To give our full stack engineers the ability to overcome these gaps, we need at least one deep stack engineer.

A simple rule of thumb: for every part of the stack, hire at least one person who has experience working at the layer below. 

For example, if we’re planning to develop our product on top of a Web framework, we must look for someone who deeply understands this framework to join the team. Ideally, this person is a current or former active participant in the framework project.

Approaching this from a slightly different angle and applying the cost of opinion lens, this person will act as the opinion cost estimator for the team. Because they understand the actual intention of the framework, they can help our team minimize the difference of intentions between what we’re engineering in our layer and the intention of the underlying framework. As my good friend Matt wisely said many moons ago, it would help our team “use the platform” rather than waste energy while trying to work around it. Or worse yet, reinvent it.

Note that the experience at the lower layer does not necessarily translate to the experience at the higher layer. I could be a seasoned Web platform engineer, with thousands of lines of rendering engine C++ code under my belt – yet have very little understanding of how Web applications are built.

What we’re looking for in a deep stack engineer is the actual depth: the capacity to span multiple layers, and go up and down these layers with confident ease.

The larger the count of layers they span, the more rare these folks are. It takes a lot of curiosity and experience to get to the level of expert comfort across multiple layers of developer surfaces. Usually, folks tend to nest within one layer and build their careers there. So next time we come across a candidate whose experience spans across two or more, we are apt to pay attention: this might be someone who significantly improves the odds of success in our engineering adventures.

Layer gaps

I’ve been writing a bit more code lately, and so you’ll notice that some of my stories are gravitating that way. Here’s one about layer gaps.

Layer gaps are when a developer surface layer fails to close fully over the layer below. Another way of saying this is “leaky abstraction”, but I’ll use my own term “layer gaps” to define what it entails in a more nuanced way.

To recap what I’ve written previously about layers, every layer tends to offer a bit of its own opinion about how to best bring value to users. When the layers are able to fully express this opinion, we have no layer gaps in this layer. For example, JavaScript is a gapless layer. It’s a language and a firm opinion about a code execution environment. It might not have features that we would like to have in a language. It might have limits within its execution environment. It might even have frustrating bugs that irritate the dickens out of us.

But at no point of using JavaScript we will suddenly go: “whoa, I am no longer in JavaScript. I fell into some weird gap that I wasn’t previously aware of, and now I am experiencing the lower layer on top of which JavaScript was built”.

To better grasp what a layer gap looks like, we don’t have to go far. Let’s look at TypeScript. TypeScript is a really interesting beast: it’s a layer of a type system that is laid over JavaScript. First off, the type system itself is delicious. It reminds me a bit of the C# type system, and I thoroughly enjoyed learning and using both. However, there’s a gap into which I fell into more than once.

Because the type system is compile-time only, the layer disappears at runtime. It simply doesn’t exist anymore once the code is executed by the underlying JavaScript engine. However, compared to other type systems that I am familiar with, I expect at least some runtime type support. 

At least for me, my mental model of a type system includes at least a little bit of ability to reason about types. Like, at least comparing them at runtime. A bit of type reflection might be nice. But because there’s no such thing as TypeScript when the code actually runs, I experience the layer gap.

As developers of layers, we need to remember that if our layer has gaps, our user must not only understand how our layer works, but also how the lower layer works, and have the gaps clearly marked. For if we don’t, we’ll hear frequent screams of anguish as they discover them. A clearly marked gap might look like documentation that helps our developers understand the tradeoffs they are making by using our layer and make the decision to use it on their own terms. It could look like superb tooling that points out the gap as soon as the user gets close to it – and possibly both.

As users of these layers, we need to be ready for every layer to potentially have gaps. We need to invest time upfront to uncover them, and build our practices to fence around the gaps.

I was sharing with my colleagues that using TypeScript is like walking on stilts. I can get really, really good at walking on stilts. I could even learn how to run on stilts and do all kinds of acrobatic tricks while on stills. But I should never forget that I am wearing them. If I do, I may find myself unpleasantly surprised when the ground suddenly hits my face. 

Layer gaps aren’t necessarily a terrible thing. They come with tradeoffs, and sometimes these tradeoffs are worth it. For instance, I embraced TypeScript, because I can delegate some of the mental load of reasoning about the data structures to the TypeScript compiler – and it does a pretty good job of it.

I just need to keep remembering that as I am enjoying the benefits of seeing farther and being taller, I am doing this by wearing the stilts.

Decision-making mindsets

I have this intuition that the process is not the most important ingredient in making better decisions. Instead, the key is the mindset with which we’re entering the decisions-making process. 

The process still plays a valuable part, but it only works when we have the right mix of mindsets. Some mindsets are more effective at decision-making than others.

Here’s a sketch of the different types of mindsets that show up in decision making. These aren’t character labels or personas. People can be in different mindsets depending on the context and circumstances. Mindsets can shift over time, and sometimes in the moment.

Note, that I am cleverly avoiding the actual hard problem: answering the “How do we bring people into these mindsets to make good decisions?”. I am tackling the easy part: identifying the mindsets we need to make better decisions.

💸 Opportunistic

The opportunistic stance is the least helpful of the bunch. In the opportunistic mindset, the process of decision-making is a vehicle for advancing my own agenda. I am not here to make decisions. I am here to use this key moment for my benefit. This stance is why politics gets a bad rap. Am I in this process to move it forward, or am I here to subvert it to serve my needs? This stance can seem beneficial in hostile environments, but at that point, there is no actual decision-making going on. It’s all just political theater.

My friends at FLUX have this amazing lens of “kayfabe”, which applies very well to decision-making processes where everyone is in the opportunistic stance – everyone knows this is not about making the decision, yet preserves the appearance and the form of the process. As soon as we detect this kind of state of affairs, ejecting from this environment as soon as possible might just be the best option available. In other words: run. Otherwise, we’ll likely become the chair in this fake-wrestling match.

🎰Opinionless

The opinionless mindset is not that much better. It usually presents itself as deference to the opinion of others. In this stance, I am a carrier of another’s opinion, rather than proprietor of my own. Typically, the opinionless stance is revealed by turns of phrase like “the studies show” or “the <senior leader> said” or “I heard that” when presenting an opinion. When making decisions, this stance is superfluous. If I find myself in this stance, I am much better off excusing myself from participating in any decision-making. Since I don’t hold this opinion, I can’t articulate the value it contains.

The opinionless stance can lead to weird stalemates when trying to make decisions. If “Alice thinks that we should ship Widgets”, and nobody else can figure out why, yet Alice isn’t here to present the opinion, an easy – and more productive – thing to do is to dismiss the opinion. However, if Alice holds power (be that expertise or rank or any other sort), the opinionless participants beholden to this power will stall and derail the process. In the past, I called the opinionless stance “weak opinions, strongly held”. What’s worse, most of the time, it feels awful to be in that stance, stuck between the rock and the hard place of differing opinions.

It’s not to say that opinions of others don’t matter. They do. However, if I myself am not of this opinion, I improve decisions-making by presenting them as the input for the process, rather than part of it. Let others who actually hold opinions examine this information and incorporate it into their reasoning.

If we look around the room when decisions are being made, and see that most are in the opinionless stance, woe to us. This is not a decision-making meeting, but rather an opinion pachinko machine: it’s hard to know where we will land, but it is clear that the decision will be random and will fail to stick. 

Whenever possible, remove (or self-remove) opinionless folks from the process. At the same time, recognize that often, the opinionless stance is forced: it is a defensive crouch that’s assumed by the folks who feel compelled to hide their actual opinion – usually due to some power dynamic. If that’s the case, opportunistic kayfabe is the next stop in our decision-making adventure, and it might be worth investigating what’s causing the defensive crouch.

🧨 Opinionated

Decision-making gets better when we have an opinionated stance. There’s some experience that we’ve accumulated along the way that gives us enough confidence to claim that we understand what needs to be done. We hold an opinion and it is ours. We can defend it, present evidence that this opinion is correct, and evidence that other opinions aren’t.

With an opinionated mindset in the mix, a decision-making process can get contentious and rather heated. In organizations that overvalue being agreeable, opinionated decision-making may feel like a failure of a process. It may look that way, but it is a definite improvement over the previous two stances. Folks in the opinionated stance often over-identify with their opinions, and understandably infuse emotion into the conversation. When managed poorly, these conversations can get unproductive. However, it is also how we know that we might just make good decisions.

In my experience, I’ve seen so many teams confuse the heat of the opinionated minds grappling around a decision with unproductive decision-making. In the seemingly logical move, people with actual opinions get quietly removed from the conversation, and replaced with folks in an opinionless stance. We are then surprised that our decisions are bland and seemingly random. I would much rather endure cranky engineers fighting over the idea and help them manage their emotions than toss coins into the decision pachinko machine.

Spotting opinionated folks is easy: they usually disrupt a conversation with phrases like “well, that is stupid” or “hey, that’s not right”. This may seem counterintuitive, but these are our markers that we have something valuable: actual opinions. Disagreements are good. First, it means that the environment we’ve created is safe enough to voice these disagreements. And second, it signals that we have a foundation for effective decision-making.

In my experience, when put into the same decision-making situation, folks in opinionated stance and folks in opinionless stance tend to have a strong aversion to each other. From the opinionless stance, the opinionated ones look like rabble rousers and troublemakers, the fire to be put out. From the opinionated stance, an opinionless participant is a dead weight. Their lack of opinion is easily smelled and the bozo bit flipped. When the two are mixed in a meeting, get ready for a mostly dysfunctional gathering, with everyone eventually falling back to the opportunist stance.

🏛️ Principled

An upgrade and likely the zenith of decision-making effectiveness is the principled mindset. When I am in this stance, I understand the problem space enough to see that there are many valid approaches to the problem, and many opinions may lead to a possible solution. I also know that none of these will be perfect.

Instead, I focus on what’s important and let that guide my thinking. Principled stance tends to have a slower start compared to the opinionated stance. In the opinionated stance, I already have my opinion, so I just come out swinging trying to get other opinions out of the way. In the principled stance, I first try to understand the principles: what are the attributes of the solution that are important? What are the desired properties we want the solution to have? I see getting these right as the key part of the process, and folks in other stances may get impatient: what is he doing? Why is he so focused on these silly bullet points?

What I am trying to do is map out the tradeoff space. I anticipate that the ideal solution will not be achievable, so I need to know where I can afford to accumulate decision debt: the downsides of the decision we’re about to make. Because ultimately, all decisions – especially the less-reversible ones – will have unpleasant side effects. Principled stance is about accepting that fact.

Principled decision-making stance typically doesn’t carry the same emotional heat as the opinionated one: there is less identity attachment to the opinion. It feels more deliberate, yet the progress toward the decisions is fairly clear and steady. When most folks in the process are in this stance, decisions are made quickly and they tend to stick.

🌱 Space-holding

There is another mindset that I’ve seen people assume during decision-making: the space-holding stance. When entering a decision-making process while in this mindset, I no longer care about the specifics of the decision. I want to make sure we make good decisions consistently.

This stance may seem similar to the opinionless stance, and because of that, opinionated folks often have an allergic reaction to space-holding folks being present. However, when they get a chance to engage, they quickly unflip the bozo bit, impressed by the fact that space-holding folks deeply understand the problem and can see how a particular opinion fits into the overall problem space.

Primarily, space-holding folks cultivate decision-making space. They help everyone stretch toward the principled mindset. They quickly detect and carefully fence off the opportunists. They give opinionless folks tasks of collecting the data and relieve them of the burden of defending others’ opinions. They disarm pitched battles of opinionated folks with curiosity, separating out the value of their opinions from the opinion-holder’s identity. They help principled folks create and improve upon principles.

I am not that great at holding this stance. When I try to adopt this mindset, I notice that I usually fall into the principled stance, lured by the actual problem that’s being solved. I get too caught up in the what and forget to care about the how. 

In some cases, I crouch into the opinionless stance, where I hold my tongue trying to “let people speak,” becoming a barnacle. Sometimes it’s hard for me to see that “creating space” is not a passive task, but rather a sort of jam session to inspire folks to reveal and present their opinions.

While it would be ideal if everyone made decisions with this mindset, my guess is that the space-holding stance is a combination of skill and probably a unique gift that only a few people possess. 

I’ve had the pleasure of working with a few folks who naturally assume this stance.  It’s a marvel to see them do it. Communities of people sprout around them wherever they go. It’s like they can’t help but create places where people can discuss hard problems and come up with insightful solutions to them. If we are blessed with one in our team, hold onto those people. They are much, much more valuable than they appear.

It is only a while after they leave that we discover that our decision-making grinds to a standstill or becomes political kayfabe. We may not even realize what happened. When did everything suddenly get so political? How did that ornery expert get so downright menacing, to the point where they are shunned by the entire team? Why do our decisions feel so random and never seem to stick?

I hope this little taxonomy helps you get closer to understanding how effective decisions are made. It certainly was clarifying for me.

And oh, look. It’s probably not a surprise, but it’s another transposition of the ADT. The mindsets roughly correspond to the Opportunist, Diplomat, Expert, Achiever, and Redefining-ish stages from Bill Torbert’s developmental stage taxonomy. Hey, if it works, it works.

Shadow Gristle

I’ve been writing a bit of Web components code recently and used Shadow DOM. I am realizing that there’s a fairly useful pattern in incorporating Shadow DOM into Web apps that I will hereby name the “Shadow Gristle”.

First things first. If you don’t like Shadow DOM for one reason or another, this is not an attempt to convince you otherwise. If you have no idea what Shadow DOM is, this will be just a few paragraphs of gobbledygook. Sorry. However, if you do find yourself dabbling with the ye olde Shadow DOM even occasionally, you might find this pattern useful. 

Very simply put, the idea is that we only put the necessary scaffolding code into the Shadow DOM, and leave most of our application code in the light DOM.

When we have the power of Shadow DOM at our fingertips, we have two choices about how we grow the subtree of the DOM elements: one is inside of the shadow tree (in the Shadow DOM), and the other on the outside (in the regular DOM).

So if we want to add another component as a child of our Web component, how do we decide which of the two places it should go into?

My intuition is that placing a child component into a shadow tree is a code smell. It indicates that we  might have lessened our ability to compose elements. There are probably perfectly good reasons to put a component into a shadow tree, but more often than not, it’s probably not the right place.

Child components love light. If they stay in the regular DOM, they remain composable. I can rearrange them or replace them without having to muck with the innards of my component.

Thus, the rule of thumb is: seek to place child components into the regular DOM. Reduce occurrences of them being added to the shadow tree.

So what goes into the Shadow DOM? Mostly gristle. It’s the stuff that connects components together. There may need to be some routing or event handling, and perhaps a few styles to set the foundation. Everything else goes in the regular DOM. For example, I try to avoid styling in the shadow tree. Thanks to the CSS variables, I can use them as pointers and allow the regular DOM tree to supply the specifics.

I hope this little pattern helps you build better Web apps. And yes, the gobbledygook is over now. I promise I’ll write something less obtuse next time. 

The law of tightening aperture

What happens to the teams with wide apertures over time? Does the aperture stay the same? What about the teams with narrow strategy apertures? When I started examining these questions, I recognized a familiar pattern. This pattern seems so pervasive that I will go ahead and boldly proclaim it as a law: the law of tightening aperture. Here it is:

Given a changing environment, the strategy aperture of any organizational unit tends to only tighten over time.

Using super-plain language, the law states that every team’s openness to exploring new opportunities diminishes over time. Every organization that exists today is highly likely to be more strategically flexible than the same organization tomorrow.

💰 The requirement of value

Why does this happen? Strategy aperture appears to be subject to a gravity-like force that can be resisted and sometimes counterbalanced, but never expected to relent: the force of homeostasis. To make it a bit less concrete and easily digestible in the context of this essay, I will rename it to the force of requirement of value.

The requirement of value can be described as a collective expectation that an organization will at some point deliver value. Given how much we put into it, we’d like to receive it back – and get at least a little bit more  (notice how this rhymes with homeostasis). 

There are organizations that don’t have these requirements – but usually, they don’t have strategies, either. In this way, the requirement of value both creates the need for strategy and imposes the law on this strategy. 

The law of tightening aperture applies to any kind of organization, including polities and ecosystems. As long as there’s the requirement of value, the same dynamic will emerge.

The requirement of value doesn’t always come from the need for tangible outcomes (profits, growth, etc.). Team identity can play a big role in the tightening of the aperture. A team that painstakingly discovers who they are and becomes comfortable with that is the team can’t become something altogether different. 

As an illustration, consider Tuckman’s phases of group development model. The “performing” phase is highly sought after and celebrated when reached, yet it is also the one with the narrowest aperture. There is a reason why there’s the “adjourning” or “transforming” stage tacked on at the end: once a team learns how to perform, it must necessarily cease to exist in its current form to do something different. 

Another source of requirement of value might be the collective desire for predictability. This comes up very strongly in the rapidly changing environments. When everything is up in the air, the need for stability can feel existential. This desire may lead to a paradox during the times of change: just when the team needs to keep its aperture wide to better anticipate and see new opportunities, the collective fear of uncertainty will keep tightening the organization’s strategy aperture.

🏛️ Not necessarily a bad thing

Aperture tightening is not always a bad outcome. It might be exactly what we’re looking for. Teams with a narrow aperture are easily pointed at the problems whose shapes are within their aperture. Confidently solving that problem is their unique gift. The key here is to understand and be intentional about the change.

When we seek a tighter aperture, we usually talk about focus. For example, the phrase “more wood behind fewer arrows” heralded such a change for Google back in 2011. Transitioning from a wide aperture to a narrow aperture is often seen as a necessary step to improve a team’s ability to create value efficiently. This is all good. Aperture tightening works out great when the viable niche the organization ended up pointing at is durable in the long term. For instance, it is exceedingly likely that people will want to consume electricity or the Internet for the foreseeable future. No matter how tight it’s aperture, an organization can thrive providing either. 

We just need to remember that – at least according to the law I present in this essay – there will be no easy way to reverse that shift. Becoming more open to contemplating new opportunities is much, much harder once the aperture tightens. If the shape of the industry changes, and the niche shifts, we will suddenly discover that we are unable to adjust, battered by the winds of change and unable to even see them clearly. Like, hey those cassette tapes were cool, but if I built my business on them, I am in for a nasty surprise in the 90s.

⏪ Can the tightening be reversed?

Can the aperture tightening be reversed? Not permanently. As I mentioned earlier, it’s best to view this force as gravity. To keep a soccer ball in the air, I need to exert energy. The default state of the ball is to lay still on the ground. Similarly, the default state of a strategy aperture is to be as narrow as possible. We can resist this force by investing our energy into it, and counteract its effects. But these investments will not have a permanent effect.

Anytime we get an impression that organization has revitalized itself, it is doubtful that this happened to a permanent broadening of the aperture. More likely, a “kick-in-the-pants” event loosened the aperture long enough to spot a new promising similarly-shaped opportunity and allowed re-pointing of the organization toward it. Or perhaps we’re actually observing a wholly different organization, similar in name only – an outcome of (likely painful) transformation. 

As organization’s leaders, when we decide where we want to invest our time, it might be useful to look at where we want to be in relation to our current strategy aperture. Relative to the aperture we have, do we want it tightened or broadened?

If we need a tighter aperture, we must be very careful about embarking on our team-focusing venture: is this a long-term viable niche? If yes, let’s plow ahead. If it is likely to shift (or is shifting already), we are making ourselves more vulnerable to disruption.

If we determine that we need to broaden our strategy aperture, it might be that the entirety of our job will be resisting the law of tightening aperture. This is why leading teams and organizations may feel so challenging and downright futile: we keep trying to walk against gravity. It’s a task that is feasible in the short-term, but not in the long term. Eventually, that soccer ball has to come down.