Founder operating principles extracted from a year of your own work

A founder's operating philosophy is rarely written down. It exists in the pattern of their decisions — the hires they make and the ones they pass on, the product calls they push back on and the ones they approve without hesitation, the way they structure a difficult conversation versus an easy one. People who work closely with them learn to anticipate it. People who don't have to discover it through experience.

This implicit-operating-system problem is a real cost for early-stage teams. New hires need months to absorb the founder's decision logic. When the founder is absent — traveling, fundraising, managing an incident — decisions get made differently, because the principles that govern the founder's approach aren't available to the people making the calls.

What extraction looks like

Skill Transfer runs on sessions. Over a year of AI-assisted work — product reviews, strategic calls, investor prep, team feedback — the capture substrate accumulates patterns from how a founder operates.

The extraction pipeline surfaces these as candidates: the consistent heuristics a founder applies when evaluating a product decision ("user pain first, then technical feasibility, then business model"), the communication pattern in difficult conversations ("acknowledge the constraint before the direction"), the hiring criteria that recur across every strong hire the team has made.

These aren't principles the founder invented in a workshop. They're the principles that are already implicit in how they operate — made explicit by the extraction process and surfaced for review.

The founder reviews the extracted candidates, keeps the ones that accurately capture their actual approach, edits the ones that are partially right, and discards the false positives. The result is a set of principles that are genuinely the founder's — not aspirational, not generic, but derived from their actual work.

Principles that load in team sessions

Once captured and reviewed, the principles become memories that can be loaded in team sessions. A leadership team member working on a product decision can start that session with the founder's relevant heuristics in context — not as a constraint to check against after the fact, but as a frame present from the start.

This changes what "the founder would have wanted" looks like in practice. Instead of the team trying to predict the founder's reaction based on pattern-matching from past decisions, the relevant principles are explicit and available. The team can reason from the principles and apply their own judgment, rather than trying to reverse-engineer the founder's mental model.

The founder can also update the principles as their thinking evolves — a principle that held in year one may need refinement in year three as the business has changed. The version history tracks the evolution; sessions after the update load the current version.

The delegation case

As teams scale, founders delegate more. The quality of that delegation depends on how well the team understands not just what the founder wants on a specific decision, but how they think about a class of decisions.

A leadership team working with rich founder-principle context makes better delegated calls than one making calls without that context. Not because the principles are right for every situation — they're not — but because starting from an explicit operating philosophy reduces the variance in "what would the founder have wanted" from situation to situation.

The principles also become the foundation for the team's own operating philosophy. As the company scales and the team adds its own accumulated decision logic, the founder's principles are one layer of the org's memory stack — not the only layer, but a foundational one.

The honest version

Extraction captures what's in the sessions. A founder who does most of their thinking in meetings, in walks, or in private — without AI assistance — will have sparse extraction candidates. The system can't capture what it doesn't see.

Also: extracted principles are a description of past behavior, not a prescription for future behavior. A principle that accurately captures how the founder operated last year may not be the right principle for the organization today. The review step — which the founder does before principles are promoted — is where that judgment gets applied.

Principles are also not a substitute for judgment. A team that loads founder principles and treats them as rules to follow rather than frames to reason from will make the same mistakes that any rule-following without judgment makes. The principles are most useful when the team understands the reasoning behind them — which is why principles stored with their rationale ("we prioritize user pain first because early-stage products that don't solve real pain don't compound") are more useful than principles stored without it.

The operating philosophy that makes a founder effective is mostly unwritten. Making it explicit, reviewable, and loadable — by the people who need to act in its spirit when the founder isn't in the room — is the infrastructure that makes it transferable.