Abstraction Ladder

Why it matters

Engineers over-explain implementation to executives; leaders hand down strategy without operational clarity. Students memorise definitions without connecting them to real decisions. The Abstraction Ladder gives you language to climb up or down on purpose - essential for AI projects where technical choices have business consequences.

• Bottom rung: code, equations, API parameters, dataset fields - necessary for building.
• Middle rung: architectures, data flows, team processes, model selection trade-offs - necessary for coordinating.
• Top rung: user outcomes, risk, cost, competitive advantage - necessary for deciding whether to build.
• You cannot stay on one rung for every conversation - match the audience and the decision at hand.
• Climbing the ladder too fast produces hand-wavy strategy; descending too fast produces solutions without purpose.

1. 1

   Before a meeting, decide which rung the decision lives on and prepare one level of detail above and below.

2. 2

   When stuck in implementation, climb up: "What user outcome does this line of code serve?"

3. 3

   When strategy feels vague, climb down: "What would we ship in two weeks to test this bet?"

4. 4

   Document the same feature at two rungs - a one-paragraph executive summary and a technical design note.

5. 5

   In AI discussions, separate "what the model does" (middle) from "what the business gains" (top) and "how tokens are processed" (bottom).

Real-world examples

• Using top-rung language ("we need AI") without middle-rung plans (data, evaluation, ownership).
• Dismissing bottom-rung concerns as "too technical" when they reveal feasibility limits.
• Assuming everyone will naturally meet in the middle without a facilitator translating.
• Teaching only at one rung - pure theory without application, or tutorials without conceptual framing.