Repository & Team Structure
How a repository is laid out, monorepo against polyrepo, ownership without silos, and the design reviews and RFCs that stop decisions living in one head.
A folder tree is a navigation aid and a change-locality claim. It should reflect how engineers actually move through the system, not a template someone copied.
Atomic changes, tooling, ownership, build scale, access control and release independence — six axes that pull in different directions. There is no universal answer, and anyone who gives you one is describing their last job.
Somebody has to be accountable for each part of the system, and the mechanism that achieves that is the same mechanism that creates silos. The tension is real; pretending it is not is how both failures happen.
Critical knowledge living in one head is a design risk, not an HR risk. It shows up in the estimate for every change to that area, long before anyone leaves.
Code review, documentation, pairing, design review and postmortems each spread a different kind of knowledge at a different cost. Choosing between them starts with naming which kind is missing.
Before a high-impact change, discuss requirements, options, trade-offs, migration, failure modes, security and observability — because this is the last point at which a boundary can still be moved.
Problem, Goals, Non-Goals, Design, Alternatives, Risks, Rollout, Open Questions. A written proposal for decisions too large for a meeting — and a reliable source of theatre when applied to decisions that are not.