The Most Powerful Question: "What Are We Optimizing For?"

Over the years, I've found one question to be more powerful than any other for cutting through ambiguity, ending circular debates, and aligning a team: "What are we optimizing for?"

This question forces clarity. In any complex system—be it software architecture, a company budget, or a team process—you cannot have everything. You have to make trade-offs. Asking this question forces us to name the one or two things we are prioritizing above all else.

It also reveals the "why" behind a decision.

Optimization's Twin: Mitigation

This question has an equally important twin that must be asked immediately after: "What must we mitigate for?"

When you choose to optimize for one thing, you are by definition choosing to not optimize for something else. Some things will become easy, but other things will become harder—they won't happen automatically.

• If you optimize for speed, you may have to mitigate for quality or tech debt.
• If you optimize for autonomy, you may have to mitigate for alignment.
• If you optimize for company spend, you may have to mitigate for employee flexibility.

Being a high-performing team isn't just about making the bold choice; it's about being rigorous and honest about the downsides of that choice and having a plan to manage them.

---

Three Illustrative Examples

These are hypothetical scenarios, not descriptions of decisions at a particular company.

1. Organizational Design Imagine a company that needs to experiment and iterate quickly. Giving small, cross-functional teams more autonomy could be a sensible choice.

• The Optimization: Velocity and team autonomy. Reduce dependencies so teams can make decisions close to the problem.
• The Mitigation: Autonomy makes alignment harder. Shared goals, clear interfaces, and regular exchanges between teams become more important. The structure isn't "right" in a vacuum; it needs to fit the goal and come with a mitigation plan.

2. Balancing Maintenance and Exploration Imagine a team responsible for both a reliable existing service and experiments that could become its next major product.

• The Optimization: Reliability without losing the ability to learn. Protect capacity for essential maintenance, and make deliberate room for experiments.
• The Mitigation: Neither category should quietly consume all available time. Make priorities explicit, define what an experiment needs to teach you, and periodically revisit the allocation.

There is no universal percentage that makes this work. The useful part is deciding consciously instead of letting the loudest request determine the balance.

3. A Simple Technical Decision Suppose a small team is choosing between a managed service and running the same capability itself.

• The Optimization: Time to a useful result. A managed service may let the team focus on its product instead of operating infrastructure.
• The Mitigation: Convenience can introduce recurring costs and dependence on a provider. Understand the pricing, check that data can be exported, and identify when it would be worth revisiting the choice.

---

From Optimization to Guiding Principles

This two-part framework—Optimize + Mitigate—is what allows us to create effective Guiding Principles.

Guiding Principles are the fallback rules a team creates after setting its strategy. They make routine decisions easier without reopening the same debates over and over.

• If we're optimizing for speed and mitigating for tech debt, a guiding principle might be: "Let's pick something that gets us to the goal fast," combined with, "All tech debt incurred must be ticketed and reviewed weekly."
• If we're optimizing for stability, a principle might be: "The new thing must integrate with our existing tech, so let's pick a language we're already familiar with."

Other examples of great guiding principles:

• "Let's not reinvent the wheel; use something off-the-shelf where we can."
• "Precision over speed." (For a billing system)

This is the framework I recommend bringing to a design review, a budget meeting, or a conversation about process:

1. "What are we optimizing for?"
2. "What must we mitigate for?"
3. "What guiding principles can we create from those answers?"