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.
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.
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.
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.
