SortedQueue.
Phase 5 complete track

Lead Android architecture across teams.

Staff work reduces risk and increases leverage across multiple teams. Your deliverables are not only code: migration plans, ADRs, platform contracts, observability, and adoption systems matter.

4teams affected
12week migration
0blocked releases target
Step 1

Write a migration plan that keeps shipping possible

Migration: XML screens to Compose

Goal:
- Move high-change screens to Compose without blocking feature work.

Sequence:
1. Add Compose to existing app shell.
2. Build shared design primitives.
3. Convert one low-risk screen.
4. Measure crash, startup, and developer feedback.
5. Convert high-change screens by product area.
6. Remove obsolete XML utilities after adoption.

Rollback:
- Keep old screen route available behind a flag until parity is verified.
Step 2

Use ADRs for decisions that outlive one PR

ADR-014: Use Compose for new feature screens

Context:
- New features need faster iteration and shared UI consistency.

Options:
- Continue XML
- Compose only for new screens
- Rewrite all screens immediately

Decision:
- Compose for new feature screens; migrate old screens incrementally.

Consequences:
- Need training and review checklist.
- Mixed UI stack remains for 6-12 months.
- Design system must support Compose first.
Step 3

Define platform contracts

NetworkingTyped errors, retry policy, auth injection, observability hooks.
Design systemApproved components, accessibility defaults, theming rules.
AnalyticsEvent naming, required properties, privacy review.
ReleaseFeature flags, staged rollout, rollback owner, release evidence.
Step 4

Make observability actionable

Crash-free sessionsRelease health and regression signal.
ANR rateMain-thread and responsiveness risk.
Startup timeUser-perceived launch quality.
AdoptionHow many teams use the platform correctly.

Do not create dashboards nobody acts on. Every metric needs an owner, threshold, and response.

Step 5

Plan cross-team adoption

  • Identify first adopter teams and their constraints.
  • Publish migration examples before enforcing policy.
  • Run office hours for the first two release cycles.
  • Track blockers publicly.
  • Define the date when old patterns become unsupported.
  • Document exceptions and who can approve them.
Step 6

Staff-level review criteria

  • The plan reduces risk for more than one team.
  • Migration can pause without leaving the app broken.
  • Ownership is clear after the original author moves on.
  • Metrics distinguish adoption, quality, and product impact.
  • Decision records explain rejected alternatives.
Continue to Phase 6Phase overview