phronesis 1.0.0

package/templates/codex/seed/judgment/groups-seek-consensus-individuals-seek-truth.md

@@ -0,0 +1,44 @@
+---
+type: codex-principle-seed
+name: groups-seek-consensus-individuals-seek-truth
+title: Groups Seek Consensus; Truth-Seeking Needs Structure
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **Groups optimize for consensus; only individuals and small, structured teams reliably
+> seek truth.**
+
+This is structural, not a moral failing. Groups require cohesion to function, and cohesion
+requires shared narratives. When a truth conflicts with the group's narrative, the group
+tends to reject the truth before it rejects itself. Large institutions drift toward worse
+explanations over time because they optimize for internal alignment, not external accuracy.
+
+But the fix is not "work alone." Truth-seeking has working machinery, and it is a *group*
+discipline built to defeat the group's own pull. Two practitioners from different
+high-feedback domains converged on the same apparatus: an explicit charter of accuracy,
+accountability, and openness to disagreement; quarantine protocols (describe a decision
+without first revealing the outcome or your own belief, so the group doesn't infect itself);
+and stress-testing views against the smartest people who *disagree*, caring about their
+reasoning rather than their seniority. Both reduce to *reasoning to be accurate, not to be
+right*. Teams structured for accuracy beat lone independents — what corrupts truth is
+unstructured cohesion-seeking, not collaboration itself.
+
+One trap this machinery is built against: the illusion of validity — confidence tracks the
+coherence of your story, not the quality of your evidence, so you cannot validate a belief
+from the inside. The premortem (imagine the plan has already failed, and write down why)
+manufactures the outside view and the dissent the group won't otherwise generate.
+
+*Test: when did your team last change a fundamental belief because of evidence? If the
+honest answer is "never," it is consensus-seeking, not truth-seeking.*
+
+*Sources: Naval Ravikant; the truth-seeking apparatus of Annie Duke and Ray Dalio.*
+
+## Interview Prompt
+
+When your team confronts an uncomfortable truth, what actually happens — does it get
+examined or smoothed over? Describe the last time evidence changed a belief your group held,
+and what made that possible.

package/templates/codex/seed/judgment/heresies-are-where-the-edge-lives.md

@@ -0,0 +1,42 @@
+---
+type: codex-principle-seed
+name: heresies-are-where-the-edge-lives
+title: Heresies Are Where the Edge Lives
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **Cross "true vs false" with "spreadable vs non-spreadable," and the competitive edge lives
+> in the true-but-unspreadable quadrant — the heresies.**
+
+Four quadrants:
+
+> - **True + spreadable** — conventional wisdom. Already known; no edge.
+> - **False + spreadable** — what spreads because it confirms what people want to believe.
+> - **True + non-spreadable** — heresies. True but threatening to group identity. *This is
+>   where competitive advantage lives.*
+> - **False + non-spreadable** — nonsense. Ignored and harmless.
+
+What spreads is what confirms existing beliefs or provokes emotion, largely regardless of
+truth value — so heresies don't spread (too threatening) and conventional wisdom doesn't need
+to (already known). The strategic move is to seek out heresies: ideas that make smart people
+uncomfortable but that you can't find a good argument against. They are disproportionately
+likely to be both true and valuable precisely because the social cost of believing them keeps
+competitors away. In product strategy, the most valuable insights are often the things the
+market "knows" are wrong — "people won't pay for X" is frequently conventional wisdom that a
+heretical builder disproves.
+
+*Diagnostic: what do you believe about your domain that you'd be reluctant to say out loud to
+your peers — not because it's edgy, but because you can't find a good counter-argument and it
+would make them uncomfortable? That list is your candidate-heresy portfolio.*
+
+*Source: Naval Ravikant.*
+
+## Interview Prompt
+
+What's something you believe about your market or product that most people in your field
+would push back on — but you can't find a good argument against? What would it mean if you're
+right?

package/templates/codex/seed/judgment/judgment-compounds-through-honest-reflection.md

@@ -0,0 +1,38 @@
+---
+type: codex-principle-seed
+name: judgment-compounds-through-honest-reflection
+title: Judgment Compounds Through Honest Reflection
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **Judgment is experience plus honest reflection, compounded over many iterations.**
+
+You can't shortcut judgment. It requires making decisions, observing outcomes, and
+honestly evaluating what worked and why — not rationalizing after the fact. The honest
+part is the whole game. Most people accumulate experience without accumulating judgment
+because they never honestly assess their mistakes: they explain them away, blame
+circumstances, or avoid the domains where they failed. Judgment compounds only when the
+feedback loop is honest. This is why some people have twenty years of judgment and others
+have one year of judgment repeated twenty times.
+
+The unit of learning is iterations, not hours. The ten-thousand-hours meme has the
+variable wrong. An iteration is: do something, reflect honestly on the outcome, change
+something, try again. Time without honest reflection just repeats the same mistake.
+Deliberate iteration with real feedback develops judgment in far fewer cycles than any
+time-based model predicts.
+
+*Diagnostic: are you measurably better at decisions in your domain than a year ago? Can
+you name specific beliefs you've updated because an outcome proved you wrong? If not,
+you're collecting experience, not compounding judgment.*
+
+*Source: Naval Ravikant.*
+
+## Interview Prompt
+
+Think of a recent decision in your work that didn't go the way you expected. Looking back,
+are you reflecting honestly on why — or quietly explaining it away? Name one belief you've
+actually changed because an outcome proved you wrong.

package/templates/codex/seed/judgment/phronesis-is-judgment-in-the-particular.md

@@ -0,0 +1,67 @@
+---
+type: codex-principle-seed
+name: phronesis-is-judgment-in-the-particular
+title: "Phronesis: Judgment in the Particular"
+created: 2026-07-02
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **Judgment lives in the particular case, not in the rule that gestures at it. The
+> work is perceiving what this situation calls for, when no rule fits cleanly and no
+> past case maps.**
+
+Aristotle split practical intelligence three ways, and the product is named for one
+of them. *Techne* knows the procedure: it makes a product to spec, and you grade it
+against the product. *Sophia* knows the principle: the eternal, the general, the
+true-everywhere. *Phronesis* knows the moment: the right thing to do here, now, with
+these people, where the material is contingent and no procedure closes the gap. This
+workspace is built for the third one. The software is *techne*, a made thing with
+skills and loops. The codex holds *sophia*, the principles you have adopted. Neither
+is the judgment. The judgment is the act of bringing both to bear on the case in
+front of you.
+
+The defining move is the priority of the particular. No rule is fine-grained enough
+to settle the case, so the grasp of the particular outranks the grasp of the rule.
+Aristotle's own test: knowing "light meats are wholesome" produces no health; knowing
+*which* meat is light does. Phronesis is not deduction. It is a trained perception
+built only from experience, the compressed residue of many seen cases, which is why a
+young person can be a brilliant mathematician but not yet practically wise. The
+capacity is accumulated, not derived. It is also why catching your cases and
+returning the relevant one is phronetic work: it feeds the perception that only
+experience builds.
+
+Skill alone is not wisdom. Aristotle names *deinotes*, cleverness: the bare ability
+to find effective means to any end, good or bad. Phronesis contains cleverness but
+adds the right aim, and without a rightly-ordered end, cleverness is only cleverness.
+That is the line between practical wisdom and mere expertise, and it is the line a
+bare model cannot cross on its own, because a model supplies means, not ends. The
+product holds both halves on purpose. The raw and compiled layers hold the perception
+(your cases, your caught decisions). The codex holds the aim (your taste, your
+validated principles, what you actually value). Retrieval without the codex would be
+*deinotes*: fast, fluent, aimless. The codex is what makes it wisdom instead of clever
+recall.
+
+The last move is the sharpest. The standard of a right call is not a formula but a
+person: the good choice is the one the practically wise person, the *phronimos*, would
+make. There is no algorithm for it. This is why the workspace seeds from operators who
+already have phronesis in a domain, borrowed exemplars rather than invented rules, and
+why it never claims judgment of its own. The system perceives which piece matters and
+pairs your particulars with your principles. The call stays yours. A tool that dressed
+rule-following as judgment would be selling the opposite of the thing it is named for.
+
+*Diagnostic: when you reach for the right move, notice whether you are applying a rule
+or reading a case. If a rule settles it cleanly, that is techne and it can be written
+down. The moments where the rule runs out and you decide anyway are your phronesis.
+Those are the ones worth catching.*
+
+*Source: Aristotle, Nicomachean Ethics, Book VI (and II.6 for the phronimos as the
+standard of the mean).*
+
+## Interview Prompt
+
+Where in your work does the rule run out? Name a recent call where no procedure or
+past case quite fit and you had to read the specific situation and decide. What did
+you see that told you which way to go?

package/templates/codex/seed/judgment/show-me-the-apparatus.md

@@ -0,0 +1,40 @@
+---
+type: codex-principle-seed
+name: show-me-the-apparatus
+title: Show Me the Apparatus
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **A stated value isn't real until there's enforced machinery that makes betraying it
+> structurally impossible — not merely discouraged.**
+
+The diagnostic separates real commitments from slogans. A company files its quarterly report
+on time because there is a massive, expensive apparatus that guarantees it — ask the
+probability and the answer is 100%. Ask the probability that it never cuts a corner on
+quality, safety, performance, design, or innovation, and the honest answer is "well, 90%."
+The gap between 100% and 90% is the gap between what is load-bearing (backed by machinery)
+and what is merely aspirational (backed by intentions). The values organizations claim
+loudest and protect least — safety, performance, quality, design, innovation — are exactly
+the ones no expensive apparatus enforces, so they're the first cut under pressure.
+
+For any value you or your organization claims, ask: what is the apparatus? Not the slogan,
+not the all-hands speech, not the value painted on the wall — the enforced machinery that
+makes betraying it structurally impossible. If you can't name it, the value is aspirational,
+and under pressure it will be the first thing to go. A value defended only by good intentions
+is a control that can be quietly bypassed; a value defended by gates, owners, and
+accountability is one that actually holds.
+
+*Diagnostic: run this on your own roadmap. Which of your stated quality or safety commitments
+have explicit gates, owners, and accountability — and which are just things you say you care
+about? The second list is what you'll quietly cut the next time you're behind.*
+
+*Source: Eric Ries.*
+
+## Interview Prompt
+
+Name a value you or your team claims to hold. What's the actual enforced machinery that makes
+betraying it impossible — or is it, honestly, just something you say you care about?

package/templates/codex/seed/judgment/small-judgment-gaps-compound-under-leverage.md

@@ -0,0 +1,37 @@
+---
+type: codex-principle-seed
+name: small-judgment-gaps-compound-under-leverage
+title: Small Judgment Gaps Compound Under Leverage
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **With leverage, a small difference in judgment produces an enormous difference in
+> outcome.**
+
+In a world without leverage, the gap between good and great judgment barely matters — you
+dig one ditch or two. With leverage — code, media, capital, automation — that same judgment
+gap produces tenfold or hundredfold outcome differences. Slightly better judgment about what
+to build reaches millions more people; slightly better judgment about timing captures a
+winner-take-all market. This is why judgment is the skill to develop above all others: it is
+the multiplier on everything else you do.
+
+The corollary is that as leverage rises, the *return* on improving your judgment rises with
+it — and so does the cost of a judgment error, because leverage amplifies bad calls just as
+faithfully as good ones. The operator with high leverage and mediocre judgment is not safe;
+they are efficiently amplifying their mistakes.
+
+*Diagnostic: where are you adding leverage (tools, capital, automation, audience) without a
+matching investment in the judgment that aims it? That gap is where leverage turns from a
+multiplier into a magnifier of error.*
+
+*Source: Naval Ravikant.*
+
+## Interview Prompt
+
+Where in your work does a small difference in judgment get multiplied into a large
+difference in outcome? And where are you adding leverage faster than you're sharpening the
+judgment that points it?

package/templates/codex/seed/judgment/taste-is-compressed-judgment.md

@@ -0,0 +1,38 @@
+---
+type: codex-principle-seed
+name: taste-is-compressed-judgment
+title: Taste Is Compressed Judgment
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **Taste is judgment you can no longer articulate.**
+
+Taste is the late stage of judgment. When you've iterated enough, pattern recognition
+becomes so fast and integrated that the reasoning goes subconscious — you "just know" the
+answer. This isn't mystical; it's compressed computation. A senior practitioner who looks
+at a draft and says "this isn't right" without being able to explain why is running
+thousands of prior cases through unconscious pattern matching.
+
+The progression has rough stages. First you reason through each decision with explicit
+logic. Then your subconscious starts supplementing the reasoning and you can still say why.
+Then "it doesn't feel right" becomes a valid and reliable signal that you can't fully
+explain. Finally your whole body reacts — wisdom lodged below thought. Most masters of a
+craft operate in the last two stages.
+
+Two failure modes guard the principle. Taste can look like arrogance to people who haven't
+developed it, so it has to be earned, not asserted. And taste without continued learning
+calcifies into dogma. The test of real taste is that it still updates: someone with
+genuine taste changes their mind against strong enough counter-evidence, even when they
+can't articulate why the old read was wrong.
+
+*Source: Naval Ravikant.*
+
+## Interview Prompt
+
+Where in your work do you "just know" the right call without being able to fully explain
+it? And when did you last change one of those gut judgments because the evidence forced you
+to?

package/templates/codex/seed/judgment/trust-taste-only-where-feedback-is-valid.md

@@ -0,0 +1,42 @@
+---
+type: codex-principle-seed
+name: trust-taste-only-where-feedback-is-valid
+title: Trust Taste Only Where Feedback Is Valid
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **Trained intuition is real — but only where the environment is regular and the feedback
+> is fast and clear. Everywhere else, confidence is not a signal.**
+
+Taste develops under two conditions: a high-validity environment (stable, learnable
+regularities between cues and outcomes) and enough practice with rapid, unequivocal
+feedback. Where both hold — chess, surgery, a well-instrumented product loop — intuition is
+genuine recognition. Where they fail — "wicked" environments, long-horizon forecasting,
+anywhere feedback is delayed, sparse, or ambiguous — confident intuition is the *illusion of
+validity*, and the felt confidence is no signal at all. Confidence tracks the internal
+coherence of your story, not the quality of your evidence; redundant and flimsy evidence
+still produces high confidence.
+
+So the discipline is to audit the *environment and your learning history*, never the
+feeling. Before trusting a gut call, ask: is this domain regular enough that valid cues
+exist, and have I had many reps with fast, clear feedback in it? If either answer is no,
+force the model, the outside view, or a premortem instead of trusting taste. This is also
+the boundary on deliberate practice — reps only build taste where the feedback is valid;
+grinding in a wicked environment manufactures confidence without skill. Roadmap and
+long-horizon forecasting are closer to low-validity than they feel.
+
+*Diagnostic: sort your domains into "fast, clear feedback" and "slow or murky feedback."
+Trust your gut in the first; distrust it and scaffold the decision in the second — no matter
+how confident it feels.*
+
+*Sources: Daniel Kahneman and Gary Klein.*
+
+## Interview Prompt
+
+In which parts of your work do you get fast, clear feedback on whether a call was right —
+and in which is the feedback slow or murky? Where might you be trusting a confident gut in a
+domain that doesn't actually feed it good signal?

package/templates/codex/seed/judgment/weigh-the-reasoning-not-the-recommendation.md

@@ -0,0 +1,43 @@
+---
+type: codex-principle-seed
+name: weigh-the-reasoning-not-the-recommendation
+title: Weigh the Reasoning, Not the Recommendation
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **Every advisor is a pattern-matching system trained on a particular corpus of experience.
+> Their recommendation is calibrated for their context; the reasoning is the part that
+> transfers.**
+
+When a respected operator gives you advice, the recommendation is the output of *their*
+system applied to *your* inputs — calibrated for their corpus, their stage, their failures.
+The reasoning behind it — why they reached that conclusion, what trade-offs they saw, what
+pattern they're matching against — is the part worth extracting. The recommendation often
+doesn't transfer; the reasoning often does. The classic case is a leader who eliminated an
+entire role at their company: the recommendation may not transfer to yours, but *why* they
+did it is highly informative — and may yield a different action in your context.
+
+The operational move: when an advisor recommends X, the next question is "why did you reach
+that conclusion?" — not "should I do X?" Then back-propagate. What corpus is this advisor
+pattern-matching against? What features of their corpus does the recommendation depend on?
+Do those features exist in yours? If yes for all the load-bearing features, it likely
+transfers. If no for any, extract the reasoning and modify the recommendation. If no for
+most, the recommendation doesn't transfer — but the underlying mechanism still might, if you
+can find its analog in your situation.
+
+The failure modes this guards against: *cargo-cult adoption* (taking advice as-is because
+the source is high-status), *cargo-cult rejection* (discarding it as-is because the source
+has a different context, when the reasoning was transferable), and *status-weighted updating*
+(weighting by the advisor's status rather than the reasoning's transferability, which leaves
+your beliefs lurching as you move between high-status sources).
+
+*Source: Howie Liu.*
+
+## Interview Prompt
+
+Think of advice you recently got from someone you respect. What was the *reasoning* behind
+it — and do the conditions that made it right for them actually hold in your situation?

package/templates/codex/seed/leadership/a-managers-output-is-the-teams-output.md

@@ -0,0 +1,35 @@
+---
+type: codex-principle-seed
+name: a-managers-output-is-the-teams-output
+title: A Manager's Output Is the Team's Output
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **A manager's output is the output of their team plus the output of the teams they
+> influence — not the work they personally produce.**
+
+This is the line that separates a manager from a senior individual contributor. Your own
+skills and knowledge are worth almost nothing on their own; they count only insofar as
+they raise the performance of the people around you. Knowing more about the work than
+anyone else in the building produces zero output until you can transfer that knowledge
+into the organization. The job is no longer measured by how much you personally make, but
+by how much your team makes because of you.
+
+The corollary reorders how you spend a day: every hour should be judged by its *leverage*
+— how much team output it produces — not by how busy or productive it felt. A manager can
+have a full, satisfying day of personal work and move the team's output not at all.
+
+*Diagnostic: at the end of a busy day, ask whether your hours raised what your team can
+produce — or only what you produced. If the honest answer is the latter, you spent the
+day as a contributor, not as a manager.*
+
+*Source: Andy Grove.*
+
+## Interview Prompt
+
+Looking back on your last week, how much of what you produced actually multiplied through
+your team — versus work you could have done just as well in any individual role?

package/templates/codex/seed/leadership/most-team-problems-are-structural.md

@@ -0,0 +1,40 @@
+---
+type: codex-principle-seed
+name: most-team-problems-are-structural
+title: Most Team Problems Are Structural, Not Personal
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **When something is wrong on a team, diagnose top-down — most problems that look like
+> people problems are structural problems wearing a people-problem costume.**
+
+The default instinct when a team struggles is to go straight to the individuals: they are
+not getting along, that one is not pulling their weight. Invert it. Picture four layers
+beneath the surface — structural (goals, roles, expectations), dynamics (how the team
+decides, resolves conflict, meets), interpersonal (specific relationships), and
+intrapersonal (one person's capacity or motivation). Start at the top and only go deeper
+when the layer above is genuinely clean. Snorkel before you scuba. The large majority of
+what looks like underperformance turns out to be unclear goals, ambiguous roles, or an
+undefined definition of success.
+
+The reason leaders skip to the bottom is that people-layer interventions feel productive —
+you had a conversation, something happened — while confronting structural debt feels like
+admitting you did not set things up well. If you do nothing else as a manager, make roles
+and expectations clear and shared; that alone resolves a surprising fraction of what gets
+mislabeled as a performance problem.
+
+*Diagnostic: the next time you think "X is the problem on this team," check first whether
+the goals are clear and shared, the roles explicit, and success defined in writing —
+before you conclude the problem is a person.*
+
+*Source: Molly Graham.*
+
+## Interview Prompt
+
+Think of someone on your team who seems to be underperforming. Before you reached that
+conclusion, how clear and shared were their goals, their role, and the definition of what
+success looks like?

package/templates/codex/seed/leadership/next-play.md

@@ -0,0 +1,36 @@
+---
+type: codex-principle-seed
+name: next-play
+title: Next Play
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **After an error, the compounding error — the defensive overcorrection that follows —
+> usually does more damage than the original. Make the mistake, forget it, run the next
+> play.**
+
+A player who clanks a shot tends to overplay the next possession to compensate, and the
+overcompensation draws the foul that actually costs the game. The same reflex runs through
+teams: after an unforced error come the defensive reviews, the blame postmortems, the
+performative caution — and that wave of compensation costs more than the miss it was meant
+to answer. The discipline is not to skip the lesson; it is to take the lesson without the
+penance, and re-orient immediately on the next move.
+
+Naming the move — "next play" — is what creates the gap between the error and the decision
+that follows it, so the next decision is made fresh instead of in the shadow of the last
+one.
+
+*Diagnostic: after your team's last unforced error, did the following weeks fill with
+extra reviews, individual blame, and performative humility from leaders? If so, the
+compounding error cost you more than the original ever did.*
+
+*Sources: Mike Krzyzewski; Brian Halligan.*
+
+## Interview Prompt
+
+Think about the last real mistake your team made. What did the days after it look like —
+and did the response end up costing you more than the mistake itself?

package/templates/codex/seed/leadership/psychological-safety.md

@@ -0,0 +1,39 @@
+---
+type: codex-principle-seed
+name: psychological-safety
+title: Psychological Safety
+created: 2026-06-24
+exposure: shareable
+stance: gravity
+provenance:
+  authored_by: seed
+---
+
+> **The single largest factor in team effectiveness is psychological safety — a shared
+> belief that the team is safe for interpersonal risk-taking.**
+
+It is not an individual feeling but a team-level property: the confidence that speaking
+up, admitting a mistake, asking for help, or challenging a decision will not lead to
+embarrassment, rejection, or punishment. Where it is present, people surface errors early,
+ask the questions that prevent disasters, and experiment. Where it is absent, they hide
+problems until the problems are too large to hide. Safety drives *learning behavior*, and
+learning behavior is what drives performance — the safety itself does not satisfy the
+customer, it enables the team to do the things that do.
+
+Guard against the four misreadings. It is not cohesiveness — cohesive groups can suppress
+dissent, which is the opposite of safety. It is not niceness, not lowered standards, not
+comfort with the status quo. The most common failure is to hear "psychological safety" and
+install politeness, which produces an artificial harmony that quietly kills candor. High
+standards and high safety are complements, not opposites: safety is what turns candor into
+a learning input rather than a threat.
+
+*Diagnostic: when someone on your team last made a real mistake, did they bring it to you
+early — or did you find out late, from somewhere else? A team that hides errors is
+reporting its climate, not its competence.*
+
+*Source: Amy Edmondson.*
+
+## Interview Prompt
+
+On your team, what actually happens when someone admits a mistake, asks for help, or
+disagrees with you in front of others? Walk through the last time it happened.

package/templates/codex/seed/leadership/right-size-your-teams.md

@@ -0,0 +1,38 @@
+---
+type: codex-principle-seed
+name: right-size-your-teams
+title: Right-Size Your Teams
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **The fundamental lever of organizational design is team sizing: build small, stable,
+> autonomous teams — large enough to gel and survive a departure, small enough to move
+> fast.**
+
+Most recurring structural questions — how many teams, a new team or an existing one, where
+the boundary falls — reduce to sizing. A useful range: a manager can actively support
+roughly six to eight people before degrading into a reactive coach-and-safety-net who is
+too busy to invest in anyone. Below about four, a group stops behaving like a team at all
+— it becomes a leaky abstraction over a set of individuals, fragile enough that one
+departure tips it from momentum back into toil, and you find yourself reasoning about
+every vacation and on-call shift one person at a time.
+
+Two companions make sizing durable. Drive the design from the structure, not the key
+individuals — fit the org to particular personalities and you buy frequent reorgs and
+organizational debt as those people move on. And protect teams that have gelled: groups
+that have worked together a long time are extraordinarily productive, while constant
+membership churn means a team never gels at all.
+
+*Diagnostic: if you have to reason about every vacation and on-call shift individually,
+your "team" is too small to be a team — it is a set of individuals wearing a team's name.*
+
+*Source: Will Larson.*
+
+## Interview Prompt
+
+Look at how your teams are sized right now. Where is one too small to survive a single
+departure, or too large for everyone to move together — and what is keeping it that shape?

package/templates/codex/seed/leadership/spend-time-on-high-leverage-activities.md

@@ -0,0 +1,36 @@
+---
+type: codex-principle-seed
+name: spend-time-on-high-leverage-activities
+title: Spend Your Time on High-Leverage Activities
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **Leverage is output divided by the time the activity took — so spend your scarce hours
+> on the acts whose effect multiplies across many people.**
+
+Three things raise a manager's productivity: doing activities faster, raising the leverage
+of each activity, or shifting the mix toward higher-leverage ones. High-leverage acts
+share a shape — one action that affects many people (a training everyone attends, a
+process everyone uses), a brief action with a long-running effect (a sentence that
+redirects a project for months), or being the one person who can supply a particular
+skill at a particular moment.
+
+The underused half of the idea is that leverage runs *negative*. Meddling, waffling on a
+decision people are waiting for, and demoralizing behavior all *subtract* from team
+output. A leader can put in a full, energetic day and end it having produced net-negative
+leverage — busy, and worse than absent.
+
+*Diagnostic: find the single activity whose effect ripples across the most people — a
+decision others are blocked on, a process everyone will use, an hour spent teaching. Then
+look at what you actually spent today on instead.*
+
+*Source: Andy Grove.*
+
+## Interview Prompt
+
+Which of the things you do regularly has the widest ripple across other people's work —
+and honestly, how much of your week actually goes to it?