KTP Life App Teams and Ownership¶
Goal¶
Distribute meaningful app ownership across chapters while keeping one coherent product, avoiding single-person dependencies, and preserving National accountability for organization-wide data and releases.
Proposed operating model
These teams are a recommended structure, not current appointments. National Technology should ratify the model and publish the lead chapter, partner chapter, named role owners, and term for each team.
Ownership model¶
Each team should have:
- one lead chapter accountable for the team's semester outcomes;
- one partner chapter able to review and take over the work;
- a National sponsor who owns policy alignment and escalation;
- a primary and backup technical or product lead from different graduation timelines when possible;
- a documented backlog, runbook, and handoff; and
- access limited to the environments and data needed for that team's role.
Chapter ownership does not mean a chapter independently controls KTP-wide policy, member data, production credentials, or releases. Those decisions remain in the approved National governance path.
Recommended teams¶
| Team | Suggested staffing | Owns | Does not decide alone |
|---|---|---|---|
| Product Council | National sponsor, product lead, design lead, engineering lead, chapter representatives | Product purpose, roadmap, priority, success measures, cross-team coordination | Constitutional policy, new data uses, major spend, or production launch without required National approval |
| Identity and Access Management (IAM) | 2–4 engineers/security contributors | Authentication experience, roles implementation, session lifecycle, access reviews, authorization test coverage | Who is eligible for a role, new identity data collection, or exceptions to National policy |
| Data Platform and DBA | 2–4 backend/data contributors | Versioned schema, migrations, server authorization policies, backups, realtime, storage, functions, and calendar synchronization | New business use of member data, unrestricted exports, retention policy, or production changes without review |
| Full-Stack Mobile Team 1 — Member Experience | 3–6 full-stack mobile contributors, including a team lead and designated reviewer | Chapter selection, onboarding, home, network, profiles, and member-facing accessibility | IAM policy, database policy, or production release approval |
| Full-Stack Mobile Team 2 — Events and Engagement | 3–6 full-stack mobile contributors, including a team lead and designated reviewer | Calendar, events, RSVP, attendance, notifications, offline behavior, and related accessibility | Attendance policy, notification policy, backend authorization, or production release approval |
| Product and Design | Product manager, designer/researcher, accessibility partner | Research, workflows, information architecture, interface system, prototypes, usability, and acceptance criteria | Collecting new personal data or releasing a feature without engineering, privacy, and owner review |
| Platform and Release Engineering | 2–3 contributors | CI, EAS build pipelines, environment separation, versioning, TestFlight distribution, observability, and release mechanics | Store launch, signing-policy changes, or emergency production action outside the approved release process |
| Quality and Accessibility | 2–4 testers across chapters/devices | Regression plans, device matrix, beta acceptance, accessibility review, and release evidence | Product scope, but may block a release that fails an adopted gate |
| Chapter Success and Beta Operations | 2–4 chapter representatives | Tester onboarding, feedback triage, release communication, training, support themes, and adoption measurement | Access escalation, security incident decisions, or promises of unapproved features |
| Documentation and Developer Experience | 1–3 writers/developers | Architecture summaries, setup, contributor onboarding, release notes, runbooks, and documentation freshness | Publishing restricted operational or member information |
If capacity is limited, combine Platform with DBA and combine Quality with Chapter Success—but keep IAM review, product approval, and release approval separated from the person writing the feature whenever practical.
Chapter assignment template¶
| Team | Lead chapter | Partner chapter | National sponsor | Primary lead role | Backup lead role | Term | Capacity |
|---|---|---|---|---|---|---|---|
| Product Council | [Assign] | [Assign] | [Assign] | [Assign] | [Assign] | [Academic year] | [Hours/week] |
| IAM | [Assign] | [Assign] | [Assign] | [Assign] | [Assign] | [Academic year] | [Hours/week] |
| Data Platform and DBA | [Assign] | [Assign] | [Assign] | [Assign] | [Assign] | [Academic year] | [Hours/week] |
| Full-Stack Mobile Team 1 | [Assign] | [Assign] | [Assign] | [Assign] | [Assign] | [Semester/year] | [Hours/week] |
| Full-Stack Mobile Team 2 | [Assign] | [Assign] | [Assign] | [Assign] | [Assign] | [Semester/year] | [Hours/week] |
| Product and Design | [Assign] | [Assign] | [Assign] | [Assign] | [Assign] | [Semester/year] | [Hours/week] |
| Platform and Release | [Assign] | [Assign] | [Assign] | [Assign] | [Assign] | [Academic year] | [Hours/week] |
| Quality and Accessibility | [Assign] | [Assign] | [Assign] | [Assign] | [Assign] | [Semester/year] | [Hours/week] |
| Chapter Success and Beta Operations | [Assign] | [Assign] | [Assign] | [Assign] | [Assign] | [Semester/year] | [Hours/week] |
| Documentation and Developer Experience | [Assign] | [Assign] | [Assign] | [Assign] | [Assign] | [Semester/year] | [Hours/week] |
Keep personal contact details and private system membership in the restricted team directory. Public documentation may list approved names, role titles, and chapter assignments.
Decision rights¶
| Decision | Proposes | Reviews | Approves |
|---|---|---|---|
| Product priority | Product and Design or Chapter Success | Engineering and affected workflow owners | Product Council |
| Authentication or role implementation | IAM | DBA, QA, and affected product owner | Engineering lead under approved policy |
| New role eligibility or access policy | Product Council or National portfolio owner | IAM, privacy/data owner, and affected chapters | Required National authority |
| Database migration | DBA | Feature team and IAM/security reviewer | Authorized backend maintainer under change policy |
| New data field or use | Product owner | DBA, IAM/security, privacy owner, and affected chapters | Required National data-governance authority |
| TestFlight beta build | Feature team or Release Engineering | QA and owning teams | Release owner |
| Production/store release | Release Engineering | QA, product, support, data, and security owners | Named National release authority |
| Incident containment | Reporting team | IAM/DBA/Release as applicable | Incident owner under the restricted runbook |
| Public release note | Documentation or Release Engineering | Product and affected technical owners | Release owner or National Technology |
Team operating rhythm¶
- Weekly: Every delivery team reviews its backlog, blockers, review queue, incidents, and documentation changes.
- Weekly: IAM, DBA, and Product Leads hold their recurring coordination meetings described below.
- Biweekly: Cross-team architecture/product sync and dependency review.
- Per beta build: Release scope, QA evidence, privacy/access changes, known limitations, and rollback readiness.
- Monthly: Product Council review of outcomes, capacity, chapter feedback, and risk.
- Each semester: Access review, chapter assignment review, maintainer health, roadmap, and structured handoff.
Required weekly coordination meetings¶
These three meetings are the baseline governance cadence during active development and beta testing. Teams may add working sessions, but they should not replace these cross-team checkpoints.
| Meeting | Core attendees | Standard agenda | Required output |
|---|---|---|---|
| IAM Team weekly | IAM lead and contributors, DBA representative, affected mobile-team representative, National Technology sponsor | Authentication changes, role and access requests, authorization tests, access-review actions, security dependencies, and blockers | Decisions and owners recorded; access or policy changes routed for approval; blockers assigned a due date |
| DBA Team weekly | DBA/data lead and contributors, IAM representative, representatives from both mobile teams, Platform/Release when deployment is involved | Schema and migration queue, backend functions, authorization-policy dependencies, data quality, backup/restore work, calendar synchronization, and release readiness | Migration/review status recorded; owners and test evidence assigned; risky production changes escalated |
| Product Leads weekly | Product lead, Product/Design lead, leads from both full-stack mobile teams, Chapter Success/Beta Operations lead, and National sponsor | Member feedback, roadmap priority, acceptance criteria, cross-team dependencies, current beta outcomes, documentation, and decisions needed | Prioritized work and owning team confirmed; scope decisions recorded; chapter communication and success measures assigned |
Meeting notes should record decisions, owners, dates, and unresolved questions in the appropriate system. Public-safe product decisions may be summarized in release notes; member reports, security details, credentials, private links, and sensitive operational notes remain restricted.
Work intake¶
Member or chapter need
|
v
Chapter Success records outcome and impact
|
v
Product and Design clarifies workflow and acceptance criteria
|
v
Product Council assigns priority and owning team
|
v
Engineering implements with data/IAM review as needed
|
v
Quality and Accessibility validates the beta candidate
|
v
Release Engineering distributes; Documentation publishes safe changes
Handoff checklist¶
- [ ] Current objectives, backlog, open pull requests, and known limitations transferred
- [ ] Primary and backup maintainers introduced to dependent teams
- [ ] Architecture decisions and runbooks current
- [ ] Repository, service, environment, and on-call access reviewed without sharing credentials
- [ ] Production ownership remains with organization-controlled accounts and at least two current custodians
- [ ] TestFlight, store, backend, CI, and documentation responsibilities confirmed
- [ ] Stale access removed after the receiving team verifies continuity
Facts needed before activation¶
National Technology needs to provide the official team names, lead and partner chapters, sponsor roles, term length, expected hours, eligibility, selection method, meeting cadence, repository permissions, release authority, support/on-call expectation, and transition date.