organisation design
Your team structure is part of your architecture
We like to pretend the architecture lives in the repository and the organisation lives in the HR system. It doesn't. Team boundaries shape who owns what, who talks to whom, which technical decisions get made quickly and which rot — and over time, they shape the system itself.
A problem that ignored the org chart
At Sheypoor, the traffic decline that dominated my arrival didn't respect team boundaries. The investigation crossed SEO (frontend), deep links (backend services), push notifications (mobile), and release capability (everywhere). The org chart said "mobile", "web", "backend". The problem refused to.
What appeared to be a business conversion problem required investigation across multiple technical boundaries — and each boundary it crossed was a place where ownership was ambiguous, the investigation slowed down.
Boundaries become architecture
Conway's law is usually quoted as a joke. It's actually an instruction. Teams don't just maintain architecture; the way teams are structured often shapes it. Interfaces harden where organisations harden. Systems grow complicated where communication is expensive. Ownership blurs where team boundaries don't match subsystem boundaries.
The reverse is also true, and it's the reason organisation design is engineering work: when we changed team structures so ownership matched the problems we needed solved, technical decisions got faster and better. Not because anyone wrote more code — because the people closest to each problem finally had the authority and information to decide.
What changed at Sheypoor
The organisational changes we made were, in retrospect, architecture changes:
- Team structure changes, so ownership matched the problems rather than history.
- Hiring and, where necessary, replacing people to address current problems rather than inherited ones.
- Clearer ownership across systems and product areas.
- More active participation from teams in technical roadmaps and engineering improvements.
None of these touched a line of code directly. All of them changed how the system evolved afterwards.
The honest cost
I want to be careful not to make this sound clean. Structural decisions affect people's roles, reporting lines, and sometimes their jobs. Some technical problems were visible before the organisational structure around them was clear, and I would have made those organisational decisions more decisively — earlier structural calls, clearer roles, clearer boundaries. Delay has a price, and in my experience the price is usually paid twice: once in confusion, once in the technical debt the confusion quietly produces.
More on that in things I'd do differently.
A practical test
If you want to know whether your team structure is helping or fighting your architecture, don't read the org chart. Watch the paths:
- When a problem spans two teams, does anyone own the seam? Or does it wait for a leadership meeting?
- Can a team improve its own subsystem without negotiating with three others?
- Do technical decisions happen where the information is — or where the authority happens to sit?
Where the answers are bad, the fix is usually not a reorg for its own sake. It's making ownership explicit where it has quietly gone shared.