People have ignored a whole swath of Ops. Let’s fix that
This is the most conceptual post I expect to write about ops. But it’s worth your while.
There’s this foundational idea that’s central to work in fast-changing companies hitting inflection points in their history and that’s not obvious. So I keep explaining it afresh. Figured you deserved a thought-out written version over my impromptu ramblings.
In short: Ambiguity is not complexity on hard mode. And if you use ops advice written for complex companies in ambiguity, you’ll mess yourself up royally.
Once you understand that, you can lead businesses in completely new ways.
Fine this is nerdy. But the bros who say “no theory ever” are simply wrong. Of course it matters. Just not … too much. We also need implications. I bet you can handle it. Got faith in you.
And I promise we’ll spin this kernel into ever wider implications. We’ll even talk about the inevitable AI and more. But to start, It’s important you and I get the basics sorted out. It’ll make it so much simpler to get practical and specific mighty fast after this. Humor me for this post.
So, let’s talk about my corner of operating businesses.
Talk axiom to me
People largely imagine what “Ops” is in their image. Whatever they know is “normal.” But in reality, Ops is absurdly diverse. I’d suggest it’s not even a discipline. It’s much more like the “negative space” left after all the other disciplines are subtracted. As a result, one company’s Ops barely resembled what any other has.
(By the way, when I say “Ops”, I mean OperatING, not OperatIONS. I mean all it takes to operate a complete business, from strategy, through actual operations, to finance. That’s because operating takes plans, their realization, and a way to turn them to money. Ops is all of that. Splitting them doesn’t work well, especially in ambiguiry, as we’ll see.)
It gets worse (and I finally get to the point):
Operating in ambiguity is utterly different from ops in complexity.
That's the axiom, the rock-bottom truth. This, you must believe (or at least be open to exploring) for anything else here to make sense. If you don't buy this, you can stop reading. Ah, but if you do, I have fun things ahead for you.
In a few more words, what I mean is that ops in ambiguity isn’t a harder version of the same job, with less data and more caffeine. It's a different discipline outright, with different mindset, priorities, and definitions of “good.”
Though that’s a simple idea, many people never needed to consider it. Complex businesses and the complexity playbook are everywhere, while the ambiguity one is, well, nowhere on the radar.
And the difference matters. In its shortest version, it implies:
- In complexity, a basic mindset of detail obsession wins.
- In ambiguity, a basic mindset of clarity obsession wins.
- In both, only the paranoid survive. Grove got that part right.
We’re talking about companies entering full-on change
You’re still here. Good.
When I say operating in “ambiguity” or operating as “fast-changing companies” or at “growth inflection points,” I mean one of two situations:
- A small business that has grown, maybe a lot, and is just vastly not set up for what it needs to do next. It’s at an inflection point. The wiring that worked for 10 people doesn’t work for 60, and that wiring in turn won't work at 200. The business is outrunning itself.
- A bigger or downright big business that just got hit by a new reality so overwhelming that company leaders must rethink the whole thing, not just one function or initiative. Maybe a market disappeared. Or a technology made things newly (im)possible. Upheaval from a regulatory change. A merger or spin. Whatever. Something that made the old business and operating model ready for the dumpster.
The exact label we use for that kind of business matters less than the shape of the problem that these leaders face. So I'll talk about “ambiguity,” “fast change,” and “growth inflection points” pretty interchangeably. They all point at the same thing: a business that cannot continue as it has, because what it already knows and does is no longer enough.
And, and this is important, the company's leaders must consider the entire business as they design the future, maybe all the way down to its core essence. The question is the future of the whole kahuna.
They are ready to abandon their local maximum in search of a new one. A stable system has lost its stability and can’t return.
A teaspoon of theory
Among these descriptions just mentioned, I find it most helpful to distinguish businesses “fighting ambiguity” and those “fighting complexity”.
I use the VUCA view of the world to talk about this (one of my favorite frameworks). VUCA names four challenges to business and leadership:
- Volatility
- Uncertainty
- Complexity
- Ambiguity
Over time, the practitioner community (especially Bill George and Bob Johansen, and also recent ones like John Austin) came up with solutions that magically match the acronym and pair with each problem, starting with the same letter. Black magic, presumably. Don't ask me how they pulled that off:
- Vision beats volatility
- Understanding beats uncertainty
- Clarity beats complexity
- Agility beats ambiguity
Here's what matters for this series:
Complexity is the bane of big, stable companies. Early on, a successful business adds people and sophistication, and it gets better. But at some point the added coordination turns into bureaucracy, misunderstandings, and the whole family of problems we collectively call complexity.
Ambiguity is something else entirely. It’s the absence of information and meaning, where you aren't even sure where you should go or what might be. It's the bane of startups, young companies, and fast-changing ones of any age.
Volatility and uncertainty can hit either type of company, so I leave them out here. What I care about is that some businesses mainly fight complexity, others mainly fight ambiguity, and the two situations are nothing alike.
What the difference looks like practically
Being as this is Ops, let’s consider the practical People, Process, Tool, and Data implications of these differences. Basically, what helps you win in one setting is an active liability in the other:
People impact
The complexity company has too many people trying to do too many things in parallel, and the work of running it is mostly coordination, like achieving clear roles, charters, and priorities, and building good interfaces between teams.
The ambiguity company has the opposite problem. Five people need to cover the work of fifty, because there just isn't anyone else yet.
For example: professional hiring pipelines, career ladders, and sophisticated role design are all excellent tools in a stable business but expensive and slow ways to sink a small one in flux. Spend serious time or money money on perfectly-defined role clarity in ambiguity and the game is over before you've put everyone in place.
Process impact
In complexity, process is both blessing and curse. It achieves consistency and high standards, and it also produces bureaucracy, gridlock, and lazy rules-lawyering. The two come bundled. You don't get one without the other.
In ambiguity, the opposite happens. You typically have no processes at all, or processes built for a past that no longer exists. The temptation is to buy a tool that promises to fix things (more on that in a second) or to outsource to experts, which can work, but only if your own team keeps learning in the process. Otherwise you've just rented a dependency you can't get out of. (Steve Blank has written eloquently about exactly this failure mode.) The thing that actually works in ambiguity is less glamorous. Limit the scope of work, then build the lightest possible processes for what remains, and only capture things as job aids that don’t box people in.
Tool impact
The complexity company has too many tools, often poorly integrated, each one the solution to a problem someone had two or three years ago. You may need hordes of integrators just to get them all to work together.
The ambiguity company has too few tools or ones of insufficient sophistication. And it's constantly tempted to believe that a tech vendor's pitch for installing their platform will fix everything. (I’ve of course never fallen prey to that.) Ok, sometimes it even does help. But more often, the tool misses the actual pain or assumes a level of professional competence the team doesn't yet have. The same tool that makes a big company run better can drown a small one in setup work it can't afford to take on.
Data impact
Complex organizations suffer from an excess of data and all the downsides that come with it. It’s structured in outdated ways, understood only by people who retired years ago, rigid or incomplete or messy. At the same time, the data is the lifeblood of the business, and going without it isn't an option. Whole disciplines (data science, analytics, knowledge engineering, whatever comes next) have evolved just to cope.
Ambiguity businesses are, again, different. Orgs fighting ambiguity often have no data or none in a form anyone at a bigger company would recognize.
For example: at one startup I worked with, the list of components used in their product was spread across individual invoices of various parts vendors. That was the “system.” The other kinds of companies facing ambiguity, those previously stable companies that have just hit a shock, have a different version of the problem. Plenty of data, but quietly poisoned, because it reflects a past that no longer exists. Use it and you reach bad conclusions with full confidence.
So that’s the issue. You can see the pattern. All four dimensions look utterly different between the two company types. The only thing they have in common is the topic.
The gnarly problems that result
Well, complex companies get too much advice on how to operate, and companies in ambiguity get too little…. which of course I hope to help fix.
Focusing on ambiguity then: In the end, you'll find very few people who specialize in ambiguity, and even less advice to read out there, to help you master it yourself.
It's a two-fold challenge:
Confusion about outcomes
Few folks talk about what “good work” even looks like in ambiguity.
Most of what we know as “good operations,” what's covered in frameworks and best methods and umpteen LinkedIn posts, is meant for operations in complexity and beyond. That actually makes tons of sense: most companies are “just running” much of the time, and complexity is the vast majority of operating work. But still. There's little advice for companies staring down ambiguity.
Getting lost in the mess
The kind of people who flock to operations work tend to do well in complexity, enjoy structure, fine-tuning, optimizing, aligning and orchestrating, removing waste, and so on. They often don't enjoy or even excel in ambiguity where none of those conditions hold.
And, at least speaking for myself, the same is true in reverse. I've dedicated my entire career to ambiguity and fast change and (clearly) nerd out on it beyond all reason. But complexity? Been there. Done that. I was decidedly meh at it. “Mid,” as the kids would say. Complexity takes real expertise too. But beyond a certain level, it's not mine.
Put the two problems together and you get the damage this series is trying to help you prevent: Treat an ambiguity business like a complexity business and you’re in a world of pain.
Even if your org chart is documented, you have all processes written up and dashboards for everything, and every best practice is intact, it’s all useless because you have no product and no customers using all of that infrastructure. Oh, and you've just run out of cash.
A flavor of what's to come
So what does work, if the complexity playbook is the wrong playbook? That's where we pick things up together.
We can’t squish the whole series into a single post. So, to start, here is a sample menu of leadership principles it takes to operate well in ambiguity, to get you thinking.
Consider to what degree you and your teams reflect these:
- Use first principles as the prime working habit: When the situation is genuinely new, you can't copy what worked before. You can’t use typical rates and benchmarks. You have to reason from what's actually true every day, from things you can point to in the real world.
- Stitch together watertight logic paths for plans: A lot changes in ambiguity, and half the time you have no clue whether any of your actions make sense. The only thing that keeps you sane is that you proved to yourself that you’re at least internally cohesive. And when things inevitably change, that logic chain also easily lets you follow all implications down to the end of the line. You may not like what you see there. But you won’t be surprised by it.
- Build the lightest complete version of a business: Light and complete. Both words matter equally. A big business has had hundreds of thousands of payroll-hours invested in becoming what it is. You don't have that luxury. But you still need all the parts, because it’s the only way to do what you must, from finance to sales.
- Hire people who can simultaneously see progress and work left to do: They need high standards but also appreciation for what’s actually realistic where you are today. They can’t call it done at the first sign of “good enough for now,” as many operators do. Nor can they despair at the long haul ahead.
- Shape a team that's absurdly robust. It probably won’t be fully healthy, and maybe not even fully functional on its best days. But your people must be tough enough individually and as a unit to keep working under the the most adverse conditions that the universe can come up with, dust themselves off after hard knocks and keep moving together. Don’t take that as a management platitude. Team cohesion matters more here because in ambiguity, where no one person can do meaningful work alone. There is no functional clarity. Your people must be able to rely on each other.
There's loads more, a bunch in various states of ready-to-go, and I'll find more for you. Here, though we’ve made a start.
A simple close and much more to come
So, there you have it. I hope it’s something you can’t unsee once you know it.
Running in ambiguity is its very own thing. Those who dare doing it need their own standards and methods. And if you do it right, it can be a ton of fun!
