Amey-Thakur Organizational design
Structure determines what is easy and what is hard. Teams organised around functions make cross-functional work expensive; teams organised around outcomes make shared infrastructure hard. Every structure trades one coordination problem for another.
Method
- Organise around the work that must move fastest. Whatever the business needs to iterate on quickly should sit inside one team with the capability to ship it.
- Minimise handoffs on the critical path. Every boundary crossed is a queue, and the number of teams a change must pass through predicts delivery time better than headcount does.
- Make ownership explicit and singular. Every system, decision, and customer commitment has one owning team, since shared ownership is unowned (see agent-role-definition).
- Match decision rights to information. Decisions should be made where the context is, with escalation for genuine cross-cutting trade-offs (see agent-escalation-ladder).
- Keep teams small enough to coordinate internally. Communication cost grows faster than team size, and beyond a threshold a team becomes two.
- Expect the structure to shape the product. Systems mirror the organisation that built them, so a structure at odds with the desired architecture will lose.
- Reorganise sparingly and explain why. Every restructure costs months of productivity and trust, so it needs a problem worth that price.
Boundaries
Structure enables; it does not substitute for capable people or clear strategy. Reorganisations are disruptive and often solve a problem that was cultural. People's roles and livelihoods are involved, which makes this consequential beyond efficiency (see agent-people-ops-desk).