TBM 379: Vertical vs. Horizontal Org Coupling

Sharing a 2x2 I’ve found useful lately (and wrong, of course).

A couple of things stand out.

Perspectives

Perspectives differ! It can be tempting to fall into the trap of believing that everyone in the company sees the company in the same way. For example, leaders are often insulated from high horizontal coupling. They see their role primarily as finding the sweet spot between low and high vertical coupling (connected enough with the big picture, but able to move fast and innovate). Meanwhile, on the front lines, people are swimming in dependencies. When things get bad, they might even crave some top-down control (“at this point, some command and control would be welcome!”).

Control vs. Coupling?

“Control” and “Top-down” are heavy words. But by “coupling,” I am trying to explore how tight the connections are vertically and horizontally. You could have a Command Towers model that was very empowering, in fact. Maybe I’ll revise the diagram to address coupling more directly (and avoid the confusion of the direction of control, e.g., top-down, and the degree of coupling). It might be worth another diagram.

At What Cost?

In many ways the real issue isn’t simply low or high coupling, but low or high at what expense. A company might achieve vertical cohesion in a way that feels effortless and cheap, or it might achieve it through heavy-handed control. Similarly, teams might manage dense dependencies through ruthless prioritization and focus, or find themselves constantly gridlocked.

Movement

During ZIRP, it was possible to absorb the inefficiencies of low horizontal/low vertical coupling. It was far easier to hire up a new team and give them unspoken permission to work around other teams and go rogue than it was to address horizontal dependencies. As long as things kept going up and to the right (for whatever reason), you were good. Over the last couple of years, we’ve observed the following cycle:

1. Start with Federated Islands

2. The org starts drifting into Hands-Off Gridlock as dependencies increase. Leaders are mostly distanced from the gridlock (they believe they’re still operating as Federated Islands)

3. Repeat efforts to solve the issue in the Locked Grid as tension/pressures rise.

4. Eventually, there are efforts to remove dependencies, and we see a shift to the upper left (Command Towers)

5. Gradually, during the next up and to the right macro cycle, there’s a drift down to Federated Islands.

Not Monolithic

An organization is not monolithic, and rarely static. You might observe some parts of the organization operating one way (e.g., strong top-down control to manage dense cross-team dependencies). At the same time, they insist on launching speedboat efforts through Federated Islands and an innovation or “New Ventures” program. Two very different motions.

This goes on for some time until the chaos of the innovation program starts bubbling over and drifting into Hands-Off Gridlock. Similarly, you might see Sales work in a Command Towers model with very distinct regions and segments, while product development oscillates between Federated Islands and Hands-Off Gridlock. This works until there is a swing back from multi-product to something more coherent (with less overhead due to redundant functions).

Cohesion?

Cohesion is sitting in the background here too. Think of the classic trade-offs:

1. High cohesion + low coupling → focused teams with clean boundaries.

2. High cohesion + high coupling → strong units, but tightly interdependent.

3. Low cohesion + low coupling → loose, fragmented efforts that may lack direction.

4. Low cohesion + high coupling → brittle systems where messy teams are locked together.

No Box Is Universally Bad

I tried to make it so that no box seemed universally bad. You could argue that Locked Grid is universally bad. Still, if you imagine a company adding high vertical coupling to get itself OUT of the upper right, then you could picture a scenario where a team is just “passing through” any of these boxes. It is about inertia and direction. You might need high vertical coupling to withstand high horizontal coupling.

Enterprise vs. Startup

A lot of enterprises are stuck with their high-level horizontal coupling. But it should be noted that startups often struggle with too little horizontal coupling. It hurts the customer experience. It is costly and inefficient. It makes it hard to do ambitious things. So while it might seem that the high horizontal coupling boxes are universally bad, it is probably best to imagine it as a spectrum and range. Similarly, too little vertical coupling, and you’re liable to have challenges with org-wide focus.

That’s it for this week!

PS: Want to see a neat Miro board?

TBM 378: How To Effectively Pitch Constraints

Time to crack open the crazy Miro board!

Mapping Company Operating Systems (FREE, 90 Minutes)
Sep 18, 2025 08:00 AM Pacific Time | 4PM London
In this session I will describe various techniques for mapping your company operating system. We will explore different "frames", visualization approaches, and core concepts. I'll leave a full thirty minutes for questions.

---

And now on to our regular programming…

One of my biggest personal career challenges has been advocating for the smart use of constraints. I strongly believe in concepts such as work-in-progress limits, planning-in-progress limits, force-ranked prioritization, getting extremely crisp on ICPs, zero-bug policies, andon cords, having a single roadmap (not two, one for engineering and one for product), "start together", maximum initiative sizes, etc.

For whatever reason, I'm wired to advocate for enabling constraints. Maybe you are too! Or you aren't, and get annoyed by people like me. In which case, this post might also be interesting.

In this post, I try to move beyond the logic of constraints and get into the messy reasons why people resist the idea of constraints and what you can do about it.

Some Examples

Let's get started with some examples. As you read these examples, consider why teams were met with constraint resistance.

WIP Limit Debate

I tend to advocate for WIP limits. Managers (and leaders) challenge me by asking, "What if we could do more stuff while blocked?" or "How about when people want to multitask?"

To them, the constraint seems forced and arbitrary. To me, it looks like a catalyst.

To them: just another rule, or something good people shouldn't have to think about. To me, it is a valuable, designed constraint we can use for continuous improvement.

To them, it is better to estimate, size, and try to fit it all in. To me: that's even more arbitrary! People are resourceful. If they do finish something, they'll figure out what to pick up next.

Discovery WIP Limit Debate

I met a team recently with a cool constraint/forcing function. At any given time, the team limits itself to doing discovery on 2x the number of work items that typically kick off in a month. The 2x factor is based on the fact that they tend to discard ~50% of the things they research/assess. So if the group starts five things a month on average, they can only be doing discovery on ten opportunities.

The big challenge they initially faced with this scheme was that the organization was obsessed with long planning horizons and annual planning. All the incentives in the organization pointed to big discovery blocks to dream up work based on some kind of idealized, historically impossible flow of work. You had teams that started the year with a rosy picture of tackling 20 initiatives, and ended the year having finished 5, imagining that somehow they'd magically defeat the laws of physics and "sign up" for 20 again (involving a lot of discovery). Meanwhile, from a flow perspective, it was only really necessary to carry N things in the discovery column of their kanban board.

It took a lot of influence and persistence to shift the org to its new approach.

Prioritization Choice Debate

Or take the example of your average PM looking for leaders to make some hard decisions on prioritization (to create a constraint, essentially). When you enter these discussions, you try everything in your power NOT to go down the road of estimates, who works on what, etc. That never ends well—it ends up back where you started, wasting everyone's time.

Yet, from the leader's perspective, it feels completely natural to say, "Why not both?" We're wired to try to make it all work. "What if _______, and what if _________, if maybe we ________ and _________, then we don't need to decide between X and Y!"

So why does this happen?

These responses have as much to do with personality, experience, and decision-making styles as anything to do with logic or whether the constraint actually works. People vary in their comfort with abstract rules, their need for concrete details, their tolerance for ambiguity, and their willingness to accept external limitations.

Loss Aversion & Optimism

Leaders often resist constraints because of loss aversion. Saying "no" to a project feels like closing a door, and humans are wired to avoid that sense of loss. People will even waste resources just to keep options open, even if it makes the overall outcome worse. A broad heuristic, such as a WIP limit, directly challenges this instinct by forcing choices and making trade-offs explicit.

Leaders also routinely underestimate how long things will take and overestimate their team's capacity to do more with less. Optimism bias creates the belief that "this time will be different" or "our team is exceptional enough to defy normal limits." Constraints that point out realistic limits can feel unnecessarily pessimistic or restrictive. Combined with natural conflict avoidance, constraints often get dismissed as "too arbitrary."

Advocates of constraints aren't necessarily wiser; they've simply experienced enough of the upside to override the usual human biases. What once looked like a loss of options now feels like a gain in flow and clarity.

Comfort with Concreteness/Abstractions

Some people thrive on specifics; they want the details of exactly what initiatives or tasks are on the table. That's how they feel comfortable making decisions. A constraint like a strict work-in-progress limit might feel like just another rule to either follow rigidly or circumvent with detailed exceptions ("What if we do extra work when blocked?"). They'll resist a simple heuristic constraint unless you provide evidence and specifics.

On the other hand, some folks are more comfortable with ambiguity or with abstract thinking. They can operate on principles, on high-level concepts, and they don't necessarily need to anchor their decisions in the nitty-gritty details. A conceptual decision-maker or an analytical big-picture thinker may see the value in a constraint as an elegant principle or heuristic, and be willing to tolerate the ambiguity it introduces (trusting that it will pan out in the long run).

Experience

Experience cuts both ways when it comes to constraints.

On the one hand, seasoned people often see the value of a well-designed constraint because they've lived through the chaos that emerges without them. They recognize how a simple forcing function can free up attention, reduce waste, and sharpen focus.

On the other hand, that very experience can also make them skeptical. Having developed strong personal discipline, routines, and coping mechanisms, they may view external constraints as unnecessary training wheels or bureaucratic overhead that interferes with their judgment.

What feels like elegant design to one person can feel like condescension or red tape to another.

This duality means that experience doesn't map cleanly onto constraint acceptance or rejection. The same leader may embrace constraints in one context where they clearly unlock flow, and resist them in another where they feel imposed or artificial. A veteran may lean on them as enablers or dismiss them as shackles, depending on whether they think the constraint enhances or undermines their own hard-earned autonomy.

So what?

Hopefully, I've demonstrated that you can't just make a logical argument for using certain constraints. What makes sense and seems logical for you might be the exact opposite for someone else. In fact, it might be threatening!

To pitch a constraint, you have to move way beyond explaining why this book said this or that book said that. It doesn't matter if you have decades of queueing theory behind your case! It doesn't matter if you have math on your side!

Many managers resist constraints not because they fail to understand the logic, but because following an imposed rule threatens their sense of autonomy and competence. Resistance goes up based on the importance of the freedom being curtailed and the arbitrariness of the restriction. By their very design, many constraints ARE "arbitrary".

For a concrete-minded audience, provide concrete case studies and observable proof that the constraint works (speak their language of specifics).

For someone comfortable with abstraction, consider framing the constraint as a principle or heuristic to experiment with. They'll often accept the idea without needing every detail spelled out.

For an autonomy-driven audience, involve them in setting the constraint or emphasize how it empowers rather than restricts. Set an expiration date.

For highly experienced veterans, acknowledge their expertise and position the experiment as a mentoring opportunity: "You already know what good flow looks like — let's try this so others can see it too."

For the maximizing leader who insists on going over all the details and always asks, "Why not both?":

• Frame constraint as maximizing. Don't call it a constraint; call it the "optimal path" to get more done faster.

• Make it their idea

• Acknowledge their intent. They want to maximize value and not leave opportunities on the table. That is a valuable tendency!

• Try to make it empirical, not arbitrary. Frame constraints as efficiency experiments with measurable outcomes (e.g., "let's compare delivery time with and without a WIP limit").

• Show how "doing both" actually slows everything down (e.g., more items in play = longer cycle times, less throughput).

• Channel their thoroughness. Suggest a time-boxed sweep through all items, then agree to carry forward only the top N.

TBM 377: Time Allocation ≠ Capacity Allocation

Before we jump in: September Conferences!

I’m heading to Enterprise Tech Leadership Summit in Las Vegas: September 23–25, 2025. I’m a huge fan of Gene Kim’s work and the community he has created. Dotwork is sponsoring, so I’ll be “working the booth.” Drop by if you’re around.

I’ll also be in Cleveland next week (9th and 10th) for Industry. Would love to meet people in person.

---

Lately, I’ve been researching the mental models, mechanisms, and reporting practices behind ‘capacity’ allocation. At the day-job I have to figure out how to walk a tightrope between what our customers ask for, and what will ultimately help companies.

Spoiler: the concept of capacity allocation is fraught with misunderstanding, and companies waste a lot of money (and do a lot of damage) by mistaking time allocation for capacity allocation.

The time-as-capacity mental model is straightforward: ‘Where do we put our time?’ Five people working 40 hours equals 200 hours to divide up. Go! You allocate capacity by deciding where to spend your time, and you report on capacity allocation by tagging the time spent by theme, bucket, category, etc.

But capacity allocation is much more nuanced.

A team (and the technology it relies on) holds a kind of potential energy that can be directed in different ways and shaped by context. From this perspective, capacity allocation is not about tallying hours, but about deciding and continually improving how we direct that energy.

This view has a strong foundation in lean manufacturing and the theory of constraints.

In a manufacturing context, capacity usually starts with the theoretical maximum output under ideal conditions (known as design capacity). But what matters more in practice is effective capacity, which takes into account factors like scheduled maintenance, breaks, supply chain delays, changeovers, quality checks, and staffing fluctuations.

Lines are also optimized for certain products, and shifting that mix can be costly. So if you asked, ‘Where did we allocate capacity?’ the answer would look less like counting hours and more like how we balanced product mix, changeovers, downtime, equipment availability, and demand fluctuations. Let’s be clear: there’s ALSO a strong emphasis on efficiency, analyzing how people spend their time and where that time gets wasted, but it is put in a broader context.

Here’s what is hard to explain to the well-meaning finance person slacking you with “I just need to know where we allocated our time/salaries in the last quarter!”

When you pay the salaries of a product team, you’re not just buying hours; you’re investing in a system. You’re funding the design, upkeep, and improvement of the ‘factory’ that produces outcomes. Who you hire, the scope and evolution of the team, how you build and maintain your codebase, how you mentor and train people, and the decisions made over the last three years all shape the team’s true capacity.

And importantly, capacity today is the result of past investments coming to bear. A stable codebase, good tooling, healthy team dynamics, and accumulated product knowledge make today’s work possible. Looking only at this quarter’s time allocation misses both the investments that built current capacity and the investments being made now to improve future capacity.

I’ve concluded that the only way to address this is to be very clear about the distinction.

TIME allocation is simply where the team invested its hours, or predictions about where those hours might go. That’s it. It tells us nothing about the quality of that investment.

Capacity allocation is a more nuanced discussion about the team’s true ability to deliver outcomes. It is shaped by interruptions, rework, dependencies, team composition, and the investments that build or erode long-term capacity.

Time is only one input. Capacity allocation considers the whole system.

Also, critically, you need to be honest! Most efforts to understand time allocation focus on only 1-3 of the categories below and call that “100%”:

• Dedicated Projects. Focused work on a defined project for weeks.

• Request Streams. Steady flow of repeatable requests.

• Streak of Stories. Small independent (releasable) tasks aligned to a bigger initiative.

• Firefighting / Stabilization. Fixes and incidents post-release.

• Maintenance / Upkeep. Routine system hygiene and fixes.

• Exploration / Spikes. Short research or experiments.

• “While You’re There”. Opportunistic cleanup during other work.

• Helping / Informing Others. Answering questions and unblocking peers.

• Customer Interaction. Research, support, or user contact.

• Meetings / Admin. Rituals and administrative overhead.

• Deployment / Release. Shipping software to production.

• Reviews. Feedback on code, designs, or docs.

• Tooling / Setup. Environment and pipeline setup.

• Context Switching / Waiting. Lost time from juggling or delays.

For example, on paper Irene was ‘allocated’ to a project for 80% of the week. In reality, much of her time vanished into waiting for CI/CD pipelines to run, wrestling with confusing code, interrupting others because of outdated documentation, struggling with her tooling and environment, and retraining her focus after constant low-level interruptions. As she put it, ‘Nowhere in the spreadsheet did I have an opportunity to tell people that those 30 theoretical hours were terribly ineffective.’

In another example I’ve shared often, these two teams in the same company had very, very different profiles in terms of actual time allocation.

So, in short, after thinking about this for a while, I think the only real solution is to make a conscious effort to decouple time allocation from capacity allocation. Use different words. Then, and only then, can we start having honest discussions about impact, efficiency, and productivity.

Don’t say capacity allocation when you mean time allocation.

And when you start having honest discussions about impact, efficiency, and productivity, then outside of maybe high level breakdowns for accounting purposes, you start worrying way less about time allocation.

TBM 376: Why Are We Organized Like This?

This post is about understanding why your company is organized and designed the way it is.

Which of these nine patterns looks familiar?

Mix and match if you like. I have framed each section as a quote, pulling from my notes from calls with leaders, managers, and ICs. Sometimes I combine two or three quotes into a good representative quote.

1. Game of Thrones

When politics and power plays shape the org

The org looks the way it does because of people, not principles. A couple of execs negotiated their titles during hiring, spheres of ownership shifted after turf wars, and we've been living with those decisions ever since. Honestly, our org design reminds me of Game of Thrones. It feels like a direct result of internal competition and factional conflict.

You can actually see the shifts: for a long time, it was the former CEO's way, with all of their lieutenants, and then there was basically a coup as the founder regained control with their favorite old-timers. People go in and out of favor, and the Eye of Sauron always seems to be looking for the next leader to scapegoat. In the end, the org designs the narrative battle, and whoever is on top at a certain point in time.

Survive: Watch the factions
Thrive: Build alliances carefully
Hack: Control the narrative before it controls you

2. Buzzwords’n’Decks

The next big fad

A couple of years ago, we had McKinsey come in, and that kicked off a big re-org around whatever was the latest hotness. Some good things came from that, but we also moved a lot of deckchairs around. We didn't really touch the heart of the issue, which is that our decision-making is painfully slow. Deep down, the company is unwilling to take significant risks that might move us away from the cash cow, so every major decision gets bogged down in endless debate.

And the truth is, it's always about a buzzword. Whatever buzzword catches on becomes the obsession, and that's all people talk about for a couple of years until the next buzzword takes over and the cycle starts again.

Survive: Speak the language of the fad
Thrive: Package substance inside the buzz
Hack: Ride the wave, then quietly pivot to real work

3. "It Just Happened" (And Happens)

Lots of small, generally coherent decisions

To be honest, it mostly emerged organically as we scaled. We had some key people making architectural decisions that influenced team ownership. Our product offering grew. We never really made any violent shifts, because things mostly worked. I don't think we ever considered anything fancy at all. We're a basic product company with product teams and some platforms. I think most people inside the company would find the question kind of funny, because the org design has always seemed pretty natural.

Survive: Accept the mess
Thrive: Shape your corner with clarity
Hack: Introduce light structure that feels natural

4. Roller Coasters

Big, painful pendulum swings

Over the last decade, we have experienced a couple of significant shifts as we scaled. We're into these violent shifts. At first, we pretty much kept the same structure, just at bigger and bigger scales. Then came the big change to multi-product, the GMs, all that, to drive growth. That played its course for a couple years, and then it was like a hard pendulum swing back in the other direction as our offering became fractured and the customer experience took a hit.

We're not good at gradual change or running parallel operating systems. We go all in on one model, it works, and we drive it way past the point of not working. And then we start over.

Survive: Buckle up for swings
Thrive: Stay flexible and opportunistic
Hack: Position yourself as the bridge during the shift

5. Re-orgs As BAU

Normalizing shifting things around

I remember when I started here. Someone gave me a heads-up to be prepared for lots of shifts and re-orgs, but reassured me that while things changed often, leaders always had our backs. Shifting things around was considered normal, and even a fun and interesting part of working at the company. It seems like we're always tweaking things, and they rarely end up in layoffs.

To be honest, I think it's a reasonable tradeoff. I've had three managers in the last five years, but each experience has been positive.

Survive: Expect constant change
Thrive: Treat re-orgs as learning resets
Hack: Use each shift to expand your network

6. Founder Centric

Their way. Or the eventual highway

You can trace a lot of our org design back to the founders. As we scaled, we brought in new leaders to buffer them, but most didn't last. Leaders who are locally effective do shape their teams, but the real gravity comes from the founders themselves. Their beliefs and preferences set the tone. And the few people who manage to survive close to them become powerful in their own right, with leeway to make big, lasting decisions.

Survive: Don't fight the gravity
Thrive: Earn trust, show loyalty
Hack: Channel founder's bias into your project

7. Founder Philosopher

Deep care (and thoughts) about ways of working

Our org design traces directly back to the founder, but not in the usual way. They've always been a deep thinker about how people work together. In a past company, they struggled with bureaucracy and politics, and they vowed not to repeat it. They had mentors who cared deeply about collaboration and trust, and they took those lessons seriously.

They don't see org design as something to delegate or outsource. They see it as their personal craft. You'll hear them reference books, models, and even philosophy. They're not afraid to admit they think about this stuff all the time, and they imagine their role as designing the system we all work within. Sometimes that slows us down, but it also means we have a founder who really believes the way we work is just as important as what we build.

Survive: Respect their ideas on org design
Thrive: Engage in the conversation, show you can think with them
Hack: Translate their philosophy into practical, everyday habits for teams

8. Disciplined Steady Hand

Drucker personified. Doing things well, by the book

The way we are structured really comes from a long tradition of management training and discipline. People here were taught how to design organizations, and it shows. Roles and structures are thought through carefully. Decisions usually take time, but they are rarely sloppy. The principles behind it are sound, if sometimes a little conservative. It gives us stability and consistency, and leaders here have a strong track record of steady, solid management.

The trouble is that the whole approach struggles when we come up against new challenges or dynamics. AI has been especially tough for us. Product thinking works in small pockets, but we never really adopted modern ways of managing and building digital products. When things call for creativity or a big leap forward, the organization feels heavy and slow to respond.

Survive: Respect the process
Thrive: Master the playbook
Hack: Frame creativity as risk-managed improvement

9. Thoughtful Transformation

The long game

I have to give credit to the leadership team. Things have gotten better over the last couple of years, though, of course, never as fast as you want. We've managed to tackle a lot of what was holding us back from an architecture perspective. While senior leadership isn't in all the details, they have empowered a few key leaders in technology, product, and in our field teams to make the right changes gradually. It is hard even to compare what it feels like to deliver now with what it was like five years ago. The difference is massive. Part of this is that over the last two decades, we've rolled with a couple of key shifts. We're not afraid to adapt, and while we are a big company now, we have learned how to stay the course.

Survive: Be patient with pace
Thrive: Lean into empowered leaders
Hack: Show quick wins that reinforce the long game

---

Anything ring true? Want to add another one?

Comment below

TBM 375: Minimally Viable Consistency

A term I’ve been using a lot with teams lately is “minimally viable consistency,” or MVC.

The general idea, in the context of how I’m using this, is that when you’re designing your company’s operating system, you should strive to have the fewest number of consistent concepts, terms, and phrases possible that still allow you to operate the way you need to.

The important part here is the viability. That’s the “V” in MVC. In some companies, people can’t even agree on a small number of consistent concepts or approaches. In that case, it’s not viable at all. On the other hand, you might have a huge company with lots of dependencies and collaboration needs. In that scenario, the list of viable, consistent things might be quite long. It might even feel uncomfortably long. But that is what viability looks like in that context.

Let’s look at an example.

Imagine you’re a company with diverse teams and groups. You want everyone to have a consistent interface that connects them to the high-level goals of the company. You might decide that OKRs—Objectives and Key Results—become that consistent interface. But you might also feel that OKRs alone don’t capture the strategy of the company. So you introduce another layer, maybe 10 to 15 core strategic pillars.

A brief interlude with a ten second request for help...

(Help needed. I’m looking to do research/discovery specifically with chiefs of staff and/or product operations leaders, director or above, in companies with >150 people in design, engineering, and product. I’m happy to split up the session into 50% research, and 50% sharing industry trends and themes, or digging into whatever puzzle you’re facing. Drop your email here, and I’ll reach out)

OK. Back to the post...

Another good example is a launch and release calendar.

Imagine you have teams that operate fairly independently, and you don’t have fully autonomous business units. The marketing team still needs to support everyone. Because this work is customer-facing, you want to communicate with customers in a consistent way. So the company might agree on a common set of terms for launches and releases. You might standardize the way you tier releases, or the language you use around commercialization. That shared structure helps create consistent behavior and language, which makes it easier to keep everyone aligned.

Launch and release is especially interesting because it shows the tension in MVC. Let’s say you come up with a general tiering scheme and describe a handful of release motions. That gives everyone a shared vocabulary. But on the ground, reality might be much more nuanced. Teams may need to work closely together and communicate in more detailed ways. The simple system doesn’t always match reality. In that case, the system might not be viable.

I experienced this myself once. The tiering system represented a market view of complexity. Tiers indicated the size and complexity of the launch. But it didn’t reflect the internal complexity for other teams. They had to invent their own side system to coordinate. That made it harder for them to communicate about their work.

This balancing act shows up everywhere. Take the word “initiatives.” It’s a useful word. But once it gets used for everything—from massive multi-year projects to one-month efforts, from things with complex dependencies to things that are independent, from outcome-oriented work to output-oriented work—it starts to lose meaning. The phrase becomes too overloaded. It stops being useful.

The big point here is that people often look at operating systems from the outside. They see something that appears simple and assume the path is to also make their own operating system simple. That can work if you deliberately force a level of simplicity and push teams to adjust around it. But more often, people overlook the underlying forces at play in a company that make that simplicity possible in the first place.

That brings us back to minimally viable consistency. You need to assess your own context. In some cases you need more consistency. For example, if your company is riddled with dependencies, you may need consistent terms for global priorities or projects. In other cases, you need less. For example, if you’re shifting to a more product-oriented model, you may loosen consistency around concepts like “epics” or other output-oriented terms so teams have more flexibility.

What really matters here is language. It’s easy to have a knee-jerk reaction in either direction. Some people are allergic to complexity and try to oversimplify. Others are allergic to oversimplification and try to keep everything complex. The real task is to ask yourself how your context benefits right now, and how language can support those goals.

As a final step, ask yourself these questions. Where is it critically important for us to have shared language, shared norms, and shared expectations? And where might common language actually be holding us back? Are we pushing people into a kind of double life at work—doing things one way in reality, while also following some official language that doesn’t really help?

And if you identify areas where consistency is truly needed, what is the least risky and highest leverage way to get it? Maybe it’s not about the exact words but about shared norms. Maybe it’s not a process but habit-building. Maybe it’s not writing things up in a wiki but learning through apprenticeship and direct interactions. The point is to choose the right approach for your context. That’s how you create minimally viable consistency in the most effective way.