Mental Models

These are recurring frameworks for reasoning about technology, organizations, and change. They are not original theories — most can be traced to well-established disciplines. What is specific here is how they have been applied and where they have been most useful.

Platform as Leverage

The model: Build once. Improve many. Every product built on shared capability pays a fraction of its development cost back to the whole portfolio.

How to apply it: When evaluating an architectural decision, ask not just what it costs for the current product but what it enables for the next three. When evaluating an investment in shared capability, ask what the compounded cost of not sharing would be over five years across the portfolio.

Where it fails: When the platform is never completed to the point where reuse is genuinely cheaper than rebuilding. Many platform initiatives fail not from wrong direction but from insufficient depth — the shared capability is defined but not validated, documented but not teachable, governed but not adopted.

The counterintuitive version: The greatest platform value usually appears in long-term support and maintenance, not in first-product delivery. If you evaluate platform ROI on first-product delivery, you will consistently underinvest.

Technology Inflection Points

The model: Every major technology has a moment when economic viability precedes organizational readiness. The technology works before the organization knows how to adopt it. The gap between those two points is the adoption opportunity — and the adoption risk.

How to apply it: When encountering a new technology, ask not just "does this work?" but "are the economics of adoption changing?" Economics shift on different timescales than capability. Linux was technically capable for years before the economics of commodity hardware made it genuinely competitive with proprietary UNIX. The Web was technically operational before browser penetration made it a practical commercial channel.

The leader who recognizes a technology inflection point before the organization does has a narrow window to build capability that will be strategically valuable when the institution catches up.

Where it fails: Mistaking capability for inflection. Many technologies become capable without becoming economically transformative. The inflection point is specifically about economics — when the cost structure changes enough to make adoption rational at scale.

The current instance: AI adoption in 2024–2026 is exhibiting exactly this pattern. The capability exists. The economic transformation — AI changing engineering economics before it changes engineering — is in early stages. Organizations that build capability now will be positioned when the economics shift fully.

Friction Mapping

The model: Most delivery problems are organizational friction problems, not capability problems. Before adding resources, effort, or process, identify where the friction is — the places where work slows, stops, or requires rework — and determine whether removing friction would change the outcome more than adding effort.

How to apply it: For any process that is slower than it should be, map the path a unit of work takes from input to output. At each step: how long does it wait? What causes the wait? Who makes a decision? What information is missing? What approval is required? Friction usually appears at handoffs, in information gaps, and at decision points with unclear authority.

Worked example: The enrollment management problem at Shippensburg in 1999 was not a data problem in the sense of missing data. The data existed on the mainframe. It was a friction problem: the data was inaccessible at the speed at which decisions needed to be made. The solution was not to create more data — it was to remove the friction between the data and the decision-maker.

Where it fails: When the friction is protective rather than wasteful. Some friction exists because removing it would create problems: a slow approval process may be preventing bad decisions as well as good ones. Friction mapping must distinguish between wasteful friction and necessary friction before optimizing it away.

Second-Order Thinking

The model: Every decision has first-order effects (the immediate, visible consequences) and second-order effects (the consequences of the first-order consequences, and so on). Most people and organizations optimize for first-order effects. Second-order thinking asks: if this works as intended, what does that create? If it fails, what does that cascade into?

How to apply it: For any significant architectural, organizational, or strategic decision, ask:

If this succeeds, what does the organization look like in three years?
If this fails, what is the recovery path?
What does adoption of this decision require from downstream teams, and are they positioned to adapt?
Who benefits, and whose interests are threatened?

The platform version: A platform decision creates second-order effects across every product that uses it. A performance characteristic of a shared component becomes a performance characteristic of every product in the portfolio. A security vulnerability in a shared library is a security vulnerability in every product that depends on it. Second-order thinking is required for platform architecture because the immediate product team cannot see the downstream consequences — only the platform architect can.

Where it fails: At excessive depth. Second-order thinking becomes counterproductive when the chain of consequence becomes speculative rather than grounded. The goal is to reason far enough to identify the non-obvious consequences that would change the decision, not to construct an exhaustive causal graph of every possible outcome.

Enable Before Optimize

The model: Make capable people more capable before trying to make already-capable processes more efficient. Optimization of a broken capability is wasted investment. Optimization of a working capability has limited return compared to enabling a capability that doesn't yet exist.

How to apply it: When deciding between enabling a new capability and optimizing an existing one, ask what the constraint actually is. If the organization cannot do something important at all, optimization of adjacent things is marginal. If the organization can do something reasonably well but slowly, optimization may be high-leverage.

The teaching version: Technology-agnostic engineering education operates on this principle. Students who have learned a specific platform are capable of one thing. Students who have learned the engineering methodology that underlies every platform are capable of navigating any platform. Enabling the methodology gives them orders of magnitude more range than optimizing their proficiency with one tool.

The organizational version: Engineers who understand how to evaluate AI-generated output are more enabled than engineers who can generate AI output faster. The enabling investment is in judgment, not in throughput.

Doctrine Over Process

The model: Teach principles before procedures. A principle explains why. A procedure explains what to do in a specific situation. When the situation changes — which it always does — people with principles can adapt their procedure. People with only procedure are lost.

How to apply it: When writing documentation, ask whether you are writing what to do or why to do it. When teaching, ask whether the student will know how to behave in a situation the procedure did not anticipate. When evaluating whether a team is ready to operate independently, ask whether they can reason from first principles or only from approved procedures.

The governance version: Governance built on procedures becomes obsolete when conditions change. Governance built on principles — what are we trying to ensure, and why — remains applicable because people can derive appropriate procedures for new conditions. In regulated environments, the principle is "continuously generate evidence of what you are doing and why." The specific procedures for doing that change as technology and practice evolve.

The failure mode: Doctrine stated without being internalized is just another procedure in disguise. The test of whether doctrine has been adopted is whether people apply it in situations that were not covered when it was taught.

Evidence Before Claims

The model: Ground assertions in observable evidence. Distinguish confident conclusions from speculative ones. Design systems and processes so that claims can be tested and revised when evidence contradicts them.

How to apply it: For any claim about system behavior, ask what the evidence for that claim is. Is it empirical observation, or is it assumption? Is it derived from the actual deployment context, or from a simulated approximation? Can the claim be falsified? Is there a mechanism for revising it when evidence contradicts it?

The AI version: AI systems produce confident output across a wide range of quality. Evidence before claims means applying active skepticism to AI-generated analysis and design — not treating confident-sounding output as verified truth.

The research version: The OWL constraint generation work was organized around this model: generate constraints from empirical evidence, tag generated constraints as defaults (revisable on new evidence) rather than permanent facts, and maintain honesty about the limits of what the evidence supports. The alternative — assert the most plausible constraint with full confidence — produces a system that looks comprehensive but cannot be trusted when it encounters conditions outside its training distribution.

→ Related: Patterns · Engineering · Leadership