Breaking Down Team Silos

01/ The Tactical Resolution

The Case Study: The Battle of the Two Auth Services

The Problem

Our engineering organization had grown to four squads. Two of these squads—Growth and Core Platform—were working on different parts of the application. Due to a lack of shared context, the Growth team built their own custom micro-service for token-based session handling to support a quick mobile experiment. At the same time, the Platform team was building a robust OAuth2 integration for our enterprise portal.

Neither team told the other.

By the time we realized, we had two completely separate authorization databases, conflicting user tables, and different JWT signing keys in production. When asked why they didn't collaborate, the Growth Tech Lead replied: “Platform takes weeks to respond to requests, and their repo is a closed fortress. We had to move fast.” The Platform Tech Lead shot back: “Growth writes messy code that compromises our system security; we can't let them commit to our services.”

The squads had turned into empires, protecting their codebases, refusing external contributions, and duplicating work out of pure frustration.

The Playbook: The Inner-Source Architecture

To break down silos, you cannot just tell people to "collaborate more." You must build incentives and pathways for code contribution across team boundaries. We call this Inner-Sourcing.

Step 1: The "Open Kitchen" Repository Standard

By default, every repository in the organization must be readable by every engineer.

• The Rule: No team is allowed to have "private" repos within the organization.
• The CodeOwners Guard: Use CODEOWNERS configurations to protect main branches, ensuring that while anyone can read and submit a pull request, the owner squad must approve the final merge. This protects system stability while allowing open contributions.

Step 2: The "Guest Developer" Rotation Program

To break down personal biases, create a structured rotation program.

• The Execution: Once a quarter, one developer from the Growth team rotates into the Platform team for exactly one sprint (two weeks). They take on standard platform tickets and participate in platform design meetings.
• Why it works: It builds empathy. The Growth developer learns why the Platform team enforces strict security audits, and the Platform team learns the friction that external developers face when using their libraries.

Step 3: Define the "Inner-Source contribution SLO"

If an external developer submits a PR to your repo, it cannot sit ignored.

• The SLA: Teams must review "guest PRs" within 48 hours. If the PR has minor style issues, the host team should pair with the contributor to fix them rather than rejecting the PR outright.
• The Reward: Highlight cross-squad contributions in the monthly engineering town hall. Celebrate the developers who saved hours of work by reusing code rather than writing duplicate services.

The Long-Term Impact

• No More Duplication: The two auth services were consolidated into a single OAuth system, and the teams co-authored the migration path.
• Empathy Restored: The rotation program helped build personal bonds. Developers stopped referring to other squads as "them" and began thinking of the codebase as a single shared ecosystem.
• Efficiency: Cross-team code reuse increased by 80%. When the checkout squad needed an SMS notifier, instead of building a new service, they submitted a 10-line PR to the platform notification repo, shipping the feature in 1 day instead of 2 weeks.