About → Handbook
Small Teams
A few good people can work more effectively than a big, bloated team of good people.
Implications
We believe in small, lean, nimble teams that are able to communicate effectively and get work done more swiftly. Smaller teams mean less communication overhead and more flexibility, autonomy and ownership. Small teams require T-shaped individuals; that are able to adapt to what's needed right now.
Rationale
- Time waste due to increased communication overhead: Having a big team means you need to spend a lot of time and energy figuring out how to keep everyone on the same page. Whereas a small team will more easily and perhaps more organically stay aligned.
- Work conflicts: Codebases can only fit so many people at the same time. Too many developers means lots of conflicts, stepping on each other's toes and a race to push first - and while we are advocates of frequent pushing, conflicts are never a good reason to do it.
- Overly engineered architecture: Sometimes, teams opt to over-engineer their architecture in an attempt to fix the issue with work conflicts. This eventually leads to unmanageable, difficult to maintain and extend codebases.