Cross-Team Implementation
One team's automation success is a proof of concept. Ten teams' automation success is a platform. Learn how to scale quality practices across an organisation without creating bureaucracy.
1 The Hook — Why This Matters
A NZ healthtech company had one team with world-class automation: 90% coverage, 5-minute regression, zero flaky tests. They were the "automation champions." The other seven teams had no automation at all. When the champion team's lead left, their practices didn't transfer. Six months later, the company had one legacy suite rotting in a repo and seven teams still testing manually. The knowledge died with the individual because there was no mechanism for cross-team propagation.
Automation success that doesn't scale is just a portfolio piece. The architect's job is designing the system that makes good practices inevitable across teams, not just possible in one.
Senior engineer insight
The first time I ran a cross-team automation rollout, I spent three months building an elegant shared library before showing it to anyone. By the time I demoed it, two teams had already built their own incompatible versions and had no incentive to throw away working code. Ship a rough v0.1 to one team within the first two weeks — getting a consumer's hands on it early reveals the sharp edges that architecture diagrams never will. Real adoption is won in Slack threads and pair-programming sessions, not in RFC documents.
The most common mistake: building the platform in isolation and calling it "done" before any team has shipped a test with it in CI.
From the field
A Wellington-based team building Revenue NZ's digital services portal had six squads and six completely different approaches to test automation — three frameworks, two languages, no shared CI standards. The assumption was that autonomy had produced innovation. What it had actually produced was six isolated silos where a bug fixed in one squad's helpers was silently re-introduced in another's three sprints later. When an architect was brought in to unify the approach, the squads didn't resist the idea of a shared library — they resisted the timing, mid-sprint with a minister's deadline looming. The lesson: cross-team standards work best when introduced between delivery peaks, tied to a specific pain point every squad already feels (in this case, duplicated flaky login helpers), and co-authored by at least one engineer from each spoke rather than handed down from a central team.
2 The Rule — The One-Sentence Version
Standardise what reduces friction; leave flexible what enables innovation. Govern through shared libraries and automated gates, not through approval committees.
Centralised control creates bottlenecks. Complete autonomy creates chaos. The hybrid "hub-and-spoke" model balances both: the hub owns platform, governance, and shared assets. Spokes (delivery teams) own execution, local customisation, and domain expertise.
3 The Analogy — Think Of It Like...
A national highway system with local roads.
The highways (shared libraries) are standardised: same lane widths, same signage, same maintenance standards. This lets anyone drive anywhere. But the local roads (team-specific tests) can be dirt, gravel, or paved based on local needs. You don't need a central committee to approve a new driveway. But you do need standards for how it connects to the highway. That's governance: standardise interfaces, not implementations.
4 Watch Me Do It — Step by Step
Here is how to implement automation across multiple teams without creating an ivory tower.
- Define what to standardise vs. what to leave flexible
Standardise Leave Flexible Framework choice (approved radar items) Test data strategy Design patterns (POM, Screenplay, Builder) Specific assertion libraries Coding standards (naming, structure, linting) Mocking approaches CI/CD integration (triggers, gate criteria) Pace of adoption Reporting format (consistent dashboards) Team-specific tooling - Build shared libraries
@company/automation-core # Base framework, drivers, config @company/automation-utils # Helpers, data generators, API clients @company/automation-reporting # Custom reporters, dashboard connectors @company/automation-pages # Shared page objects (design system)Governance: semantic versioning, automated publishing on merge, changelog and deprecation policy, consumer team representation in architecture decisions.
- Choose a governance model
Dimension Centralised CoE Federated Hybrid (Recommended) Decision speed Slower Fast Balanced Consistency High Variable Moderate-High Innovation Lower High Balanced Best for Regulated industries Mature teams Most large organisations - Roll out using ADKAR
Stage Action Success Signal Awareness Communicate "why" — business case, pain points >80% of leads articulate the vision Desire Identify champions; show early wins Volunteers emerge for pilot Knowledge Training, pair programming, documentation First automated test merged Ability Hands-on support, Slack channel Team runs tests independently in CI Reinforcement Metrics, recognition, remove blockers Adoption becomes habitual
5 When to Use It / When NOT to Use It
✅ Standardise across teams when...
- >3 teams are building automation
- Executive leadership wants consistency
- Shared services (reporting, CI) need integration
- Mobility of engineers between teams is common
❌ Allow autonomy when...
- Teams have radically different tech stacks
- Maturity levels vary widely
- Experimentation is culturally valued
- Standardisation would block urgent delivery
6 Common Mistakes — Don't Do This
🚫 Centralised CoE doing operational work
I used to think: The CoE should write tests for every team.
Actually: When the CoE performs operational tasks, it becomes a bottleneck. Teams wait in queue instead of building capability. The CoE defines standards and provides platforms. Teams write tests and own quality.
🚫 Mandating tools without buy-in
I used to think: If the architecture team chooses the tool, everyone must use it.
Actually: Mandates without understanding create shadow IT. Teams will build their own solutions in secret to bypass the "official" tool. Involve team representatives in tool selection. Address their concerns before rolling out.
🚫 Measuring adoption only by coverage %
I used to think: Teams with 80% coverage are doing better than teams with 40%.
Actually: Coverage without quality is vanity. Measure: pipeline integration rate (% of teams with automated gates), self-service ratio (% using shared libraries without CoE help), and escalation volume (support tickets per team per month). These measure real adoption, not checkbox compliance.
Why teams fail here
- The CoE becomes a gatekeeper, not an enabler. When every new test pattern requires a pull request to a central repo owned by one team, delivery squads learn to route around the bottleneck. Standards erode because compliance is slower than shipping.
- Adoption is measured by coverage numbers, not by pipeline integration. A squad can report 80% coverage against a suite that never runs in CI. Track the pipeline integration rate — what percentage of teams have automated quality gates blocking a merge — not the coverage percentage in a disconnected report.
- Shared libraries go unversioned and undocumented. In regulated environments like NZ health sector or TransitNZ, a silent breaking change in a shared helper can fail compliance audits across multiple teams simultaneously. Semantic versioning and a changelog aren't optional overhead — they are the trust mechanism that keeps teams willing to upgrade.
- Champions leave and take the culture with them. If cross-team automation is carried by one or two enthusiastic engineers rather than embedded in documented standards, sprint agreements, and on-boarding material, it collapses the moment those people take another role. The practices must survive personnel churn to count as institutional adoption.
Key takeaway
Automation that lives in one team's repo is a prototype; automation that is designed to be adopted, versioned, and survived by strangers is a platform — and only the platform compounds.
7 Now You Try — Interview Warm-Up
Scenario: You are rolling out a shared automation platform to 10 teams. Three teams are enthusiastic. Four are neutral. Three are actively resistant ("We don't have time," "Our app is too complex," "We tried before and it failed").
What is your rollout strategy?
The strategy:
- Start with champions: Support the 3 enthusiastic teams first. Their success becomes the proof point for the neutral teams.
- Address resistance directly: For "no time," show time saved per sprint. For "too complex," start with API layer (more stable than UI). For "tried before," acknowledge past failure and explain what's different (better tools, support, lessons learned).
- Mandate minimum viable: Every team must have smoke tests in CI within 3 months. Not full coverage. Just smoke. Make the barrier low enough that compliance is easier than resistance.
- Gamify carefully: Leaderboards for coverage improvement, paired with quality metrics (not just quantity). "Automation champion" awards quarterly.
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you got all three, you're ready to practice.
Q1. What is the hybrid (hub-and-spoke) governance model?
The "hub" (CoE or platform team) owns shared libraries, standards, and governance. The "spokes" (delivery teams) own execution, local customisation, and domain expertise. This balances consistency with autonomy.
Q2. What are the five ADKAR stages for change management?
Awareness (communicate why), Desire (identify champions), Knowledge (training and documentation), Ability (hands-on support), Reinforcement (metrics, recognition, remove blockers).
Q3. Why should shared libraries use semantic versioning?
Semantic versioning (MAJOR.MINOR.PATCH) communicates breaking changes clearly. Teams can upgrade independently when ready. Breaking changes require migration guides. This reduces fear of updates and enables incremental adoption.
9 Interview Prep — Architect Q&A
Cross-team scaling questions focus on change management, governance, and organisational dynamics. Architects are tested on their ability to navigate complexity.
Q. "How would you implement testing practices across 5+ independent teams?"
Start with a pilot on one team that's hungry for change. Show measurable improvement in their metrics (test velocity, escape rate, deployment confidence). That team becomes your proof point for the doubters. Simultaneously, identify champions in the other teams—people who are frustrated with the status quo. Invest in training them first. Use the hub-and-spoke model: the CoE (you) owns shared libraries, governance, and metrics. Each team owns execution and customisation. Never mandate tool choice across all teams; mandate outcomes (e.g., "every change needs risk-based test coverage"). Let teams pick the tool that gets there. Enforce adoption gradually: month 1 is smoke tests in CI, month 2 is structured regression, month 3 is cross-team shared patterns.
Q. "What are the biggest blockers to consistent test automation adoption?"
Not technical. The real blockers are: 1) Ownership confusion (is QA responsible or developers?), 2) Skill gaps (teams don't know how to write good tests), 3) Schedule pressure (teams are too busy to automate), 4) Tool fatigue (teams have tried and failed before), and 5) Motivation misalignment (leadership wants automation but doesn't allocate resources). Counter these by: establishing clear ownership (developers write unit and integration tests, QA focuses on E2E and risk-based), providing hands-on training and pair programming, protecting time for automation in sprint planning, learning from past failures openly, and tying automation metrics to team goals and bonuses. Money talks—if you reward automation, teams will prioritise it.
Q. "How do you maintain test quality as you scale to hundreds of tests?"
Quality degrades with scale because: more tests = more maintenance burden, more flakiness, more false positives. Combat this with: 1) Intelligent test design (use risk-based selection so you run only relevant tests per PR), 2) Aggressive refactoring (treat tests as code; refactor constantly), 3) Flakiness budgets (limit flaky tests to <1%; fix them or remove them), 4) Code review for tests (peer review is mandatory before merge), and 5) Automated analysis (run tools that flag low-value or duplicate tests). As you scale, the CoE's job shifts from writing tests to enforcing test quality standards. Use metrics: test durability (% pass rate), execution time distribution (flag slow tests), and code coverage by risk level (don't measure total coverage; measure critical path coverage).
Q. "How do you make the case for automation investment to leadership?"
Don't lead with "good engineering practice." Lead with business impact. Quantify: current manual testing takes X weeks, finds Y bugs, blocks Z releases. Automation can reduce that to X/3 weeks, maintain or improve Y bugs found, and enable weekly releases. ROI: if one prevented escape costs $100K in customer impact and automated testing catches 2 escapes per year, that's $200K benefit. Set costs are tooling, training, and CoE salary. ROI is usually positive within 6-12 months at scale. Present a phased pilot: Month 1-3, invest $50K, measure impact on one team. If metrics improve, expand to all teams. If metrics don't improve, kill the pilot without blame. Leadership respects data and pragmatism. They don't respect vague promises of "quality."