Beyond 'You Build It, You Run It': Why Collective Ownership Scales Better

The phrase "You build it, you run it" is frequently cited as the gold standard of modern engineering culture. The original intent was sound: break down the wall between developers throwing code over the fence and operations scrambling to keep systems alive at 3 AM.

However, in practice, rigid interpretation of this rule can backfire. It often creates isolated silos where:

• Individual engineers become irreplaceable single points of failure (SPOFs).
• Platform or infrastructure engineers become glorified human ticket queues.
• Cross-team contributions stall because "that's not our team's repo."

My take? Anyone should be able to build, and anyone should be able to contribute. But if no one can sustainably own or support a component, it shouldn't be built in the first place.

Here is what I learned managing Terraform infrastructure at scale, and how shifting toward an InnerSource model transformed our operational efficiency.

The Trap: Becoming the Human Bottleneck

At a previous company, I was the primary owner of our shared Terraform modules. As project velocity increased across the organization, my inbox were constantly flooded with requests:

• "Can you build a module for this new service?"
• "We need to expose this new property on an existing module ASAP."
• "When will this module update be ready?"

Handling requests this way is a massive source of operational toil. Every ad-hoc tweak pulled focus from strategic reliability and long-term platform initiatives.

More critically, it created an operational anti-pattern: I was inadvertently acting as a gatekeeper instead of an enabler. The engineering organization didn't need one person doing all the module work; they needed the tooling, patterns, and safety nets to contribute themselves.

1. Cookie-Cutter Design: Lowering the Cognitive Load

To break this bottleneck, every module needed to feel familiar before an engineer even read the code.

I adopted a standardized cookie-cutter scaffolding across all modules:

• Predictable structure: Consistent layout for variables.tf, outputs.tf, main.tf, versions.tf, and examples/.
• Sensible defaults: Exposing only what was necessary while baking in security policies, tagging baselines, and cost guardrails by default.
• Runnable examples: Every module contained copy-pasteable examples/basic and examples/advanced directories tested in CI.

When all modules share the exact same structural ergonomics, any engineer who has seen one module can immediately read, debug, and submit a PR to any module without cognitive friction.

2. Docs-as-Code & Wikis: Turning Questions into Self-Service

Code without documentation is technical debt in disguise. To scale module adoption without answering the same questions every sprint, documentation was treated as a first-class deliverable:

1. Module Design Principles: A clear internal wiki detailing how and when to design a module.
2. Automated Documentation: Generating input/output tables automatically via tools like terraform-docs directly into the README on every pull request.
3. Contribution Guidelines: A concise guide explaining how to test changes locally, lint with tflint, and submit PRs.

When an engineer asked for a new property, the response shifted from "I'll add it to my backlog" to "Here’s the contribution doc and module scaffold: open a PR, ping me for review, and CI will validate it for you."

3. The Golden Rule: "If No One Can Support It, Don't Build It"

True ownership isn't about hoarding code; it's about stewardship.

Before introducing a new custom tool, abstraction layer, or infrastructure module, ask three questions:

1. Is the ongoing maintenance burden justified, or does an existing standard suffice?
2. Is the documentation and scaffolding clear enough that someone outside our immediate team could patch it?
3. If the original author leaves tomorrow, is this an asset or an operational liability?

If a solution cannot be documented, standardized, and shared, it shouldn't be deployed to production.

Final Thoughts for Engineering Teams

High-performing SRE and Platform teams don't scale by adding more people to answer ad-hoc pings. They scale by:

• Building paved roads with clear, cookie-cutter templates.
• Cultivating an InnerSource culture where any developer feels empowered to contribute.
• Prioritizing actionable documentation and wikis over tribal knowledge.

When everyone can build, everyone can contribute, and the entire team shares ownership, your platform stops being a bottleneck and becomes a true accelerator.