For a subsystem team, the boundary is the product. Each area below is something SVT owns end-to-end so the Pods don't have to — and each one maps to a Q3 outcome we're measured on.
The competency-modeling, scoring, and validation logic — the deep technical core no Pod should reimplement.
Reduces Pod cognitive load. Embedding a validation specialist in every Pod isn't cost-effective and pulls them off delivery. Concentrating the expertise here is the whole rationale for a subsystem team.
MVP in progress, targeting two pilot roles.
Scope creep from Pods asking us to own their surfaces, not just the engine.
The model of what "validated" means for a given skill or role — the domain definition the engine encodes.
It's the specialist knowledge. The framework is only credible if it's owned by the team closest to the domain and validated with the people who use it.
Validation underway with SMEs and hiring managers.
SME and hiring-manager time is the schedule risk — see dependencies.
The published, versioned interface consuming Pods build against — the boundary that lets us change internals without breaking anyone.
A subsystem is only useful as a service. A stable contract is what turns the engine from an internal project into something Pods can depend on.
Being agreed with the first consumer, Pod 3 (Talent Marketplace). Pod 5 (Performance Management) is next in line.
Lock the schema early so we can build behind a stable interface.
Note: KR statuses and dashed ↗ source links are placeholders — set the statuses to reality and point the links at your real OKR, Jira, and Confluence URLs.