Protect Engineering Capacity

Description

When external demands threaten to overload engineering capacity, protect capacity by either requiring the demand to come with additional resources, or forcing hard prioritization choices upstream.

Typical Approach

Reject work that displaces existing priorities without growing capacity. Require partnerships to add headcount, not just fund activity. Force Product to separate critical path from nice-to-haves. Use phased estimation to protect engineers from premature commitments while still giving leadership visibility. MINED REFINEMENTS (from 19 meta-learning observations, 2026-01-15 to 2026-08-11). The canonical formulation is external work must grow the org, not displace existing priorities - the funding requirement on a partner deal and the pushback on a Product roadmap are the same logic. Sub-moves observed repeatedly: condition custom engineering work on a commercial commitment rather than refusing it outright; guard margin over logo and be willing to lose a deal cleanly rather than absorb scope the team cannot staff; when everything is labelled priority, force the upstream party to do the painful triage rather than letting engineering absorb the ambiguity; make implicit work visible via explicit ticketing so it competes for resources and Product owns the trade-off. One high-value inversion of the usual framing, from 2026-08-11: REMOVE the capacity objection before asking for an estimate. Assume we get headcount to cover this is not generosity - it forces the answer to be what would this take rather than can we fit it, which are different questions with different numbers. DOCUMENTED EXCEPTION (2026-03-23): Peter deliberately inverts this pattern when existential platform risk is at stake - the RESF situation overrode normal capacity-protection instincts. Do not treat a capacity-protection match as automatic when the underlying platform is itself threatened.

Trigger Conditions