Scaling Automation Across Teams

Most organizations have at least one team doing automation well. The hard problem is not inventing the practice; it is getting the other twenty teams to adopt it without a central group becoming a bottleneck or a police force.

Three operating models link

flowchart TD
    subgraph "Centralised"
    C1[Central team builds<br/>and operates everything]
    C1 --> C2["Consistent · deep expertise<br/>Bottleneck · product teams<br/>lose ownership"]
    end
    subgraph "Decentralised"
    D1[Each team does its own]
    D1 --> D2["Fast · fits local needs<br/>Duplicated · inconsistent<br/>Security gaps"]
    end
    subgraph "Federated"
    F1[Central platform + standards]
    F2[Teams own their implementations]
    F1 <--> F2
    F1 --> F3["Consistent where it matters<br/>Autonomous where it does not<br/>Requires deliberate boundary-setting"]
    end

The federated model is what most organizations converge on, and its difficulty is entirely in drawing the boundary. Get it wrong toward the centre and you have a bottleneck; wrong toward the edges and you have twenty incompatible implementations of the same thing.

A workable division:

The test for centralising something: would inconsistency here cause real harm? Inconsistent secret handling causes breaches; inconsistent dashboard layouts do not.

Why mandates underperform link

Mandating adoption produces compliance behaviour — the minimum that satisfies the letter of the requirement — and destroys the signal that tells you whether the thing is any good. It also creates an adversarial relationship where teams invest effort in exemptions rather than in adoption.

What works better, in rough order of effectiveness:

1. Make it obviously easier. If the paved road takes an afternoon and the alternative takes two weeks, adoption needs no persuasion.
2. Make the benefit visible. Publish the numbers: teams on the standard pipeline deploy N times more often with a lower failure rate.
3. Reduce switching cost. Provide migration tooling, not just documentation. The most common blocker is not disagreement; it is that migration is a two-week project nobody has scheduled.
4. Use social proof. A respected team’s adoption moves more teams than any directive.
5. Reserve mandates for genuine non-negotiables. Security controls, regulatory requirements. Mandating a preference spends the credibility you need for the requirements.

Communities of practice link

Cross-team groups spread practice horizontally in a way that top-down programmes cannot, because the transfer is between peers with comparable problems.

What makes them work rather than becoming another meeting:

• A real, recurring slot with an owner who prepares it.
• Demonstrations, not status updates. Someone shows what they built and what broke.
• Decision rights over shared standards. A group that only discusses has no reason to keep meeting; one that agrees conventions and reviews shared modules does.
• Written output. Decisions and patterns recorded where people who missed the session can find them.
• Explicit failure sharing. The most valuable session content is what did not work, and it only happens if it is safe.

Making internal knowledge findable link

Practice spreads only if it can be found at the moment someone needs it.

• One documented paved road per common task, discoverable from where people start looking.
• Architecture decision records capturing why choices were made. The rationale is what transfers; the decision alone is not enough for another team to know whether it applies to them.
• A searchable incident and postmortem archive. Institutional memory of failure is one of the most valuable assets an organization has, and it decays fast without a searchable home.
• Working examples over reference documentation. A repository someone can clone and run beats a specification.

Measuring the spread link

The variance measure is the honest one. If one team has excellent delivery metrics and the rest have not moved, the organization has a good team, not a good practice.

Sequencing an organization-wide effort link

flowchart TD
    A[Find the team already doing it well] --> B[Extract and generalise<br/>what they built]
    B --> C[Pilot with 2-3 volunteer teams<br/>chosen for difference, not similarity]
    C --> D{Did it work<br/>for teams unlike the first?}
    D -->|No| E[Fix the generalisation.<br/>The abstraction was wrong.]
    E --> C
    D -->|Yes| F[Publish results and<br/>migration tooling]
    F --> G[Open adoption; support<br/>the teams that come]
    G --> H[Only now consider mandating<br/>the security-critical subset]

Choosing pilot teams that are different from the originating team is the step that gets skipped. Three similar teams will validate an abstraction that fits only their shape, and the failure surfaces at team fifteen when the pattern is already entrenched.

What stalls it link

• The platform team is measured on delivery, not adoption. They ship features nobody uses and report success.
• No migration path. Teams agree the new way is better and never have a quarter free to move.
• The originating team’s context was unusual. What worked for the team with three senior infrastructure engineers does not transfer to the team with none — which is an argument for more automation in the paved road, not less.
• Leadership attention moves on before the middle of the adoption curve, which is where the difficult teams are.
• Success is never made visible. Teams do not adopt what they have not heard about.

Adoption checklist link

• The central/team boundary is explicit and justified by real harm from inconsistency.
• Adoption is driven by making the paved road easier, not by mandate.
• Mandates are reserved for security and regulatory non-negotiables.
• Migration tooling exists, not just documentation.
• A community of practice meets regularly with decision rights and written output.
• Decisions, patterns, and postmortems are searchable.
• Adoption breadth and cross-team metric variance are tracked.
• Pilots deliberately include teams unlike the originating one.