The Shirley Principle
Updated 2026-08-17
INTRODUCTION
English translation pending.
CORE DEFINITION
The Shirley Principle is a diagnostic heuristic named after the observation that most IT problems are really bad business processes or management issues in disguise. It holds that technical symptoms usually trace back to upstream process and management chaos, so the demand should be questioned before anything is built. The key qualifier is that it does not deny the existence of genuine technical problems; it only insists that they be identified rather than assumed.
SCAFFOLDING EFFECT
Reduce cognitive load
- Attribution check: Pause before building a complex feature and ask whether a broken process is the real cause. - Effort audit: Separate tactical diligence in code from strategic avoidance of management work. - Demand triage: Sort incoming technical requests into process fixes versus genuine engineering work.
Anchor fast decisions
Technical work sits at the end of a long causal chain, so it absorbs and displays the disorder produced upstream. When a broken process generates defects, the organization can either repair the process or build a more complex system to absorb the symptoms. The second option feels like progress, which is why it is chosen, and the added complexity then hides the original management failure instead of resolving it.
MINIMUM ACTION
In progress 0/2Practice this model in one real situation:
account_treeGenealogyexpand_more
menu_bookReferencesexpand_more
Source support: Explicit
- agilelaws.comhttps://agilelaws.com/shirky-principle.htmlverified
PRIVATE NOTES · Only visible to you
SAVED Q&A
ENTRY Q&A · Private saving available
Ask with a clear boundary
thinkingmodels answers from published entry context only.
Your question is sent to thinkingmodels. The answer uses public entry context only.