Local snapshot only. The workspace page is authoritative.
1.1 Governance model
PDS uses shared domain governance rather than a single approval chain.
The Design Ops Lead, Tyler Skrabek, acts as PDS Product Owner and owns program direction, Core scope, backlog order, roadmap, operating model, support , and the quality and coherence of the full PDS experience.
Each domain owner retains go or no-go authority within its accountable area. Work may proceed only when all required design, engineering, product, quality, and release gates have passed. No role may override a no-go issued within another role’s domain.
Core classification is jointly decided by the Design Ops Lead and Design Ops Product Designer. The Design Ops Lead resolves a tie when they do not agree.
1.2 Roles and authority
Role
Accountable decisions and evidence
**Design Ops Lead / PDS Product Owner, Tyler Skrabek**
PDS strategy; Core scope; backlog order; roadmap; support model; operating standards; organizational alignment; overall experience quality; final governance action after all required domain gates pass
**Design Ops Product Designer, Laura Vo**
Design-quality go or no-go; design and content evidence; Figma assets; component behaviour and variants; responsive behaviour; semantic intent; public naming; design documentation; design-to-code parity
**Product Manager, Thomas Petitjean**
Delivery planning; initiative framing; dependency tracking; milestone and outcome reporting; stakeholder alignment; product-team coordination; risk and decision tracking; preparation of roadmap and priority inputs with the Design Ops Lead
**Software Development Manager, Scott Yu**
Engineering capacity; staffing and allocation; engineering delivery commitments; assignment of the engineering lead and maintainers; escalation of engineering risks; alignment between PDS work and PDP engineering plans
**PDP engineering lead / PDS Lead Maintainer, Danielle Perazzolo**
Technical go or no-go; repository stewardship; architecture; maintainability; contributor review; API and dependency safety; automated tests; package and version impact; technical documentation; merge authority; build, distribution, and release execution
**QA/SDET**
Go or no-go for the manual accessibility, assistive-technology, regression, and other test evidence it is assigned and qualified to produce
**DevOps**
Pipeline, package, deployment, and release-infrastructure work it accepts; operational evidence within that scope
**Contributing product team**
User and product need; local research and testing; disclosure of consumers and known gaps; adoption feedback; maintenance of its own implementation; accessibility of the full product experience
**Voluntary contributor**
Implementation of an approved and assigned PDS backlog item within its agreed scope; required evidence; response to review feedback; disclosure of blockers, availability changes, and unfinished work
The Product Manager supports delivery and coordination but does not independently set design standards, approve technical architecture, classify Core components, or order the PDS backlog.
The Software Development Manager owns engineering capacity and staffing but does not independently set PDS strategy, design quality, maturity, or Core classification.
Voluntary contributors add delivery support but do not receive governance, backlog, maintainer, merge, or release authority.
### 1.3 Working structure and decision rhythm
The core working team includes:
- DesignCD Ops Lead, Tyler Skrabek
- Design Ops Product Designer, Laura Vo
- Product Manager, Thomas Petitjean
- Software Development Manager, Scott Yu
- PDP engineering lead / PDS Lead Maintainer, Danielle Perazzolo
The core team meets every two weeks to review:
- new intake and proposed Core work;
- backlog priority and capacity;
- delivery progress and dependencies;
- voluntary contribution assignments and review demand;
- design, technical, quality, and release evidence;
- component health and lifecycle changes;
- documentation and deprecations;
- roadmap changes, risks, and unresolved decisions.
The Design Ops Lead chairs the governance discussion and owns backlog decisions.
The Product Manager maintains the delivery plan, records decisions, tracks dependencies, coordinates follow-up, and distinguishes committed capacity from supplemental contribution support.
The Software Development Manager confirms engineering allocations, manages engineering capacity conflicts, and resolves staffing issues.
The PDS Lead Maintainer advises on technical sequencing, review demand, and the amount of contributor work that can be supported without reducing planned PDS delivery.
Each domain owner provides the required go or no-go within its accountable area.
QA/SDET, DevOps, accessibility specialists, product teams, and contributors join when their evidence, work, or decisions are required. They retain authority only within their assigned scope and are not required at every recurring review.
### 1.4 FY27 resourcing
PDS’s standing delivery group consists of:
- Design Ops Lead, Tyler Skrabek;
- Design Ops Product Designer, Laura Vo;
- PDS Lead Maintainer, Danielle Perazzolo.
The PDS engineering role is filled through protected front-end engineering capacity hosted by PDP.
The Product Manager and Software Development Manager are part of the core governance and planning team. Their involvement supports delivery planning, staffing, capacity, dependencies, and risk management. It does not replace protected design or engineering delivery capacity.
QA/SDET and DevOps support are scheduled as needed. Work that depends on this support must account for confirmed availability before it is treated as committed delivery.
Voluntary contributors are supplemental capacity. They are not part of PDS’s committed delivery capacity unless their home team has approved and recorded a specific allocation.
A contributor assignment must record:
- the approved backlog item;
- the contributor and home team;
- the agreed scope;
- the expected allocation or availability;
- the target period;
- the required reviews and evidence;
- the accountable PDS owner.
Contributor work must not be included in delivery forecasts, roadmap commitments, or target dates unless the allocation has been confirmed and recorded.
The Product Manager tracks committed and supplemental capacity separately. Forecasts must show which work relies on protected PDS capacity, scheduled specialist support, or voluntary contribution.
### 1.5 Decision gates
PDS does not use majority voting. Approval is based on the domains affected by the work.
1. The Design Ops Lead identifies the required decision gates.
2. Each domain owner reviews the evidence within its accountable area.
3. The work proceeds only when all required gates receive approval.
4. A no-go pauses the work. The domain owner records the unmet condition and the evidence needed for a new review.
5. One domain owner cannot overrule another domain’s no-go.
6. Each domain owner remains accountable for the approval it provides.
Governance approval does not replace technical review, merge, release, deployment, or publication controls. Those actions remain with the roles and processes defined in the relevant sections of this operating model.
### 1.6 Continuity and delegation
Each member of the core working team must identify a delegate when their absence could block a time-sensitive decision.
**A delegation must record:**
- the delegated role or decision;
- the scope of authority;
- the named delegate;
- the start and end date;
- any limits or conditions.
A delegate may act only within the authority recorded for that period. Team membership, contributor status, or prior involvement does not grant approval, maintainer, merge, release, or governance authority.
When no valid delegate is available, the affected decision waits for the accountable owner. Lack of response does not count as approval.
The Design Ops Product Designer may provide the Design Ops design-quality decision when the Design Ops Lead is unavailable. Decisions concerning strategy, backlog order, roadmap, support posture, or organizational commitments require the Design Ops Lead or a written delegation.
The PDS Lead Maintainer must name an engineering delegate for time-sensitive repository, technical-review, merge, and release decisions.
QA/SDET may approve only the evidence it was assigned, qualified, and able to complete. Unavailable QA/SDET support does not count as a passed quality gate.
Contributor work does not transfer automatically when a contributor becomes unavailable. The Product Manager records the status, and the Design Ops Lead decides whether the item returns to the backlog, moves to another contributor, or is reassigned to committed PDS capacity.
### 1.7 Decision records and visibility
Decisions that affect the governed PDS system must be recorded in the shared work item. This includes:
- Core classification;
- support level;
- maturity promotion;
- exceptions;
- breaking changes;
- deprecation;
- removal.
Each decision record includes:
- the decision and affected asset;
- the user, product, or system need;
- the rationale;
- supporting evidence;
- required decision gates and results;
- accountable owner;
- decision date;
- effective version or date, when applicable;
- review date or condition for reopening the decision.
The Product Manager maintains the decision log and ensures that decisions, owners, dependencies, and follow-up work remain visible. Each domain owner is accountable for the accuracy of the evidence and approval recorded for its area.
The Design Ops Lead owns one the company-visible PDS roadmap showing recently completed, current, and planned work. The Product Manager keeps it current based on backlog order, confirmed capacity, delivery status, and decisions made by the core working team.
The roadmap communicates direction and priority. It does not replace the backlog, delivery plan, capacity record, or decision record.
### 1.8 Developer contributions
Authorized the company developers may contribute to PDS through approved backlog work.
Contributions add delivery support while keeping PDS priorities, technical quality, and long-term ownership clear.
#### Contribution boundaries
- The Design Ops Lead decides which backlog items are available for contribution and retains ownership of backlog order and scope.
- The Product Manager coordinates contributor assignments, records allocations, tracks progress, and manages dependencies with the contributor’s home team.
- The Software Development Manager confirms any formal engineering allocation or delivery commitment made by PDP or another engineering team.
- The PDS Lead Maintainer defines the technical approach, repository standards, required reviewers, test evidence, merge criteria, and review sequence.
- Contributors may implement an approved backlog item, provide required evidence, and respond to review feedback.
- Contributors must not begin unplanned PDS work, change backlog priority, expand an item’s scope, classify work as Core, approve their own gates, merge their own change, publish a release, or create an ongoing PDS commitment.
- New ideas, defects, and proposed components must enter through PDS intake before implementation begins.
- PDS retains governance and long-term ownership of accepted contributions.
- Any support or maintenance expected from a contributing team must be agreed and recorded before the contribution is accepted.
Work completed outside an approved PDS backlog item may be reviewed as new intake. PDS is not required to accept, merge, release, or maintain it.