Outcome focus: Defined Principle Stacks and Priority Stacks as ranked decision mechanisms, explained their failure modes, and provided a template for using them in product, engineering, and personal planning.
decision makingprinciplessystems thinkingleadershipproduct strategy
I keep coming back to one question:
What wins when good things conflict?
Not when the choice is obvious. Not when one path is responsible and the other is reckless. Those decisions are easier than people pretend.
The hard decisions are between goods.
Safety and speed.
Accuracy and reach.
Customer value and cost discipline.
Deep work and responsiveness.
Family and ambition.
Health and obligation.
The problem is not that people lack values. Most teams have too many values, or at least too many words that sound like values. The problem is that the values are unordered. When everything matters, the loudest person, the newest crisis, or the hidden incentive decides.
That is why I like the idea of a Principle Stack.
Spelled with an "e." Not principal, as in money or a school administrator. Principle, as in a rule that governs behavior.
The phrase is associated with Ben Thompson and James Allworth's Exponent Episode 177, "Principle Stacks", published on November 8, 2019. That episode grew out of Thompson's writing on Tech and Liberty and the debate over speech, platforms, and Facebook's political ad policy. The concept has stayed with me because it is simple and severe:
Take the principles you actually operate by.
Put them in a strict order.
When they collide, the higher principle wins.
Then write down the reasoning.
That is the whole machine.
It is not a slogan wall. It is not a list of vibes. It is not a company saying "integrity, excellence, customer obsession, innovation" and hoping everyone makes the same call under pressure.
It is a ranked mechanism for trade-offs.
Why principles need order#
Values without order are easy to praise and hard to use.
Everyone can agree with safety. Everyone can agree with customer value. Everyone can agree with speed. Everyone can agree with quality. Everyone can agree with financial discipline.
Then a launch arrives.
The feature is valuable, late, expensive, politically visible, and not quite safe enough. The metrics say one thing. The support team says another. Legal has concerns. Engineering has a mitigation plan but needs two more weeks. Sales wants the promise kept. Product wants learning. Leadership wants momentum.
Now the values collide.
If the organization has not already decided what outranks what, the meeting becomes a negotiation over identity. People do not only argue about the decision. They argue about what the company is.
That is slow.
It is also dangerous because the decision may be made by power instead of principle. Whoever owns the metric, the budget, the customer relationship, or the executive relationship can frame the choice.
A Principle Stack reduces that ambiguity.
It does not eliminate judgment. It does not make hard calls painless. But it gives the team a way to say:
We chose X because principle 2 outranks principle 4 in this conflict.
That sentence is powerful.
It turns a decision into something inspectable.
Principles are different from values#
The Harvard Business Review article It's Time to Define Your Company's Principles argues that mission, vision, and values are not enough. Principles are more operational. They guide behavior during difficult decisions.
Stanford eCorner makes a similar point in Principles Belong in Your Decision-Making Toolkit: values only take you so far; principles help people and companies make better decisions and reinforce norms.
That distinction matters.
"Quality" is a value.
"We do not release a product we would not use ourselves" is a principle.
"Customer obsession" is a value.
"When internal efficiency conflicts with customer trust, customer trust wins" is a principle.
"Innovation" is a value.
"We prefer reversible experiments over long speculative plans when user risk is low" is a principle.
Values point at what you admire.
Principles say how you will behave.
A Principle Stack goes one step further. It says how principles behave when they collide.
A stack is not a collection#
The word stack matters.
A stack has order.
This is the uncomfortable part. Teams like to say many things are equally important. Sometimes that is true in ordinary conversation. It is rarely true in a conflict.
If Safety and Speed are both "top priority," what happens when a safety concern delays launch?
If Customer Trust and Revenue are both "non-negotiable," what happens when the highest-revenue path undermines user confidence?
If Deep Work and Team Responsiveness are both essential, what happens when every notification feels urgent?
Fake ties create hidden politics.
The stack forces the team to expose the real hierarchy. If A and B conflict, which wins? If B and C conflict, which wins? If A creates cost pressure against D, what is the rule?
You do not discover the stack by asking what people admire.
You discover it by asking what people sacrifice.
The stack should describe reality before aspiration#
The first draft of a Principle Stack should be honest.
Not flattering.
Every organization has stated principles and revealed principles. The stated principles live in decks, onboarding documents, all-hands speeches, and strategy memos. The revealed principles live in decisions.
What gets funded?
What gets delayed?
What gets forgiven?
What gets punished?
Who gets promoted?
Which incidents cause process changes?
Which customer complaints get attention?
Which risks are accepted without debate?
That is the real stack.
If the written stack is too far from the revealed stack, people will notice. They may not say it in the meeting, but they will know. The document will become theater.
The better move is to start with the stack you actually live by, then decide whether that is the stack you want.
This is where the work becomes uncomfortable in a useful way.
A company example#
Imagine a consumer platform with this Principle Stack:
- User Safety
- Trust and Accuracy
- Customer Value
- Speed
- Cost Discipline
Each principle needs a rule.
User Safety:
We delay, redesign, or kill features that materially increase harm risk.
Trust and Accuracy:
We would rather be late than misleading in content, metrics, recommendations, or claims.
Customer Value:
We ship when there is clear user benefit, even if internal convenience or vanity metrics lag.
Speed:
We prefer reversible bets, flags, staged rollout, and small releases when higher principles are not at risk.
Cost Discipline:
We optimize infrastructure, tooling, and team time after reliability and user trust are stable.
Now a new feature increases engagement but also increases harassment exposure.
Under this stack, the decision is not mysterious. It does not ship as-is.
User Safety outranks Customer Value and Speed. The team can still pursue the feature, but only after mitigations are in place: rate limits, proactive detection, reporting paths, abuse tooling, rollout controls, review queues, and clear measurement of harm.
That does not make the decision easy.
It makes the decision legible.
The memo can say:
We delayed launch because User Safety outranks Customer Value and Speed. The feature remains strategically attractive, but the current version raises harm exposure beyond the threshold we are willing to accept. We will revisit after mitigation work is complete and measurable.
That is a different kind of operating system.
The stack is for conflict, not decoration#
A Principle Stack earns its keep in conflict.
If the principles never collide, they are probably too vague.
The HBR and Stanford material on company principles both emphasize difficult moments. Principles matter when leaders and teams face choices without a clean playbook. That is the same reason the Principle Stack idea has force. It is built for collision.
A good principle should have teeth.
It should rule some things out.
It should disappoint someone.
It should make at least one attractive option unavailable.
If a principle never says no, it is probably a preference.
If every principle can be satisfied in every decision, the stack is not doing much.
Failure mode 1: mushy phrasing#
The first failure mode is mush.
Words like integrity, excellence, innovation, collaboration, ownership, and customer focus can be useful, but only after they are made operational.
The test is simple:
Can someone use the principle to make a decision without you in the room?
If not, it is not clear enough.
"Integrity" is too broad by itself.
"We do not ship metrics we cannot explain to a customer, regulator, or teammate" is more useful.
"Innovation" is too broad by itself.
"When user risk is low, we favor small experiments over speculative planning" is more useful.
"Ownership" is too broad by itself.
"The team that owns a workflow also owns its monitoring, documentation, and rollback path" is more useful.
A principle should reduce interpretation, not increase it.
Failure mode 2: fake equality#
The second failure mode is fake equality.
Teams often resist ranking principles because ranking feels like betrayal. If Safety is above Speed, does that mean speed does not matter? If Family is above Deep Work, does that mean work does not matter? If Trust is above Revenue, does that mean revenue is unimportant?
No.
Ranking is not rejection.
Ranking is conflict resolution.
Lower principles still matter. They just do not win when they directly conflict with higher ones.
Speed matters until it threatens safety.
Cost discipline matters until it threatens reliability.
Responsiveness matters until it destroys deep work.
Community matters until it consumes health or family obligations.
Without rank, the organization invents rank in the moment. That is usually worse.
Failure mode 3: shelfware#
The third failure mode is shelfware.
A stack that never appears in decision memos is not a stack.
It is branding.
The test is whether consequential decisions include the rationale:
- Which principles were in conflict?
- Which one outranked the other?
- What did the decision cost?
- What evidence would cause reconsideration?
- What exception, if any, was granted?
The phrase I like is "Stack Rationale."
It does not need to be long. For many decisions, a few sentences are enough:
Stack Rationale: We are choosing the slower remediation path because Trust and Accuracy outranks Speed. The faster patch reduces the visible error but leaves the underlying measurement discrepancy unexplained. We will ship once the metric can be reconciled end to end.
That kind of note builds institutional memory.
New people learn the culture by reading decisions, not posters.
Failure mode 4: changing the stack too often#
A stack should be reviewed.
It should not be rewritten every time a decision is uncomfortable.
If the stack changes constantly, the organization probably has preferences, not principles. Preferences are allowed. They are human. But they should not be confused with principles.
I would review a team stack quarterly at most. For a company-wide stack, even less often. The review should ask:
- Did the stack help us make hard decisions?
- Did we ignore it?
- Did any principle create a repeated bad outcome?
- Did our revealed behavior contradict the written order?
- Are there new constraints that genuinely change the hierarchy?
Changing the stack should feel like a governance event, not a mood shift.
Building a Principle Stack#
The process is blunt.
Start with five to seven principles.
More than that becomes hard to remember. Fewer than that may be too coarse, though some teams can operate with three.
Write the principles you actually use, not the ones you wish sounded impressive. Look at recent decisions. Look at what got delayed, funded, escalated, ignored, rewarded, or killed.
Then force pairwise conflicts.
Ask:
If Principle A conflicts with Principle B, which wins?
Do that until the order is unavoidable.
Then write each principle in four parts:
Name:
The short label.
Rule:
The one-sentence operating rule.
Applies when:
The situations where this principle governs.
Does not apply when:
The boundaries and exceptions.
Beats:
The lower principles it outranks and why.
Finally, attach the stack to real decisions. A stack without examples is too abstract. For each principle, record at least one decision it governed.
That evidence is where the stack becomes real.
A technical team stack#
For a software or data platform team, a stack might look like this:
- Correctness and Safety
- User Trust
- Operability
- Product Learning
- Delivery Speed
- Cost Discipline
Correctness and Safety:
We do not knowingly ship behavior that corrupts data, violates permissions, or creates material user harm.
User Trust:
We make system behavior explainable, reversible where possible, and honest in its claims.
Operability:
We design features with monitoring, rollback, ownership, and support paths.
Product Learning:
We favor designs that let us learn from real use without overcommitting to unproven assumptions.
Delivery Speed:
We ship smaller reversible increments when higher principles are protected.
Cost Discipline:
We optimize spend and team effort after correctness, trust, and operability are stable.
This stack would affect real engineering choices.
It would reject a data pipeline that is fast but silently drops invalid records.
It would delay an AI feature that cannot explain why it produced a recommendation in a high-stakes workflow.
It would favor feature flags and staged rollout over a risky big-bang release.
It would prioritize monitoring and rollback before expanding usage.
It would resist infrastructure optimization if the system is not yet reliable.
Notice that none of these principles are anti-speed.
They define the conditions under which speed is good.
A product strategy stack#
For product work, I might use:
- Real User Harm
- Trust
- Clear Customer Value
- Measurable Learning
- Speed
- Efficiency
That stack says something specific.
We do not create harm for growth.
We do not mislead users to improve metrics.
We do not ship features that are easy to build but unclear in value.
We do not spend months on polish before learning whether the direction matters.
We do not confuse speed with thrashing.
We do not optimize cost before we understand the value loop.
That is a strategy.
Not a complete strategy, but a behavioral strategy. It tells people how decisions should feel when trade-offs appear.
A personal Priority Stack#
The same architecture works personally.
I think of this as a Priority Stack.
The difference is that the object is not a company decision. It is attention.
Working from home makes this especially important because the boundaries are too easy to dissolve. A message arrives during dinner. A family need appears during a deep work block. A workout gets pushed because the laptop is already open. A community obligation sounds meaningful, but the week is already full. Everything is close enough to interrupt everything else.
Without a stack, every collision gets decided from scratch.
That is exhausting.
A personal stack might be:
- Family
- Health
- Deep Work
- Team
- Community
Family:
I protect committed family time unless there is a true emergency.
Health:
I treat sleep, movement, and recovery as infrastructure, not optional leftovers.
Deep Work:
I reserve device-silent blocks for the work that moves my life and craft forward.
Team:
I am responsive and reliable inside agreed collaboration windows and true escalation paths.
Community:
I contribute when it does not consistently consume the priorities above it.
This is not moral grandstanding.
It is a way to reduce guilt and decision fatigue.
Family dinner means work pings wait unless they are true P0s.
Health yields to Team when I am on call or inside a pre-defined sprint crunch, not every time someone feels anxious.
Deep Work beats casual responsiveness during blocked focus time.
Community matters, but not at the cost of becoming unavailable to the people and work I already committed to.
The stack does not make life neat.
It gives conflicts a default resolution.
Exceptions need names#
Every stack needs an exception policy.
Otherwise people will either apply it too rigidly or quietly ignore it.
A good exception has three parts:
- The condition that makes it valid
- The person or role that can approve it
- The date or event when it expires
For example:
Health normally outranks Team. Exception: during a scheduled production incident rotation, Team can outrank Health for urgent response windows, but recovery time must be scheduled after the rotation.
Or:
Speed normally outranks Cost Discipline. Exception: if projected infrastructure spend crosses a defined monthly threshold, Cost Discipline temporarily outranks Speed until the architecture review is complete.
Exceptions should be explicit because unnamed exceptions become loopholes.
Loopholes become culture.
The stack creates a paper trail#
One reason I like Principle Stacks is that they leave evidence.
Good decisions can still produce bad outcomes. Bad decisions can sometimes get lucky. Without a written rationale, teams learn the wrong lesson from both.
The stack gives you a way to inspect the reasoning later.
At the time, we believed Safety outranked Speed.
At the time, we believed Trust outranked Growth.
At the time, we made an exception because the risk was reversible.
At the time, we accepted cost because operability was not yet stable.
That paper trail matters.
It lets you improve decision quality without pretending hindsight was available at the time.
It also protects teams from narrative drift. Six months later, people may remember the decision differently. The written rationale anchors the memory.
That is useful in product strategy, architecture, incident response, AI governance, and personal planning.
How this connects to systems thinking#
A Principle Stack is a small governance system.
It defines priority.
It reduces ambiguity.
It creates feedback.
It makes decisions observable.
It limits politics by making the decision rule explicit.
It also reveals where the system is lying.
If a company says Safety is number one but repeatedly rewards unsafe growth, the stack exposes the contradiction. If a team says Operability outranks Speed but constantly ships without monitoring, the revealed stack is different. If I say Health outranks Team but sacrifice sleep for every non-urgent message, my real stack is not the one I wrote.
That is uncomfortable.
That is why it works.
Systems improve when feedback is visible.
Minimal template#
Here is the smallest version I would use.
Stack name:
Scope:
Where this stack applies.
Principles:
1.
2.
3.
4.
5.
Principle:
Name:
Rule:
Applies when:
Does not apply when:
Beats:
Real decision:
Stack Rationale template:
Decision:
Principles in conflict:
Winning principle:
Trade-off accepted:
Exception, if any:
Review trigger:The template is intentionally plain.
The point is not design.
The point is use.
My current read on it#
I do not think a Principle Stack solves every decision problem.
Some decisions need more data. Some need moral courage. Some need legal review. Some need negotiation. Some need time. Some are genuinely ambiguous even after the stack is applied.
But a stack does one thing very well:
It prevents every hard decision from becoming a new argument about first principles.
That is enough to matter.
For teams, it creates consistency.
For products, it clarifies trade-offs.
For engineering, it makes architecture decisions easier to defend.
For AI systems, it helps decide what cannot be optimized away: safety, privacy, explainability, reliability, human review.
For personal life, it protects attention from being auctioned off to the nearest interruption.
The best part is also the hardest part.
A Principle Stack forces honesty.
Not what do we admire?
What wins?
That is the question.
Related notes#
- Thinking and Communication as Engineering Work
- Product Planning Is Shaping the Work
- Lead Measures Make Dashboards Useful
- Ten Ideas About Thinking in 2026
- Algorithm Complexity as Engineering Judgment