A practical org design model for engineering teams delivering across automotive, ERP, retail, and healthcare domains simultaneously.
Engineering org design is the most under-discussed lever in delivery performance. Teams obsess about Scrum vs. Kanban while the actual bottleneck is that the team that owns billing also owns notifications, neither domain gets enough attention, and every cross-team change requires three sync meetings. The org chart is the architecture.
This post is the model we've used across automotive, ERP, retail, and healthcare engagements when an engineering org has outgrown its initial structure — typically around 30 engineers, often again around 80.
The topology
Three team types: **domain squads** (own a business outcome end-to-end), **platform enablement** (build the paved road), **architecture council** (decide cross-cutting concerns). That's it. No matrix, no chapters, no guilds in the formal org — those can exist informally if people want them.
Domain squads — the unit of value
A domain squad has 5–9 engineers, a product manager, a designer (or fractional design), and owns one business outcome end-to-end: customer onboarding, lab QC, supplier ingestion. They own their services in production, on-call rotation, customer escalations for their domain.
Critical rules:
- One squad, one outcome. "Onboarding and billing" is two squads.
- Squads are stable. People don't get pulled to other squads for short-term staffing.
- Squad KPIs are business outcomes (onboarding completion rate, lab turnaround time), not engineering metrics (velocity, deploy frequency).
Platform enablement — measured by enablement, not tickets
Platform team builds the internal developer platform: CI pipelines, deployment templates, service mesh, observability defaults, auth library, data ingestion patterns. Their job is to make the right thing the easy thing for domain squads.
They are measured by:
- Adoption rate of platform primitives across squads (target: >80% on new services).
- Lead time for a new service from idea to first production deploy (target: <2 days).
- Domain squad satisfaction (quarterly survey — honest, anonymous).
They are explicitly *not* measured by ticket throughput. A platform team measured by tickets becomes a ticket-shop and domain squads stop using them.
Architecture council — decisions, not designs
6–8 senior engineers from across domains plus the head of platform. Meets weekly for 60 minutes. Decides cross-cutting concerns: when to introduce a new database technology, how services authenticate to each other, what observability standard to adopt.
Output is ADRs, not slide decks. Each decision has an owner who shepherds it to adoption.
Anti-pattern: the council designs systems. That's the squad's job. The council decides constraints; squads design within them.
Decision flow
For 90% of decisions, the squad decides. For decisions that affect more than one squad (shared library, contract change, infrastructure pattern), an RFC goes to the architecture council — published, 5-business-day comment window, council decides if consensus doesn't emerge.
For decisions that affect the business (pricing model, customer-facing SLA), product + engineering leadership decides together.
Leadership cadence — separate strategy from execution
Two rhythms:
- Weekly execution sync (60 minutes, all squad leads + platform lead + engineering manager): blockers, decisions needed, cross-team dependencies. Action-oriented. No status theatre.
- Monthly strategy review (2 hours, engineering leadership only): are we investing in the right domains, what should we stop doing, what's the next 6-month bet.
Mixing these meetings produces neither good execution nor good strategy.
When to reorg
Reorg when the value stream has clearly moved — not when individual managers want bigger teams or executives want a new org chart. Signals: a squad's outcome has become two distinct outcomes, two squads keep colliding on the same code path, a domain that was peripheral is now strategic. Reorg quarterly at most.
Closing
Engineering org design is architecture. Pick stable domain squads, build a paved road around them, decide cross-cutting concerns deliberately, and the system stays coherent as it grows. Skip this and no agile framework will save you.
