Interactive Org Chart

Stacked sections · mode tag per DL · click any field to edit · changes auto-save to this browser

All changes saved View-only access

DELIVERY LEADS OFFICE

target 4-6 · currently 0

Technical face of every customer project · runs demos, collects sign-offs, coordinates across service teams, pods, and self-serve · reports to Head of Delivery

PURPOSE & SCOPE

Single technical face to the customer.

Owns customer outcome end-to-end.

No service team commits dates to a customer without DL approval.

Sized by mode:

  • Mode A (Mature): 1 DL : 3–5 projects
  • Mode B (Maturing): 1 DL : 2–3 projects
  • Mode C (New): no DL — Pod TL leads
  • Mode D (Self-Serve): no DL

RESPONSIBILITIES

  • Solution architecture across service teams & pods
  • Translate customer requirements → backlog & estimates
  • Cross-team scheduling & sequencing
  • Risk management & escalation
  • Project budget & timeline ownership
  • Customer relationship management

Career path:

Senior eng → TL → DL → Head of Delivery

DEMOS & SIGN-OFFS ★

  • Run customer-facing demos directly — service teams demo to DL only
  • Bi-weekly demo cadence with customer

Sign-off chain:

  • Collect sign-off from each service team
  • Consolidate into single sign-off pack
  • Present consolidated pack to customer
  • Hold final UAT sign-off authority

CADENCE & AUTHORITY

Forums:

  • Weekly: capacity review with Service Team TLs
  • Bi-weekly: customer SteerCo + demo
  • Bi-weekly: DL portfolio review
  • Monthly: capacity planning

Authority:

  • Only DL commits scope/dates
  • Owns project P&L & risk

CURRENT DELIVERY LEADS

QA CHAPTER

core: 0 · plus embedded testers in every team

Embedded testers collaborate with developers inside every team · core platform team builds shared automation infrastructure · owns quality metrics across the org

EMBEDDED + MATRIX MODEL

Testers sit inside each team and collaborate directly with developers from day 1 of a feature.

Dotted line to QA Chapter Lead for standards, framework, and career growth.

Staffing pattern:

  • Service team: 1–2 testers embedded
  • Pod: 1 tester embedded
  • Self-Serve team: 1 tester (rotates if small)
  • Platform team: 1 tester (security & infra focus)

TEST CASE REVIEW

Developers write automated tests; testers review them.

  • Review ALL automated test cases written by developers (unit, integration, E2E)
  • Approve coverage before code merges to product mainline
  • Mentor developers on test design & edge cases
  • Pair on test plans at start of each story
  • Block merges that don't meet team's coverage bar

NEGATIVE TEST PLATFORM ★

Central platform built & owned by the QA Chapter core team — automates negative scenarios too domain-specific or complex for unit tests.

Scenario examples:

  • Invalid pricing / tax combinations
  • Integration failures — timeouts, partial reads, retries
  • Race conditions in commercial flows
  • Multi-tenant data leak scenarios
  • Customer-specific edge cases (parameterized)

Each embedded tester contributes scenarios for their domain; QA core team maintains the framework.

BUGS & METRICS

Track:

  • Central bug board across all teams
  • Triage flow for production bugs
  • Customer-reported vs. internally-found ratio

Report weekly & monthly:

  • Test coverage per team
  • Defect leakage rate (test → prod)
  • Test automation % (manual → automated)
  • MTTR for bugs (open → resolved)
  • Blocker / critical bug count over time

QA CHAPTER — CORE TEAM

Embedded testers live inside each team — name them in that team's Members list, with a "(tester)" suffix to flag the role.

PLATFORM LAYER

Foundation every product runs on — security, infrastructure & cross-cutting services · reports to Head of Platform