lignment. I’m sure the mere word sounds like buzzword bingo to you. Yet, as soon as you try to wrangle your Operations (some project spanning process and software config), you find yourself borrowing that tired refrain: “we need to get everyone aligned!”.

Of course, Operations leaders know that disparate teams, when they all pull the chain together, can move big things. On the other hand, when everyone is pulling in opposite directions, you get nowhere. Or worse, your project gets drawn and quartered:

So why isn’t all this alignment talk getting people pulling in the same direction? Let’s borrow a lesson from the Product Discipline:

Goal Clarity is King

Seasoned PMs have almost invariably learned a lesson that many Operations leaders miss: communication alone doesn’t create alignment. Goal clarity does. In fact, often it feels like the more you communicate, the less aligned you feel. Yet time and again, I’ve seen Ops leaders institute meetings and check-ins to try to build alignment on a project. Why does this strategy often work against goal clarity and fall flat on its face?

First, let’s envision a rough model for how projects come to be defined, borrowing from modern product development philosophy. Generally, projects start from business goals (explicitly stated or not) and are worked down into a batch of features (Product parlance, which for an Ops project, may be tools/processes) through a series of smaller approximations. Features, once shipped, collectively attempt to work their way back up towards impacting the original goal. Some variation of:

Scoping

A goal gets attacked in increasingly smaller parts.

On each leap down and back up the cycle, you hope to ensure the work you delivered has impact on the intended higher levels.

But here’s the thing: the above completely oversimplifies what’s actually going on: at each step, we face the challenge of making choices.

Scoping, Take 2

See, each business goal likely has multiple bets you might make to accomplish it. Each bet likely has multiple problems standing in the way of you having already made the bet. Each problem can be solved in a number of ways. And each solution is comprised of many smaller feature-sized possible components to your approach. So it looks more like:

Already, I’m calling out a common bad habit: choosing (circled) features that don’t necessarily tree up the same path to a goal, instead being only adjacently related to the original goal.

But real life is even tougher. Most businesses have multiple business goals. And they try to place many bets at once. A realistic model ends up looking more like many superimposed versions of the above:

Scoping, Take 3

This feature complexity increases even more as more teams, people and ideas interact — via, you guessed it, communication!

You might think using OKRs enables teams to basically circle the three colors above, defining clear Goals and Bets. However, by the time your teams take on Problem>Solution-spaces, they often end up playing a ‘zone defense’ to demands for various projects, something that looks more like the red dotted circles above, typically conflated under a vague project name. All your ‘alignment’ meetings start merely introducing more perspectives to the mix. Those perspectives invite new interpretations to the vague dotted red line projects, creating even more branches at the bottom of the tree.

And what’s even happening at the bottom? The features become nearly impossible to track back to which bet or goal they came from. So what do one of these red dotted line -oriented teams tend to do? They go to the Scoping Buffet.

The Scoping Buffet

In the Scoping Buffet, teams with too many concurrent objectives and a slew of related ideas look at these dogpiles of features and start arbitrarily assembling them onto their plate. Aren’t buffets great? Not here. Our dishes need to be designed with a nutritional purpose, not assembled voraciously like slop at a trough.

Why? The whole point of what we are doing is to somehow not get lost on our way back the way we came: from features, to solutions to known problems, which unblock bets in the service of business goals. Unless your business isn’t particularly innovative, it’s already a long shot that your features will successfully deliver against the top level goal (most of the steps amount to an educated guess). You hurt your odds when you genericize ‘goodness’ instead of building specifically with your path back to the goal in mind.

You know what this multi-step translation process reminds me of? You ever played “telephone”? (yes, the curly-cord lines above was artistic foreshadowing) It’s where a set of individuals consecutively whisper a secret phrase into each other’s ear, and by the end, the phrase somehow doesn’t even make grammatical sense, let alone sound like what the first person started with. The more people in the game, the worse the final outcome.

Aside… the outcome also gets worse the longer the sentence. A nearly ubiquitous tendency towards scope creep in projects is almost definitely making this problem worse.

What can be done?

The most important thing is for anyone running a project to make sure all communication around a project is connecting back its path to goals. You need a trail of breadcrumbs, like Hansel and Gretel. So how do PMs do this?

Quick Win: Cut Scope

Want the most quick and dirty trick out there? On every project, document what is “Out of Scope”. Write this at the get go, and contribute towards it as you your project moves on, all the way through rollout. If you only manage to take away one thing from this post, make it the bolded sentence above.

What about a little more nuanced approach, rather than just avoiding scope creep? To be sure, small batching is part of it, but not enough without connecting back to goal clarity.

Introducing: Outcome-First Operations

The key lesson of Outcome-First Operations is this:

In scoping a project, at each increasing level of granularity, only do what’s needed to try to impact the level above it

Brainstorming and free-association of adjacencies is great on your way down the granularity spectrum. But when assembling a scope that intends to make its way back up, only undertake what you must.

Why does this sound familiar?

A similar philosophy from the medical profession is minimally invasive treatment. Surgeons seek fewer cuts, Medical Doctors seek fewer medications. Equilibrium in the body is complex. Simply put, the less you can mess with, the fewer complications.

Software engineers have a similar process design principle. Its part of Test Driven Development (TDD), and here’s how it works:

• Pay a tax upfront by writing a test (helps omit unnecessary scope)
• Next, write minimal code needed to pass your test (helps deliver outcomes, vs code)
• The less code you write, the fewer doors you’ve shut, the fewer dependencies created, and the fewer concepts you’ve conflated into a bounded context

This discipline shouldn’t evaporate when it comes to Operations. Ever done this? You draw a giant process flowchart for a team, from your mind, on a whiteboard. You build consensus, adding to it over several meetings. At last, you commit it to a multi-month project.

This type of design (massive, bespoke software and process implementation) can easily be compared to the now highly antiquated “waterfall-style” of development. It shares all the same shortcomings: slow feedback, high outcome ambiguity, low user centricity, worse outcomes.

Granted, bigger teams make it harder to deliver in small, precise measures. Don’t accept that cop out. The bigger your audience, the more ambition an Ops leader should be able to handle, and the more sophistication that should be possible. For example, an audience of billions doesn’t stop Facebook from making dozens of concurrent bets.

What Outcome-First Operations Looks Like

Again, much of this approach owes to well-documented trends in modern software development lifecycle technique. These tactics aren’t new. Operations leaders just tend to overlook them. Here’s a rough structure of how to stay Outcome-First at each project phase:

Start from Goal Clarity

Prioritize a distinct business goal, and what kinds of bets might realize that goal. Seek value at a fundamental level, like when using the five whys. Do the very difficult job of deferring solutions.

Know the Problems, Iterate Solutions, Define Features

From there, get a bead on the problem space standing between you and the outcomes needed. How these problems are solved should not be part of this, and for now should be treated as a black box. Do your research here — don’t fall victim the most common and damning shortcut of assuming you know why a desired outcome isn’t happening.

Then, identify not one, but multiple solutions to the problem space. Solicit team members varying ideas about how this can be done. Even if the team has a high level of consensus on a single solution, present the next best approach for thoroughness sake.

Compare the tradeoffs of each approach, as well as the assumptions you are knowingly making and any risks that you intentionally bear.

Split your top choices for solutions into Features (software configurations, processes) that can be delivered individually, but have some sort of impact on the solution you’ve chosen.

Scoping for Outcome-First Operations

This is absolutely the hardest part.

Pick a set of features that collectively the team can deliver in less than two weeks, and most importantly, you believe will together contribute to at least a partial solution to the problem space you identified. Ideally, you’ll be able to measure if it did. Often, you’ll only get a sense, not a black and white answer.

With a rough scope, then try to imagine a path all the way back to it delivering something the CEO hopes to accomplish. Imagine the CEO calling out this project at an All Hands meeting months later as ‘part of our progress here’. Get super ahead of yourself. Actually. Because you should know what bet you think you are making. The next part is no fun.

At this point, be a total pain in the butt in meetings whenever incremental process or software config get talked about, unless it has same kind of connection to outcomes as you’ve invested in making. Be a broken record about goal clarity. Don’t let people use the words ‘table stakes’. Don’t give in to complaints about ‘a partial solution’. Don’t let them go to the Scoping Buffet.

Some other advice for the painful scoping stage:

• My favorite: Name the project something that exactly implies why it is valuable, vs. describing its constituent features
• Continuously add future adjacencies in your ‘Out of Scope’ section
• Nevertheless, MVPs should be built with a vision of how the world might evolve around them
• Use principles borrowed from Object Oriented Design: store data in objects that mirror the real-world as much as possible. (ie, call notes belong on a call object, not on an opportunity object, which might comprise many calls)
• Be on the lookout for processes that cost more to the team than they benefit the company. Be on the lookout for expensive-to-build automations that only handle edge cases
• Use comms to keep everyone on the same page about the plan and most importantly, the intended outcomes and what is out of scope

You’ll be surprised how much faster your project moves when everyone is racing in the same direction, instead of playing bumper cars.

Just adding more communication to big, vague projects fails because it creates many definitions of what’s being accomplished and how.

Alignment happens once everyone has the same exact definition.