Phase 6 complete track
Set Android technical direction with business judgment.
Principal engineering is not “more senior staff.” It is choosing the technical direction that best manages product risk, delivery economics, platform quality, and organizational constraints.
DirectionWhat technical path should the org take?
CostWhat must be funded, paused, or rejected?
RiskWhat can damage users, revenue, reliability, or hiring?
GovernanceHow will decisions stay coherent across teams?
Create a three-year mobile strategy
Mobile platform strategy Current state: - Android app is native Kotlin with mixed XML and Compose. - Build time and release confidence are slowing product delivery. - Teams duplicate networking, analytics, and design-system code. Target state: - Compose-first native Android. - Shared platform modules for design, network, auth, analytics, release flags. - Offline-first for user-critical workflows. Non-goals: - No full rewrite. - No cross-platform migration without a separate economic case. - No platform mandate without migration support.
Evaluate decisions economically
| Build | Use when the capability is product-differentiating or deeply integrated. |
|---|---|
| Buy | Use when the problem is commodity and vendor risk is acceptable. |
| Defer | Use when cost is real but the risk is not urgent. |
| Reject | Use when the technical appeal is high but product value is weak. |
Decision rule: Do not approve a migration unless it has at least one measurable payoff: - lower crash/ANR risk - faster delivery - lower maintenance cost - better compliance/security posture - improved hiring/onboarding leverage
Define architecture governance
- Architecture review is required for new platform primitives.
- Teams can make local feature decisions inside approved boundaries.
- Every shared library has an owner, support policy, and deprecation path.
- Exceptions are documented with expiration dates.
- Release quality gates are visible before code freeze.
- Security and privacy reviews happen before sensitive data is collected.
Write an executive-readable decision memo
Subject: Fund Android platform reliability work for H1 Recommendation: - Fund a two-engineer platform lane for six months. Why now: - Release confidence is dropping and duplicated mobile infrastructure is slowing feature teams. Expected payoff: - Reduce repeated implementation work. - Improve crash and ANR response. - Shorten onboarding for new Android engineers. Trade-off: - Two engineers will deliver fewer product features in the short term. Risk if declined: - Teams continue local solutions, making future migration more expensive.
Maintain a principal-level risk register
| Risk | Signal | Response |
|---|---|---|
| Platform dependency decay | Old libraries block SDK upgrades | Quarterly dependency health review |
| Release fragility | Hotfix rate increases | Staged rollout and rollback drills |
| Accessibility debt | Support complaints and failed audits | Accessibility gate for core flows |
| Architecture drift | Teams duplicate platform code | Owner review and documented exceptions |
Principal-level completion gate
- You can explain technical strategy to engineering and non-engineering leaders.
- You can quantify why a migration is worth funding or not worth funding.
- You can define governance without blocking every local decision.
- You can identify risks before they become incidents.
- You can create successors and owners so the platform does not depend on you.