1.2The Three Dominant Models

There are three dominant models for organizing QA engineers within a company. Each has trade-offs, and the right choice depends on your organization's size, culture, and product architecture.

Model 1: Centralized QA Team

All QA engineers report to a QA manager and are assigned to projects as needed.

VP of Engineering
    +-- QA Manager
            +-- QA Engineer A --> assigned to Team Alpha
            +-- QA Engineer B --> assigned to Team Beta
            +-- QA Engineer C --> assigned to Team Gamma
            +-- QA Engineer D --> floater / specialist

Advantage	Disadvantage
Consistent standards across the organization	QA engineers may feel disconnected from their dev teams
Easier to share knowledge and best practices	Assignment changes can disrupt team dynamics
Clear career path within QA hierarchy	Can create "us vs them" dynamic with developers
Efficient resource allocation across projects	QA priorities may conflict with dev team priorities
Stronger QA identity and community	Slower feedback loop if QA is not co-located with devs

Best for: Large enterprises with many product teams, organizations that need strict quality standards, companies with dedicated QA leadership.

Pro Tip: If you run a centralized model, create a rotation schedule so QA engineers spend at least 6 months with each product team. This prevents the "parachute tester" problem where QA shows up without context, tests superficially, and leaves.

Common Mistake: Building a centralized QA team that becomes a "testing service desk" -- taking orders from dev teams rather than partnering with them on quality strategy. If your QA engineers are just executing test cases someone else wrote, the model has failed.

Model 2: Embedded QA (Distributed Model)

QA engineers report directly to the engineering manager of their product team. There is no centralized QA organization.

VP of Engineering
    +-- Team Alpha Lead
    |       +-- Developer 1
    |       +-- Developer 2
    |       +-- QA Engineer A
    +-- Team Beta Lead
    |       +-- Developer 3
    |       +-- Developer 4
    |       +-- QA Engineer B
    +-- Team Gamma Lead
            +-- Developer 5
            +-- QA Engineer C

Advantage	Disadvantage
QA is deeply integrated with the dev team	Inconsistent practices across teams
Faster feedback loops and tighter collaboration	QA engineers can feel isolated from QA peers
QA understands the product domain deeply	Career growth may be limited without QA leadership
No resource allocation conflicts	Knowledge sharing across teams is harder
QA participates in all team decisions	Risk of QA being treated as a junior developer

Best for: Agile startups, companies with autonomous product teams, organizations with strong engineering culture.

Pro Tip: If you use the embedded model, create a "QA Guild" -- a cross-team community of practice where embedded QA engineers meet biweekly to share learnings, align on standards, and support each other. This solves the isolation problem without adding management overhead.

Common Mistake: Letting embedded QA engineers become "the team's manual tester" with no voice in design, architecture, or sprint planning. Embedding only works when QA is a full team member, not a subordinate role.

Model 3: Hybrid Model

A small centralized QA team sets standards, builds tooling, and provides expertise, while most QA engineers are embedded in product teams.

VP of Engineering
    +-- QA Platform Team (centralized)
    |       +-- QA Architect --> frameworks, tooling
    |       +-- Performance Specialist
    |       +-- QA Coach --> standards, mentoring
    +-- Team Alpha (embedded QA)
    |       +-- Developers
    |       +-- QA Engineer A (dotted line to QA Architect)
    +-- Team Beta (embedded QA)
            +-- Developers
            +-- QA Engineer B (dotted line to QA Architect)

Advantage	Disadvantage
Best of both worlds: local integration + central standards	More complex organizational structure
QA platform team builds shared infrastructure	Dotted-line reporting can create confusion
Embedded QA engineers have peer community	Requires strong coordination between central and embedded
Consistent tooling with team-specific flexibility	Central team can become a bottleneck for decisions

Best for: Mid-to-large companies, organizations transitioning from centralized to agile, companies that want consistency without rigidity.

Pro Tip: The hybrid model works best when the centralized team positions itself as a service team, not a governance body. Build tools and frameworks that embedded engineers want to use, not rules they are forced to follow.

Common Mistake: Making the dotted-line relationship ambiguous. Be explicit: the embedded QA engineer's primary reporting is to their team lead (for day-to-day work), and their secondary relationship is with the QA platform team (for standards, career growth, and tooling). Document this in writing.