Mobile architecture is often presented as a diagram: layers, arrows and a preferred state-management pattern. The diagram can be correct and the decision can still fail.
A staff engineer has to ask a wider question: what conditions must exist for this architecture to remain useful after the design meeting? That moves the work from component structure into ownership, migration, feedback and delivery.
Start with the pressure, not the pattern
Architecture is a response to pressure. A team may need to isolate a volatile API, make parallel feature delivery safer, reduce startup work or establish a path away from a legacy framework. “Adopt Clean Architecture” is not a pressure; it is one possible response.
Naming the pressure changes the conversation. It gives product and engineering a shared outcome, and it creates a way to decide whether the intervention worked. Module count is not an outcome. Faster startup, safer releases and shorter time to understand a change are.
Design the migration as part of the system
On an established Android product, the migration plan is architecture. A target design that assumes a rewrite or a long feature freeze is incomplete.
I prefer a sequence built around safe seams:
- Find a boundary where behaviour is already reasonably coherent.
- Describe the contract before changing the implementation.
- Move one vertical path through the new boundary.
- Measure runtime behaviour and the team’s ability to work with it.
- Expand only after the path proves cheaper to own.
This approach supported modernisation work in streaming and news products where delivery could not stop. It also exposes a weak abstraction early, before it is copied across the codebase.
Ownership is an architectural property
A module boundary does not create ownership by itself. People need to know who can change the contract, how compatibility is handled and where a cross-cutting decision is made.
The most effective architecture documentation is often a small set of operational rules: dependency direction, state ownership, release expectations and examples of where new code belongs. These rules make review faster and give engineers confidence to make local decisions.
That is also why mentoring and code review are not separate from platform work. They are how an architectural decision becomes a team capability rather than the knowledge of one author.
Treat trade-offs as a deliverable
Senior engineers can identify trade-offs. Staff engineers make those trade-offs legible to the organisation.
A useful design note states what is being optimised, which costs are accepted and what evidence would cause the decision to change. It distinguishes a constraint from a preference. This does not need to be a long document; it needs to make disagreement productive.
The leadership boundary
Architecture ends and engineering leadership begins at the point where a technically sound idea needs coordinated behaviour from multiple people and systems.
The staff-level responsibility is not to make every decision. It is to create the conditions for good decisions to be made consistently: visible constraints, clear interfaces, useful feedback and an adoption path the team can actually follow.
The diagram still matters. The real work is making it true.