Team Capacity Model
:::info Source
Sourced from docs/roadmap/team-capacity-model.md in the documentation repo.
:::
Execution-layer companion to ROADMAP.md.
Defines team composition per milestone, critical-path teams, parallelizable workstreams, low-load redeployment, and the recommended allocation plan. Aligns hiring + program management with the critical path to revenue (M+9) and GA (M+15).
1. Starting Assumptions
- Starting headcount: 26 (M0).
- Target headcount: 62 (M5).
- Team topology: stream-aligned teams + one enabling team (Platform) + one complicated-subsystem team (AI Services).
- Velocity: trunk-based development; feature flags per tenant; 2-week sprints; pair + review culture.
- Each service has a named owner from M0; one engineer may own 2–3 services initially.
- Design-partner feedback loop weekly from M1.
2. Headcount Table
| Team | Role mix | M0 | M1 | M2 | M3 | M4 | M5 |
|---|---|---|---|---|---|---|---|
| Platform | eng, SRE, security eng | 6 | 5 | 5 | 5 | 5 | 6 |
| Learner (delivery/progress/player) | eng, FE, QA | 2 | 6 | 4 | 4 | 4 | 5 |
| Authoring | eng, FE | 1 | 2 | 6 | 5 | 7 | 5 |
| Commerce (marketplace/billing) | eng | 0 | 1 | 5 | 4 | 4 | 5 |
| Enterprise (assignment/certification/SSO) | eng | 0 | 0 | 1 | 6 | 4 | 4 |
| Content-Packaging | eng | 1 | 3 | 3 | 4 | 3 | 3 |
| Data/AI/Insight | ML eng, data eng, FE | 2 | 2 | 3 | 5 | 6 | 7 |
| Media | eng | 1 | 2 | 3 | 3 | 5 | 5 |
| Security + SRE | security, SRE, compliance | 3 | 3 | 3 | 4 | 5 | 6 |
| Design + UX | designers, research | 3 | 3 | 3 | 3 | 3 | 3 |
| PM + Program | PM, program mgr | 2 | 2 | 3 | 4 | 4 | 4 |
| DevEx + Docs | eng, tech writer | 2 | 2 | 2 | 2 | 3 | 3 |
| Support + Solutions | CSM, SE | 0 | 1 | 2 | 3 | 4 | 4 |
| Total | 26 | 32 | 40 | 48 | 55 | 62 |
3. Role Mix Within Teams (indicative)
| Team | Senior eng | Eng | SRE/security | FE | QA | ML/data | Designer | PM |
|---|---|---|---|---|---|---|---|---|
| Platform | 2 | 3 | 1 (SRE) | — | shared | — | — | shared |
| Learner | 1 | 3 | — | 1 | 1 | — | — | — |
| Authoring | 1 | 3 | — | 2 | 1 | — | — | — |
| Commerce | 1 | 3 | — | 1 | — | — | — | — |
| Enterprise | 1 | 3 | — | 1 | 1 | — | — | — |
| Content-Packaging | 1 | 2 | — | — | — | — | — | — |
| Data/AI/Insight | 1 | 2 | — | 1 | — | 2 | — | — |
| Media | 1 | 2 | — | — | — | — | — | — |
| Security + SRE | 1 | 2 (sec) | 2 (SRE) | — | — | — | — | — |
| Design + UX | — | — | — | — | — | — | 3 | — |
| PM + Program | — | — | — | — | — | — | — | 2–4 |
4. Critical-Path Teams Per Milestone
The team whose delivery gates the milestone. Missing their dates slips the milestone.
| Milestone | Critical-path team(s) | Reason |
|---|---|---|
| M0 | Platform | Foundations — tenant iso, events, AI gateway, sync |
| M1 | Learner + Content-Packaging + AI Services | Player + offline bundles + AI tutor |
| M2 | Authoring + Commerce | Authoring MVP + marketplace + billing saga |
| M3 | Enterprise + Content-Packaging | Assignments + SAML + SCORM 2004/xAPI |
| M4 | Authoring + Sync | Live collab + offline authoring + conflict UI |
| M5 | Data/AI/Insight + SRE + Mobile Platform | AI admin v2 + multi-region + mobile native |
5. Parallel Workstreams
All streams run concurrently from M0 with named owners to avoid a single critical-path bottleneck. See ROADMAP.md §7 for the summary Gantt per stream.
| Stream | Starts | Peak load |
|---|---|---|
| A Platform & Foundation | M0 | M0 (6), M3 (5 residency prep), M5 (6 residency + HIPAA) |
| B Learner | M0 (design skeleton) | M1 (6) |
| C Authoring | M0 (block schema RFC) | M4 (7) |
| D Commerce | M0 (ACL design) | M2 (5), M5 (5) |
| E Enterprise | M1 (SSO + SOC 2 prep) | M3 (6) |
| F Data/AI/Insight | M0 | M5 (7) |
| G Media | M0 | M4 (5), M5 (5) |
| H Security + SRE | M0 | M5 (6) |
| I Design + UX | M0 | flat (3) |
| J PM + Program | M0 | grows with scope |
| K Mobile Platform | M3 | M5 (5) |
| L Developer Experience | M0 | M5 (3) |
6. Idle / Low-Load Periods and Redeployment
| Team | Low-load window | Redeployment |
|---|---|---|
| Enterprise | M0–M1 | (a) SSO prototyping against IdP emulators; (b) SOC 2 documentation; (c) RRULE fixture corpus authoring; (d) compliance architecture workshops with Legal |
| Commerce | M0 | (a) PSP + tax vendor evaluation; (b) billing ACL design; (c) refund-policy authoring with Legal; (d) SCORM 1.2 customer-LMS interoperability research |
| Authoring | M1 | (a) Block runtime (learner side) in content-service; (b) block schema freeze; (c) AI prompt eval corpus; (d) author research with design partners |
| Data/AI/Insight | M0–M1 | (a) prompt registry + eval harness; (b) vector index partitioning design; (c) RAG corpus strategy; (d) provenance + audit UI specs |
| Mobile Platform | M0–M2 | (a) Capacitor-wrapped PWA parity tests; (b) offline bundle decryption on iOS/Android; (c) biometric stack integration design |
7. Hiring Plan (rolling)
| Milestone | New hires (cumulative total) | Primary roles |
|---|---|---|
| M0 → M1 | +6 (26→32) | Learner (+4), Authoring (+1), Support (+1) |
| M1 → M2 | +8 (32→40) | Commerce (+4), Authoring (+4), PM (+1), Support (+1), Data (+1), offset by reshuffles |
| M2 → M3 | +8 (40→48) | Enterprise (+5), Data (+2), SRE (+1) |
| M3 → M4 | +7 (48→55) | Authoring (+2), Data (+1), Media (+2), SRE (+1), DevEx (+1), Support (+1) |
| M4 → M5 | +7 (55→62) | Data (+1), Mobile (+3), SRE (+1), Commerce (+1), Support (+1) — some mobility across teams |
Notes:
- Hiring ramps ahead of peak by ≥ 1 milestone to allow onboarding.
- Senior/eng ratio targets 1:3 in each team.
- Every new service owner rotates through a 2-week platform onboarding (tenant isolation, AI governance, sync protocol, testing pyramid).
8. Velocity Assumptions
| Factor | Value |
|---|---|
| Sprint length | 2 weeks |
| Sprints per milestone | 6 |
| Velocity per eng (mature team) | 8 pts / sprint average |
| Velocity per eng (new team, first 2 sprints) | 4 pts / sprint |
| Onboarding cost (new hire) | 50 % capacity first sprint, 75 % second, 100 % from third |
| Meetings/ceremonies overhead | 15 % |
| On-call rotation overhead | 10 % of SRE + senior eng capacity |
9. Load Heatmap (visual)
Team ↓ / Milestone → M0 M1 M2 M3 M4 M5
Platform ███ ██ ██ ██ ██ ██▌
Learner █ ███ ██ ██ ██ ██▌
Authoring ▌ █ ███ ██▌ ███ ██▌
Commerce – ▌ ██▌ ██ ██ ██▌
Enterprise – – ▌ ███ ██ ██
Content-Packaging ▌ ██ ██ ██ ██ ██
Data/AI/Insight █ █ █▌ ██▌ ███ ███
Media ▌ █ █▌ █▌ ██ ██
Security + SRE █▌ █▌ █▌ ██ ██▌ ███
Design + UX █▌ █▌ █▌ █▌ █▌ █▌
PM + Program █ █ █▌ ██ ██ ██
DevEx + Docs █ █ █ █ █▌ █▌
Support + Solutions – ▌ █ █▌ ██ ██
█ = high load (target 100 %), ▌ = ~½ block of load, – = not staffed yet.
10. Allocation Plan — Priority Rules
When hiring lags or unexpected churn occurs, allocate per this priority:
- Protect Platform at M0; a weak platform causes permanent rework across 19 services.
- Protect Learner + Content-Packaging + AI Services at M1; without moat features we have no differentiator.
- Protect Commerce at M2; no revenue = no runway.
- Protect Enterprise at M3; lost enterprise deals = lost quarter.
- Protect SRE + Security across every milestone; trust incidents erase product progress.
- De-prioritize Mobile Platform polish first; PWA covers acceptable mobile UX until M4/M5.
- De-prioritize Developer Experience second; external SDK can wait.
11. Governance
- Quarterly capacity review aligned with milestone exits.
- Owner of record per service + per slice; dependencies negotiated in architecture sync.
- Bench + on-call rotations published; nobody carries on-call alone.
- Onboarding playbook owned by DevEx.
- Capacity reported to leadership with burn-down vs plan + forecast.