Notes on the margin of safety for software teams.

The phrase *margin of safety* belongs to Benjamin Graham, passed to his pupil Buffett, and then to anyone who has sat with an annual letter long enough to absorb the cadence. Its premise is simple: do not buy at the price at which the investment makes sense. Buy at a price that leaves room for your analysis to be wrong.

Applied to a software team, the idea is almost offensively intuitive and almost universally ignored. A team that is planned to 100% of its capacity is a team that is planned to fail at 101%. A rotation that is staffed to exactly cover its oncall hours will burn out at the first illness. A dependency that is presumed to stay at its current API surface will be deprecated on the Tuesday of the week you needed it most.

The margin of safety in my own practice looks like this: 20% reserved capacity on any team planning quarter, an oncall rotation that can cover two absences, and a standing "critical dependency" review every eight weeks with a bias toward pinning, not chasing. None of this is glamorous. All of it earns its keep the week a founder's wedding, a child's illness, and a deprecation notice arrive on the same Monday.

I do not think of it as conservatism. I think of it as respect for the fact that I am going to be wrong, regularly, about specifics I cannot yet name.