Tried to iterate with the conversation in the wg-ansible-nexus-leads thread
graph TB
subgraph old["OLD: Component/PDT Model (since 2.5)"]
O1["Sequential refinement gating"]
O2["Component-aligned PDTs"]
O3["Sprint-based cadence"]
O4["EM in Feature 3IB"]
O5["Shared team ownership of sprint goals"]
O6["Established escalation/CVE routing"]
end
old ---|"Transition"| new
subgraph new["NEW: Lean Feature Pair Model"]
N1["Rolling refinement, code early"]
N2["Feature-aligned pairs"]
N3["Continuous flow / Kanban"]
N4["EM out of Feature 3IB"]
N5["Pair owns the feature end-to-end"]
N6["Higher velocity, smaller scope"]
end
mindmap
root((Synthesis))
Keep from Old
Operational excellence
CVE/escalation handling across Sankey priorities
Established triage and routing
Component ownership for supportability
Predictability
Built trust with BU counterparts
Sprint commitments drove accountability
Team identity and morale
Shared sprint goals created positive feedback loops
Swarming to close carryover built camaraderie
Engineers had a home and a mission
Customer sentiment
Year-over-year improvement at Summit
Kevin confirmed this from his perspective
Keep from New
Velocity
Code is cheap, start early
Demos and clickable prototypes beat bullet points
Features close faster with lean teams
Lean delivery
2-person pairs with clear ownership
Less overhead, less bike-shedding
Estimates reflect actual work, not process bloat
Rolling refinement
No waiting for all epics to decompose
SDP gates design exit, not all activity
Full-stack ownership
Pairs own backend, UI, testing, docs
No handoffs to cleanup crews
mindmap
root((Fix))
Fix from Old
Speed
Time to production code was glacial
All refinement had to complete before coding
Estimates wildly inflated for consensus driving
Scaling
Didn't handle simultaneous priorities well
Too much focus on component team
Hard to staff cross-cutting features
Overhead
Too many sequential gates
Architecture calls gated all story creation
Process optimized for risk avoidance over delivery
Fix from New
Siloing
Feature engineers only know their own ANSTRAT
No visibility into broader portfolio
Don't know where they could help others
Burnout risk
Higher velocity without team support structure
No shared mission / positive feedback loop
Individual accountability without team backing
Project management gap
Robin: "We no longer have someone acting as PM"
Who tracks milestones and date risks?
Lead devs may resist or struggle with PM duties
Terminology confusion
Robin: Feature Lead vs Feature Architect vs Lead Engineer
Feature Architect has existing meaning in collab delivery
Need a glossary everyone agrees on
graph TB
T1["WHO PROJECT-MANAGES\nTHE FEATURE?"]
T1a["Robin: Lead devs go heads-down,\ndon't track parallelization or dates.\nSaw this fail in Cloud."]
T1b["Aaron: Lead dev does PM if features\nare small enough. Size matters."]
T1c["Robin: Consider giving PM role\nto the Pair Engineer instead."]
T1 --- T1a
T1 --- T1b
T1 --- T1c
graph TB
T2["DOES THE EM STAY\nOUT OF FEATURES?"]
T2a["Robin: Are we sure? EMs had\n5 features in old model too."]
T2b["Aaron: EM can't manage delivery\nacross 5 teams in 5 areas.\nBut not sure of anything yet."]
T2c["John: EM coaches and coordinates,\ndoesn't own delivery. Feature team\nowns accountability."]
T2 --- T2a
T2 --- T2b
T2 --- T2c
graph TB
T3["WHAT IS THE PDT NOW?"]
T3a["Naveen: Is a PDT still a thing?\nIs that identity important?"]
T3b["Aaron: PDTs will still exist.\nIsolation and lack of team is\nalready hurting us."]
T3c["Matt: Teams have to look different.\nConway's law. Are we doing teams\nthis way because it works or\nbecause we always have?"]
T3 --- T3a
T3 --- T3b
T3 --- T3c
graph TB
T4["SWARMING IS AN\nANTI-PATTERN NOW"]
T4a["Matt: Only 1 person writes code\nwith an LLM at a time.\nSwarming won't work the same way."]
T4b["John: Agreed, retracting\nthe swarming point."]
T4c["Matt: Far fewer people can and\nshould write code on an ANSTRAT.\nWe need independent pairs."]
T4 --- T4a
T4 --- T4b
T4 --- T4c
graph TB
T5["ARCHITECT ROLE CLARITY"]
T5a["Robin: Feature Architect = Lead Dev.\nAlways has been. They write the SDP."]
T5b["Robin: Architect Buddy = Outcome Architect.\nLightweight oversight, not feature design."]
T5c["Naveen: We're mixing terms.\nNeed a concrete example with\nreal people and titles."]
T5 --- T5a
T5 --- T5b
T5 --- T5c
The architects (Robin, Naveen) raised specific structural concerns. Here's how we should think about each:
| Concern | Raised By | Proposed Resolution |
|---|---|---|
| "Feature Lead" term is nebulous and overloaded | Robin | Adopt Robin's taxonomy: Feature Architect (lead dev, writes SDP, owns design+delivery), Architect Buddy (outcome architect, cross-feature oversight). Drop "Feature Lead" to avoid confusion. |
| Feature Architect shouldn't also be project manager | Robin | Split PM duties: Feature Architect owns technical delivery. PM owns milestone tracking and status. If PM capacity is limited, the Pair Engineer could pick up coordination (Robin's suggestion). |
| Architect Buddy scope is well-defined already | Robin | Architect Buddy = Outcome Architect role as already documented. No change needed — just consistent naming. |
| "Staffs & organizes feature pairs" can't be one EM | Naveen | Collaborative staffing: EM proposes based on their team's capacity/skills, but assignment is agreed across the leads group for cross-team features. |
| Need a concrete example with real names/titles | Naveen | Action item: Map a current ANSTRAT (e.g., ANSTRAT-1972) with actual people in each role. |
| Feature-to-feature coordination is the real complexity | Matt | This is the EM's primary value-add in the new model: cross-feature awareness, dependency tracking, portfolio-level risk surfacing. Not feature delivery, but feature coordination. |
graph TB
subgraph portfolio["Portfolio Level"]
RC["Release Coordinator\n(rotation, cross-PDT)"]
LEADS["Leads Group\n(collaborative staffing decisions)"]
end
subgraph pdt["PDT: Home Team"]
EM["Engineering Manager\n─────────────────\nCross-feature coordination\nDependency tracking\nCoaching and growth\nEscalation triage\nCapacity and staffing proposals\nPortfolio-level risk surfacing"]
subgraph feat1["Feature: ANSTRAT-XXXX"]
FA1["Feature Architect\n(Lead Dev — writes SDP,\nowns design + delivery)"]
PE1["Pair Engineer\n(could take on coordination\nduties per Robin's suggestion)"]
PM1["PM\n(milestone tracking,\nstatus, stakeholders)"]
AB1["Architect Buddy\n(Outcome Architect —\ncross-feature oversight)"]
end
subgraph feat2["Feature: ANSTRAT-YYYY"]
FA2["Feature Architect"]
PE2["Pair Engineer"]
PM2["PM"]
AB2["Architect Buddy"]
end
subgraph guardian["Guardian / Interrupt"]
G1["Engineer(s) on rotation\nCVEs, escalations, tech debt"]
end
end
EM -->|"coaches, coordinates"| feat1
EM -->|"coaches, coordinates"| feat2
EM -->|"triages to"| guardian
LEADS -->|"collaborative\nstaffing"| pdt
RC -.->|"release-level\ncoordination"| portfolio
AB1 -.->|"cross-feature\noversight"| AB2
| Aspect | Earlier Gist | Updated Based on Thread |
|---|---|---|
| Terminology | "Feature Lead" | Feature Architect (Robin's existing taxonomy) |
| Project management | Feature Lead does it all | Split: PM tracks milestones, Feature Architect owns technical delivery. Pair Engineer as potential coordinator. |
| Swarming | EM facilitates swarming | Removed. Anti-pattern with LLM-driven development (Matt). Only 1 person codes at a time. |
| Staffing | EM staffs unilaterally | Collaborative across leads group (Naveen). EM proposes, group agrees. |
| PDT identity | Tied to component name | Decoupled from component, but component ownership remains for support routing (Aaron). |
- Feature sizing target — Aaron proposed 6 weeks or less. Do we align on this? What breaks if features are bigger?
- PM capacity — If PMs are spread across multiple features, who actually tracks day-to-day milestones? The Pair Engineer?
- Concrete example — Map ANSTRAT-1972 (or another live feature) with real people in each role (Naveen's ask).
- Guardian/interrupt model — How do we handle CVEs and escalations without a dedicated component team? Rotation within the PDT?
- LLM-era development patterns — Matt's point about only one person coding at a time has implications for pair structure. Are pairs actually taking turns, or is one person coding while the other reviews/tests/coordinates?
- De-siloing mechanism — How do feature pairs stay aware of the broader portfolio? Weekly cross-feature sync? Dashboard? EM-facilitated?
- Team identity without sprints — If we move to continuous flow, what replaces the shared sprint goal as a bonding mechanism?
- Experienced + junior pairing — Naveen's question: can less experienced engineers keep up with LLM-accelerated seniors? Do they flip roles (junior codes, senior reviews)?