A mobility platform's teams are organised by technical layer - mobile, backend, data, infrastructure. Why does that slow delivery, and what is the alternative?
Show the full answer Hide the answer
Why layer-aligned teams slow delivery
Every customer-facing change crosses every layer. A new pricing feature needs mobile, backend, data and infrastructure work, which means four backlogs, four prioritisation processes, four sets of dependencies and a coordination overhead paid on every feature.
The overhead is structural. No amount of process improvement removes it, and the usual response — adding a programme manager and a synchronised release train — institutionalises it.
The alternative
Stream-aligned teams, each owning a customer-facing flow end to end: rider experience, driver experience, pricing and matching, payments. Each has the skills to deliver a change without external dependency.
Supported by:
- Platform teams providing self-service capabilities that stream-aligned teams consume without needing to talk to them — the interaction is a product, not a ticket queue.
- Enabling teams that temporarily help a stream-aligned team acquire a capability, then leave.
- Complicated-subsystem teams for genuinely specialist components — a matching engine, a pricing model — where the expertise cannot reasonably be distributed.
What it costs
Duplication. Four stream-aligned teams will each solve some problems independently and inconsistently, and some of that duplication is waste. The trade is deliberate: coordination cost is paid on every feature, duplication cost is paid once per instance, and for a fast-moving business the first dominates.
The mitigation is not to centralise but for platform teams to make the shared solution more attractive than the bespoke one.
The honest constraint
Specialisation is real. Not every stream-aligned team can have deep mobile, data and infrastructure expertise, and pretending otherwise produces teams that are shallow everywhere.
The resolution is that the platform absorbs the depth — the stream-aligned team uses infrastructure without being expert in it — and that the genuinely specialist components live in their own teams with a clear interface. Cognitive load is the limiting resource, and team boundaries should be drawn to keep it within what a team can hold.