TL;DR: Engineering teams tend to create their own rules and local governance, often without anyone above them signing off. That governance is rarely visible to the rest of the org, and isn’t necessarily aligned with what the org actually needs. That gap kills accountability and cross-team learning, so the same violation gets rediscovered instead of fixed once. Pandorian lets every team keep its own rules while giving leadership one governed view of drift, violations, and ownership.

What’s in this post

• Every Team Is Already Writing Its Own Rules
• The Rollup That Never Happens
• Accountability Needs a Name, Not Just a Team
• The Lesson One Team Learns Dies With That Team
• Control Doesn’t Require Uniformity
• One Place to See Every Team’s Standards, Drift, and Ownership
• The Governance You Can’t See Isn’t Governance At All
• Common Questions

Picture three teams in the same engineering org. The payments team has a strict rule about idempotency keys that nobody wrote down, they just know it. The frontend team quietly agreed to stop using a state library that caused three outages last year. The platform team enforces a naming convention that nobody outside platform has ever seen.

All three teams have created their own local rules. None of it was aligned with the rest of the org, and none of it is visible to anyone above them.

Then a VP R&D gets asked in a leadership meeting what the org’s engineering standards actually are, and the honest answer is: it depends which team you ask. Nobody lied. Nobody hid anything on purpose. The standards were simply never built to travel past the team that wrote them.

This isn’t a discipline problem. It’s a visibility and alignment problem, and until leadership can see standards, drift, and violations across every team at once, “governance” is just whatever the closest team happens to believe today, whether or not it matches what the org actually needs.

Every Team Is Already Writing Its Own Rules

Most engineering teams create their own local rules long before anyone in the org calls it governance.

A senior engineer catches a pattern in code review and says “we don’t do it that way here.” A team agrees in Slack to always validate a certain input. A repo’s README quietly documents three rules nobody bothered to formalize because everyone on the team already knows them.

None of it is necessarily wrong, but none of it was built with the rest of the org in mind either. It’s local by default: created by that team, for that team, with no visibility outside it. The problem shows up the moment someone outside that team needs to know what the standard actually is, or whether it lines up with what the org needs: a new hire, a neighboring team building an integration, or a VP trying to answer a board question about engineering risk.

The Rollup That Never Happens

Engineering leadership rarely has a single, current view of which standards exist across every team, let alone where those standards are drifting.

Standards live in a Confluence page here, a pinned Slack message there, or nowhere at all beyond the memory of whoever has been on the team the longest. Leadership usually finds out about drift the same way they find out about most engineering risk: after an incident, during a postmortem, or when an auditor asks a question nobody can answer with confidence.

DORA’s 2025 research on platform engineering names this exact tension. Platforms that impose rigid, top-down standards without collaboration turn into what the researchers call an “ivory tower,” and teams route around them. But the opposite failure mode, no standardization at all, is just as costly. The winning pattern DORA’s data points to is dependable autonomy: teams keep moving independently, while the organization still has a consistent, visible baseline underneath them.

Most orgs never get that baseline. They have autonomy without alignment, and no visibility layer sitting on top of either.

Accountability Needs a Name, Not Just a Team

Accountability breaks down the moment nobody outside a team can see what that team owns or how it’s holding up.

A team can be technically responsible for a repo’s security posture and still have zero real accountability, because “responsible” only means something if someone else can check. Without a shared view of violations and drift, ownership is theoretical. It’s a line in an org chart, not something anyone can actually verify.

This is where a rolled-up view changes the dynamic. Every guideline can carry its own record of total violations, repos affected, and pull requests scanned, all traceable back to the team and repo that own it. Leadership doesn’t need to interrupt a team’s workflow or sit in on their standups to know where things stand. The record is just there, current, and specific enough to name who’s accountable for what.

The Lesson One Team Learns Dies With That Team

The same violation often gets discovered independently by two or three different teams, because none of them can see what the others already fixed.

Gartner analysts speaking at this year’s Data & Analytics Summit put a name to this: fragmented context, spread across documentation, tribal knowledge, and disconnected tools, is one of the biggest reasons organizations can’t scale what they’ve already learned. In engineering terms, that’s a security fix one team wrote into a PR comment eight months ago, never captured anywhere a second team could find it, and rediscovered the hard way when they hit the same bug in production.

A written guideline doesn’t have that problem. Once one team turns a hard-earned lesson into an explicit, enforceable rule, that same rule can be assigned to another team’s repos instead of waiting for someone to remember to mention it in a hallway conversation that may never happen.

Control Doesn’t Require Uniformity

Visibility across teams does not mean every team has to run the same rules the same way.

Forcing identical standards onto every team backfires for a simple reason: a security rule written for payment services doesn’t belong flagging a data science notebook, and a team that gets buried in irrelevant alerts stops reading any of them. We’ve written before about why one-size-fits-all governance breaks down once an org has more than one kind of team. That post is about getting the right rules to the right team. This one is about the layer above it: once each team has the rules that actually apply to them, leadership still needs to see all of it in one place.

That’s the distinction that matters at scale. Each team can decide, guideline by guideline, whether a rule blocks a pull request or simply gets monitored while the team ramps up. Leadership doesn’t dictate that choice. Leadership sees the result of it, across every team, every repo, every guideline, all at once. Once an org crosses into 100+ engineers spread across multiple business units, that combination, team-level control paired with organization-wide visibility, is often what finally lets leadership retire ad hoc code review as the last line of defense and replace it with something that actually holds.

One Place to See Every Team’s Standards, Drift, and Ownership

Every failure mode above traces back to the same root cause: standards that exist, but aren’t visible, or verified as aligned, past the team that wrote them.

• Team-owned guidelines: Each team writes and assigns its own standards, in its own repos, in its own language.
• Independent enforcement modes: Enforce or Monitor is a per-team, per-guideline decision, not a mandate handed down from the top.
• One rolled-up view: Every guideline’s violations, repos affected, and pull requests scanned surface in a single dashboard leadership can actually read.
• Explicit ownership: Every violation traces back to the team and repo responsible, so accountability has a name attached to it instead of a guess.
• Shareable standards: A guideline one team writes can be adopted by another, so a hard-earned lesson stops dying with the team that learned it.

The Governance You Can’t See Isn’t Governance At All

Teams making their own calls was never the problem. Making those calls invisibly, with no way to check whether they line up with what the org needs, is.

When leadership can see drift and violations across every team without dictating how any single team writes its code, control, alignment, and autonomy stop being at odds with each other. That’s especially true once an org has grown past a handful of teams and a few hundred engineers across more than one business unit, the point where no single person could hold every team’s standards in their head even if they tried.

Standards that nobody above the team can see, or verify, aren’t standards. They’re just local habits, and nobody can say whether they line up with what the org actually needs.

Common Questions

Written by Daniel Avital, CEO & Co-Founder at Pandorian

Related Reading

• Why One-Size-Fits-All Governance Breaks Modern Engineering Teams
• Your Postmortems Don’t Prevent the Next Incident
• Code Review vs. Codebase Governance: Why Speed Isn’t the Same as Control
• What Are Engineering Standards and How to Enforce Them
• Explore the Pandorian Platform