Skip to main content

Building Centers of Excellence

Prerequisites: Distributed Teams and Scaling Automation Leads to: After this, you'll be ready for AI-Assisted QA Leadership and Automation Transformation.

Why This Matters​

A Head of QA who builds a Center of Excellence disconnected from real teams. A Head of QA, wanting to drive consistency across a growing number of product teams, forms a dedicated Center of Excellence staffed by senior engineers pulled away from day-to-day product work, tasked with defining standards and best practices in relative isolation. The standards the Center produces are technically sound but don't reflect the practical realities individual teams actually face, and adoption stays low — teams treat the Center's output as a compliance requirement to nominally satisfy, not genuinely useful guidance, because it was built without their input.

A Head of QA who builds a Center of Excellence embedded in real practice. A peer building a similar structure instead staffs it with a rotating mix of engineers who split time between the Center and their own product teams, ensuring every standard is grounded in what's actually shown to work in practice, not designed in isolation. Standards get piloted on the contributing engineers' own teams before broader rollout, the same evidence-based pattern from Shift Left at Scale. Adoption is measurably higher, because the guidance reflects real, demonstrated practice rather than theoretical best practice imposed from a disconnected group.

Both leaders wanted the same outcome: consistent, high-quality practice at scale. Only one built a structure that stayed genuinely connected to the teams it was meant to serve.

What a Center of Excellence Should Actually Do​

A Center of Excellence (CoE) is a more formal structure than the lightweight governance from Test Governance — appropriate once an organization has grown large enough that informal cross-team coordination genuinely no longer scales. Its core functions:

  • Identify and codify genuinely proven practice, not theoretical best practice — standards should trace back to something demonstrated to work on a real team, not be designed in the abstract.
  • Maintain shared infrastructure and tooling that individual teams would otherwise duplicate independently, the same infrastructure investment from Quality Engineering as a Discipline, now formalized at larger scale.
  • Provide a channel for cross-team learning, surfacing what one team discovered so other teams don't have to rediscover it independently.
  • Stay narrowly scoped to genuinely cross-cutting concerns, the same proportional-governance principle from Test Governance — a CoE that tries to control every team-level decision becomes exactly the kind of disconnected bureaucracy this module's opening scenario describes.

Common Mistakes​

Mistake 1: Staffing the CoE entirely with people disconnected from day-to-day product team work. This module's opening scenario — standards designed in isolation from real practice tend to be technically sound but practically disconnected, producing low genuine adoption regardless of their theoretical quality.

Mistake 2: Rolling out CoE standards organization-wide without piloting them first. The same evidence-based rollout discipline from Shift Left at Scale applies here — standards that haven't been proven on a real team first are both riskier and less credible when proposed broadly.

Mistake 3: Letting the CoE's scope expand into every team-level decision. A CoE that tries to control too much becomes bureaucratic and resented, the same failure mode heavyweight governance falls into — keep it narrowly scoped to genuinely cross-cutting concerns.

Mistake 4: Treating CoE membership as a permanent, disconnected role rather than a rotating one connected to real team work. Permanent CoE staff who never do hands-on product-team work risk losing touch with practical reality over time — rotation keeps the group's output grounded in current, lived experience.

Best Practices​

Practice 1: Staff the CoE with a rotating mix of engineers who split time with real product-team work. This keeps every standard genuinely connected to practical, current reality, rather than theoretical best practice designed in isolation.

Practice 2: Require every proposed standard to trace back to demonstrated, piloted success on a real team. This evidence requirement, mirroring the shift-left pattern of piloting before broad rollout, is what keeps CoE output credible and genuinely adopted rather than nominally complied with.

Practice 3: Keep the CoE's scope narrow, focused on genuinely cross-cutting infrastructure, standards, and learning. Resist the instinct to expand its authority into every team-level decision — the same proportional-governance discipline from Test Governance applies directly.

Practice 4: Build an explicit channel for cross-team learning, not just top-down standard-setting. A CoE's value includes surfacing what individual teams discover, not only distributing centrally designed guidance — genuine two-way flow, not one-way distribution.

From the Field

As AtlasBank grew past 150 engineers across its four product teams, the Head of QA formed a Testing Center of Excellence to address growing inconsistency in automation practices and shared infrastructure decisions. The initial version, staffed entirely by senior engineers permanently reassigned away from product teams, produced a comprehensive automation-framework standard that individual teams found impractical for their specific contexts and largely ignored. Restructuring the CoE around a rotating model — engineers spent 20% of their time on CoE work while remaining embedded on their own product teams, and every proposed standard had to be piloted successfully on at least one real team before broader adoption — produced standards with measurably higher genuine adoption within two quarters, because the guidance now reflected demonstrated practice rather than theoretical design.

Mini Challenge​

Scenario: You're forming a QA Center of Excellence for an organization that has grown to 8 product teams with increasingly inconsistent automation practices.

Your task: Describe the specific staffing model you'd use to keep the CoE connected to real practice, and name one requirement you'd impose before any proposed standard gets adopted organization-wide.

Key Takeaways​

  • A Center of Excellence should codify genuinely proven, piloted practice, not theoretical best practice designed in isolation from real teams.
  • Staffing the CoE with people who remain connected to real product-team work, rather than permanently disconnected specialists, keeps its output practically grounded.
  • The same evidence-based, piloted rollout discipline from shift-left applies directly to CoE standard adoption.
  • A CoE should stay narrowly scoped to genuinely cross-cutting concerns, the same proportional-governance principle as lightweight test governance.

What You Just Learned​

  • What a Center of Excellence should actually do at larger organizational scale, and why it's a more formal extension of earlier governance principles
  • Why staffing and evidence requirements determine whether a CoE produces genuinely adopted standards or disconnected bureaucracy
  • The importance of keeping CoE scope narrow, applying the same proportional-governance discipline from earlier in this path
  • The AtlasBank example of restructuring a disconnected CoE into a rotating, evidence-based model that achieved genuinely higher adoption

Interview Questions​

Q1: How would you structure a Center of Excellence to avoid it becoming disconnected from real team practice?

What to look for: An answer emphasizing rotating staffing and evidence-based, piloted standards rather than a permanently dedicated, disconnected group — a candidate who describes only top-down standard-setting likely hasn't considered this specific failure mode.

Q2: What's the difference between a Center of Excellence and the kind of lightweight governance you'd introduce earlier in an organization's growth?

What to look for: An articulation connecting the two as points on the same scale — proportional governance formalizing further as an organization genuinely grows — not treating them as unrelated concepts.

Common Interview Mistake

Some candidates describe a Center of Excellence purely as a way to enforce standards across teams, without addressing how those standards get created or validated. A strong answer emphasizes that CoE output should trace back to demonstrated, piloted practice, not be designed and imposed from a disconnected group.

Q3: How do you keep a Center of Excellence's scope from expanding into every team-level decision?

What to look for: A connection to proportional governance — deliberately scoping the CoE to genuinely cross-cutting concerns and explicitly leaving team-level decisions to individual teams, echoing the same discipline from earlier governance reasoning in this path.

Glossary​

Center of Excellence (CoE): A formal structure for driving cross-team quality consistency at larger organizational scale, focused on codifying proven practice, maintaining shared infrastructure, and enabling cross-team learning.

Rotating Staffing Model: Staffing a Center of Excellence with people who split time between CoE work and real product-team work, keeping its output grounded in current, practical reality.

Quick Revision​

Remember these five points:

✓ A Center of Excellence should codify genuinely proven, piloted practice, not theoretical best practice designed in isolation.

✓ Rotating staffing that keeps CoE members connected to real product-team work produces more practically grounded output.

✓ Proposed standards should be piloted and demonstrated successful on a real team before broader rollout.

✓ A CoE should stay narrowly scoped to genuinely cross-cutting concerns, not expand into every team-level decision.

✓ A CoE's value includes enabling cross-team learning, not just distributing centrally designed standards.

Section 8 Complete​

Across three modules, this section extended scaling judgment to organizational stage, distributed teams, and formal cross-team structure: recognizing that the right QA approach genuinely differs between a startup and an enterprise, redesigning coordination and automation investment deliberately for distributed teams, and building a Center of Excellence that stays genuinely connected to real practice rather than becoming disconnected bureaucracy. From here, continue to Section 9 — Modern Leadership, starting with AI-Assisted QA Leadership and Automation Transformation.

Section 8 Knowledge Check​

Three realistic scenarios. For each, decide which of this section's concepts applies, and how. No answers are provided here — this is a chance to apply the section's reasoning yourself before moving on. Solutions: Section 8 Solutions.

Scenario 1: A QA Lead from a large enterprise background joins a 20-person startup and introduces the same heavyweight, multi-stage review process used at their previous company, slowing release velocity sharply.

Scenario 2: A QA team newly distributed across three timezones continues running a synchronous daily standup scheduled for the original team's convenience, and the newest timezone consistently misses it or attends at an inconvenient hour.

Scenario 3: A newly formed Center of Excellence, staffed entirely by senior engineers permanently reassigned away from product teams, produces standards that individual teams find impractical and largely ignore.