Category: What Dimitri Learned

The process of inferring a set of constraints with which to communicate a strategy can get pretty overwhelming, so I made this handy little framework for enumerating them. It’s not a complete taxonomy, but hopefully it’s generative enough to get started.

When looking for constraints, I use a riff on Lawrence Lessig’s pathetic dot framing. Think of constraints as loosely bunched into four different forces that press from every direction: capabilities, rules, norms, and incentives. Their sum is what defines the game being played.

From the bottom, we are supported — and limited — by our capabilities. These are our team’s strengths and weaknesses and understanding them greatly helps us assess our potential. What is the team’s mix of senior and junior members? How do their collective skills map to the challenge at hand? What are particular things that make this team unique? What are the known failure modes the team might be susceptible to?

At the top, there are rules that are imposed on us by the environment. These could be related to funding or deadlines, or priorities of the larger organization. Market and ecosystem forces also fit in here. A good way to spot these kinds of constraints is to look for things that we perceive as happening regardless of our attempts to control them. These are our threats and opportunities.

Forming the vertical axis, rules and capabilities are in tension with each other. Usually, one acts as a limit to another, establishing dynamic equilibrium. If there’s no such equilibrium between these two, it’s not a game. When listing out rules and capabilities, make sure that the sets feel roughly evenly matched. Otherwise, we might be deceiving ourselves about the nature of the game.

The horizontal axis captures constraints that reflect dynamics within the team. Just like with the game axis, these forces are in tension. If they are mismatched, there is no team.

On one side, there are incentives. Incentives are what drives individual agency within the team. In this bunch, there are constraints that define the reward system for the team. How do the individuals know if they are succeeding or failing? How do they know whether they are progressing along their intended career arc? Are they making the kind of impact that is aligned with the team’s objectives? This one can be tricky. For example, in larger organizations, the incentive structure is commonly imposed centrally, which means that the team leads might find that their objectives are often at odds with that structure (like the “I don’t want to work on this project, because there’s no promo for me in it” case). In such a case, those are better viewed as rules (the top-down arrow), rather than team incentives.

On the other side, there are norms that bind us together. “Bind” is the operative word, because the thing that binds us always acts as a constraint. Cultural norms define what’s acceptable and not acceptable within the team. Norms are tricky, because “culture” has developed a bit of a duality in modern organizations. There’s the norms that we’d like the team to have and there are the norms that exist. If we use this exercise to evangelize the former, we might arrive at communicating a strategy for some other, imaginary team. For example, if we aspire to triage bugs within 24 hours as a team, this is not a constraint. Instead, the constraint is the actual time it takes today — our norm. 

As we enumerate constraints, a picture of the playing field emerges. If our norm is that it takes us 7 days to triage a bug, yet one of the looming threats is our customers consistently finding our support levels lacking, we look to the counterbalancing constraints. For example, there might be incentives or capabilities we underutilize that we could lean onto — and this thinking process leads to generating various plans to accomplish that. Add a solving diverge-converge exercise to pick the best alternative, and now we’re cooking with gas. Shifting from plan-based strategies to constraints-based strategies creates more cognitive load on the team — planning becomes a much more distributed process — but it also dramatically increases the team’s capacity to navigate flux. More importantly, understanding constraints creates a space for team leaders to examine them and mutate them to intentionally change the game.

A click up from a plan is communicating strategy as constraints. When plans are constantly stymied with change, we start seeking the means to describe this change in terms of invariants. We climb up the abstraction ladder to see if there’s less flux up there. Constraints are usually what we encounter next.

An easy way to grok constraints-based strategy communication is to look at sports. Sports are games with well-defined constraints: what’s allowed and not allowed, how one is rewarded or punished while playing. Like structural beams of a house, constraints frame the problem space.  If the constraints are stable and well-rounded, we humans are exceedingly good at discerning, adopting them — and adapting to them. Constraints also serve as generative sources of plans. Instead of having just one plan that is created each time, a good coach will have a whole playbook of plan templates drilled into their teams. When the game begins, there is no one Big Plan: instead, plans emerge and evolve from the playbook’s templates. My friend Alex Russell had this really nice “beat saber block” analogy. When the team communicates their strategy in terms of constraints, plans — like blocks from that VR game — materialize a short distance out, while being informed by a larger arc of the story, framed by constraints.

That’s what makes communicating strategy as constraints so much more effective than producing plans — and also a lot more challenging. To communicate them, a leader needs to first devise a set of constraints that capture the nature of the game they want to be played. This requires strategic awareness, rigor, and patience. Though my inner game designer momentarily rejoices at the opportunity, it’s incredibly difficult in my experience. Instead of inventing a new game, this effort is mostly about inferring some semblance of stability out of the churning stew of the environment. As a result, most constraint sets come out dismally misshapen in their first iteration.

Usually, they are leaky. For example, imagine that I provided a constraint that the score is only awarded when the hockey puck crosses the goal line, but forgot to specify the size of the goal. It is fairly easy to see how an overly clever team might be tempted to bolster their defenses by shrinking the goal to be smaller than the puck — this may or may not be a true story from my childhood.

They also tend to be either too specific or too broad. Go too specific, and you’re back in the plans territory. Go too broad, and the constraints are no longer useful. In one of the dimmer moments of my career, I once proclaimed that the goal of our team would be to “not screw it up” in the next year. Great! What does that even mean, oh fearless leader?! 

An experienced leader — just like a seasoned coach — usually carries a playbook that allows them to sketch out a decent initial set of constraints for any team. However, I found that getting constraints to the point where they’re stable and well-rounded is something that can only happen by the team collectively participating in refining the rules of the game by which they play.

A colleague asked me this great question: “What’s the difference between a strategy and a plan?” Put very simply, a plan is one way to communicate a strategy. But you know me, I want to get at the subtlety of what this implies.

First up, semantics. I found that when people say “strategy,” they usually mean one of two distinct things. One is the business strategy, which is a whole discipline about the means to obtain durable differentiating business outcomes. This field is well staked-out and I don’t want to trespass there. The other one has a more generic meaning, as in strategy games or strategic thinking, which is usually associated with seeking some long-term outcomes through a series of short-term actions. That’s the one I want to play with.

Applying this definition, most of us operate with some sort of strategy in mind. Unlike that forgetful fish from Finding Nemo, we wish for what we did today to contribute to some longer-term objective. When we believe that it didn’t, we feel like we wasted our time. When we believe that it did, we feel more content: things are going our way.

Working as a group, our good fortune depends (among other things) on how well our actions align toward a common goal. This alignment is an emergent phenomenon: if we end up pulling all different directions, we might be trying really hard, yet make no progress toward the goal. Conversely, we race toward it when we’re aligned. A team leader’s key challenge is making sure that a) there is a high degree of alignment and b) the team’s common goal matches the desired outcomes the leader has in mind. 

Somehow, the leader needs to ensure that when team members act in the short term, their actions add up to positive momentum toward where the team is asked to go. Somehow, they need to communicate their strategy: transfer the necessary parts of their strategy from their minds to the minds of the team members.

Plans are an ancient and probably simplest method to do this. Outline all the steps that the team needs to take to get to their objective and communicate them in a resonant way — usually many times over — until everyone on the team knows what they are. Plans are amazing, because all we need to do is follow the steps and if we do, we know we’re going in the right direction. They are exceedingly effective in environments where the validity of the strategy can be easily verified. For example, if I walked through a maze and wrote down all the turns, you can follow my plan and know for certain whether it works. From there, a previously treacherous puzzle becomes a slightly annoying routine for everyone who follows the plan. In such a setting, the plan is the strategy.

In more fluid environments, plans tend to rapidly lose their effectiveness. When we don’t know if the maze stayed the same since the last time we traversed it, communicating strategy needs to mature beyond plans. The leader has to transfer not just a particular solution to a particular maze, but the means to solve any maze in a consistent and safe way. To meet their challenge of alignment, they need the team to continue making progress toward the long-term outcome when the circumstances change: collectively inching toward the exit even if the walls in the maze shift and mutate.

So, when we’re looking at a strategy artifact, here are some questions to reflect on. If it looks like a plan, are we operating in a stable, predictable environment? Can we quickly validate that this is the right plan? If so, we’re probably set — let’s go. Otherwise, we are better off stepping back and investing a bit more time into considering how might we share our mental model of the environment with the team to empower them to create and change their plans on the fly in a way that’s still compatible with our strategy.

I wrote this one primarily for myself, though I believe it’s good advice for anyone who’s ever found themselves in a leadership role in today’s work environment. Here it is: slow down.

I am not talking about taking some time off, going on a digital vacation, or just relaxing a bit in the evening and doing some light reading. Those things are great and important parts of our lives all in themselves. When I say “slow down,” I mean slowing down at work: to remain surrounded by work, but take time to reflect on what’s happening. When I was developing my self-work routine, I had this metaphor of a riverbank that might be useful here. Slowing down means stepping out of the turbulent river of our daily work and sitting on the riverbank for a little bit. Pause. Look around. Are we still going where we want to go? Or are we being carried by the river?

Think of it this way: we’ve learned to go fast, we’ve honed our effectiveness, ways to put the pedal to the metal. Today, our problem is not that we are lazy. It’s that our undercurrent of achieving is too strong. Through this lens, procrastination can be a shaming word for having patience to let the solution reveal itself. And when we start getting worried that we’re not achieving fast enough, we get further trapped in the churn of the river. 

In Adult Development Theory, there’s this notion of fallback. A metaphor for it that I really like is that our minds are houses with rooms, where some rooms become inaccessible during fallback. It’s like we know our house has them, but we just can’t find our way to them. So while in fallback, if we want to go to the Strategy room and do some long-term thinking, we keep finding ourselves in the Tactics room, covered in glitter and glue of the short-term fixes. There are many causes of fallback, and in my experience, the achiever stress is not an uncommon one.

As we fall back, our perspective narrows. We can no longer see options and opportunities that are locked away in those now-inaccessible rooms, and it feels right and natural to just keep doing what we’re doing. A deadline is coming up, so of course we need to jump on that. Our colleague needs to meet, so yes, we’ll find the time. And as we just keep on swimming, we find our schedules getting busier and pace continuing to rise. We keep going faster and faster. In the moment when we need to open some space to think, taking an even little pause feels like the wrong thing to do: who’s going to do all this work?

Those of you who work with me know that I have my late Friday afternoon blocked off for reflection. I have three questions that I pose for myself. They are loosely: 1) what did I do this week? 2) am I losing sight of the big picture? and 3) what might I change in how I conduct my next week? This is my time to slow down. No matter how high the fires are, and how urgent the pings to meet, I try to spend this time sitting on the riverbank. Sometimes it doesn’t work, though over time, I am realizing that the trick is to keep trying. Keep trying to slow down.

We had a bit of weather recently, and while waiting for electricity to come back on, I found myself flipping through the pages of The Timeless Way of Building by Christopher Alexander. I was re-reading the chapter about the structure of patterns when something clicked. I realized that patterns and well-learned organizational principles are very similar in structure.

Principles are a big thing in today’s organizations. Most want to have them, yet few get to benefit from them. It is fairly easy to list out a bunch of “things we wish to be true”. But how do I make them actually useful to my team? A sound principle is like a pattern in this regard: it helps navigate a tension that is otherwise difficult to grasp. A principle is only an aspiration if it simply points at the desired destination without doing the hard work of capturing the challenges that will make reaching this destination difficult. Put it differently, if a principle doesn’t wrestle with some tension, it’s probably not a principle.

Borrowing from Alexander’s playbook, my guess is that a sound principle will have this structure: it will begin with the context, describing the situation in a way that is resonant to the team. Then, it will point out the forces that are present within this context — these forces are usually in tension with each other. Then, it will provide guidance (Alexander calls it “configuration”) on how to navigate this tension. Another thing that stood out for me was Alexander’s pursuit to get the name of the pattern right. Similarly, the few words that capture the nature of the principle will become the team’s shorthand, the intuitive handle. It’s worth a bit of extra wordsmithing to make that handle fit like a well-built tool in the team’s collective minds. 

To play with this idea, I decided to use a principle from an org I used to lead. We dubbed it “Treat 1P like 3P.” It was a simple phrase, but it seemed to have been useful: it helped resolve conversations about priorities, serving as a planning and strategy tool. Let’s see if I can retcon that principle into the structure above.

We’ll start with framing the broader context.

Our team ships a developer surface to both internal and external customers. We are at the early stage of our journey, where most of our customers are internal, but we expect the ratio to shift toward external customers over time. The internal customers sit right next to us. We know their workflows and tools. We work at the same company. We  can talk easily to them and partner with them as well as coordinate our plans. The external customers work at other companies, and we often have no easy way to communicate with them. At the start, we only have some guesses about what tools and workflows they might use, but we know for sure they will be different from the custom stack of our internal customers.

Next, we point out the forces that operate within this context. There are two: availability bias and technical debt.

Availability bias. Proximity, familiarity, and general alignment of values creates an incentive toward first-party customers. The path of least resistance leads to shaping our developer surface closely to fit the tools and workflows of internal customers.

Technical debt. Knowing that the internal/external ratio will shift over time, we need to be cognizant that overfitting to the needs of internal customers will incur the cost of painful future migration to a more flexible architecture.

Now that the forces are defined and it’s fairly easy to see how they are in tension, let’s provide guidance on how to navigate that tension.

We recognize that the availability bias is a short-term force, and technical debt is a long-term force. We expect that the short-term force will generally prevail in day-to-day decisions, so we lean a bit toward the long-term force. To do so, we treat our internal customers as if they were a kind of an external customer. We avoid embedding any special knowledge of the internal customer-specific stack. We do research on other potential stacks and ensure that our architecture is flexible enough to support them.

Finally, the handle. Within our team, we called internal customers “1P” and external customers “3P,” so “Treat 1P like 3P” ended up working nicely: it was easy to say and remember while conveying the gist of the guidance.

Looking back, this is not how I structured the principle. Instead, it was just a brief paragraph of words beneath the title. But now that I’ve gone through the exercise, I am noticing something interesting: I want to argue with my past self about the context and the nature of the forces that I was seeing back then. This is probably the most powerful part of structuring principles like that: it allows your team to examine the principle, understand how you arrived at it, and help you make it more sound by presenting their own perspectives. 

There’s this fairly common technique: the diverge-converge exercise. I first heard about it when learning about design thinking, and now recognize it in other places. The gist of it is fairly simple: break down your thinking process into two distinct phases. In the first phase, encourage divergence of ideas to broaden the space of possibilities. In the second phase, study this space to converge on one artifact that best satisfies the intended objective of the exercise.

When working on a decision-making framework, I realized that there are two distinct kinds of this diverge-converge exercise, each with a different goal. I am going to call them “framing” and “solving”. As I implied before, the first one roughly maps into the Complex Cynefin space, and the second one into the Complicated.

The solving diverge-converge exercise is the one that I see described most commonly. Invest a bit of time in the “diverge” phase to generate a rich pool of possible alternatives, then compare them to pick the one that works best in the “converge” phase. A typical engineering doc that’s an outcome of the solving diverge-converge exercise has several alternatives listed with pros and cons, and a discussion followed by a decision to pick one of these alternatives. This kind of diverge-converge exercise is very much about finding the best fit, and it benefits from having a strong fitness function that guides the process of making the pick.

The framing diverge-converge exercise might seem similar, but has an entirely different mindset. Here, the “diverge” phase is meant to collect perspectives that all describe something that’s difficult to see from just one side. When framing, the “converge” phase is no longer about picking the best fit. Instead, it’s the process to see the larger picture, incorporating all perspectives, studying the differences and similarities between them to synthesize a larger perspective. A typical artifact here is a problem statement doc, describing multiple perspectives of the stakeholders and outlining how they relate to — and interact with — each other, along with the outline of the synthesized larger perspective. In the framing diverge-converge exercise, the choices aren’t narrowed down. Instead, they are used to improve the understanding of the space.

When trying to compare the two kinds, the blind men and the elephant parable comes to mind. When applying the solving diverge-converge exercise, the big question will be whether it’s a fan, a snake, a tree, or a wall: we have to pick one. When applying the framing diverge-converge exercise, we might actually see the elephant.

Another kind of story that I’ve encountered in my exploration of coherence narratives is the story of agency. Again, it’s loosely borrowed from the Four Needs Framework and plays a catalytic role similar to that of the story of belonging.

The story of agency is all about going it alone. It’s about striking out on my own, finding our own path, independence, and self-sufficiency. It can also be about perseverance, toughing it out, defending, and standing tall.  The story of agency is deeply woven into American culture, celebrated on July 4, in remembering the Alamo, and oh so many movies with a lone heroic protagonist.

Just like the other catalyst story, the story of agency leans on the structure of another story. Combined with the story of an opportunity, it celebrates uniqueness and breaking with convention as the precious ingredient. Mixed into the story of a threat, it uses the same qualities to draw the bright line between life and death.

Looking at various organizations, I am picking out two distinct patterns. First, the story of agency often plays a role in diminishing coherence. It is the story of break-ups, of abandoning the common goal, of “this is not working out.” Behind every tense conversation, irreconcilable disagreements, and teams deciding not to collaborate lurk stories of agency.

Second, the stories of agency and belonging tend to blend into this curious nested-doll relationship that increases coherence. The story of agency provides the lens to evaluate the external environment, while the story of belonging sets the tone for internal: “we come together to be unique and different from others.” This is also a very common strategy in marketing. Apple’s “Think Different” poster immediately pops to mind when looking for an example of such a nested doll. I buy your product to stand out, while at the same time becoming part of a group.

Through this symbiotic relationship of two stories, organizations and any groups of individuals create boundaries. The story of belonging is what defines the in-group, and the story of agency — the out-group. The story of a threat, catalyzed by the in-group’s story of belonging, is often based on the story of agency: the threat from whom? — the out-group, of course.

For example, a team’s narrative might be about building something truly revolutionary (story of agency + story of opportunity) while persevering in a rapidly shifting, or even hostile conditions (story of a threat + story of belonging). If such a narrative is particularly resonant and crisp, it tends to live for a very long time, sustaining coherence of a group and becoming this group’s identity.

Suppose you’ve said to me that “the falling maple leaves whirl in a delicate dance with the gentle breeze.” It’s late fall, so it feels like a reasonable thing to say. The trouble is, my language only has words like “eat, fight, run, here, that, there, now, later.” I might be fascinated by what you’ve said, but get very little out of it — and even less to pass on to others. At best, I will point at the sky and say “that!” and bulge my eyes meaningfully.

This might seem like one of those — duh! — obvious observations. Of course the language frames the story. However, I am finding that I easily forget this in the contexts of teams and how they are organized. To communicate with each other, teams establish a common language, a set of semantic shortcuts that allow them to work together effectively. This is where the non-obvious bits hide. This common language also frames what is being communicated.

For example, let’s imagine a hypothetical organization where communicating strategy across teams is done through a list of annual objectives and key results (OKRs). There is a process to assemble them into a coherent whole. When it’s all said and done, the story written in the language of OKRs tells where we will go next year.

However, some of our desired destinations take longer than a year to reach. To communicate these destinations, we need a language that can describe ideas that last longer than a year. Can you guess what happens when we try to express them in the language that only speaks in year-long sentences? Sure, within teams there might be long-term thinking and sound strategic artifacts. However, given the pidgin of annual OKRs that prevails outside, it is unlikely that these artifacts survive cross-team communication. The multi-year ideas will be neatly chopped or scrunched into the one-year box — rendering them as useful as my eye-bulging-while-pointing.

If I am lucky enough to work in an organization full of brilliant individuals, I will also start seeing these folks adapt to the common language. More and more, I will see how they pick out ideas that fit within the language to reduce the friction, making sure that only year-long journeys are those that count, whether in impact or attention of leads. Sure, there will still be the linguistic idealists who rail helplessly trying to overcome the limits of the OKR pidgin, but those will eventually give up and leave.

While the organization wonders why it struggles to think strategically, it might be worth it to examine the language it uses to organize itself. Is the language flexible enough to accommodate both short-term and long-term destinations? Are all ideas that matter expressible in the semantic shorthand that everyone is expected to speak?