gbrain: sync converted org-mode brain files

ideas/orders-of-magnitude-time.org

@@ -0,0 +1,29 @@
+#+title: Orders of Magnitude — Time
+#+filetags: :passepartout:framework:time:scale:hierarchy:
+
+:PROPERTIES:
+:ID:       orders-of-magnitude-time
+:CREATED:  [2026-05-23 Sat]
+:END:
+
+Time at human scales is best thought of in orders of magnitude, not linear progression. Each jump in scale is qualitatively different — the constraints, the tools, the feedback loops, and the failure modes change entirely.
+
+The hierarchy:
+
+| Scale | What fits | Feedback | Failure mode |
+|-------|-----------|----------|--------------|
+| Minutes | Firefighting, ops, real-time decisions | Instant | Burnout, whiplash |
+| Hours | Work session, meeting, focused task | Same day | Interruption cascade |
+| Days | Shippable thing, momentum building | Next day | Drift, distraction |
+| Weeks | Sprint, feature, market pulse | One cycle | Wrong direction |
+| Months | Product cycle, hiring, traction | One data point | Bleeding out slow |
+| Years | Company, moats, technology shifts | Scarce | Irrelevance |
+| Generations | Culture, regulation, infrastructure | Post-founding | Irreversibility |
+
+Practical use:
+
+When planning anything, identify which order of magnitude you're operating in — then use the tools and cadence appropriate to that scale, not the one below or above it. A minutes problem solved with a weeks solution is overengineering; a years problem approached with days thinking is naive.
+
+Common mistake: treating a months/years problem as if it can be solved in days/weeks (startup hype, premature optimization) or a minutes problem as if it deserves weeks of deliberation (analysis paralysis, bikeshedding).
+
+See also: [[file:time-estimates.org][Time estimates]] applies this framework to Passepartout's development timeline.