Thinking SmallSmall Teams, Small Contracts, and Attention to Detail
Simon Wardley's doctrine has two "think small" principles: Think small (details), which means knowing the details, and Think small (teams), which means using small teams. Both start the same way. You use a Wardley Map to break a large landscape into its components, then put a small contract around each one.
Start With a Map
A Wardley Map shows the components needed to meet a user need, how they depend on each other, and how evolved each one is, from genesis (new and uncertain) to commodity (standard and widely available). Those components are the units you think small about. Splitting work along them, rather than along department lines, ties each piece of work to something a user needs.
Small Contracts
Here, a contract is an agreement or interface around a single component. It can be an internal agreement between teams about what a component does and how others use it, or a contract with an outside supplier. A contract around one component is easier to write, check, and change than one around a whole system. It also lets you treat each component in the way that suits it: a novel component might sit with an in-house team working in an Agile way, while a commodity might come from a utility provider on standard terms. If one component needs to change, or one supplier needs replacing, you can do it without reopening everything else.
Small Teams
Small teams are easier to coordinate, and each member can see how their work affects the whole. Wardley's doctrine pairs them with small contracts: a small team owns a small part of the map, with a clear contract at each edge.
Amazon's Two-Pizza Teams
Amazon's "two-pizza team" rule, attributed to Jeff Bezos, keeps a team small enough for two pizzas to feed.
Haier's Micro-Enterprises
Haier's RenDanHeYi model splits the company into thousands of self-managing micro-enterprises, each with its own P&L and its own users.
One Owner per Component
Whatever the team size, give each component one owning team. When ownership is clear, so is accountability, and duplication is easier to spot.
Knowing the Details
Think small (details) asks you to know each component well: what it does, who depends on it, what it costs, and how it fails. Detail is where duplication, hidden dependencies, and wrong assumptions turn up. A small team with a small contract can keep that level of detail in view. A large department responsible for a whole system struggles to.
Putting It into Practice
Map the Landscape
Start from a user need and map the components that meet it, with their dependencies and how evolved each one is.
Draw the Contracts
Put a contract around each component, or a small group of closely linked ones. Say what it provides, to whom, and how you will know it is working.
Assign Small Teams
Give each contract a small team that owns it, and let the team choose methods that suit how evolved its components are.
Revisit as Components Evolve
Components move towards commodity over time. When one does, change its contract and team to match, for example by moving from a custom build to a utility service.
Where to Start
Pick one large system or contract that keeps causing problems. Map it, find the components inside it, and look for one you could split out with its own contract and team. Learn from that before you go further.