How Operations Can Prepare for Continuous Transformation

A fact of life for any operation's professional: change and "transformation" are constants. There is never an endpoint. That big, highly political move you're making now—to the product operating model, to platform-centricity, to an AI-enabled operating model—will be something else in a few years. That's the way these things work. Anyone pretending to have a forever answer is either 1) talking in such high-level principles that basically what they say will be true forever, or 2) selling you a bridge to your next bridge.

The big challenge for operations is that we need to both enable these shifts and deal with all the gory side effects of these shifts. Operations is like a canary in a coal mine forced to run the coal mine. It's hard. You're balancing BAU with whatever is evolving and emerging. As much as your organizer brain might want to have all the dots neatly connected, you have to accept that some things will be messy.

Questions abound:

• To tool up, or wait it out
• To risk your political capital on a core issue, or focus on paper cuts (or both)
• To "processify" or let something be messy for a while
• To embrace the status quo to make it easier, or nudge toward a better way

In that sense, operations is a mix of order and chaos, harnessed to create forward momentum. There is no endpoint; there are just lulls in the action where the team can enjoy abundance and stability until the next exciting change adventure.

At work, we talk to many ops leaders facing these challenges. Here is a list of key challenges and general principles for tackling them.

Exception Handling

Imagine that 90% of your initiatives are owned by one team. And 10% of your initiatives are owned by multiple teams. Do you create processes for the 10%, or do you treat those as exceptions that you deal with on a case-by-case basis? Specifically, do you develop processes for the 10% that bleed over into the 90% like requiring a big kickoff or "big room planning" even for the independent items? From a tooling standpoint, the trick becomes figuring out how to handle the 10% gracefully without spilling over into the 90%.

This balancing act is one of those forever tradeoffs. Operationalize all the variability, and you can end up with something overwrought and difficult to manage. Treat many things as exceptions, and suddenly you are running parallel motions without great operational support.

You will always have exceptions; the challenge is figuring out how to treat those exceptions. An extra twist? Humans are great at handling exceptions. This is good and bad. Good in that we are progress machines. And bad in that we can absorb exceptions way longer than we should.

Key Challenge:

How can we design systems that accommodate edge cases without allowing those exceptions to distort or dominate the primary mode of operation?

Principles:

• Don't optimize around the exceptions you want to see less of
• Know (or anticipate) the "tipping point" when an exception becomes the norm.
• Name it to tame it: name the exception. At least this acknowledges that it exists.
• Put an expiration date around how you're dealing with exceptions (so people aren't afraid this is going to become the norm)

Juggling Compression and Coherence

The next challenge is compression and flattening, and the continuous challenge of presenting things at the "right" level of detail. For example, in reality, initiatives form a big dependency graph—something ungodly to look at, and enough to send shivers up the COO's spine. So, what does the operations or program management team do when prepping for the big review? Flatten it, leave out information, and simplify reality.

Maybe they crunch all those dependencies into a RAG (red, amber, green—not related to AI) indicator, or maybe teams boil all of that work into something like, "We're spending 30% of our time on other stuff, but let's call the remaining 70% our 100% for this meeting."

In theory, when you present data, you show a "view" of that data. In theory, you can keep all of that mess available for hard-core operational views that attempt to solve problems much closer to the problem (vs. the executive views, which have an optics component, and where you specifically aren't inviting people to a solution or play Tetris). But what happens in practice is that each "view" requires work. Each view may also rely on distinct data that must be cared for, cleaned, and collected.

So, what you see in practice is that, due to the operational and cognitive overhead, teams settle on a dominant, crunched-down, and compressed view of reality optimized for the most powerful person's needs (makes sense). Collecting data to supply that view becomes the dominant ask, and teams must use ad hoc and reactive approaches to navigate reality on the front line. Meeting both needs is the crux of the challenge.

Key Challenge:

How do we create simplified representations of complex work that serve leadership needs without severing the connection to the detailed structures that drive execution?

Principles:

• Most people want the dots to matter to them, not all the dots.
• Get clear on the contexts in which you will share different "views" of the data.
• Tooling can make recontextualizing easier. Invest wisely
• Once you commit to flattening, you can't go backward. Seriously reconsider this decision and explore all available options.

Parallel Realities and Scaffolding

In many environments, there is a battle between the official way, emerging ways, the idealized future, and the reality of the present. There's no such thing as one definitive "This is how things work around here" because no one person is going to perceive the current reality in the same way. So, what you end up with is parallel realities and perspectives around what is happening.

• Official Narrative: “We are a PLG company now.”
• Sales Reality: “We still make our number through sales-led enterprise deals. PLG is a distraction.”
• Product Reality: “We’re building self-serve features but don’t control pricing, packaging, or onboarding.”
• Marketing Reality: “We’re stuck between generating leads for sales and trying to optimize self-serve funnels.”
• Customer Success Reality: “We’re measured on retention, but self-serve users don't talk to us.”
• Leadership Reality: “We need to appeal to investors with a PLG story—even if 90% of revenue is sales-led.”

This battle gives rise to an interesting operational challenge. You must choose where to create scaffolds, where to live with incoherence, where to intentionally NOT support ways of working, where to formalize certain practices, and where to pretend certain things aren't happening in a conscious effort to let those seedlings grow under the radar, hidden from the prying eyes of formalized process.

Sometimes you need to be OK with something being called multiple things by multiple people. Trying to get people to agree on a definition will undermine your long-term mission, or the long-term mission of someone powerful (who will make your life very difficult if they win). There are situations where you can (and should) make different ways of working visible, and where visibility and transparency can be a catalyst for change—but this is not true in all (or even a majority) of cases, so proceed with caution.

Key Challenge:

In a context where multiple interpretations of reality coexist, how should we decide what to support explicitly, what to let evolve informally, and what to leave unresolved?

Principles:

• There is no one reality in your organization.
• Get super crisp on where a shared definition IS important. It may not be.
• Incoherence may be a signal of better things to come. Learn to live with it (temporarily).
• For the safety of your job, at least give a hat-tip to the official reality.
• When there is convergence, celebrate that. An org that can agree on a few key things is a minor miracle!

Forever Problems

Ask one hundred teams what their biggest problem is, and they are liable to say something like "prioritization, dependencies, explaining where our investments are going, and figuring out how to strike the balance between short-term and long-term wins."

These are what I call "forever problems." All companies have these problems. If they didn't, I would guess that they are in a completely static domain or simply aren't asking the hard questions.

Over the years, I've come to understand that there is a fine balance between dealing with forever problems and troubleshooting things that are definitely broken. Dependencies are a great example. As a company grows, its structure will always drift from its strategy. "Structure" here applies to architecture, teams, and incentive structures. So, naturally, you will start accumulating dependencies you must deal with.

There are, however, BAD ways to deal with the forever problem. There are ways to approach dependencies that 1) enforce harmful dependencies and 2) cause premature convergence and negatively impact outcomes.

Guaranteed Bad Way

• A central ops or program management team rolls out a mandatory dependency management template or tooling layer for every initiative.
• Every team must log dependencies in the same way, even if it doesn’t fit their workflow.
• Dependencies are reviewed in giant coordination meetings, regardless of whether they’re meaningful or blocking.
• Teams are required to pre-commit to delivery timelines based on dependency agreements that are brittle and abstract.
• The framework is positioned as “industry standard” and tied to vague notions of maturity or discipline.

Understanding the difference between the two is an operations superskill. You can't just pick a "best practice" for dealing with dependencies because there's a very good chance that the best practice is optimized for the most mediocre and middle-of-the-road outcome and the most context-free articulation of the problem and solution.

Almost by definition, how you deal with forever problems will NEED to be highly contextual and grounded in your company's culture.

Key Challenge:

How can we support teams in navigating persistent tensions like prioritization and dependencies without locking them into oversimplified or context-free solutions?

Principles:

• Accept forever problems as the fun of doing great work.
• Remember that best practices are typically context-free practices.
• Ask whether your well-meaning attempts to solve forever problems are making them worse.
• The question is how to resolve the tension around _______ in your company.

Beyond Standardization and Efficiency

Many operations teams see their job as creating object hierarchies, integrating tools, producing reports, defining processes, etc., and they lose sight of the goal.

You are in the 1) decision-making support business, 2) the friction-busting business (on behalf of customers and your partners internally), and 3) the "beneficial consistency" business—keeping a small number of things consistent in ways that support #1 and #2 without causing negative second- and third-order effects.

It is easy to believe that you are creating value by simply bringing "order from chaos." If you are floundering a bit trying to understand where to drive impact, I suggest starting with rituals and interactions. Where are people coming together to make decisions? Where are they coming together to exchange information and make sense of things? Where are they being forced to come together to do rather transactional things that could easily be automated or made smoother?

You could have the best SOPs in the business. Still, if your rituals are ineffective and people simply admire dashboards and reports instead of making the decisions they need to make to do their job, you'll get some back-pats but may struggle to advance the operations function.

Key Challenge:

What does it look like to treat operations as a platform for coordination, decision-making, and adaptation rather than as a function focused only on control and standardization?

Principles:

• Observe rituals. That's your barometer.
• SOPs will come and go. Good habits will stick around a lot longer.
• Decision quality and decision velocity are good North Stars.
• Think in terms of platforms. You're a big force multiplier and lower the cost of consistency.

Intentionality Without Exhaustive Documentation

I've yet to see a strong correlation between making culture docs and detailed "How we work" docs, and actual org performance. I can cite as many examples of teams that painstakingly document how they work yet do a lot of counterproductive things, as I can examples of teams that somehow hive-mind their way into high performance while intentionally resisting being explicit.

That said, I have seen a correlation between teams that have intentional conversations about how they work and the quality of their work. This suggests to me that intentionality is the key component—not some desire to document and codify. To be clear, some companies choose to write it all down, which can be great, but it isn't the deciding factor.

But this presents an interesting challenge for operations. It is hard to make good decisions without intent, and to understand intent, you either need to be 1) in the room to ask questions, or 2) able to understand a clear articulation of principles, beliefs, org design decisions, etc. Even if you understand those principles, you will still need to rely on your spidey sense and ops expertise to figure out how to turn principles into something legible from a tooling or ritual support perspective.

Key Challenge:

How can we design tools and rituals that reflect the underlying intent of how teams work, even when that intent is distributed, implicit, or resistant to formal documentation?

Principles:

• Get used to the ambiguity of no documentation.
• You may need to fill in the blanks yourself, which is OK.
• Operations documentation does not necessarily need to be public to everyone. Do what you need to do to understand what is happening.
• Conversations with key decision makers and culture-shapers are gold. Whenever you can cut out the middle person, take this opportunity

How do all these principles translate into tangible tooling decisions?

I think the general tendency with operations—like many supporting disciplines—is to be in reactive mode. So you tend to enter the fray late in the game once the big decisions have been made. Or you get involved when the current way has imploded under a lot of operational friction.

But when you take the long view, a couple of things become clear:

1. Things will change, so a small number of things will likely stay constant over the years.
2. Like any product, there is an initial stage of keeping things flexible and adaptable. You are in learning mode. Being "in market" (internally) with something rough around the edges is OK. People will cut you some slack. However, you must architect your solutions to roll with the changes over time as things become more formalized.
3. Above all, there will always be a portfolio of problems and shifts, ranging from an increase in exceptions to a change in the "official vs. real" to level-of-abstraction problems. Once you see this as part of the job, you can start working on creative ways to solve the various fun challenges at your doorstep.