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.


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.