And that conversation naturally leads into more granular questions. Are bets different from strategies? Where does the roadmap fit? What goes in our backlog?

Creating shared language is important because teams need some way to reason together. But language can also become a hiding place. The more energy a team spends debating labels, the easier it is to avoid the harder question: can we explain how today’s work moves us closer to the outcome we said we wanted?

That is the job of a goal cascade. A goal cascade is not a hierarchy of documents. It is a chain of assumptions.

At the top, you name the outcome you want. Underneath it, you name the path you believe will get you there. Closer to the work, you name the faster signals that should tell you whether the path is behaving the way you expected.

If the cascade is healthy, teams can move between those levels without losing the thread. A backlog item connects to a roadmap bet. A roadmap bet connects to a strategy. A strategy connects to an objective. Each layer has a reason to exist because each layer helps the team make a better decision.

If the cascade is unhealthy, the words still look right. The slide still has objectives, goals, strategies, measures, key results, initiatives, bets, and metrics. But the connection between them is mostly decorative. The team can recite the framework, but cannot use it to decide what to cut, what to protect, or what to learn next.

That is where goal systems usually break: not in the naming, but in the missing feedback loop.

Illustration of qualitative and quantitative goal pairs cascading between objective, strategy, and bet levels

Start with the pair: intent and evidence

Behind any goal framework is a common principle: every useful goal needs two parts.

1. It needs a qualitative description: what are we trying to make true?

2. It also needs a quantitative description: how will we know whether it became true?

Different frameworks name this pair differently. In OGSM, the objective is the qualitative statement and the goal is the quantitative counterpart. In OKRs, the objective is the qualitative statement and the key results are the quantitative counterpart. The labels matter less than the pattern.

Qualitative without quantitative becomes aspiration. Quantitative without qualitative becomes metric theater. Together, they create a usable goal: a direction with a way to inspect progress.

Take a simple example.

“We want to create a cohesive, high quality customer experience” is a useful direction, but by itself it is not enough. Different people can hear that sentence and make different choices. A designer may think about consistency. An engineer may think about stability. A product manager may think about conversion. A support team may think about fewer complaints.

None of those interpretations is wrong, which is exactly the problem. The phrase needs a measuring partner.

A team might choose signals like pages loading under 2.5 seconds. Or the team might choose a broader composite signal, like Lighthouse scores above 90.

Those numbers are not magic. They are not the customer experience itself. But they give the team something inspectable, which means the conversation can move from opinion to evidence.

That is the first useful move in any cascade: pair the thing you want to make true with the evidence that would tell you whether it is becoming true.

The cascade connects slow outcomes to faster feedback

The biggest difference between long-term goals and day-to-day work is feedback speed.

A long-term objective sets direction, but feedback is slow. “Create a better customer experience” may take years to fully prove. Revenue, retention, conversion, repeat visits, support volume, and brand trust all matter, but many of them move slowly or are hard to attribute cleanly.

Closer to the work, feedback gets faster. A team can measure whether a page got faster this week. It can measure whether responsiveness improved. It can measure whether duplicate tags were removed. It can measure whether a component migrated to a shared architecture. Those signals are not the final outcome, but they can tell the team whether the chosen path is behaving as expected. That is the purpose of leading indicators.

A lagging measure tells you whether you got there. A leading measure tells you whether you seem to be getting closer.

The road trip analogy is simple because it works. If the goal is to arrive in Washington in time for a wedding, the lagging measure is whether you arrive on time. The leading measures are the things you can inspect along the way: miles traveled, time elapsed, fuel remaining, traffic, detours.

No one mistakes miles traveled for the wedding. But they are important signals as you make progress.

Work is the same. A team may not be able to prove revenue impact until more of the funnel is on a new platform. That does not mean the team should fly blind. It means the team should measure the inputs it believes will eventually matter: page speed, stability, accessibility, adoption, reliability, or whatever else the strategy depends on.

A good cascade makes that belief visible. It says, “We believe this faster signal is connected to that slower outcome.” The belief may be wrong, but now it can be inspected.

Strategy is the path, not the wish

A strategy should explain how the team believes it will achieve the objective.

If the objective is a cohesive, high quality customer experience, one strategy might be to create responsive digital experiences on a stable modern front-end architecture. More specifically, a team might decide to move product surfaces onto a modern framework because shared architecture should make performance, consistency, and maintainability easier to improve.

That is a strategy because it chooses a path.

It also implies tradeoffs. If the path is monorepo adoption, then some work deserves protection even when it does not immediately look like feature output. Migration work, tooling, standards, documentation, and developer experience are not side quests. They are part of the operating theory.

This is where teams often lose nerve. The objective sounds customer-facing, but the strategy may require platform work. The lagging outcome may be conversion or customer satisfaction, while the leading work may be build pipelines, app migration, performance budgets, and fewer duplicate tags.

Without a cascade, that work is easy to dismiss as internal plumbing.

With a cascade, the team can explain the mechanism: better architecture should improve speed and consistency; speed and consistency should improve the customer experience; improved customer experience should support the business outcome.

The chain may be wrong. But at least now the team is debating the right thing. Not whether platform work “counts,” but whether this platform work is the right path to the outcome.

Bets are how strategy learns

Teams often get stuck trying to distinguish strategies from bets. The distinction is mostly time horizon.

A strategy is a longer-running path. “Move teams onto the monorepo” may take a year. “Create a faster, more stable customer experience” may take longer. These are large directional choices, and they need sustained attention.

A bet is a smaller move inside that path. It is a learning move. It says: if we make this specific change, we expect this specific signal to move.

For example: if we remove duplicate Google Tag Manager tags from a page, we expect site speed to improve by 500 milliseconds.

That is a bet. It is useful because the feedback loop is short. The team does not have to wait a year to learn something. It can run the change, inspect the signal, and decide what to do next.

This does not make bets separate from strategy. Bets are how strategy learns.

A bet moves the roadmap. The roadmap moves the strategy. The strategy moves the objective. Or at least that is the theory.

The cascade keeps the theory honest by making each assumption visible enough to challenge. If the tag cleanup does not improve speed, the team has learned something about the mechanism. If speed improves but conversion does not, the team has learned something else. Either way, the work produced information instead of just activity.

Roadmaps and backlogs translate the cascade into work

One common mistake is trying to stuff everything into the framework.

The OGSM should not contain the entire roadmap. The OKR should not become a backlog. A goal-setting system is not a project inventory.

These layers should inform each other, but they should not collapse into one another. When they collapse, teams lose the ability to reason at the right level.

A backlog item is too small to carry the whole strategy. A strategy is too broad to tell an engineer exactly what to build next. A roadmap translates between them.

That translation is where a lot of planning work either becomes useful or becomes theater.

If the roadmap is connected to the cascade, a team can explain why migration work belongs next to customer-facing work. It can explain why a performance budget matters. It can explain why removing duplicate tags, improving responsiveness, or standardizing components is not just cleanup. Those items are small because work has to be small enough to do, not because the outcome is small.

If the roadmap is disconnected from the cascade, the backlog becomes a list of things people hope are important.

Use any framework, but keep the operating principle

This is why the framework matters less than the operating principle underneath it.

You can use OKRs. You can use OGSM. You can use bets.

You can use a roadmap with outcomes and measures. You can use your own language if the team understands it.

But the principle should stay the same:

1. Pair qualitative intent with quantitative evidence.

2. Connect slow outcomes to faster feedback.

3. Make the strategy explicit enough to expose tradeoffs.

4. Use bets to learn before the lagging outcome arrives.

5. Keep the roadmap and backlog connected to the outcome, without confusing them for the outcome.

The point is not to make planning look clean. The point is to make decisions easier when reality gets messy. Because reality is messy. Dependencies slip, metrics don’t move like we expect, customers don’t stay in the happy path.

A good cascade does not prevent that. It gives the team a way to respond without losing the plot. If the objective is clear, the team can adjust the path. If the strategy is explicit, the team can inspect whether it is still working. If the measures are leading indicators instead of vanity metrics, the team can learn before it is too late. If the backlog is connected to the roadmap, the team can explain why today’s work matters.

The test is: when the plan starts to slip how well can the team still explain what it is learning and what it will change next.

For a long time, product management had a clean shape.

You learn the craft, you earn trust, and you move “up.” Up usually means more scope, more stakeholders, and more distance from the work. That distance is framed as leadership. It’s also framed as leverage.

And it worked, because coordination used to be expensive. If you didn’t have someone translating between design, engineering, analytics, marketing, support, and leadership, the system slowed down.

PRDs mattered because the cost of misunderstanding was high. Status updates mattered because nobody had a shared view of reality. “Keeping things moving” was a real job.

AI doesn’t change why product exists. We still win or lose based on whether we build something that creates value for customers and the business.

But AI does change what it costs to coordinate. And cost changes job shapes.

The tension: coordination is getting cheaper

A lot of what lived inside the coordination layer is now lighter, sometimes dramatically lighter.

Things like writing first drafts of PRDs, turning messy notes into clear user stories, summarizing meetings, extracting action items, translating a vague ask into a structured plan, even basic progress reporting.

With AI, none of that disappears but the effort drops. And when the effort drops, organizations stop rewarding the role that existed mainly to carry that effort.

This isn’t new in principle. We’ve always known that more options and faster feedback lead to better decisions. What’s changed is how cheap those options are to generate.

That’s why the PM role doesn’t just feel like it’s “evolving.” It feels like it’s splitting. Like the bar is moving as Charmy Jilka called out. That’s all because the underlying economics of the work are shifting.

The split: builders and coordinators

On one side are builders. These are not “engineers who moonlight as PMs.” These are builders in the product sense: People who take an idea and put pressure on it, explore multiple paths, test assumptions early, and get something real in front of users.

AI amplifies this type. Not through sheer speed, but through widening the surface area they can explore before committing. These Builders can consider more prototypes, more scenarios, more edge cases, more learning per unit time.

On the other side are coordinators. This is role many of us grew up with (or grew into). Coordinators align stakeholders, manage process, translate between functions, keep work moving.

In the world of AI, this is still valuable. Every organization needs people who can connect dots across teams.

But the “manual labor” inside coordination is shrinking, and that changes the bargain. If the coordination layer can be partially automated, then coordination alone stops being the value.

The uncomfortable part: careers were built on the old bargain

Here’s where it gets personal. A lot of product people build their careers by getting better at that coordination layer. They earn credibility by being the person who can bring clarity to chaos. Being a good leader has always looked like adding more of that.

Even further, most product organizations are still structured around coordination processes to keep things moving like status updates and alignment layers.

But what if abstraction isn’t the scarce resource anymore? What if closeness to reality is? That’s a disorienting shift, not because the work changed, but because what’s valuable did.

AI doesn’t remove the need for ownership, incentives, and decision-making. As Matt Haney put it: it can automate reporting, but it won’t fix a broken KPI cadence or unclear ownership. In other words: AI can reduce coordination work, but it doesn’t replace accountable operating models.

So the people who were rewarded for carrying the coordination layer now have to ask a harder question:

What is my value when coordination is no longer the bottleneck?

The system reframe: leverage comes from reducing coordination, not managing it

This is not an argument for builders vs collaborators. Not everyone needs to learn to code, but more people need to learn how to build.

That might look like: turning an idea into something tangible (a prototype, a flow, a draft), generating multiple approaches instead of debating one, or designing how something will be evaluated before it ships.

The real divide is between people who help the system learn and people who help the system talk to itself.

Leaders with the most leverage right now don’t look like they’re adding coordination. They look like they’re removing it. They still operate at the system level setting direction, articulating trade-offs, and shaping incentives. But the new class of leaders in the AI age are also close enough to the work to engage without disrupting the flow. They can test assumptions without spinning up a full process. They can validate a direction without turning it into a six-week alignment tour. It’s not that the role is splitting, the bar is moving.

Coordination isn’t going anywhere, it just doesn’t carry you anymore. AI is eating the “keep things moving” work.

A few months ago, a team would’ve spent days or weeks aligning on a one-pager doc before building anything. A lot of effort went into just getting something everyone could react to. Quite often that reaction was a realization we didn’t know enough, which tacked on more time.

Now we generate multiple directions in an hour and react to something real. There are still information gaps, but they show up faster and earlier, when they’re cheaper to address.

What’s left is whether you can think clearly, test fast, and actually build something that matters.

A useful question: who owns the outcome?

If builders ship fast but don’t connect to the business need, you get impressive demos that go nowhere.

If coordinators keep everyone informed but don’t produce customer value, you get motion without progress.

So again the question isn’t “builder or coordinator” as an identity. It’s: who owns the outcome, and how do they learn their way into it?

In many orgs, that question is left implicit. Everyone assumes the system will produce the outcome. But systems don’t produce outcomes. People do: Through decisions, trade-offs. through what they choose to measure and ignore.

AI makes this more obvious because it removes some of the scaffolding. When the paperwork gets cheaper, the thinking becomes the work.

What this means for PMs (and for teams)

If you’re a PM, the implication is straightforward and uncomfortable. If your main value is translating and coordinating, you’re sitting on a shrinking island. You can still be useful, but you won’t be differentiated.

Your leverage is moving toward:

• Clear thinking under uncertainty

• Fast, low-cost validation

• Product judgment that shows up in decisions, not documents

• The ability to build “just enough” artifact to learn, not to perform

• Operating model design: ownership, metrics, cadence, incentives

And if you’re a product leader, there’s a second implication: Leadership may no longer mean more distance from the work.

It may mean being close enough to reality to remove friction, not add it. To be close enough to ask better questions and to see the system fail before the quarterly business review.

The bet

Being a builder isn’t about tools. It’s about lowering the cost of exploring options so decisions improve

The PM role isn’t going away, but I don’t think we can assume that the prestige path continues to be “more abstraction, more coordination.”

In the version that survives, leaders will look a lot more like builders. NOt for the reason that coordination stops mattering but because the organization can finally afford to make coordination less central.

And when you can afford that, you find out what was always true:

The work was never the paperwork.

The work was the judgment.

Most teams think agent skills are just a better way to save prompts. That misunderstanding is going to break how they scale AI.

Better prompting is not why this category exists. It exists because large language models are generalists, while real work is local.

Your company has a codebase, a style, a release process, a risk tolerance, a customer promise, a bunch of half-documented edge cases, and a long trail of hard-earned judgment about what “good” looks like. The model does not wake up knowing any of that. Out of the box, it knows the broad patterns of software, writing, analysis, and reasoning. It does not know your team or your habits, practices, or preferences.

That gap is what this category is trying to close. The opportunity is not just better outputs. It is better transfer of judgment.

I’ve already seen teams hit this wall. One person has a “magic” setup that produces clean, reliable output. Another tries to replicate it and gets something slightly off. A third copies a few prompts from Slack and ends up with something slightly different again.

Everyone is using AI. Nobody is using it the same way. And nobody can fully explain why the outputs differ.

This category exists because organizations need a way to turn tacit judgment into portable context.

The real problem is not “better prompting”

Most people first encounter AI skills as a convenience layer. You install one that writes better tests. Another that reviews pull requests in your house style. Another that helps with release notes. Another that explains a codebase to new engineers.

From the outside, it looks like a bundle of reusable instructions, which is accurate but incomplete. A good skill is not just a reusable prompt. It is a decision policy in miniature.

It says:

1. Here is what to pay attention to.

2. Here is what to ignore.

3. Here is how we define quality.

4. Here is the order of operations.

5. Here is what “done” means in this environment.

That matters because the value of AI at work is rarely “the model knew something clever.” The value is usually “the model behaved in a way that matched the team’s expectations without needing to be re-taught every single time.”

That is a coordination problem, not a model problem. And coordination problems create categories.

Subscribe now

Why this category showed up now

Since AI emerged, teams could get away with treating tools as personal productivity software.

One person had a good prompt. Another had a better system prompt. A third built a little snippet library. None of that had to be standardized because the tools were mostly used by individuals, in isolated workflows, with low organizational visibility.

That phase is ending.

Now AI tools are being used to write code, summarize tickets, propose architecture, generate tests, review diffs, draft docs, and shape internal decisions. That means their outputs are no longer private drafts. They are entering shared systems.

The moment that happens, teams run into five problems at once:

1. Consistency: People want the assistant to behave similarly across users and tools.

2. Distribution: New teammates need the same setup without Slack archaeology.

3. Governance: Someone has to decide which instructions are trusted.

4. Maintenance: Skills drift as the codebase, process, and org change.

5. Security: A markdown file that can steer an agent is not harmless just because it is readable.

Once those problems appear, a category becomes inevitable because the coordination burden is real.

Why generic AI is not enough

A common reaction is: “Won’t the models just get better and better until this is unnecessary?”

Yes, they will get better. But that does not remove the need.

Smarter general intelligence does not erase local operating context. In some ways, it makes that context more important. The more capable the model becomes, the more leverage there is in steering it toward the right defaults and away from the wrong ones.

A stronger model can write more code faster. That only increases the cost of a bad instruction set.

This is why the category should not be framed as a workaround for weak models. It is better framed as interface infrastructure between general intelligence and specific environments.

The model supplies broad capability. Skills, manifests, scanners, sync flows, and conventions supply local control. Those are different jobs.

Most teams will fail here for a boring reason

They will treat skills as content when they should treat them as operations. Content is easy, operations are hard

Teams will install a bunch of clever skills, share them in a chat thread, maybe commit a few to the repo, and then declare that they are “using AI well.” But most of what they will actually have is scattered advice with no owner.

That approach fails for the same reason unmanaged documentation fails. I think this will be the dominant failure mode in the category.

The problem is upkeep. Almost every team can generate ten useful AI skills in a week. Very few teams can answer these questions three months later:

• Which of these skills are still current?

• Which ones are mandatory versus optional?

• Which are safe to trust?

• Which were written for a different workflow that no longer exists?

• Which outcomes got better after adoption?

• Who is responsible when the assistant follows outdated instructions?

If nobody can answer those questions, the team does not have a skill system. It has a pile.

Why the best teams will think about this like dependency management

The important shift is a psychological one. The best teams will stop asking, “What cool skills should we install?” and start asking:

• What repeated judgments are worth standardizing?

• What context should travel with the project instead of with a person?

• What instructions are important enough to version, review, and distribute?

• What guardrails do we need before these instructions touch production work?

This is where the real opportunity starts to become visible. The teams that win here will not just install better skills. They will build better systems for distributing, updating, and trusting them.

That is why package management, manifests, sync flows, and scanning matter so much. They are not just implementation details. They are signs that the category is maturing from personal hacks into team infrastructure.

If skills become operational, they need the same things as any other dependency: versioning, distribution, scanning, trust. That’s the gap tools like Skulto are trying to fill.

The deeper reason most teams struggle

Most organizations are bad at turning tacit knowledge into explicit systems. That weakness existed long before AI.

Teams say things like “Jane just knows how to handle migrations safely,” or “You kind of learn what good looks like after a while” or “There are edge cases here, but it is hard to explain,” or “We don’t really have a checklist. People just know.”

AI skills expose that weakness because they force a choice.

Either you make your operating judgment explicit enough to encode, or you keep paying for rediscovery in every prompt, every review cycle, and every new hire ramp.

That is uncomfortable. It’s much easier to buy a tool than to formalize a standard.

So many teams will fail because they do the easy part: adopt the interface for skills, manifests, or marketplaces then stop before the harder work of deciding what their assistants should actually be taught.

side note: security is not a side note

One reason the category exists, and will keep growing, is that these files are not passive. They shape behavior. In agentic workflows, behavior is power.

That means the trust model matters. Teams that would never curl | bash random shell scripts are still surprisingly willing to drop unreviewed instruction files into an assistant that can inspect code, run commands, and propose changes with authority. They see markdown and assume “harmless.” They should not.

The marketplace explosion increases the value of scanning and provenance, not decreases it. More supply is good for discovery, but it also expands the surface area for bad assumptions, malicious instructions, and low-quality cargo culting.

This is another place where the opportunity splits in two. One layer of the market will help people discover skills. Another layer will help teams trust them. Those are not the same job.

The general lesson is larger than any one tool: If a file can steer an AI agent inside a production environment, that file belongs in your operational trust model.

So why does this category exist?

Because organizations need a layer between raw model capability and local execution.

They need a way to package judgment, to distribute context. To keep teams aligned across tools and to audit what their assistants are being taught.

That is the category. Not “prompt libraries.” Not “AI tips and tricks.” Not “power-user customization.”

A new operating layer for making general-purpose models useful inside specific systems.

Share Product AF

What the winners will understand

The teams that get value here will treat skills the way mature engineering orgs treat other important interfaces. They’ll keep the useful ones close to the work, version what matters, review what gets shared, measure whether the instructions actually improve outcomes, expect stale skills to become liabilities, and distinguish discovery from distribution.

Most teams, at least at first, will over-install, under-govern, and confuse novelty with leverage.

That is normal for a new category. But it also means the long-term winners in this space probably will not be the teams with the biggest skill libraries. They’ll be the teams with the clearest operational discipline around what their AI systems are allowed to learn, reuse, and trust.

But that’s a much less glamorous story than “the marketplace has 350,000 skills now.”

The bottom line

This is why this category is here to stay. Not because prompts needed a better home, but because teams need a way to manage how their systems behave.

The moment a skill becomes important enough that you want everyone to use it, you’re no longer talking about personalization. You’re designing an environment. And environments come with requirements: standardization, distribution, maintenance, and trust.

Most teams will stop short of that.

A smaller group will do something harder. They’ll treat judgment like infrastructure. Something that can be encoded, versioned, distributed, and trusted.

That’s why Skulto’s place in the category. That’s the leverage.

If you want to go deeper on the technical side, Adam Cobb’s piece on why package management and scanning still matter after marketplace growth is here, and TJ Maynes’s piece on why a manifest matters for team-wide skill coordination is here.actually what would you recommend

Here’s how to use it

Open Source GitHub: https://github.com/asteroid-belt/skulto

Install: brew install asteroid-belt/tap/skulto

The reason we created it has less to do with tools and more to do with how work actuall flows. We built it because today when teams use AI its hard to adhere to standards and write code with consistent quality.

I’m not a technical person. You might not be either. So I want to explain why I’m excited about AI skills, and why I think Skulto can matter even if you never plan to write code.

Last year, ChatGPT added Projects.

It allowed you to group related conversations, come back later, and the system would carry some memory of what you were working on. It wasn’t perfect, but for the first time, it didn’t treat every thread as if it were your first.

That moment stuck with me because it made something obvious: when AI remembers more, you can do more with it.

Many conversations about AI focus on better prompting. IMO that isn’t where the real friction shows up. The real issues are in the second, third, and fourth time you have to remind it of your intent, constraints, and taste. It sucks when you put hours into a conversation only to realize you solved part of the same problem yesterday in a different thread. Now your options are all bad. You either abandon today’s progress or rebuild the same context again in your new thread.

It’s like having the same meeting over and over again or debating the same things repeatedly. Individually, that’s frustrating. For teams, it’s stagnating.

When context resets, teams lose focus and can’t work efficiently. With AI one person’s setup never quite matches another’s. Two people ask the same question and get different answers. And no one can point to a shared source of truth for what “good” looks like.

Share

I care about context because that’s how quality accumulates through context. For any software team, quality comes from context that carries forward, not one-off moments of brilliance.

Over time, teams learn where their standards sit. They learn which constraints protect quality and which ones are just noise. They develop a shared sense of judgment that survives more than one session, sprint, or release.

Applying that of accumulated contextual knowledge is what makes lasting quality. You can see it in writing as tone that holds across drafts, in design as component libraries and style-guides that prevent inconsistent experiences, or in product work as decision rights that don’t need to be re-litigated every time.

Most AI tools today interrupt that process.

They treat each interaction as a clean room. People may learn, but the system doesn’t. As a result, the AI’s output quality suffers even when the team knows better.

Where Skulto fits

Last fall, Anthropic added Skills.

At first glance, it looked like a way to organize prompts. But it offered a potential way to finally help AI remember more and allow teams to do more with it.

Skulto came out of running into that idea repeatedly while trying to work with multiple AI agents on teams.

We are setting a foundation. Before you can preserve context, you need a way to see what you’re reusing. You need a way to manage skills across agents, understand what they do, and trust that they won’t do something unexpected. Without that foundation, “memory” is just another abstraction layered on top of chaos.

Skulto is building that foundation.

Skulto is an open source registry (free marketplace) of AI skills where teams can discover, inspect, and manage skills, then use them across the agents they already rely on, whether that’s Claude, ChatGPT, or something else.

What Skulto actually does today

In practice, Skulto is a CLI and TUI app (so yes, it requires a small amount of technical comfort) for discovering, inspecting, installing, and managing agent skills across different AI agents.

It exists to solve the problem that once teams use more than one agent it becomes hard to tell what’s trusted, what’s been modified, or what’s safe to reuse.

Here’s what Skulto does, and why each part exists:

• A single control surface (CLI + TUI): One place to manage skills so shared practices don’t fragment across tools.

• A real starting library: 420+ curated skills and six starter skills so teams can align around examples instead of inventing from scratch.

• Search inside skills: Find what a skill actually does by searching its instructions, not just its name.

• Tag-based browsing: Explore skills by intent rather than repository structure.

• A built-in skill creator: Turn an idea into a reusable skill using structured specifications instead of ad-hoc prompting.

• Security scanning: Automatically scan skills for risky behavior so reuse doesn’t require blind trust.

• Works across agents and projects: Install globally or per project, with updates kept in sync so learning stays portable.

• GitHub repository support: Add, scan, and update any repository from the CLI instead of copying and forgetting.

• Offline-first behavior: Skills continue to work even when conditions aren’t perfect.

We are the only product on the market that scans skills for nefarious code, and the only one that combines a command-line interface with a managed database of skills usable across multiple agents. That matters because without trust in skills, reuse fails long before context is even needed.

Skulto is focused on making reuse safe, visible, and manageable. That’s the groundwork. Context can’t compound if the building blocks aren’t stable.

When those blocks are in place, quality has something to build on. And when that happens, teams can finally move forward instead of paying the same learning costs over and over again.

If you’ve ever felt that the best part of your team’s process is the part the tool doesn’t remember, you already understand the problem. The opportunity now is to design for continuity, and see what becomes possible when quality has somewhere solid to live.

Subscribe now

I hope you try it out. Tell me what you build.

Open Source GitHub: https://github.com/asteroid-belt/skulto

Install: brew install asteroid-belt/tap/skulto

Leave a comment

Suddenly, all the ideas and small tools I’d always carried around in my head felt doable. Things I’d previously dismissed as “not worth the effort” now felt within reach.

Through sharing my excitement with engineers I know I began to notice how every developer carries a set of preferences honed into instinct, like how tests should be written, tabs versus spaces, how much abstraction feels right, what “clean” means, where to trade safety for speed, and so on.

Those preferences work beautifully at the individual level. But on a team where building is collaborative they have to do more than coexist: they have to overlap constructively, complement each other, and sometimes give way.

As I shared, it became clear that AI tools don’t seem to help much with this. And I’m starting to wonder if that’s why we don’t hear more stories about teams AI-coding together at scale.

Where I see inconsistencies accumulate

Let me show you what this looks like in reality. Last month, I watched three developers on the same team each use AI to add error handling to different parts of their application.

• Developer A’s AI-generated code threw custom exceptions with detailed context objects.

• Developer B’s code returned Result types with explicit error enums.

• Developer C’s code used simple boolean returns with errors logged internally.

Or consider testing. One developer’s AI generated comprehensive unit tests with extensive mocking. Another’s produced integration tests that spun up a full database for each test run. A third leaned on property-based tests with randomly generated inputs. Meanwhile, the rest of the team’s AI-generated code often shipped with minimal or no tests at all.

This team’s CI pipeline was a Frankenstein’s monster with some tests running in milliseconds, others minutes, and new developers had to adopt multiple testing philosophies and toolchains just to contribute.

These are more than style issues a linter can fix. They’re architectural decisions that teams normally negotiate explicitly but that AI makes implicitly, file by file, developer by developer.

AI fits individual style better than collective agreement

My inspection keeps coming back to the belief that software only survives because coding is deeply collective, and that the real craft of building durable systems lives in the tension between individual expression and shared constraint.

Good teams aren’t aligned because everyone thinks the same way, but because they’ve negotiated a set of agreements they can rely on one another to honor.

AI tools, as they exist today, seem to fit cleanly into only one side of that equation. They adapt beautifully to individual style, mirroring how you think and reinforcing your instincts.

But good teams depend on consistency more than cleverness, and on predictability more than brilliance. What AI lacks is participation in the collective work teams do around the code to build that consistency.

How could AI be better for teams

Recently, I’ve been thinking about AI Skills as a way the economics and constraints of team coordination might change. What seemed “not worth the effort” before might be more within reach than ever. The question becomes: how do teams make their shared preferences tangible enough that AI can participate without dissolving it?

I see three emerging directions worth exploring:

Explicit team context through Skills. Instead of each developer configuring their AI individually, what if teams created shared Skills that encode the decisions they’ve already made together? A “Backend Error Handling” skill, for example, could specify: “Use custom exceptions in the API layer, result types in the domain layer, log but don’t throw in background jobs.” This treats AI less like a solo assistant and more like a new team member who’s been onboarded into team conventions.

AI-augmented code review focused on consistency. Most teams use AI to generate code, but its value might show up just as much on the review side. A skill that knows team patterns could help with PR review to make the inconsistencies easier to catch. A reviewer juggling multiple PRs might miss a subtle shift in error-handling style but an AI that knows the team’s usual patterns wouldn’t. This reframes AI from “code producer” to “alignment aid.”

Skills as living team agreements. If Skills become visible artifacts that teams discuss, refine, and version control alongside their code, they start to function like living agreements. The conversation changes from “what did you tell your AI?” after the fact to “what should our shared Skills encode?”. When testing practices drift, you update the Skill and everyone’s AI adapts together.

None of these are complete solutions. The tools barely exist yet, and the practices are still being invented. But they share a common insight: the problem isn’t making AI smarter at writing code in isolation. It’s making our collective agreements visible and enforceable in a world where much of our code is generated rather than hand-written.

The real challenge to think about next

AI doesn’t mind idiosyncrasies or provisional decisions. In fact, it often amplifies them. That’s a feature when you’re working alone and a liability when you’re trying to build something with other people that lasts.

The work of alignment has always been part of software teams. What’s changing is how easy it is to bypass that work while still producing something that looks plausible.

The question isn’t whether AI can help individual developers be more productive. It clearly can. The harder question is whether we can design AI-assisted workflows that make team agreements more visible.

I don’t think this is a solved problem yet. But I’m increasingly convinced it’s the one that will determine whether AI coding tools will simply keep individuals moving faster or actually help teams think together.

They're not universal truths. But they've helped me navigate messy situations, get unstuck faster, and make clearer decisions in ambiguous work.

1. Start simple, then extrapolate from there

So many things in life are hard to grasp quickly. New ideas are everywhere from interpersonal dynamics to product strategies to technical systems. It takes time and effort to understand it all.

When I started my career, I constantly felt like I was playing catch-up because every new detail seemed to require this enormous mental investment. I'd obsess over all the information, trying to master it all at once. I'd get stuck in this loop of "I need to understand every variable before I can move forward." Then a few weeks or months later, I'd do it all over again. I see coworkers and friends fall into this trap over and over again.

Eventually I realized is that most things, no matter how domain-specific or complex, can be distilled down into something simple. And once I got good at finding analogies, it unlocked something game-changing: fundamental principles or patterns are shared across almost everything. If you spot the common foundation, you can learn everything fast and deeply, without actually needing all the details.

Take coding. At its simplest, functions exist to do one of only two things: write new information or read existing information. There are a million different gradients between the two, but if you zoom out far enough, it's only these two patterns.

• Reading: understanding existing logic, consuming data, tracing flows.

• Writing: creating logic, mutating state, expressing intent.

Similarly, there's a moment in any technical problem where you're either creating new logic or trying to understand existing logic. Writing mode is generative. Reading mode is interpretive.

Am I creating something new? Or understanding something that's already been created?

That same zoom-out lens works in decision-making too. Not everything has one right answer. And that brings me to the next paradigm.

2. The difference between facts and frames

I've noticed that most problems are approached as if they have one objectively correct answer. But in reality, they don't. This fallacy has led me into so many endless debates, draining meetings, and decision paralysis.

How many times have you sat in a room where people argue about the "correct" strategy, user flow, or team structure? Experience doesn't turn anyone into a fortune-teller, and most high-confidence assumptions are nothing more than strong opinions.

So here's a small trick that's kept me out of a lot of rabbit holes. Anytime you have a problem to solve, or if you start to get into a pissing contest over a specific solution, think:

• Is this something that has one right answer? (math, compliance, binary processes)

• Or is it interpretive? (user experience and motivations, "is this MVP enough?", org dynamics, etc.)

If it's the former, the answer is knowable, so finding the answer might be worth it.

If it's interpretive, you'll never find a right answer in advance. In these cases, start trying out different possible answers and see which solves your problem. Looking for a right answer is a waste of time.

And just because something's interpretive doesn't mean it doesn't matter. Or that it can't be measured.

3. Not all outcomes are measurable

No matter how many dashboards you monitor, how significant your A/B tests are, or how many commas are in your salary, some of the most important successes simply can't be quantified. I don't mean to be philosophical. This is practical.

The absence of a measurement doesn't mean the absence of impact.

I'll never forget what Janice Fraser told me: "A mistake people always make is thinking goals have to be measurable." Not everything that matters comes with a number attached.

Think about it: Every action ripples outward. Some effects show up immediately in your analytics. Others take months to surface. And some of the most profound results like building a reputation, making yourself or people trustable and resilient, or helping others learn life skills may never translate cleanly to a chart.

As someone who works in product development, this paradigm is essential. We've all sat through meetings where someone demanded "measurable outcomes" for inherently nuanced work. While metrics matter, over-quantifying can actually diminish what you're trying to achieve. It's like trying to measure a friendship by counting text messages…you miss the entire emotional landscape.

When we force-fit complex realities into neat numbers, we often optimize for what's countable rather than what counts. Sometimes the most important signals come as tiny attitude shifts or very gradual movements, not data points.

If you only value what you can track in a spreadsheet, you'll miss half the system. The most valuable data sometimes isn't a number at all, it's a pattern you notice, a shift in behavior, or simply a feeling that something has changed.

Other Mental Models I Come Back To

The three paradigms above are my personal go-tos, but they're part of a bigger toolkit I've built over time. Here are a few mental models from others that have stuck with me and shaped the way I think:

• For uncovering fundamental truths: First Principles Thinking helps you break down problems to what's undeniably true before rebuilding from there.

• For acting on opinions while staying open to change: Strong Opinions, Weakly Held is a mindset that balances decisiveness with humility.

• For making relative (not binary) product decisions: Compare & Contrast Decisions is a great framework from Teresa Torres for choosing between options instead of chasing an illusion of "best."

• For knowing when to act and when to wait: Real Options helps you delay decisions until the last responsible moment without losing flexibility.

• For identifying what's blocking value delivery: Theory of Constraints helps you spot the single biggest limiting factor in a system so you can improve the whole by focusing there.

These paradigms aren't revelations. But they're reliable.

They've helped me cut through the swirl, decide faster, and focus on what actually matters, especially when everything around me feels messy, ambiguous, or emotionally charged.

Maybe they'll do the same for you.

Here’s one that’s been on my mind lately.

For years, I’ve been dealing with the long tail of a high school sports injury. With nerve damage and chronic pain I’ve spent years rotating around rehab strategies like physical therapy, strength training, HIIT, and more. All of it helped a little, but nothing stuck. Lately, I’ve been training something called Functional Patterns (FP).

FP…is different. It doesn’t work isolated muscle groups or brute strength. It’s focused on teaching the body how to move again intentionally, systemically, as a whole.

FP is slower, more intentional, and more methodical. It’s about teaching the body to move in total alignment through posture, tension, and timing. Not just repetition, but functional movement.

Naturally, I started seeing the parallels to product work. And the more I looked, the more it held up.

Because when you look at the dysfunctions of product development and the constant voices promoting the best frameworks and methodologies, I see the same pattern I saw in my own body: strength in some areas, deep compensation in others, and a lot of unaddressed dysfunction reinforced by well-meaning routines.

A Kinesthetic Product Org is built with a felt sense of how we move, where we’re drifting, and what needs attention.

Subscribe now

What Is Posture in a Product Org?

In the body, posture isn’t about standing up straight. It’s about creating systemic stability through structural alignment of how weight is distributed, how tension is stored, and how energy flows through the system. Good posture makes movement and applying force efficient. Bad posture makes everything harder.

In product teams, posture is strategy. Not the deck, the alignment. Posture is teams being able to apply the right amount of force and energy to any given situation.

If your product org feels like it’s fighting itself (think competing priorities, lack of risk-taking, absence of decision-making, constant rework) you likely have a posture problem. You're expecting teams to move fluidly without enabling them to work together. You’re compensating for lack of alignment.

Like the body, you can’t fix posture by solving one of the symptoms. You have to train the supporting systems.

What’s Breath?

In FP, breath isn’t only breathing. It’s the act of re-stabilizing under pressure. Breath acknowledges and regulates tension, realigns posture, and directs how you move next.

Breathing is rhythmic. Without it, posture breaks down during movement and it creates more dysfunction.

For product orgs, breath is akin to the habits that maintain strategic alignment. It’s how you retro. It’s how you listen to feedback loops. It’s how you respond and how you adjust to improve alignment.

In both FP ad product, breathing should become second nature. Of course, product teams that don’t breath don’t collapse. But they will drift out of alignment, moving with no sense of direction. They might execute but can’t explain why.

Breath is how your org remembers what it’s doing while in motion.

Awareness won’t come from more flowcharts

You can diagram a system all day but that doesn't mean you can feel it. Just like you won’t learn how to ride a bike without getting on an trying it, mapping out dependencies or adding swimlanes won’t fix how teams interact.

That’s one trap: we mistake one-off maps for embodying it. Diagrams are helpful, but they’re snapshots. Good movement is a dynamic feedback loop.

FP reminded me that alignment isn’t proven on paper, it’s felt under pressure. The best product orgs have strong body awareness. They know when tension is healthy, when movement is drifting, and when it’s time to reset.

I struggle to articulate this model precisely because it’s not one-size-fits-all. Think of it like your neuromuscular system: health isn’t about memorizing stretches. It’s about moving well, sensing misalignment, and adjusting often. It’s more about discipline than dogma.

A Kinesthetic Product Org sustains that cycle. It doesn’t depend on any one methodology but it always comes back to how it moves.

The Core Mechanisms

These are the embodied dynamics every healthy org needs to sustain forward motion:

• Breath: Reflection rhythms. Your capacity to realign while in motion.

• Tension: Potential energy. The friction between priorities and perspectives that creates stored power.

• Elasticity: Adaptive strength. Your ability to flex and focus effort without breaking.

• Posture: Strategic alignment. The integrated structure that holds all motion together.

Together, these form the rhythm of how an org moves. Breath → Tension → Elasticity → Posture → back to Breath.

The Awareness Practices

This is how you know it’s working:

• Postural awareness: Can you feel drift before the metrics say so?

• Breath discipline: Do your teams pause before reacting or do they react and chase requests?

• Functional feedback loops: Can you sense which parts fail under pressure, and why?

• Embodied knowledge: Can your teams anticipate issues before they’re measurable? Have you trained that organizational proprioception?

This is how I think we move from systems thinking to embodied practice. It’s less about what you document. More about what you feel.

Share Product AF

Functional First Principles

1. Focus small, intentional movements

In FP, it’s it’s about making small adjustments with control. You don’t rush reps or stack on weight to feel progress. It looks really easy from the outside. Even I’ll catch myself thinking, “this can’t possibly help.” And then I’m drenched in sweat.

It reminds me of how good product work happens. You don’t earn long-term leverage by pushing harder. You do it by making precise, high-signal adjustments that set up future movement. Your roadmaps are honed through progressive overload, not a pre-seeded to-do list.

I once worked with a team building an internal platform. Stakeholders loved the long-term vision but didn’t want to start small. Every foundational starting point was blocked because it did not create the “value” of the long term vision. "That feature is not for us," they'd say, "let's focus on the big things we’re all excited about." They weren’t allowed to build stabilizers. Trying to push weight with bad form stalled them for over two years.

2. Integrate movement across planes

Real movement is 3D. In FP, you’re always moving forward, twisting, stabilizing. The big muscles might visible move you, but it’s the deeper, hidden muscles that stabilize you. If any part overcompensates, others collapse.

What's fascinating is how product orgs are no different, excet the planes here are dellivery, discovery, and strategy. When you separate them, you create weird imbalances and the system has to compensate. This might look like research getting buried, or like designers being left out, or roadmaps ignoring reality. Over time these things compound into dysfunctions that eventually lead to injury.

I’ve seen teams spend weeks on discovery, then never revisit it again. Or ship something technically brilliant that no one can maintain. Or chase metrics that don’t match the problem. That’s all the same thing: overtraining one plane while ignoring the others.

Functional movement means your entire org system is stable during motion, the visible and hidden muscles flexing and firing together.

3. Tension and elasticity create functional power

In FP, tension is potential waiting to be used. The right amount of stored energy lets you move fluidly and explosively. With too little tension you collapse and with too much you strain.

The same goes for product orgs. Healthy tension (between strategy vs. delivery, today vs. tomorrow, speed vs. safety) creates resilience. Functional teams know how to hold that tension and translate it into forward motion.

Breath helps here too. Reflection is how you learn to tell the difference between productive strain and misalignment. It’s what lets you redirect energy rather than leaking it.

Most orgs are overtrained in the wrong direction

Like gym bros skipping leg day, a lot of product orgs are overdeveloped in the show muscles like velocity, demos, and dashboards. And they’re undertrained in the stabilizers that sustain progress like discovery cadence, cross-team trust, decision hygiene, and strategic alignment. They’re all biceps, no core.

Functioning well isn’t about pushing harder, it’s about moving smarter. That means improving how your system coordinates: how decisions flow, how information transfers, how feedback loops close. It’s the interplay between discovery and delivery, short-term execution and long-term vision.

At least that's what Functional Patterns taught me. And it's a mindset product orgs should train for too.

how can your team move more like a system with awareness and intention?

You don’t need stronger teams. You need an org that moves better.

Instead of looking at how each team is working, keep an eye out for alignment across them, set up points for inspection, and help them focus their push ⇆ pull energy well.

If you liked Be a Weed, this is the next layer. Resilience isn’t much more than enduring change, it’s adapting to it in motion.

If you liked Real Options, this is the embodied version. Sensing tension and elasticity tells you where to push and where to flex.

If you liked Velocity ≠ Progress, this is what progress actually feels like.

Train your org like you’d train a body. Odds are, you don’t need more strength. You need better movement.

Subscribe now

“Inspire customers with a valuable experience and delightful products.”

“Ensure the purchasing experience is trusted, intuitive, and frictionless.”

“Make finding the right products easy and fun.”

For people who aren’t used to clear outcome statements, it might not be obvious that despite sounding strategic, these outcomes are all fluff. If your teams are actually expected to operate from outcomes, they need to understand what those statements mean clearly enough to make tradeoffs, advocate for what they need, and connect work to strategy without second-guessing it. Outcomes that aren’t fully understood aren’t good enough to steer by.

The “outcomes vs outputs” distinction is one you’ve probably come across, but it’s often misunderstood. Just because outcomes are more abstract than outputs doesn’t mean they can’t be concrete. This assumption is the trap I’ve seen in nearly every “outcome-driven” organization: a fuzzy outcome gets written, a detailed plan gets built in its name, and teams start executing. Then the outcome is forgotten and never gets clarified, because there’s already a plan, right?

That’s an outcome mirage. A fuzzy outcome plus a specific plan kills autonomy while giving the illusion of it. No one can say what success is beyond executing to plan.

Clarity must be built

While leading the product practice at a large retail technology org, I had a chance to try a different approach. The org had been through the usual transformation: outputs to outcomes, project to product, delivery to discovery. Everyone spoke the right language but the impact hadn’t materialized. Teams were building a lot, but not tying it back to a coherent outcome.

We brought in DoubleLoop, a platform purpose-built to make strategy usable instead of aspirational. Unlike tools that live downstream of outcomes (roadmaps, project trackers, dashboards), DoubleLoop sits upstream, helping leaders and teams translate fuzzy vision into structured drivers, signals, and metrics that guide day-to-day work. Through that partnership we noticed something striking. The teams delivering the fewest outcomes weren’t confused about the work, they were confused about how the work connected to the goal. They had tactics, but no usable strategy. Not because they hadn’t been given one, but because the strategy hadn’t been clarified in a way they could use.

DoubleLoop’s scaffolds gave us a way to reverse-engineer clarity without having to rewrite vague goals. Outcome trees allowed teams to map from ambiguous phrases down to specific levers and measures they could influence.We didn’t publish templates. We started at the top.

Our thinking was if teams are expected to deliver outcomes, then leaders have to know how to define outcomes that actually mean something. That takes practice and ownership. It can’t be phoned in. It has to be built by them, not bestowed.

So we asked SVPs to articulate their domain’s outcomes. And what we got were well-meaning but vague statements like “We help customers shop seamlessly digitally and in-store.”

At this point, we had a choice: try to rewrite the outcome with the SVPs, or leave it as-is and teach their teams how to pull clarity from it. We chose the latter and stumbled across something I think is pretty powerful.

Operative phrases are your way in

An operative phrase is a directional word, like ‘fast’, or ‘delightful’, or ‘trusted’, that signals intent but hides the specifics. It’s where we were able to focus teams to start unpacking things. No matter how generic the outcome, we found that operative phrases gave teams something to start with.

For example, from the above outcome we pulled out two operative phrases: “seamless” and “digital and in-store.” Each phrase acts as a signal to flag attention and help focus for the groups and relevant teams below. Who owns the online experience? Who owns in-store? What does “seamlessly” mean, specifically? Is that different for the two contexts?

Helping teams ask these questions was about making strategy usable, not just wordsmithing. Operative phrases gave teams a way into the strategy instead of just nodding along.

An example of cascading clarity with operative phrases.

One of the clearest examples came from a platform team. Their group’s outcome, “network connection is reliable, available, and strong so the company can operate”, was a good start. But it wasn’t translating and the team kept disagreeing on priorities.

So we asked them to reflect on what “reliable”, “available”, and “strong” mean in their context and which was most important for their team, then we entered it into DoubleLoop’s AI builder, which parsed the operative phrases and proposed a structured outcome tree within minutes.

• Top node (Outcome): Reliable delivery of value to internal teams

• Middle nodes (Drivers): System uptime, time to recovery, incident volume, platform usability

• Base layer (Signals & Metrics): 99.9% uptime, average recovery <15 min, P95 support response time, usability survey scores

Suddenly, their vague outcome became a usable map. The team could see how different priorities would affect their goals, how they were already tracking, and where they had gaps. And more importantly, they built it so they felt more ownership.

Because the team built it themselves, with just enough scaffolding, they understood and trusted what it meant. Suddenly, their vague outcome became a usable map. The team could see how different priorities would affect their goals, how they were already tracking, and where they had gaps.

Subscribe now

Language, leverage, and operation

Zooming out again, once leaders and teams identified their operative phrases they could build outcome trees that meant something. And by inviting everyone to view the map they were creating living strategy artifacts linked to data and updated as reality changed.

This is what working with outcomes really looks like. It’s not the same muscle as defining outputs or drafting action plans. Those come later. First, you have to do the work to make strategy legible. That means defining your drivers and signals. What levers do we control? What signs tell us we’re making progress? How will we know when we’re stuck?

Only then will you be able to use outcomes effectively. Teams need shared language to spot over-investment, argue for under-measured risks, and have those conversations without defensiveness before tying plans to intent and aligning roadmaps to leverage points.

This is where most outcome rollouts fall flat and they get written off. Outcomes are supposed to create shared focus and real autonomy. But when you skip the clarity part you end up with hollow objectives and vague key results. You get:

• “Delight our customers”

• “Drive platform reliability”

• “Improve business outcomes”

No one’s going to argue with these, but no team could succeed with criteria so vague.

How to use operative phrases in the wild

One thing I took away from using operative phrases is that you don’t need to be a part of a transformation initiative to make it a habit. Anyone can do this and it works in so many situations. You don’t need a workshop. Just curiosity and the nerve to ask.

1. Listen for vague alignment. When you hear a statement like, “drive value,” “support the business,” “improve the experience,” or “ensure reliability,” don’t just nod.

2. Extract the operative phrases. Look for the squishy adjectives, verbs and abstract nouns that aren’t objective.

3. Cascade them into action. For each phrase, ask: How is this relevant to what I own? What’s observable? What’s measurable? What’s misunderstood? Even one level deeper can make a huge difference.

Most teams don’t fail from a lack of ambition. They fail from a lack of shared meaning.

So the next time someone hands you a vision statement that sounds good but doesn’t help you move, don’t nod. Ask what it means. That’s where clarity starts and the moment strategy starts to become operational. Whether it’s on a whiteboard or in a platform like DoubleLoop, the real work is making the abstract specific. Clarity isn’t a nice-to-have, it’s the foundation of real autonomy.

Share

Once it gains enough altitude it can coast on the currents, gliding for miles without flapping. Many large enterprises are already at this stage where the height they’ve risen to over decades sustains their momentum. But when the wind changes or others start to fly higher, the question becomes, can you still keep up and generate lift? Can you flap or have those muscles been lost?

This post explores something I’ve wrestled with since I read this HBR article years ago: Since the industrial revolution companies have been optimized for smooth, predictable systems. But the world hasn’t become smoother, it’s gotten weirder. And the systems we’ve inherited break under this pressure.

Leaders of industry were always the ones who mastered economies of scale. And naturally, that’s still what many C-suites aspire to. If you can keep everything running lean and fast, you win. Simple as that.

But is that still true today? What if the efficiency mindset we were taught to master is no longer the one that will help us thrive? What if the business rules we inherited are now making companies vulnerable?

How do you navigate that? Are you leading teams that can still build altitude? Who can respond and adapt mid air? Or are you quietly stripping away the very things they’ll need when the gliding stops?

Here’s my thesis: In a world defined by complexity and constant change, efficiency alone is like gliding. It feels smooth until the wind shifts. What once gave us an edge now erodes our ability to adapt. Doubling down on efficiency atrophies the strategic, operational, and emotional muscles that organizations need to generate lift again. And leading through that requires a counterintuitive shift: resilience isn’t built through more optimization. It’s built through stewardship.

Efficiency Is Factory Logic in a Wilderness World

Efficiency wins in a world where the system is knowable, linear, and controllable. It’s factory logic rooted in a worldview that seeks to eliminate variability, maximize output, minimize slack. Production lines were a competitive advantage specifically because **to create was literally predictable and linear.

But in knowledge work, there’s more uncertainty than predictability about what will come from your work. Impact doesn’t happen because of controlled environments anymore. The exception here might be applying that scientific method, but that process, as proven as it is, is essentially trial and error. The success rate of science experiments across pharmaceuticals, psychology, animal testing, and general labs is only 18%.

Picture a production line that only built what it intended 18% of the time. Can you imagine an auto manufacturer leaving the final product up to that chance? No way! Process efficiency needs close to 100% certainty.

Knowledge work can’t come near that threshold. It happens in much more unpredictable and evolving ecosystems.

I see a connection between this concept and Kent Beck’s analogy of Forest and Desert. Deserts are sparse and stable. You can see far ahead. You can optimize a path to cut through without changing the desert. Forests are different though. They are thicker, harder to navigate, and you can’t see where the path is ahead of you. But forests are also teeming with life and unpredictable. You can’t bulldoze through and expect it to remain a forest, you have to adapt to it.

There is a very different mindset needed to navigate a Desert vs Forest. My argument is that finding ways to optimize and be efficient, what we have been primed to seek, is a desert mindset. But Desert logic doesn’t build in forests.

Over-Optimization Creates Fragility

I was curious to know if this argument holds up. What are instances of over-optimized systems breaking? Is it true that, at scale, the pursuit of maximum efficiency through elimination of "waste" (buffers, slack, redundancy) creates fragile structures vulnerable to disruption? Outside of small companies disrupting incumbents, has over-optimization within enterprises actually traded resilience for efficiency?

Looking across the past 15 years, it wasn’t hard to find examples. Every buffer trimmed, every dependency tightened, every ounce of slack removed created more failure points for systems to break under pressure.

2008 Financial Collapse: Fragility by Design

In the lead-up to the crisis, financial institutions became masters of optimization by leveraging every asset, automating every trade, removing every “inefficiency.” But by removing friction and distributing risk without truly understanding it, they created a global house of cards.

Throughline: The systems worked perfectly until assumptions broke. The collapse wasn’t just about bad actors. It was about brittle systems built for speed and scale, not resilience.

2020 COVID-19 PPE Shortage

Hospitals and governments adopted just-in-time (JIT) inventory practices for critical medical supplies like masks, gloves, and ventilators. When global demand surged, supply chains snapped. There was no slack, no buffer, no redundancy.

Throughline: In pursuit of efficiency, the ability to absorb shock was optimized away. Lives were lost not just from disease but from the assumption that efficiency was always the right tradeoff.

2023 Toyota production halt: JIT revisited

Toyota’s commitment to lean manufacturing has always been a benchmark. But even they are vulnerable. First in 1997 a supplier parts shortage revealed just how interdependent and fragile supply chains had become. And again in 2023, another parts shortage, this time semiconductor-related, forced Toyota to halt production again.

Throughline: Even a best-in-class system built for continuous improvement can buckle under complexity. Toyota didn’t abandon lean, but they acknowledged that resilience means adding flexibility, not just eliminating waste.

2024 Crowdstrike Outage

A botched update by security software firm CrowdStrike caused widespread outages in 2024, bringing down tens of thousands of Windows systems globally. The culprit? A tightly coupled dependency between a low-level driver and critical operating functions.

Throughline: The system was “efficient” until a single fault cascaded across hundreds of enterprises. When dependencies are optimized for speed and uniformity without isolating failure, resilience vanishes.

The Brittleness Formula

What’s the pattern that supports my thesis? In each case there are 4 commonalities to look for

1. Optimization Pressure: Efficiency is a key lever enterprises use to reduce cost. In doing so they remove buffers, slack, and redundancy to achieve lean operations and minimize overhead.

2. Efficiency Gains: In the short term this approach leads to performance improvements as systems become more streamlined and cost-effective.

3. Brittleness Creation: However, the elimination of these safety nets creates single points of failure and tight coupling within systems, making them more fragile.

4. System Failure: The increased brittleness results in systems being vulnerable to cascade disruption events, where a failure in one part can lead to widespread system breakdowns.

These weren’t failures of execution. They were failures of adaptability. And as the pace of change increases the frequency of failure does too. We’re entering the age of Forests.

Build resilience with redundancy, reflection, and range

If you realize you are making unintentional short term trade-offs for resilience, what can you do? Prevailing wisdom says become more adaptable and resilient, but those are loaded terms. What’s their guiding principle?

If efficiency is about squeezing out what’s “unnecessary,” resilience is about preserving what might be needed later. I think about resilience coming from three factors:

1. Redundancy: These are your backup plans, excess capacity, and loose coupling. Redundancy increases your ability to absorb shock. One of my favorites stories about resilience is Teddy Roosevelt famously carrying an extra pair of glasses wherever he went. Or the bus factor.

2. Reflection: You need space to act intentionally. Even in crises pausing to make sense of what’s going wrong will help you form a better plan of action instead of pushing through it reactively.

3. Range: You need to be ready to operate in ambiguity. Learn to consider systems that support multiple paths forward and ensure people have context and support so they can act without full certainty. Find areas to become a generalist.

In a Desert mindset with 100% predictability these things are unnecessary, inefficient even. But in a complex world of Forest they’re survival traits.

Complexity-Conscious Leadership: Navigating the Zones

As a leader managing knowledge work, complexity is the new reality. You can still make the sure short time bets of removing toil and optimizing processes, but for long term success you have to make investments with less certain ROI. You have less visiblity into how and what your teams are doing. Your mindsets needs to evolve to be resilient too.

One source on how to applly redundancy, reflection, and range to your organization comes from the Depthfinding framework from The Ready. It starts by slicing organizational dynamics into four:

• Sunshine Zone: What’s visible on the surface: org charts, KPIs, strategy decks

• Twilight Zone: How work actually happens: rituals, incentives, team dynamics

• Midnight Zone: What’s unspoken: fear, identity, culture, trauma responses

• Sky: What’s outside: market shifts, societal forces, emerging trends

As a leader, if you work in an efficiency-driven organization, this is probably where you focus most of your energy. The Sunshine zone is also where most transformation efforts (i.e. moving and organization from a Desert to Forest mindset) start. But developing a resilient organization depends on change happening at deeper level in the Twilight and Midnight Zones, which are the messier, more human and emotional parts that resist control but shape everything.

My takeaway for you is: The Sunshine zone is the only layer that can be optimized. If you want to lead resilient teams in a complex world, spend less time refining the surface and more time tending to the roots you can’t simply optimize (e.g emotion, culture, incentives, dynamics, etc) in the twilight and midnight zones.

Learn how to be a steward instead of an authority. Complexity-conscious stewardship isn’t about having the answers or having a system to solve problems. It’s about knowing where to look, what to listen for, and how to ask questions and challenge everyone to make adjustments.

What got us here won’t keep you here

For probably as long as you’ve been alive, efficiency has been the game. In stable contexts, like assembly lines, logistics, or well-defined systems, it still is. But when you’re working in living systems, not machines, the game changes.

Today, complexity is the constant. Change comes faster, systems are more interdependent, and the unexpected is the norm. In that context the qualities we think of as strengths like precision, predictability, and optimization, now create brittleness.

We’ve optimized ourselves into fragility.

As a leader, this does not mean abandoning structure. For large organizations, don’t throw away what works. Keep the processes that provide stability and intentionally invest in what structure alone can’t offer: slack, optionality, sensemaking, and human judgment.

If you’re leading, that means shifting your stance. Less control and more stewardship. Less surface polish and more attention to what’s beneath.

In my view, the future belongs to those who can build for the wilderness.

other sources:

1. Schintler & McNeely (2022): how efficiency optimization creates brittleness vulnerability.

2. NIH Research (Dai et al., 2020): highlights "excessive individual-level optimization" without considering resilience.

3. PlanetTogether Analysis: analysis of how "Lean has very little room for error," leading to equipment failure cascades.

The Soviet Union had just launched the first satellite and sent the first human into orbit. The U.S. was scrambling.

Then President John F. Kennedy stood before Congress and made a bold declaration:

“I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the Earth.”

At that point, the US had no rocket capable of reaching the moon, no lunar lander, no playbook for space missions, no budget to support it. But JFK gave them one critical thing: a direction.

That shared commitment shaped how NASA operated for the next decade. It determined what to fund, what to prioritize, and what to let go.

And in 1969, eight years later, Apollo 11 made good on the promise. They didn’t get there because they had a perfect system. But because they were working from the same map and able to move their part forward with shared purpose.

Now contrast that with Kodak.

In 1975 a Kodak engineer named Steve Sasson invented the first digital camera. It was clunky and low-res, but revolutionary.

Execs saw it as technically impressive but dismissed it as “cute” and shelved it. Why? Because Kodak made billions from selling and processing film stock. Their core business wasn’t cameras, it was film. Digital photography threatened to undercut their most profitable line.

So instead of mapping their company toward the future, they kept optimizing their existing system at better film sales, bigger marketing, more of the same.

They were productive, but their work was not leading them anywhere purposeful.

By the time Kodak did pivot to digital in the late 1990s, it was too late. Other players like Sony, Canon, and Nikon had already captured the digital camera market.

From inspection to direction

A lasting productivity system needs both movement and purpose. They’re often mistaken for the same thing, but are actually separate elements you need to bring together.

We all tend to assume that if things are happening, value must be happening too. And from that perspective, when results fall short it’s low productivity to blame.

However, most system aren’t broken, what’s missing is clarity of direction. If it’s not clear where you want to end up, you’ll make a lot of motion without making real progress.

And even when direction is clear, it’s easy to stall out while trying to find the “perfect” next move. That can feel like purpose but without movement, it’s just another form of drift. Motion without purpose is noise. Purpose without motion is delay.

The kind of productivity I care about is momentum: direction with energy behind it. Momentum starts by choosing a direction and starting to walk.

That’s what this post is about. Productivity as clarity in motion.

In Part 1 of this series, we used productivity as a Lens to inspect how decisions are made.

In Part 2, we looked into the Mirror seeing how fear, power, and identity shape what gets prioritized.

Now it’s time to move from inspection and reflection to direction. Because your lens and mirror have hidden signals meant to spur you into action.

TL;DR

Aim for a system that creates momentum, not just motion. Because once your you get moving it’ll carry you. Figure out where it should take you first.

1. Motion needs to inform your map’s directional progress

Think about your team’s productivity as a wayfinding system: something that can guide, not just track, progress.

Most teams measure output: how much got done and how fast. But those metrics only tell you if work happened. They don’t tell you if it mattered.

Executing fast is valuable when it helps distinguish between making progress and accumulating motion. Motion on its own is just noise. Motion connected to purpose is momentum. Your system should measure momentum.

If you’re not clear on where you’re trying to go, your system will default your priorities to those that are loudest, whether urgency, volume, or reactivity.

I’ve seen strong teams lose their autonomy in a matter of weeks just because the leader who protected their space and clarity moved on. It’s shocking how fast drift can take over even when how the teams operates doesn’t change.

Something to Try: Before your next retro, ask: “Did we move closer to something we care about?”

2. Include what you want to protect

When you have a clarity of purpose and direction, protect it. Your system should make defending what matters easier, not harder. Every team has limited time, energy, and attention and if you don’t choose what deserves protection, the system will fill itself with requests, scope creep, and noise. Protect space for learning. Protect focus from interruptions. Protect trust by avoiding churn and thrash.

What do you want your team to optimize for? What deserves elevation?

Something to Try: Audit your current rituals. What are you actively protecting? What are you unintentionally sacrificing?

3. Always protect decision-making

By default, most systems are built for execution. They expect teams track work done but not necessarily better decisions made.

The flaw with this is that decision quality is where real leverage is. Processes that support output are easy but designing a system that supports decision-making takes ongoing intentionality and constant vigilance to maintain.

Good systems make tradeoffs visible. Great systems turn trade-offs into friction points that force choices. They help you consider and commit with intention before inertia makes the decision for you.

Something to Try: Review your backlog and roadmap. For each item, ask: Is this a bet, a belief, or a demand? Then ask: are we treating those differently in how we make decisions? You should be.

In Mirror, I shared a story about how I realized my approach was not improving my own opinions or allowing me to own decisions direction. A friend of mine, Coby Almond, called out an important point.

One principle I subscribe to, and something I hope is a through line in all of my writing, is: nothing works everytime or everywhere. That mindset of “we know better” absolutely falls under this principle. It helped me in the moment but, if left unchecked, it becomes an interia trap.

Don’t assume strong conviction means you’re right. You’ll stop listening, dismiss feedback as noise, and mistake decisiveness for direction.

Conviction without learning isn’t clarity. It’s a closed loop. A strong system makes space for feedback without losing ownership of the map or clarity of purpose.

4. Make drift detectable

Even the best maps are useless without a way to tell when you’ve gone off course. You don’t just need a vision, you need regular feedback loops to check direction.

Not metrics for the sake of metrics but markers that ask “are we still heading where we meant to go?”

Something to Try: As a part of your retros, add a monthly “drift check” to ask: “Are we learning what we hoped to learn?” “Are we doing meaningful work or just visible work?” “Are we still in agreement on what good looks like?”

If you’ve never done this kind of reflection, your system may be silently drifting and reinforcing the wrong signals.

5. Finally, build your productivity system on purpose

The biggest misconception about productivity is that it’s neutral. It’s not. How you work always reflects something, and if you don’t design it with intention it will default to fear, inertia, and the loudest voices in the room.

Lens helped you see how decisions get made.

Mirror helped you see what’s internal factors are shaping those decisions.

Map is about action and taking the reins.

Viewing your productivity system as a map means building it to work for you, now and in the future, and not the other way around.

You’re the Cartographer Now

Clarity keeps you purposefully on the path you chose. Movement drives progress. The productivity system you inherit doesn’t guarantee either of these and you’ll need both. Don’t just inherit or maintain your system. Design it to serve you.

If you’ve made it through all three parts of this series, here’s what I hope you take with you:

• Your productivity system reveals how decisions happen.

• It’s also a mirror that reflects your fears, defaults, and unspoken rules.

• And finally, it should be your map to help navigate with purpose instead of drifting and reacting.

You’re probably already be working long hours or feeling burnt out. You don’t need more motion, you need momentum. You need to choose where you’re going and build a system that moves you towards what actually matters.

Want help putting this into practice?

I created a Productivity Map Builder Notion template you can use to reflect on your system and redesign it with intention.

It’s lightweight, interactive, and built to help you protect what matters, upgrade decisions, and stay on course.

👉 Grab it here.

The team was demoing progress and we wrapped the session with a list of requests and new ideas from the stakeholders. The meeting ended, and walking alongside my pairing buddy, I suggested what we needed to do next.

“Okay,” I said. “So now we just figure out how to make all those changes they asked for happen, right?”

He looked at me and said, simply: “No.”

I was stunned. That’s the whole point of these meetings, isn’t it? To listen to stakeholders and act on it?

Then he said something that’s stuck with me ever since:

“They have an agenda. We’re building a product. Their feedback is an input for us but they don’t actually know what should be in that product better than we do.”

That moment cracked something open for me. Up until then, I wasn’t really making decisions. I was performing the role of someone who listens well and executes diligently.

But I wasn’t forming my own opinions or allowing myself to say no and trust my own judgment. I wasn’t shaping anything. I was mistaking productivity for responsiveness.

And what I realized is: how we work often reflects who we think we’re supposed to be.

From Lens to Mirror

In Part 1 of this series, I explored the idea that productivity can be a lens to inspect how you make decisions.

But it’s more than just how you operate. What you do reflects your fears, your assumptions, the risks you accept, and the invisible rules you follow.

It becomes a mirror that shows not just your process, but your posture.

💡 TL;DR

Your productivity system is never just a set of tools. It’s a reflection of power, fear, and identity: yours and your team’s.

If something feels off, it might not be something broken, but instead something being protected.

Productivity Reflects Fear

There is an element of fear behind most dysfunction, and that makes it easy to default to survival instincts.

When someone fears being wrong they hesitate to make decisions or take calculated risks.

• Someone afraid of saying no or being seen as a blocker will overcommit to everything.

• A team who fears being judged might refuse to descope a release, worried about shipping something unfinished.

• An org with no real conviction about what good looks like might lean too heavily on scoring models and dogma.

Our systems reveal emotional defaults. And fear manifests as structure.

Productivity Reveals Power

It’s tempting to think about what you prioritize as entirely objective. But not only is it rarely neutral, it’s heavily influenced by power dynamics at play.

• Which “quick ideas” from executives always get added? They have power.

• Which work gets cut when resources get tight? They lack power.

• Who feels safe saying no? Who doesn’t?

As much as we’d like to claim our priorities are purely about outcomes and value, many roadmaps are political documents as much as strategic ones.

One of my favorite definitions comes from Rich Mironov: “Prioritization is not an objective ranking exercise. It’s a negotiated settlement among powerful stakeholders with competing incentives.”

When teams struggle to prioritize, sometimes it’s because they’re stuck in an invisible negotiation they aren’t supposed to acknowledge.

I’ll call it what it is: you’re negotiating power.

Productivity Embeds Identity

Fear comes from care. When we pour ourselves into our work, our identity gets wrapped up in how it’s perceived. So when a decision threatens the work, it feels like a threat to us

And even when your identity gets wrapped up in good things, like being competent, collaborative, or valuable, sometimes your system starts to bend to support that image.

You’ve probably met these people:

• The Over-Deliverer: always “delivering” to prove their worth, tying value to visible output.

• The Consensus Builder: seeks constant alignment, needs harmony to quiet a fear of being disliked.

• The Optics Manager: prioritizes what looks impressive to leadership, regardless of real impact.

You might assume you’re optimizing for outcomes. But really, you’re optimizing for perception.

The point is, a lot of work happens to reinforce how people want to be seen more than to move the product forward.

Mirror Types: How Fear, Power, and Identity Show Up in Systems

So how does all of this manifest? These aren’t hard archetypes, but they show up often enough to feel familiar.

1. The Prover Provers are afraid of not being seen as valuable, capable, or trustworthy and they believe they have to “earn their keep” constantly. Because they often lack formal authority they try to gain power through high output because they equate productivity with credibility. This is reinforced by their self-perception as a doer or high performer. Saying no feels like failing that identity. As a result, they overcommit, take on too much, and burn out. Their backlog becomes a monument to people-pleasing.

2. The Avoider Avoiders are afraid of being wrong, challenged, or exposed. They tend to believe that trust comes from never making mistakes, so they play it safe, avoiding bold decisions or high-stakes bets. They often cede decision-making authority because they don’t feel empowered to take risks. Their identity is wrapped up in being cautious and thoughtful. But in practice, they stall progress and retreat into low-risk work. The roadmap fills with incremental changes while meaningful movement lags behind.

3. The Absorber Absorbers fear disappointing others, especially people with power. They don’t feel confident rejecting leadership input, so they say yes to everything in order to maintain access, trust, or goodwill. Because they don’t have formal authority, they rely on being seen as collaborative and dependable. Their identity is shaped around being helpful, adaptable, and “easy to work with.” But that same flexibility becomes a liability. They absorb scope creep, overextend their team, and quietly let strategic clarity unravel.

4. The Analyst Analysts are afraid of being blamed for a wrong or subjective decision. They seek protection in frameworks, scoring systems, and process rigor, not for insight, but for insulation. They often hold power or accountability without enough psychological safety to make gut calls. Their identity is tied to being logical, objective, and data-driven. If a decision can’t be justified through a model, it doesn’t feel safe. The result is slow decisions, false precision, and a culture that prioritizes defensibility over direction.

You’ll notice none of these are about laziness or lack of strategy. They’re about self-preservation, coping, and unwritten expectations.

And because these patterns are often rewarded (or at least not dis-incentivized) they become institutionalized.

You Can’t Fix What You Won’t Face

Rarely do we pause to ask: What is our current system reflecting back to us?

You can’t solve something until see it and recognize it as a problem. We spend so much time trying to optimize our systems but the way we work is not always the problem that should be solved.

If productivity is a mirror, the goal isn’t to make the reflection prettier, it’s to get honest about what’s there. And once you do that, I’ve found you can name what’s underneath and begin to build something better.

That’s where I see things going next:

From Mirror → Map.

Where you don’t just inspect how and what you work on, you design and shape your system on purpose.

Or are one who sinks hours into comparing frameworks like RICE scores or 2x2s without actually moving anything forward?

When you’re feeling unproductive most solutions start with a surface-level frustration: “Why isn’t more getting done?”

The first instinct is usually some kind of process optimization. After all, what do we all do when we feel disorganized and unfocused? We organize, we structure, we put processes in place.

If you’re anything like me, trying out a new productivity tool feels kind of exciting. It adds structure. It creates rituals. It promises clarity.

But here’s the problem: productivity tools don’t solve for clarity, they just simulate it.

Productivity Is Mistaken for Throughput

Optimizing productivity by adopting frameworks really only works in narrow contexts where you own the full loop and you’re already a in flow state.

In most situations equating throughput with productivity distracts from the real accelerant to high productivity: deciding what matters.

Most teams aren’t isolated units. They’re embedded in complex, interdependent systems where priorities shift without any warning, dependencies can’t be controlled, and through all that clarity on everything evaporates.

In that context, speeding up output without improving decision quality is like accelerating through fog.

What We Call Productivity Problems Are Often Decision-Making Problems

I hate when teams get labeled as not productive. In my experience, that term flattens complex dynamics into something that sounds like it could be fixed by just working harder. But teams rarely become more productive simply by doing more.

When I hear that a team isn’t doing enough, I don’t think about their effort. I think about the system they’re operating in.

What it usually means is: the reasoning behind decisions isn’t clear.

It always looks like a workflow issue. Or a motivation issue. Or a lack of effort. But what I’ve learned is that nine times out of ten, it’s not.

It’s a prioritization avoidance issue.

I’ve made this mistake plenty of times. I’ve pushed teams to do more in all the wrong ways (more process, more structure, more urgency). And you know what? It almost never worked. Because I was solving for effort when I should’ve been solving for clarity.

The team isn’t misaligned on how to move forward. They’re misaligned on what’s worth moving toward.

Productivity Reflects Your Decision Framework

Your calendar, Kanban board, rituals are not just coordination tools. They’re expressions of how your team makes decisions: what gets added, what gets done, and what gets ignored.

That’s your decision system, made visible.

Making your system more efficient is easy but the better question is: What kind of decisions does our system enable, or suppress?

Are you optimizing for throughput or clarity? Are you chasing consensus, or digging for conviction? If you had a handful competing asks, which one would you ignore and why?

The truth is, your productivity system already tells a story. You’d be surprised at how often it’s not actually the story you think you are telling.

For example, if you call your teams empowered but never push back on urgent asks from leadership, no matter how off-strategy or unclear, you’re not actually being a steward for the team. You’re reinforcing a different story: one where top-down urgency overrides team ownership.

Good Productivity Systems Support Clarity, Not Just Motion

To steward high-productive teams you should create clarity by creating a decision system that helps teams do a few things with intention:

1. pause when necessary

2. avoid reliance on frameworks and templates

3. build conviction, not consensus

Telling the story you want isn’t just about which tools or rituals you use. Two teams can use the same tool and have wildly different results.

Some systems look rigorous. Others look chaotic. The difference isn’t in how polished they appear, it’s in whether they create clarity or just the illusion of it.

We’ve all used the prioritization scoring models and used them (even unintentionally) to avoid hard conversations. It’s easier to say, “This one ranked higher,” than to admit, “We don’t know what matters.” When you’re uncertain, it’s more comfortable to let process decide.

But you can’t optimize your way out of ambiguity. it just leads you deeper into the fog.

At some point, you have to make a choice, even if the choice is to defer.

If your system doesn’t make space for that kind of timing and taking a pause is seen as indecision, it’s not helping you think. It’s just pressure dressed up as process.

And if you’re not careful, it’ll end up telling a story about how you work that you never meant to write.

Decision Quality Is the Real Leverage

The most impactful shift isn’t from slow to fast. It’s from foggy to clear.

Better bets made earlier leads to fewer dead ends and momentum you can trust.

The biggest productivity unlock isn’t doing more stuff. It’s doing fewer things, with purpose.

• From optimizing throughput → to improving decision quality

• From “How fast can we go?” → to “How well are we choosing?”

Most teams don’t suffer from a lack of effort. They suffer from effort applied to the wrong things. Their problem isn’t only low velocity. it’s having thoughtful people working hard on priorities that don’t have impact.

Prioritization is often treated like a planning activity. But it’s actually an act of leadership. Not hierarchical leadership, but personal leadership. The kind anyone can practice. All you need is to be willing to decide.

Every confident ‘yes’ or intentional ‘not yet’ builds a system that can move with more trust, more focus, and less waste.

All you need is the willingness to decide.

TL;DR: What to Ask Instead of “How Can Get More Done?”

Your productivity system is not a neutral toolkit or a silver bullet, it’s a lens into how you make decisions.

If it’s not helping you make better decisions and clarifying why they matter, it’s not actually help you achieve more.

If you’re stuck in a productivity valley and trying to figure out why it keeps happening, ask yourself:

• What is the next decision I have to make?

• What will make me confident in the next decision?

• How can this decision help unlock the next one?

Look at your team and its work.

What story should it tell? Is it telling that story?

Next: The Mirror

Looking at your productivity like a lens will help you assess the health of your decisions.

But it doesn’t just reveal how we decide. It also reflects who we are when we decide.

Your productivity system isn’t just a lens. It’s a mirror too. And in the next post, we’ll take a closer look.

Share

Someone leans forward, unmutes, and says:

“But is that even a real experiment?”

“Where’s the control group?”

“This isn’t statistically significant. What can we really trust here?”

I’ve been in that meeting. I’ve probably asked those questions. They’re not all bad questions (okay, they are pretty bad) but they reflect a deeper confusion.

Experiments aren’t just process to perform, they’re a tool for reducing uncertainty.

Sometimes you need a “Capital-E” (E)xperiment. But often, something I call a “lowercase -e” (e)xperiment will get you there just as well and faster.

That’s the language I’ve come to use to describe activities you learn from but wouldn’t qualify as formal experiments. It’s not perfect, but it helps me separate the form of an experiment from the function of experimentation because in modern software development, I’ve found we talk a lot about experimentation but rarely inspect how we experiment or why.

Somewhere along the way, “experimentation” became a ritual characterized by formal hypotheses, control groups, and scientific theater. That level of rigor has its place, but not every product decision needs to be treated like a peer-reviewed journal submission.

The function of experimentation: learning under uncertainty

I hear A/B tests described like gold standard truth machines. As if anything less structured is too flimsy and doesn’t “count.”

But in the real world rigor doesn’t guarantee truth or success. It just guarantees structure. And structure isn’t the same as insight.

The purpose of experimentation is not to check a box. It’s to reduce uncertainty. To discover value. To get smarter.

When we confuse the tool (an experiment) with the goal (learning), we start optimizing for the wrong things.

I think of the spectrum of experimentation something like this:

When “Capital-E” (E)xperiments shine

Use (E)xperiments for your high-stakes bets. Think science vs art. Think pricing changes, new customer retention strategies, or anything that could meaningfully affect the business at scale. (E)xperiments stand up to objective scrutiny in contrast to scrappier “just ship it and see” efforts. You need strong signal with low noise. You’re trying to validate or kill an idea with confidence.

But (E)xperiments come with trade-offs. They take more time, coordination, and investment. They need stable traffic and clean attribution, without which you risk false precision and can cause you to delay action waiting for statistical significance.

Examples of Capital-E (E)xperiments: A/B tests, Multivariate testing, time bound baseline testing, etc

You earn the right to run these types of tests after you’ve eliminated shaky underlying assumptions and explored the edges of the idea. Not before. If you don’t already have an opinion you want to test, you are not ready to run an (E)xperiment.

The power of “lowercase-e” (e)xperiments

These can be everyday sense-making activities. Think having a conversation with a few users, sketching a janky prototype on a literal piece of paper, or doing a hallway test with a colleague. They're about directional learning and momentum towards removing shaky assumptions.

They often don’t look like experiments at all. But that’s kind of the point. You don’t need to be “doing science” to learn something useful.

If you’re trying to answer:

“Is there some signal here?”

“Are we on the right track?”

Then these small (e)xperiments are invaluable. They won’t give you confidence intervals but they might give you 80% of the learning in 10% of the time.

The real risk: performing science instead of practicing learning

This is where teams get stuck: they run (E)xperiments™ without learning. A/B tests are launched with fuzzy hypotheses. Success is measured with metrics that don’t map to value. And when the experiment ends…nothing changes. Let’s even say say statistical significance is declared but did not account for the other ongoing tests as influencing factors. Once it’s implemented the expected impact…never materializes.

A successful A/B The point is, don’t confuse ceremony with substance. A clean room doesn’t mean you’re learning the right thing.

This is why I agree with Ash Maurya, who says “Running experiments is not the most important thing scientists do. Explaining what they observe is.”

And that’s the thing, real learning often happens after the test ends.

How to Choose the Right Tool

When you’re deciding how to approach a problem, start with the uncertainty before selecting the method.

Ask yourself:

• What decision am I trying to make?

• How much uncertainty exists?

• What’s the cost of being wrong?

• How fast do I need a signal?

If you need direction, start small. If you need confidence, scale up. Instead of striving for purity, we should strive for usefulness.

This matches what Itamar Gilad points out: “Experimentation is a learning engine, not a performance review.”

When rigor becomes a roadblock

(E)xperiments sound great in theory. But in practice? They’re fragile. They require clean starting conditions to work well.

Messy attribution? Leaky funnel? Flawed measurement? You might end up trusting noise dressed up as certainty or running a test you’ll never implement. Or worse, the perfect experiment set up can take so long that momentum dies before the learning even begins.

That’s the irony: chasing rigor for rigor’s sake often slows down the very thing experimentation is meant to accelerate: learning.

Think through the tradeoffs of the tool you select

Every experiment is a tradeoff between confidence and speed, thoroughness and momentum, the desire to be right and the need to move.

The simplest way I’ve found to frame it: (E)xperiments favor confidence over speed while lowercase-e experiments prioritize speed over certainty. Neither is better. But both come at a cost.

• Is confidence more important than speed right now?

• Will the precision of the answer actually change the outcome?

• Are we in explore mode or refine mode?

The best teams don’t chase rigor, they chase relevance. They know exactly what kind of learning they need right now.

Experiments are tools, not identities

There’s a subtle pressure to look rigorous. To be seen as someone who “does things right.” But experimentation isn’t a badge of craft. It’s a tool. And tools only work if you use the right one for the job.

Next time someone says:

“But that’s not a real experiment,”

Try reframing:

“It might not be rigorous, but it helped us learn something we didn’t know yesterday.”

“It’s not conclusive but it’s enough to take the next step.”

Sometimes, that’s all you need.

The real goal: reduce uncertainty, not prove a point

If you’re chasing whispers of demand or validating a hunch, you probably don’t need p-values. You need direction. If something seems promising then yes - tighten the variables. Run a cleaner test. Break out your lab coat.

But not before.

The best teams are the ones learning fastest, with the least effort, and acting on what they find.

Final Thought: constant learning rarely looks like science

Great product teams don’t just run (E)xperiments. They think experimentally. They build feedback loops into everything they do. They care less about looking scientific, and more about getting smarter, faster.

And that mindset really compounds over time.

You don’t need a lab coat to reduce uncertainty. You need curiosity, context, and the humility to say: we don’t know…yet.

Subscribe now

"I want to empower my teams, but there are a million things they already need to do. We can’t just let them make all the decisions…"

— A committed but confused product VP

I’ve seen the road to product chaos. It’s paved with good intentions.

On one side are burned-out husks of teams given false freedom to deliver fully predefined priorities. On the other lie the bleached bones of teams granted decision-making power, but no strategic direction, slowly drifting away from anything that drives value.

These are two ends of the same horseshoe: one on a sliver-thin path with a false perception of freedom, the other lost in an open field. Both have been given empowerment. Neither is empowered. Both fail.

I should caveat that I don’t see this as a flaw of those trying to create autonomy. Empowerment is hard. If I could give one piece of advice to leaders on both sides of the horseshoe, it’d be this:

• For the leaders on the left, pick one or two corporate priorities—and help your teams balance their work mix.

• For the leaders on the right side, give your teams a through line that threads all the way to a shared goal.

If self-organization is a key principle of empowerment, then so is intentional leadership. Autonomy doesn’t thrive by default - not when we expect teams to know what to do and just “run with it.” Table-stakes to creating autonomous, empowered teams is the condition of committed and involved leadership.

• In Part I, we talked about the need for shared practices and enabling constraints.

• In Part II, we explored how teams need a balance of work types to not just do the work right, but do the right work.

• Now in Part III, we’re diving into the leadership layer:

  • How do we create structure that supports autonomy?

  • How do we make sure teams are empowered and accountable?

  • And how do we know if it’s working?

Autonomy Without Structure Isn’t Empowerment

One of the most common failure modes of empowerment is assuming that once teams are autonomous, the rest will sort itself out. This has never worked before so don’t assume your team is special.

Empowerment is about helping teams anchor their decisions in shared outcomes with clear accountability.

In this, leaders have the most important role: setting shared direction. There are many frameworks that help with this (shout out opportunity solution trees), but conceptually, this is the scaffold underneath them all:

1. A long term business outcome / vision (why) that your teams are working toward together.

2. A focused set of strategic levers (what) that are the areas of opportunity believed to be the strongest bets to achieve the above outcomes.

3. Sometimes - especially in bigger orgs - you might have multiple levels of this tying outcomes to lever more and more grnularly

When you start down the path of empowerment, each of your teams or domains should have a clear strategic lever to connect their work to a measurable outcome. From there, each team should get autonomy to break that lever down into prioritized problems to solve and define leading indicators that track toward their long-term outcome.

By following this in principle, you’ve set up clear expectations and enabling guardrails: teams are free to focus on what they believe is most valuable—as long as they stay aligned to the strategic lever, and report progress based on success metrics and their contribution to the shared outcome.

“The principles of outcomes over output apply to the whole organization, not only the teams. '10 features this quarter?' That’s output. 'Moving the right metrics?' That’s an outcome."

—Aakash Gupta

When teams understand how their work ladders up to a shared outcome and having success metrics tracked in the open, it creates the conditions you need for real ownership. Not only over the work that ships, but over the impact it makes.

Top-Down vs. Bottom-Up Is the Wrong Question

Once the structure is in place, the real work begins—because empowerment isn’t just about what’s defined on paper, it’s about how people behave within that system.

A challenge I often is “we can’t just let teams decide whatever they want to prioritize.” They’re right—but also missing the point.

Autonomy has never been about choosing between top-down and bottom-up control. It’s about designing a system where top-down strategy and bottom-up insight are in constant conversation. Where both leaders and teams take on new behaviors to make that system work.

Jochem van der Veer puts it well in his post, Top-down or bottom-up prioritization is not a decision to make:

“Setting goals and KPIs is done top-down, and everyone has a process for it. Bubbling up opportunities from research, data analyses and customer insights is a bottom-up process every company practices. And yet, how many of us have fabricated OKRs because we couldn’t align on which opportunity to pursue?

The real opportunity—and the real discipline—is using bottom-up opportunity discovery to inform the top-down delivery system. That’s the magic. That’s where empowerment becomes real.”

Thinking about you behavior as a part of a holistic system creates a shared mental model across teams. Goals aren’t vague. Opportunities aren’t disconnected. Strategy and delivery become two sides of the same coin.

(And this is where frameworks like OKRs often fall short—they set goals but don’t help teams connect them to meaningful opportunities or decisions.)

A better question is who can make which decisions

So how do you give autonomy without creating bottoms-up vs tops-down tug of war? One concrete way is to clarify decision rights.

Decision rights are a technique to build a shared understanding of who decides what so people can do their best work without ambiguity or delay. It empowers everyone by articulating the specific choices a person or team can make without needing approval from others.

For example, rather than saying a team "owns product delivery," decision rights clarify that they can decide when to release, what sequencing to follow, or when to change timelines—without escalating every time. These boundaries aren't meant to restrict; they're enabling constraints.

To be effective, decision rights should be:

1. specific, not conceptual

2. co-created with the people doing the work

3. live with the roles that are closest to the work

4. evolve as context changes.

5. reflect what leaders are actually comfortable giving away. Pretending to empower while holding back authority is worse than being honest about the limits.

Clarifying decision rights is not about dodging accountability or avoiding collaboration. They bring autonomy to life by establishing consent for the guardrails within which a team can truly operate. Done well, they make work faster, more focused, and more strategic.

When we say we want autonomous teams or to follow the Product Operating model, we can’t forget that autonomy only lasts when it’s backed by (1) structures that reduce friction and reinforce purpose, (2) alignment on transparent metrics that matter, and (3) consent on clear decision rights.

Leading empowered teams looks different than leading teams did 30 years ago: it’s evolving as an even more critical and dynamic role that requires different principles:

• Asking questions and setting context over setting priorities and roadmaps.

• Creating feedback loops over relying on process rigor and status reports.

• Communicating constantly over presenting finished plans.

• Monitoring measurable progress over tracking output.

• Reinforcing accountability to customer and company over reacting to to internal demands.

Self-organization doesn’t mean chaos. It means treating people like adults who are trusted to make good decisions.

These aren’t just modern management techniques—they’re the new fundamentals of leadership in an empowered, outcome-driven organization.

What This Looks Like in the Real World

Take Sarah's team at a mid-sized e-commerce company. Their leadership doesn't hand down a massive to-do list. Instead, they give the team something more powerful: clarity.

The team's north star is simple: Become the most personalized shopping experience for young professionals.

Their concrete goal? Increase repeat customer purchases by 25% in 18 months.

Their biggest strategic lever? Reduce friction for first-time buyers.

That's it. No 50-page strategy deck. No predefined feature list.

Here's the real twist: Sarah's team gets to define their own leading success metrics. Leadership sets the high-level outcome, but the team decides how they'll measure progress. Maybe they create a "customer discovery ease" score. Or track time-to-second-purchase. They're not just executing. They're strategizing.

In their monthly check-ins, the conversation looks totally different. It's not "What features did you ship?" Instead, the first questions are always:

• "What's our progress on repeat purchases?"

• "What did we learn about customer behavior?"

Sarah's team now has total freedom to experiment. Some weeks they're running customer interviews. Other weeks they're tweaking recommendation algorithms. They might redesign the homepage navigation or create smarter email triggers.

What makes this work? Their leadership team tracks an outcome that’s measurable, not just shipped work. They set the team up for success by providing context about why the work matters and gave full decision-making power within enabling constraints. And finally they talk regularly to discuss learnings, not micromanage.

The magic is in the boundaries. Empowerment implies real accountability to results. If an empowered team isn’t improving the outcomes they own, something’s off. If the team knows exactly what success looks like, knows what good progress looks like, and knows what choices they have full ownership of, they are set up with complete autonomy to get there.

This isn't just empowerment on paper. It's empowerment that actually works.

Wrapping Up: Empowerment Is a System

Empowerment is a privilege, not a default. It does not work through a policy or a principle, it’s a system. One that depends on shared practices, committed leadership, clear outcomes, and explicit decision rights.

It’s not about letting go. It’s about showing up consistently, intentionally, and transparently.

If you want teams to do their best work:

1. Give them a clear direction.

2. Make sure they know what decisions they can make.

3. Care about progress made through real results, not activity.

4. And stay in the loop. Not to control, but to support.

Because when empowerment works, it doesn’t look like chaos. It looks like clarity, ownership, and results.

Thanks for reading this series on the conditions for empowerment. If you’ve been following along from Part I through Part III, I’d love to hear what resonates or where it breaks down in your context.

“... no matter what the client says the problem is, it is always a people problem.”
- Kent Beck, Extreme Programming Explained: Embrace Change

If you want to empower your teams and make it stick, there’s first some groundwork to lay. You need to create conditions that will support the people you are empowering. Last post I proposed a key element is having shared practices and enabling constraints. Another critical piece of building empowered teams is ensuring they are applying their talent to the most important work. Creating an environment where teams can thrive is also about where they focus.

This is the argument for making sure teams commit to work they should do, not simply what they can.

Always doing different types of work helps manage the mess

On any given product team, work falls into different categories. John Cutler has written about balancing rigor and flexibility from a different perspective that I think applies here too. I like his buckets, but I’m adapting them slightly:

• Corporate Initiatives (“large, complex projects”): Top-down projects that align with company-wide goals. These provide direction, but an overload of them can stifle team autonomy, making teams executors instead of decision-makers.

• Zero-to-One Product Work: Work focused on creating new products or features from scratch. This drives innovation but can become disconnected from overall strategy if done in silos.

• Maintenance and Improvements (”independent product work”): Refining and sustaining existing products based on user feedback or making technical improvements. This is critical for long-term success but often gets deprioritized in favor of net-new work.

  

If you want to create autonomy, find the middle

Different types of work are best suited for different levels of autonomy. Startups, small companies, or teams with immature products have lots of freedom to carve their own path. More established organizations with mature products often have teams with less autonomy because it’s important to make sure the work supports broader goals (but at the same time, it’s more difficult and complex to do so).

If you’re starting from a place of high autonomy (left side), like at an early-stage startup, as you build 0-1 products you need to balance time spent on shipping new work with maintaining and iterating on what you’ve already built. As you scale to multiple teams, you also have to introduce corporate-level initiatives that drive broader impact.

If you’re starting with more rigidity and less flexibility (right side), like an enterprise or mature product ecosystem, you’re at a place where big, complex corporate priorities take up a bulk of teams’ focus already. You already have the rigor and need to increase team-level flexibility.

Empowered teams naturally thrive in the middle scenario, where these different types of work are in balance. The problem is, being in the middle is a lot messier than being at either end of the spectrum. There’s more visibility, less defined boundaries, and more responsibility. I’d argue that a key component of having autonomous, empowered teams is being prepared to navigate that 'messy middle.’ If either your leders or your teams aren’t committed, this autonomy won’t last. Everyone together needs to pay attention to the balance of work happening at any given time, not only how and when it’s being done. When empowered teams operate out of balance they’re more likely to turn into reactive order-takers, build things disconnected from strategy, or get overloaded with top-down priorities. Inevitably, products and outcomes suffer.

Empowerment requires rethinking how your org works too

When companies say they want to empower teams, its common to only look at how the teams need to change. Yet for empowered teams to succeed it’s not simply about “giving teams ownership” but making sure they have the guidance and air cover to support a healthy mix of work. The right balance between rigor and flexibility is one the organization itself needs to consent to.

A healthy team doesn’t just do one type of work, it balances all three. Too many corporate initiatives? The team is not empowered, it’s a feature factory. Too much zero-to-one work? The team is detached from any coherent business goal. Too much maintenance? The team stagnates, stunting progress and impact.

If teams have real decision-making power and autonomy to achieve outcomes, they need dedicated space to work on product-driven and maintenance efforts with clarity into they can impact broader goals, a say in how priorities are shaped, and a system for balancing work types.

True empowerment and autonomy are not about letting people do whatever they want, it’s about treating them like adults by creating the conditions for success, enabling focus on meaningful work, and providing the freedom to operate within that space.

Coming Up in Part III

In the next part of this series, we’ll explore signals you might not be as empowering your teams as well as you think plus practical ways to help teams practice cohesively and prioritize effectively, including:

• Establish decision rights

• When to set priorities without micromanaging

• Balancing company goals with team-driven initiatives

• Avoiding overload while keeping teams accountable

There are two types of people in this world: those who love Agile and those who hate it. Either Agile works or it sucks. It’s either being used wrong or it will never work.

The point that matters is usually missed though: forget Agile frameworks. What’s undeniable is the world is changing faster than ever. In business, in life, in community, thriving means getting better at responding to change. Especially with unlimited information at our fingertips, the real outcome is knowing what to pay attention to and what to ignore. The reality is what worked in the past just doesn’t work as well anymore. Because of that, it’s hard to be convinced that agile is dead.

In business, smaller faster newcomers beat large market incumbents more often. The ones that survive do so by learning to change direction fluidly and coherently - finding new ways to grow, win customers, or keep market share by staying relevant.

Agile frameworks can be one solution, but they are not the solution. In fact, there is no single solution for everyone. Agility is what helps disruptors win, And frameworks are just one strategic option to get there.

Whichever camp you fall into, the importance of becoming more adaptable, responsive, and flexible is what should matter, not the methodology. And unfortunately, no one—including the Agile experts with fancy frameworks—can hand you a playbook for that. Operational adaptability is highly contextual, not deterministic.

Being Agile has nothing to do with being agile.

Stop glorifying and villainizing Agile. Make it about adaptability and results.

In theory, being empowered is paradise for individuals and outcomes. But in practice (outside the walled garden) it’s more of a purgatory. This gap between theory and practice leaves many teams and organizations feeling trapped between too much autonomy and too much oversight.

How do others manage this disconnect? Jeff Bezos had a surprising take on it: “If we wanted Amazon to be a place where builders can build, we needed to eliminate communication, not encourage it.” A counterintuitive point, but what he was getting at is that too much leadership input can stifle innovation. Builders need to be allowed to build.

Bezos emphasizes that reducing unnecessary oversight is critical for innovation. But there’s a second key ingredient: the ability to work distraction-free. Morgan Housel of Collab Fund takes this further, explaining that true autonomy comes from having the space to apply your expertise without constant interruption.

Tacking this idea on to Bezos’, empowering others is not about granting unlimited decision-making power. To operate with autonomy is to have a structured environment, kind of like a like a well-marked trail, with freedom to move, experiment, and build without constant oversight. Too much freedom without boundaries, and teams can get lost. Too many restrictions, and they struggle to move at all.

Think about a great teacher you had growing up. My guess is they didn’t micromanage every aspect of your learning process but they also didn’t leave you to figure everything out on your own. They set up the right structures (curriculum, feedback, guidance) while allowing flexibility for you to learn in your own way. That same balance of structure and autonomy is what makes empowerment work in any system, including teams.

This tension between freedom and structure has led to a fundamental misunderstanding of empowerment. It’s often interpreted as the need to remove all constraints, but in reality, it’s about designing the right ones. This is a big topic and I plan to share my thoughts on the conditions needed to empower people in a couple parts. This post focuses on shared practices.

The “Office Space” approach to shared practices

Bezos and Housel are great and all, but I’ve got a better example: the 1999 movie Office Space.

If you’ve seen it, you’ll remember the infamous ‘flair’ scene. Employees at Chotchkie’s restaurant are required to wear at minimum 15 pieces of flair (buttons, pins, etc.), but are encouraged to express themselves by wearing more. Some employees go to extremes—piling on 37 pieces to prove their enthusiasm.

It’s actually a great illustration of the components you need to empower teams: minimum expectations, individual flexibility, and implicit leadership pressures.

How this can work in practice

A couple years back I tried this approach with a team of product managers. Everyone had varying levels of experience, skills, and preferences and Office Space worked to make the concepts of practices, principles, and constraints more relatable. We defined our boundaries and autonomy around three categories:

The “Uniform” (things we all do):

Some things must be consistent across all teams. These are the foundational practices that provide clarity, efficiency, and alignment. “Uniform” doesn’t mean rigid rules, it means shared agreements that make collaboration easier. Having a baseline set of expectations acts as a common language across teams. Here are some examples from our working sessions:

• For user stories: Use a consistent template for writing stories (e.g., “As a user, I want…”).

• For presentations: Every quarterly update needs to review of Goals/OKRs to provide clarity on priorities.

• For process consistency: Teams should use labels and epics sparingly and intentionally to promote small releasable stories and avoid clutter and irrelevant groupings.

The goal isn’t standardization here. Not everything needs to be identical. These aren’t bureaucratic rules or processes, they’re principles that enable execution and alignment.

Allow “Flair” (where to be flexible):

This is where teams and individuals can adapt based on what works best for them. While uniformity provides structure, flexibility allows for creativity, innovation, and ownership. Everyone has different natural strengths, styles, and preferences for how they work best. They should be given space to “express themselves” within the broader structure. This is where creating flexibility creates room for empowerment.

• For user stories: Everyone can choose how much detail to include in their stories (some teams may prefer a highly detailed breakdown, others may keep them lightweight).

• For presentations: The order of slides or how content is presented (e.g., narrative style vs. data-heavy approach) is variable.

• For communication: Some teams prefer Slack standups, while others prefer daily video calls.

The amount of flexibility depends on the team’s maturity, working style, and needs. Some areas require more structure, while others can afford more adaptability.

Establish Guardrails (bounds to stay within):

Unlike rigid rules, guardrails exist to prevent chaos, misalignment, and inefficiency. Empowerment doesn’t mean “anything goes.” and these boundaries create focus, keep teams aligned, and prevent unnecessary backtracking, without stifling creativity.

• For user stories: “T-shirt sizing” is not the same as story pointing—teams must separate estimation techniques.

• For presentations: Updates need to focus on purpose over output (not a glorified status update).

• For decision-making: Teams should ensure alignment with the broader strategy and not operate in a vacuum.

Guardrails aren’t meant to be restrictive—they protect autonomy by ensuring teams aren’t working at cross-purposes.

Why shared practices are table-stakes to conditions of empowerment

Even the most well-intentioned leaders struggle with this. An excellent and curious VP once asked me, “I have a pile of things my boss needs my team to build. I get we want to empower them, but what am I supposed to do? Let them decide everything?”

Empowerment is not just something given to teams. It requires thoughtful structure and reinforcing behaviors from everyone around them. If you seek to empower, you need to have a shared operating model that clearly sets expectations while leaving space for flexibility.

Shared practices done well set the stage for consistency, efficiency, and scalability. When teams use consistent practices, it reduces cognitive load and friction to collaboration. And when everyone acts based on a shared set of values and understanding, you get a culture of trust, reducing the amount of redundant conversations needed to explain your process or justify every decision ad nauseam. Then, as organizations grow, shared ways of working enable scaling without losing cohesion in culture, quality, or capability.

Shared practices set the foundation for autonomy. Without them, teams either get micromanaged or lost in ambiguity. However, practices alone aren’t enough. True empowerment isn’t just about how teams work—it’s also about what they work on.

If practices shape the how, the next dimension of empowerment is providing clarity on the what needed to make effective decisions. To build trust and autonomy, teams need to focus on the right work and achieve the right outcomes.

Empowering others means creating a unified vision and clear priorities and enabling a balance of focus across different types of work. That’s what we’ll explore in Part II: thinking about how teams use their time and focus as a condition for empowerment.

You think to yourself: Why aren’t you going faster?

You’ve tried working longer, measuring engineer productivity and, heck, you even adopted a shiny Agile process promised to help you succeed. But the signs of friction are often already there—more bugs, bigger releases, longer cycle times, and a growing pile of work-in-progress.

This is what happens when teams try to go fast by going fast. You take on more, cut more corners, and push harder until the weight of unfinished work, tech debt, and constant firefighting slows you to a crawl. You’ve been accelerating in the wrong direction.

So ask that first question differently: What’s actually slowing you down?

Lean+XP keep you moving

I’ve worked with Lean and XP teams for a long time. I’ve seen XP deliver incredible results at high speed. I’ve also watched it fail. I don’t think it’s the answer to get a team unburied by debt. But if you’re not fully stuck yet, Lean+XP practices will keep you fast. Not by making you faster, but by making sure you don’t get stuck in the first place.

When teams try to get fast, they usually focus on acceleration. Usually this means they focus on productivity (AKA higher velocity), resulting in more commitments and emphasis on pushing harder to go faster. But really, speed only helps if you’re learning faster too.

But speed is not acceleration.

Speed is maintaining momentum.

Lean+XP don’t guarantee teams go faster in the short term. They optimize for never getting stuck once you’re moving.

Here’s how they work together: Lean eliminates unnecessary work before it can slow you down. (Fewer bottlenecks, fewer wasted cycles.) XP keeps codebases flexible and changeable so that future iterations aren’t painful. (Refactoring, TDD, continuous integration.) Both focus on short feedback loops so problems are caught early, not after months of bad assumptions.

Momentum isn’t about gaining speed. It’s about removing what slows you down.

The real reason teams get slower over time

Every product team starts out moving quickly. New teams, new codebases, new projects—it all feels easy at the beginning.

Inevitably, things bog down. I’ve seen this play out over and over. It’s like being stuck in the mud where your wheels are spinning and engine is roaring but you’re not actually getting anywhere. And the harder you press the gas, the deeper you sink and the more frustrating it is. The only way to regain control is to admit you’re stuck—and stop pressing the pedal. Why?

Because the biggest threat to speed isn’t a lack of force or effort. It’s internal friction.

That MVP you rushed out the door? Now it’s full of workarounds that make every change painful. That feature you built last year? Now it has dependencies no one accounted for. That “small” scope cut? Now there’s rework because it didn’t actually solve the problem.

Most slow teams aren’t lazy or bad at execution—they’re just buried in self-inflicted slowdowns. They could go fast, but every new thing they try to do is like pushing through deeper mud.

And if you don’t deliberately fight that friction, your team will only get slower.

Stop measuring velocity, start watching for drag

Most teams measure speed in terms of how much they’re shipping. Story points, iteration velocity, release frequency. Consulting companies focus on this too, as if there’s any believable correlation between having a high velocity and running a successful businesses.

So start asking “what’s slowing you down?” And if you see some of these things, the warning signs are already there:

• Are you working on more debt and bug fixes than new features or 0-1 work?

• Do you dread deployments?

• Is your release cadence unpredictable?

• Does your bug count skyrocket after every release?

• Does work get blocked after you start it because of unanticipated scope or dependencies?

• Does work sit in progress for weeks?

Slowing down isn’t always obvious, but most teams are constantly accumulating friction and by the time you start noticing it, doing more work or increasing velocity is the worst possible response.

Lean+XP together help teams break this cycle by creating ways to catch friction early and then fixing it, flowing work and preventing slowdown before it happens. Here are some ways to spot friction I’ve learned:

1. Stop hoarding work: The longer something sits unfinished, the more it drags you down—cluttering focus, increasing rework, and adding to cognitive load.

2. Tighten your feedback loops: If it takes weeks to get user feedback, your learning cycle is too slow. If it takes days to deploy a fix, your pipeline is slowing you down.

3. Prioritize tech debt like product debt: If a feature is hard to change, it’s already a problem—even if no one is complaining yet. Prioritize making it easier to change.

4. Treat process friction as a bug: If something takes longer than expected, don’t just power through. Ask why. Treat slow handoffs, unclear requirements, and rigid approvals like defects to be fixed.

If you’re slowing down, you don’t need a new process—you need to stop breaking momentum

If this sounds familiar then you know trying to speed up didn’t last. If you’re trying to go fast by going fast, you’re just setting yourself up for slowdowns you haven’t hit yet. No amount of tune ups are going to solve your problem.

Every team inevitably slows. But the teams that stay fast the longest treat friction like a critical issue, not a cost of doing business. If your team feels like they’re getting slower, the solution is to stop introducing new slowdowns.

Practicing Lean+XP isn’t magic. It won’t instantly make you faster—especially if you’re already bogged down. But once you get going it will help you keep your momentum.

And in the long run, that’s the only thing that actually matters. The best product teams don’t just move fast—they stay fast.

So I’ll ask again: What’s the biggest source of drag in your team right now? And what’s stopping you from fixing it?

In high school, I was injured playing lacrosse. Not the kind of injury you shake off, but one that rewired how my body worked. I had to relearn everything—walking, running, even standing still without tipping over. It forced me to rethink what resilience really means. And that’s why I don’t see resilience as being like an unbreakable tree.

I did intensive physical therapy and occupational therapy. Progress was slow and frustrating, a constant trial and error. But I did get most of it back.

The damage isn’t fully gone many years later. There’s still chronic pain, still occasional numbness. Today, compounding issues from that injury make daily life harder than it should be.

For a long time, I figured if I just worked harder, gritted my teeth, and refused to give in, I’d eventually return to ‘normal.’ I saw myself as resilient and thought that meant pushing through. But that’s not how it works.

It does take grit, but that’s not enough. Suffering through something is not the way to get better. You have to adapt. You have to change your approach. You have to focus on small improvements, because the big all-at-once fix doesn’t exist.It takes ruthless attention, focus, and discipline. Most importantly it takes knowing when to push and when to pivot.

One thing I’ve learned is that resilience isn’t about suffering. It’s about adjusting. It’s not about refusing to break—it’s about bending, changing, and finding new ways to grow.

The best metaphor for resilience isn’t a tree or a rock. It’s a weed.

Be a Weed

Think about weeds. They grow in cracks, sidewalks, places no one expects. They are impossible to get rid of and thrive in environments that should kill them.

Not because they’re tougher than everything else but because they’re adaptable.

A tree might stand tall for years, towering over its neighbors, but in a strong storm it can snap. A weed, though? It bends. It finds new soil. It spreads.

This is what true resilience looks like.

The Problem with Grit Alone

We glorify perseverance. Hustle culture tells us to grind harder. Leadership books praise those who never quit.

But treating resilience as mostly grit has consequences. It makes people think suffering is progress. It traps teams in sunk-cost fallacies: they push forward because they’ve already invested so much, even when a better path is available. It keeps people stuck instead of adjusting when conditions change. What doesn’t kill you makes you stronger, right?

Being a weed means knowing when something that won’t kill you also won’t make you stronger.

Resilient Isn’t Just Surviving, it’s thriving in different environments

Teams that don’t take the easy route will get battered and beaten and get stronger because of it—they don’t lets themselves bounce back into the same habits. They learn, evolve, and use setbacks to get stronger.

A resilient team doesn’t just say, “We’ll power through.” They ask, “How do we need to change?”

It’s the difference between enduring stress and using stress as a signal. Work keeps slipping? That‘s not just bad luck, it’s a sign the your prioritization process could be improved. A product launch falls flat? That’s not failure, it’s new data points on what customers actually need.

The teams that last aren’t the ones that keep pushing the same way no matter what. They’re the ones that know when to pivot.

Subscribe now

How to Build Resilience in Yourself and Your Team

1. Know When to Pivot vs. Persevere

Grit is valuable, but only if applied in the right places. Some challenges require persistence, but others are signals to shift. If the road ahead is blocked, pushing forward isn’t strength. It’s stubbornness.

Ask yourself: Am I / are we pushing through because it’s the right move or because we don’t want to admit we need to change?

2. Treat Stress as a Sign, Not a Threat

Stress isn’t something to avoid: it’s information you can use. If a team is constantly overwhelmed, it’s usually not just about workload. It’s likely because of misaligned priorities but it could be a few things. If something keeps breaking, that’s a signal to change something because your system (process) isn’t working.

Resilient teams and people listen to what stress is telling them.

3. Build in Flexibility, Not Just Strength

Rigid things break. Flexible things last.

A strong product team isn’t the one that commits to a roadmap and never wavers. Or the one that tried to plan ahead for every possible contingency. It’s the one that builds in optional paths and can adapt when reality changes.

Decisions should be reversible whenever possible. Instead of making one big commitment, create opportunity points to adjust along the way. Operating processes should encourage learning, not just execution.

If people are afraid to admit something isn’t working, they’ll keep forcing a bad path.

Stop Trying to Be Unbreakable—Be Adaptable

I’ve learned that resilience isn’t just about more than how much you can take. It’s knowing when to push forward and when to pivot. It’s bending instead of snapping. It’s finding new ways to grow when your environment changes.

Be a weed. I am

Because the people, teams, and companies (and products) that last aren’t the ones that endure the longest. They’re the ones that adapt the fastest.

My first job out of college was at an advertising agency in Chicago. During my first or second year there, one word seemed to be in every campaign: “Pure.”

On my daily commute, I saw it plastered across billboards and in stores: “Pure Flavor” for Starbucks coffee, “Absolutely Pure” cocoa essence from Cadbury, “Pure Juniper” for gin.

It was the go-to buzzword for every brand. But the more I saw it, the less it seemed to mean anything at all. If everything was pure, then pure was just a gimmick—something brands said because they thought they were supposed to. Apparently it resonated with customers, but meaningless at its core.

When Everything Is “Pure,” Nothing Is

This is exactly how I feel now when I hear a company say they’re “data-driven.”

On it’s face, it resonates. Who wouldn’t want to have more information and be able to make decisions based on better facts and numbers? But I’ll be honest—it makes me cringe.

When everyone is data-driven, it stops being as useful. And when taken too far, being “data-driven” can actually make teams worse at decision-making. Most companies that claim to be data-driven are great at collecting data, but not great at making it useful.

Why is this a problem? I’ve seen first hand that when you have all the data it has a tendency to replace human judgment, instead of supporting it. When that happens, teams stop thinking. They mistake correlation for causation or get paralyzed when they don’t have complete information sets.

Data should guide decision-making. It should never replace it.

The Problem With Being “Data-Driven”

A dogmatic data-driven approach assumes that if you just track the right numbers, the right answers will emerge. But decisions are rarely that simple.

Here’s where it fails:

The most measurable things aren’t always the most meaningful.

Conversion rates, DAUs, NPS scores—they’re easy to track. But the most important parts of product success are often harder to measure: Are we solving a real problem? Are we improving how customers feel about our product? Are we playing a good long game?

Data only tells you what is happening—not why.

Imagine a feature that users don’t engage with. The data says, “No one is clicking this.” What does that actually mean?

• Do users not understand it?

• Do they not need it?

• Is it buried in the UI?

• Is it valuable but just used in a different way than expected?

If you only prioritize what’s easy to measure, you risk making decisions that look good on a dashboard but don’t actually improve the experience. The data can’t tell you. But a conversation might

Optimization and efficiency kill innovation.

If you let data drive every decision, you’ll always do more of what’s already working. That sounds smart—until you realize it means you’ll never take a big swing.

Every breakthrough product starts as a bet. And most bets don’t have clean, quantifiable justifications upfront. If they did, someone else would have already built them. A/B tests and analytics help you refine an idea. They don’t help you find the next big one.

What to Be Instead: Data-Informed, Not Data-Driven

I’m not saying you should ignore data. I’m saying don’t allow data to become a gimmick. Teams that win aren’t data-driven. They’re data-informed.

They use data to validate and challenge intuition, not replace it. They treat dashboards as starting points for conversations, not as decision-makers. They remember that data is a tool, not a verdict.

How to Use Data Without Letting It Use You

If you want to avoid the pitfalls of being data-driven, but still use all that data you’ve accumulated, here are a few ways to shift your approach:

1. Pair Quantitative Data with Qualitative Insights: Numbers tell you what is happening. Talking to customers tells you why. For every KPI you track, ask “what customer behaviors drive this number?” “what unmeasured factors might influence it?” “Do qualitative insights confirm or contradict what the data suggests?” If you don’t know why a number is moving, you don’t really understand it.
   

2. Measure Progress, Not Just Performance: Performance metrics (like conversion rates) tell you how well your system is working right now. Progress metrics (like engagement over time) tell you if you’re actually moving toward your goal. High performance on the wrong thing isn’t success, it’s just being efficient at the wrong work.
   

3. Don’t Let Metrics Define Strategy: Many teams set goals based on what’s easy to measure. “Increase NPS by 10 points.” “Improve conversion rate by 5%.” But metrics should follow strategy, not define it. An approach I’ve used:

   1. First, start with a product vision. Before looking at any numbers, ask: What is the product trying to achieve? Are you trying to reduce friction for customers? Do you want to drive long-term engagement? Are you aiming to make a specific task effortless? Your vision should be qualitative and directional, not just a collection of performance indicators. Metrics should serve this vision—not the other way around.

   2. Next, define what success looks like in human terms: Success is more than a number on a dashboard. In this step, translate your product vision into something tangible and meaningful. Ask, what does a successful user experience feel like? How do you know when you’ve truly solved a problem? What should customers be able to do more easily than before?

      For example, instead of saying “We want a higher NPS,” ask “What would make customers recommend us without hesitation?”

      Instead of “We want to increase conversion rates,” ask “How do we ensure customers feel confident completing this action?”

      Again, metrics emerge as a way to track progress toward these real-world outcomes not as the goal itself.
      

4. Finally, choose metrics that indicate progress. Once you have a vision and a human-centered definition of success, then—and only then—should you choose metrics. Pick metrics that reflect the underlying goal, not just what’s easy to measure.

   1. If the goal is habit formation, track repeat engagement rather than one-time sign-ups.

   2. If the goal is trust, track resolution rate of customer issues rather than just satisfaction scores.

Recognize that no single metric tells the full story. Pair quantitative data (e.g., activation rate) with qualitative insights (e.g., user interviews). Monitor unintended consequences—if conversion rates go up but long-term retention drops, you might be optimizing the wrong thing.

By taking this approach, you set your team up to work toward meaningful outcomes, not just chase numbers.

Data is a Mirror, Not a Map

At its best, data helps teams see reality more clearly. At its worst, it narrows vision instead of expanding it.

If you let numbers drive your decisions, you’ll optimize yourself into a corner—faster and faster, but never toward anything new.

If you use data to inform judgment, challenge assumptions, and guide exploration, you’ll make better decisions than any dashboard ever could.

So before you call yourself a data-driven team, ask yourself:

Are you making decisions? Or is the data making them for you?