Have you ever watched an organization attempt transformation only to see it stall, fragment, or quietly revert to old patterns? The initiative had executive sponsorship. The consultants delivered their frameworks. The town halls were held. And yet, six months later, teams are still making decisions the way they always have.
I have seen this pattern repeat across industries. When I dig into what went wrong, the diagnosis is often the same: the organization tried to change behaviors without first naming them. They wanted a new culture without codifying what culture actually meant in practice.
We cannot change what we do not name.
This is not a soft observation. It is a structural one. When research highlights culture as a barrier to change, it often points to a lack of clarity, alignment, and shared language for how decisions get made. Teams are not resisting change—they are navigating ambiguity.
Without codified principles, every decision becomes a negotiation, a guess, or a deferral to whoever speaks loudest.
The best companies are already doing this
This insight is not mine alone. The leading voices in product thinking have been converging on this point for years.
In TRANSFORMED, Marty Cagan identifies twenty product model first principles that the best product companies share—outlined in Chapters 15 through 19. What struck me is that while Apple, Amazon, Netflix, and Spotify each have dramatically different cultures, they share similar principles for how they build products. These companies refer to it simply as "their way.” The principles are codified, reinforced, and embedded into daily decisions. They are not decorative posters; they are decision-making tools.
Melissa Perri's framework for building great product organizations names Product Culture as one of four essential dimensions—alongside Organizational Design, Product Strategy, and Product Operations. Culture is not a byproduct of transformation; it is a prerequisite.
And John Cutler observes that "teams respond well if there are a small number of things that people are stubborn about." That stubbornness—the unwillingness to compromise on core principles—is what separates codified culture from decorative values.
The common thread: transformation requires naming what you believe and how you will operate. Without that foundation, change efforts become disconnected initiatives rather than a coherent shift in how the organization works.
What does it mean to codify culture?
So what does it actually mean to codify culture? It is not about writing values on a wall. Most organizations already have those, and most employees cannot recite them.
And here is what I often encounter: leaders who genuinely believe they have communicated culture. They have held the town halls. They talk about priorities. But the test is not what leaders have said—it is how teams actually decide.
When I find teams in the middle of a difficult negotiation, I ask simple questions: What are we optimizing for? What trade-offs has this organization said it will make?
The silence—or the conflicting answers—tells me everything. These questions highlight the root issue: if teams cannot answer, the codification did not happen, regardless of intention.
The problem is that generic values like "Excellence" or "Innovation" provide no decision-making guidance. They are aspirations, not constraints.
Codified culture is different. It consists of two elements working together:
- Principles define how we operate.
They are specific enough to guide real decisions and create actual constraints on behavior.
- Trade-offs define what we prioritize when principles collide.
They acknowledge tension rather than pretending everything matters equally.
Together, principles and trade-offs form a decision-making system—a shared language that allows teams to act with autonomy while remaining aligned to organizational intent.
Principles that create constraints
Let me illustrate with a principle I call Radical Simplicity:
We ruthlessly eliminate steps, data, or code that do not directly add value to the customer. Complexity is a form of technical and operational debt.
Notice this is not a feel-good statement. It creates a constraint. It says that when you are designing a process or building a feature, you must justify complexity. The default is elimination, not addition.
For business teams, this translates to what I call the "One-Touch" Rule: we do not ask the customer for information we already have.
For technical teams, it means standardization over customization—using reusable patterns rather than building custom code for edge cases that occur less than one percent of the time.
The motto that makes it stick: "If it is hard to explain, it is wrong."
Another principle, Outcome over Output, creates a similar constraint:
We measure success by business impact—revenue, retention, savings—not by the volume of features shipped.
We do not mark a project complete when it launches; we mark it complete when the KPI targets are hit.
The motto: "Don't confuse motion with progress."
These principles have teeth because they create real constraints on behavior. They tell teams what to prioritize and, just as importantly, what to deprioritize.
Trade-offs that acknowledge tension
Principles alone are not enough. In practice, organizations face moments where good principles pull in different directions. This is where trade-offs become essential.
Consider The Launch Trade-Off:
Accuracy and quality even over speed.
The word "even" is critical. It does not dismiss speed—speed matters. But it clarifies precedence. When pressure mounts to ship something broken just to hit a deadline, this trade-off provides explicit guidance: it is better to miss a launch date than to erode customer trust with data errors or bad experiences.
The motto that reinforces it: "Apple was never first to market; they were best to market."
Another example, The Scope Trade-Off, addresses organizational politics directly:
Global optimization even over local efficiency.
This trade-off acknowledges that we will sometimes make decisions that make one department's job slightly harder if it makes the entire company significantly faster or more profitable. We reject what I call "Silo Success"—local wins that create global drag.
The motto: "Optimize the Whole, not the Part."
What makes these trade-offs powerful is their honesty. They name tensions that most organizations pretend do not exist. And by naming them, they give teams permission to make hard calls without endless escalation.
From codified to enculturated
Codifying principles and trade-offs is necessary, but it is not sufficient. The real work is enculturation—the consistent, visible application of these principles until they become second nature. A document no one references is not culture; it is wallpaper.
Enculturation happens in three ways:
First, principles must be injected into existing processes.
You do not need new rituals; you need to embed principles into the rituals you already have. Sprint planning becomes a moment to ask, "Does this align with Outcome over Output, or are we just shipping to ship?" Retrospectives become opportunities to reflect: "Did our decisions this sprint honor our stated trade-offs? Where did we deviate and why?" Architecture reviews gain a new evaluation criterion. The principles become part of the decision-making fabric, not a separate exercise. And when existing processes are not aligned with principles, that is when you recommend and scope process changes—but you do not need to change everything at once.
Second, leadership behavior must model the principles.
When a senior leader invokes a principle to explain a decision—"I chose this direction because our Launch Trade-Off says quality over speed"—it signals that the codified culture is real. When leaders protect team members who use principles to push back, it creates safety for the culture to take root. And when leaders apply principles even when inconvenient, it builds the trust that makes enculturation possible. The first time leadership violates a stated trade-off without acknowledgment, trust erodes.
Third, you must watch for signals that culture is being picked up.
Culture is enculturated when the language shows up in daily decisions without anyone referencing a document. When teams invoke the mottos in Slack, in planning sessions, in cross-functional negotiations—unprompted—the principles have taken hold. Conversely, if principles exist on paper but leaders do not model them, if people who invoke principles get labeled as "difficult," or if hierarchy still wins every conflict, the codification has failed to become culture.
I will be writing more on the tactical change management work of enculturation in a follow-up post. For now, the key insight is this: codification is the starting point, not the finish line.
For individual contributors (IC), codified culture creates an opportunity: asking the right questions.
When a stakeholder pushes for a shortcut, an IC can ask, "How does this align with our principle of Radical Simplicity?"
When speed is prioritized over quality, they can reference the Launch Trade-Off.
Codified culture gives everyone—not just leaders—a vocabulary for productive pushback. The principle becomes the arbiter, not hierarchy or whoever argues loudest.
The foundation for transformation
This work is foundational to any organizational change, but it is especially critical for companies transitioning to a product operating model. The product model requires autonomous teams making decentralized decisions. Without codified principles and trade-offs, autonomy becomes chaos.
Here is the distinction that matters:
Codifying culture through principles and trade-offs is tactical strategic work. It is the work of deciding who you are and how you will operate.
Cascading that into behaviors—the enculturation—is tactical change management work. Both are necessary. But you cannot do the second without completing the first.
This is the essence of change management done right—not more process, but clearer principles. Not more oversight, but better decision-making frameworks.
If your organization is struggling to make change stick, the question is not whether you need better processes. The question is whether you have named what you are trying to become.
Michael Toland is a Senior Product Management Consultant and Coach at Test Double, and has experience in data and platform product management, product culture, and helping tie the tactics of strategic work to the day-to-day operations running our organizations.
