Shared Principles Beat Shared Tools - Every Time
Culture is how shared principles show up in everyday delivery as implicit and explicit contracts
Why don't shared tools fix slowdowns?
What is culture, really?
How can a few principles speed everyone up?
The Hidden Tax
If you walk into any scaling engineering organisation and look closely, you'll often find the same pattern plaguing your best talent.
Exhausted Engineers
Your best engineers are tired from constant firefighting
Low-Leverage Problems
They're solving the same issues repeatedly across teams
Increased Complexity
Engineers struggling to manage systems held together by a thread.
The Real Drag on Delivery
The real drag on delivery often isn't slow developers or bad code. It's the invisible toll of re-deciding the basics, every time, leading to endless conversations.
We call this coordination tax. But it's also something else: a culture without principles, or rather, no culture at all.
The good news is: these are leadership questions, which means this is where leadership can drive meaningful impact.
Why It Happens
Too often, platform teams show up with tools before any shared principles are agreed. This is where conversations tend to get lost to tangents.
Developer Resistance
Developers reject tools selected for them by other parts of the business. Not because they're bad tools, but because they weren't involved in the conversation. Adoption feels like enforcement, not support.
Infrastructure Hesitation
Infrastructure teams focus on stability and uptime. New tools or increased change rates introduce operational risk that their training and incentives are designed to minimize.
Security Bottlenecks
Security teams care about enforcement and traceability but get involved too late. They end up saying "no" after the fact, frustrating everyone.
Each group is doing what they were incentivized to do. But the result? Misalignment, bottlenecks, and blame.
The Shift: Shared Principles Create Flow
Here's the shift: shared principles turn that tension into flow.
A principle like "every change must have a full audit trail" can align every actor through a fully automated implementation
1
Change Managers
Get the visibility and accountability they need
2
Infrastructure Teams
See risks surface early, not late
3
Security Teams
See controls built-in, not bolted on
4
Developers
Skip manual approval meetings because trust is automated
That's the power of encoding expectations in pipelines: not as restrictions, but as shared contracts.
Freedom Through Shared Interface
Everyone still chooses their tools. But they plug into the same interface. And that shared interface gives:
- Visibility for infra
- Traceability for change
- Proof for security
- Automation for developers
The right guarantees, in the right places, give everyone more clarity, more confidence, and more freedom.
That's what shared principles make possible. And pipelines are how you make them real.
How to Spot It
If you're leading a team, ask yourself:
Are senior devs regularly asked the same support questions?
Are your best engineers jumping between feature work and firefighting issues with infrastructure, pipelines or
deployments?
Do teams keep revisiting the same debates: environments, ownership, security, priorities?
Are you spending more time discussing toolchains than agreeing on quality gates?
These are symptoms of a missing contract, a problem that tools can't fix, only culture can. But what is culture? My favorite definition is that culture is the presence of your group's shared beliefs, values and principles in your day to day life and actions.
The Simplest Test
If individuals from ten different teams in your org were each asked to define "done," how many different answers would
you get?
The Real Cost
When principles aren't shared, decisions fragment. That's the real coordination tax. Not just time lost to meetings but energy lost to subjective, ambiguous and often frustrating conversations.
1
Senior Engineers Can't Focus
Constant context switching
2
Leads Can't Lead
Management overhead increases
3
Strategic Work Deferred
Important projects delayed
4
Trust Decays
Foundation erodes
What Good Looks Like
This is where platform engineering shows up, not just as a team, but as a system for shared understanding.
Part of building that system means deciding, together, what matters. Not just what to automate, but what to believe in: as engineers, as teams, as an organization.
Without shared principles:
- Teams make different assumptions, and integrations fail silently
- Ownership gets fuzzy, and work slows down
- Every decision becomes a debate you can't rationalize
- Delivery drags and drifts
The Missing Foundation
What's often missing isn't technology, it's a foundation for conversation. One rooted in leadership-defined principles that help people disagree better, align faster, and navigate the unknown with a shared compass.
The piece that most platform initiatives miss is not in the platform itself, but in the agreements that underpin it.
And it's not hard to get started, especially if you're willing to be principled.
Types of Principles That Work
Here are just a few categories we've seen work well. Things that are worth getting explicit about:
| Principle Area | Why It Matters | What Happens Without It |
|---|---|---|
| Definition of Done | Prevents ambiguity across teams | Everything downstream gets messy |
| Minimum Testing Levels | Clarifies what counts as "safe enough" | If you can't measure quality, you can't manage risk |
| Delivery Steps Agreement | Creates shared accountability | Slower, less safe automation, obscurity |
| SLA Targets | Interface between engineering and business | Unclear quality vs cost vs time tradeoffs |
| Business Priorities | Aligns planning around business goals | Tension between infra, product, platform |
It's not about having the perfect list. It's about having something that people can lean on, trust and build from. See some specific examples of our below.
Because when these principles are agreed, and people start behaving this way instinctively, and others begin to rely
on it… You haven't just improved delivery. You have developed culture.
From Pledge to Platform
When reflecting on both successful and unsuccessful platform projects, we end up circling around the same themes:
trust, alignment, shared belief.
On a podcast I was listening to, there was a description of how groups in Genghis Khan's army were organized. Soldiers were divided into squads of ten (called aravt), and their effectiveness came from a principle that carried real consequences: you don’t leave anyone behind.
Each person submitted to their unit leader, knowing that if they abandoned a comrade, they not only risked the mission but also faced punishment from their peers and leaders. The pressure was real. But it created trust — the certainty that everyone else would uphold the same standard. It wasn’t just hierarchy; it was a social contract. A belief system that let a large, dispersed group act quickly and decisively under threat.
In elite teams, whether in military, sports, or high caliber engineering, you see the same pattern: trust becomes the
foundation for speed in environments with risk.
In engineering, the risks are different. But the dynamic is the same. If you want people to move fast without breaking, they need to know what and who they can count on.
That's where the "Core" in Core Engineering came from. We started as a small core team, committed to core principles we would align all stakeholders under. That alignment let us move fast, earn trust, and gave our leadership a steering wheel.
Because trust doesn't scale by accident. It needs something to stand on. Shared principles are that foundation. Pipelines are how you reinforce them.
The Principles That Helped Us Most
So, with all that said, here are the principles that made the biggest difference for us: simple, practical, and battle-tested. Think of them as toil busters.
Each one made things clearer, faster, or safer. Usually all three.
Everything as Code
Why it matters: If it's written down, we won't forget. If it's code, we can test it. No surprises.
What goes wrong if you don't: People forget things. Knowledge gets lost. Setup is not repeatable.
Deploy Daily
Why it matters: Practice makes perfect. If we can ship safely every day, big changes don't feel scary.
What goes wrong if you don't: Big deploys break stuff. Everyone panics. Changes pile up making diagnosis harder.
Security Shifted Left
Why it matters: We check for monsters before we go into the cave, not after.
What goes wrong if you don't: Security shows up late. Fixes are harder. Risks slip through.
Remove Manual Actions
Why it matters: People make mistakes, code doesn't. Automate the boring stuff.
What goes wrong if you don't: Manual steps break. People forget. Progress slows. Tribal knowledge.
Decouple Teams
Why it matters: Don't make people wait on each other. Give them what they need to move on their own.
What goes wrong if you don't: Delivery stalls and everyone is waiting, calling 'blocked'. Frustration grows.
Environments as a Service
Why it matters: Need a sandbox? Just push a button. Every team gets their own preview playgrounds on demand.
What goes wrong if you don't: Teams fight over environments or stop testing entirely. Environments are flaky.
Getting Started
Want to start using them? Pick just one. Make it real. Stick with it.
That's how we started and most of the benefit came from just committing to doing a few things well, every time.
Choose One Principle
Start with what hurts most
Make It Real
Implement it consistently
Stick With It
Build the habit before adding more
We'd Love to Hear Your Thoughts!