At roughly 40 engineers, a platform organization stops being a group of teams and becomes a system. Informal coordination breaks down. The operating model — how work flows, how decisions are made, how teams depend on each other — matters as much as the technical architecture.

This is a field report from an organization that grew from 14 to 42 engineers over eighteen months while reducing change-failure rate and increasing deployment frequency. The details are specific, but the principles generalize.

Topology: four teams, one contract

We organized around four durable missions:

  • Core platform: compute, networking, identity, and the paved road for deployment.
  • Data platform: ingestion, warehouse, event contracts, and analytics enablement.
  • Developer experience: CI/CD, local environments, observability tooling, and documentation.
  • Reliability: incident response, service-level objectives, and cross-cutting resilience work.

Each team had a named mission, a primary customer, and a published interface. The interface was not an API spec — it was a service catalog entry describing what the team owns, what it promises, and how to request work.

Planning: quarterly outcomes, two-week commitments

We planned in two horizons. Quarterly, each team committed to three outcomes with measurable success criteria. Every two weeks, teams chose the next increment and published their dependencies. The rule was simple: no silent dependencies. If another team's work was required, it appeared on the dependency board with an owner and a date.

This reduced the weekly "are we on track?" meeting to a fifteen-minute async review. It also made cross-team risk visible early enough to act on.

Decisions: one owner, written record

Every significant decision had exactly one accountable owner. We used a lightweight decision record with context, options considered, decision, and consequences. Records lived next to the code and were reviewed in architecture office hours. The point was not bureaucracy; it was reducing repeated debate and preserving context after people changed teams.

Alignment is not everyone agreeing. Alignment is everyone knowing who decided, what was decided, and why.

Metrics that shaped behavior

We tracked four delivery metrics and two health metrics:

  1. Deployment frequency and lead time for change.
  2. Change-failure rate and time to restore.
  3. Percentage of teams with a current service catalog entry.
  4. Percentage of planned work that depended on an unplanned handoff.
  5. Engineer-reported cognitive load (quarterly survey).
  6. Percentage of incidents with a completed learning review.

We deliberately avoided using lines of code, ticket counts, or utilization as performance measures. They reward activity over outcomes and quietly punish the collaboration that platform work requires.

What we would do differently

We over-invested in a custom internal dashboard before we had stable definitions. We also let the reliability team become a catch-all for work nobody else wanted. Both problems were fixed by narrowing missions and making ownership explicit. The operating model is never finished; it is a product you maintain.