Tension between current collaborative delivery process and the way AO is working: component teams (PDTs) vs. feature teams (pairs/small groups). Some concern if EMs leave the Feature 3-in-the-Box, who provides the "project manager" glue? And what does the PDT even do now?
The PDT becomes a stable home team — a federation of feature pairs that share a component domain (e.g., Controller). The EM leads the PDT but does not own feature delivery. Feature pairs own their own delivery. The EM provides the connective tissue between features and across teams.
By being somewhat stable, we get the benefits of the forming, storming, norming, performing cycle that happens over time, becoming comfortable working with each other, etc.
Release Coordinator is a separate concept — That is about coordination across the org for a specific release, being accountable to phases and milestones. These releases could span 1-to-many PDTs.
graph TB
subgraph org["Organization"]
RC["🔄 Release Coordinator<br/><i>Cross-PDT release coordination</i><br/><i>Separate rotation, not EM-owned</i>"]
end
subgraph pdt["PDT: Controller (Stable Home Team)"]
EM["👤 Engineering Manager<br/>───────────────<br/>• Staffs & organizes feature pairs<br/>• Coaches & supports engineers<br/>• Coordinates across features<br/>• Drives swarming when needed<br/>• Handles escalations & cross-team needs<br/>• Accountable for PDT health, not feature delivery"]
subgraph fp1["Feature Pair A: Workflow Orchestration"]
FL1["⭐ Feature Lead<br/><i>Owns delivery + project mgmt</i>"]
DEV1["👩💻 Engineer"]
PM1["📋 PM"]
ARCH1["🏗️ Architect Buddy"]
end
subgraph fp2["Feature Pair B: Metrics & Analytics"]
FL2["⭐ Feature Lead<br/><i>Owns delivery + project mgmt</i>"]
DEV2["👩💻 Engineer"]
PM2["📋 PM"]
ARCH2["🏗️ Architect Buddy"]
end
subgraph fp3["Feature Pair C: Installer Integration"]
FL3["⭐ Feature Lead<br/><i>Owns delivery + project mgmt</i>"]
DEV3["👩💻 Engineer"]
PM3["📋 PM"]
ARCH3["🏗️ Architect Buddy"]
end
SUP["🔧 Component Support<br/><i>Escalations route to PDT<br/>EM triages & assigns</i>"]
end
EM -->|"staffs & coaches"| fp1
EM -->|"staffs & coaches"| fp2
EM -->|"staffs & coaches"| fp3
EM -->|"triages"| SUP
RC -.->|"release-level<br/>coordination"| pdt
| Aspect | Before | After |
|---|---|---|
| EM in Feature 3IB | EM is part of the 3-in-the-box for each feature | EM is not in the Feature 3IB |
| Feature 3IB | PM + Architect + EM | PM + Architect Buddy + Feature Lead |
| Who "project manages" the feature? | EM | Feature Lead (senior engineer in the pair) |
| PDT purpose | Component team that picks stories from a backlog | Stable home team; a federation of feature pairs sharing a domain |
| EM accountability | Feature delivery | PDT health, staffing, coaching, cross-feature coordination |
| Release Coordinator | Separate rotation; coordinates across PDTs for a release | Separate rotation; coordinates across PDTs for a release |
mindmap
root((EM Role))
Staffing & Organization
Form feature pairs
Balance workload across pairs
Adjust pairs as priorities shift
Coaching & Support
Engineer growth & development
Remove impediments
Support feature leads in PM skills
Cross-Feature Coordination
Identify dependencies between features
Facilitate swarming when a pair is stuck
Surface risks across the PDT portfolio
Escalation & Support
Triage component escalations
Route support requests to right pair/person
Represent PDT in cross-team forums
NOT Responsible For
Day-to-day feature delivery
Being in the Feature 3IB
Acting as project manager for a feature
Release coordination across PDTs
The Feature Lead (senior engineer in the pair) picks up the delivery accountability that the EM previously held within a feature:
- Owns delivery milestones — keeps the feature on track, calls out date risks early
- Posts daily async updates — the human perspective on where the feature stands
- Drives the pair — makes day-to-day architectural decisions within feature scope
- Coordinates with PM and Architect Buddy — the new Feature 3IB
- Manages the feature backlog — stories, bugs, prioritization within the feature
Release Coordinator is a rotating responsibility:
- Coordinates across 1 to many PDTs for a specific release
- Runs cross-feature alignment syncs (e.g., Like the monday morning sync per Robin's proposal)
- Tracks release-level milestones and readiness
- Their management of PDT is a separate concern.
| Concern | Who Raised | How This Addresses It |
|---|---|---|
| "We no longer have someone acting as project manager for the feature" | Robin | Feature Lead explicitly picks up this role within the pair |
| "Does the EM role shift to include Release Coordinator?" | Aaron | No — Release Coordinator is a separate rotation. EM provides glue within the PDT, RC provides glue across PDTs |
| "Is a PDT still a thing?" | Naveen | Yes — it's the stable home team. Engineers belong to a PDT, get coached by an EM, and deploy into feature pairs |
| "Conflating component teams and feature teams" | Robin | PDT = stable identity/home. Feature pair = delivery unit. These are different layers |
| "Who handles escalations if there's no Controller PDT?" | John | PDT still owns the component. EM triages escalations and routes to the right person |
| "PDTs will have to change how we work... design things to try and learn" | Aaron | This is one such design — explicitly experimental, to be retro'd |
- Can a feature pair span PDTs? (e.g., an engineer from Controller PDT paired with one from EDA PDT for a cross-cutting feature)
- How does the EM handle "coaching Feature Leads in PM skills"? — This is new muscle for senior engineers
- What's the minimum viable ceremony set for the PDT as a home team? (Weekly retro? Monthly team health check?)
- How do we handle the social/identity concern Naveen raised? — Engineers need to feel they belong somewhere