Techniques & Models
This chapter is the EMBoK's reference library: every named model, technique, and law cited in the domain chapters, collected in one place — what each is, when to reach for it, and where it stops working. Two cautions before using it. First, these are tools for reasoning, not doctrine: the exams never ask you to name a framework; they ask whether you can make the call a framework would have helped you make. Second, every model here has a domain of validity — knowing a tool's limits is the difference between judgment and cargo-culting, and exam distractors are frequently a real technique applied outside its domain.
Entries are grouped by the work they serve. Each cross-references the competencies where it appears in context.
Leading people
Situation–Behaviour–Impact (SBI)
A feedback structure that anchors feedback in a specific situation, describes observable behaviour rather than inferred character, and names the impact. It works because it removes the two triggers of defensiveness: generalisation ("you always…") and diagnosed intent ("you don't care about…"). Used throughout competency 1.2, including feedback to managers about their leadership. Use it when: any corrective or reinforcing feedback, at any seniority — including upward. Limits: a structure, not a substitute for courage; SBI-shaped avoidance is still avoidance. For patterns (not single moments), name the pattern with several SBI-shaped examples.
Situational leadership
The model (Hersey & Blanchard) of flexing leadership style — directing → coaching → supporting → delegating — to a person's competence and confidence on the task at hand. The core insight: leadership style is a variable, not a personality. Use it when: calibrating how much structure to give anyone new to a task — including a new manager, or a new executive. Limits: style must track the task, not the person's title or overall seniority; misread it and you micromanage experts or abandon novices.
Task-relevant maturity
Andy Grove's sharper version of the same idea (High Output Management): how much direction someone needs depends on their experience with this specific kind of work. A senior engineer commanding their first incident has low task-relevant maturity at incident command. Use it when: deciding delegation scope and support level — the backbone of competency 1.1 at every altitude. Limits: maturity must be reassessed as tasks change; yesterday's calibration quietly becomes today's mismatch.
Structured interviews and calibration
Consistent questions mapped to a defined rubric, scored independently before discussion, with interviewers calibrated on what "meets the bar" means. Markedly more predictive and more equitable than unstructured conversation — the foundation of competency 1.3. Use it when: any hiring or promotion evaluation; calibration also governs performance ratings across teams (1.4 Professional). Limits: rubrics encode their authors' biases if unexamined; structure reduces noise, it does not by itself remove bias — that takes deliberate design and diverse panels.
30/60/90 onboarding
Framing a new hire's first quarter as explicit 30-, 60-, and 90-day outcomes, paired with an early real contribution, a named guide, and documented context. Use it when: every hire, scaled to seniority — for senior leaders the 90 days are mostly integration: norms, relationships, how decisions really get made (1.3 Expert). Limits: a plan is not a relationship; the framing fails without genuine support behind it, and senior-hire failures are usually integration failures no checklist catches alone.
Skip-level one-on-ones
Regular 1:1s between a leader and the people who report to their reports. Their purpose is unfiltered signal — team health, issues a manager might miss — and visible accessibility. Use it when: leading through managers (1.5 Professional onward); essential whenever your picture of a team comes entirely from its manager. Limits: never a decision bypass or a shadow management channel — used that way they destroy the manager they were meant to inform. Protect sources when acting on what you hear.
Growth ladders and competency matrices
Explicit descriptions of what each level looks like per competency, making "what does the next level require?" concrete, and promotion decisions comparable across people and teams. Use it when: career conversations (1.5), promotion fairness across teams, and calibration. Limits: ladders describe the what, not a schedule; they decay into checkbox-collection if levels are treated as tenure milestones rather than demonstrated judgment.
Span of control
The number of direct reports a leader can effectively serve. There is no magic number: it is a function of the reports' experience, the stability of the work, and how much coordination each report requires (1.1 Professional). Use it when: designing org structures; diagnosing an overloaded manager or an executive bottleneck. Limits: optimising the number without the context produces neat charts and failing teams; a span that works in steady state fails during change.
Running delivery
Cost of delay
The value lost per unit time that a piece of work remains unshipped. Sequencing by cost of delay (rather than effort, age, or advocacy volume) is the economic core of prioritisation (2.1). Use it when: ordering a queue, arguing a priority call, exposing the real price of "just one more thing first." Limits: most delay costs are estimates; treat them as explicit assumptions to argue about — false precision here just launders opinion into arithmetic.
Urgent vs. important (the Eisenhower distinction)
Separating what demands attention now from what matters most — the observation that urgency systematically crowds out importance unless deliberately resisted. Use it when: triaging demand on a team (2.1 Associate); diagnosing a calendar or a roadmap that is all reaction. Limits: a lens, not a scheduler; real work is often both, and the discipline is funding the important-but-quiet work, not labelling quadrants.
Work-in-progress limits and flow
Constraining how much is in flight so the most important things finish sooner. The counterintuitive core of flow thinking: starting less finishes more, and a system loaded to 100% utilisation has no capacity to absorb variance — busy-looking is not effective (2.1 Professional). Use it when: a team, department, or portfolio where everything is started and nothing ships; whenever "we need more people" might actually mean "we need less WIP." Limits: limits need enforcement at intake, or they become decoration; and slack must be defended as capacity, not harvested as laziness.
Cycle time and historical forecasting
Using how long work actually takes (measured) rather than how long people hope it will take (estimated) as the basis of forecasts. History beats optimism (2.2). Use it when: forecasting, recalibrating chronic over- or under-committers, replacing estimation theatre. Limits: history predicts only work resembling the past; novel work still needs de-risking spikes, and a cycle-time distribution is a range — quoting its average as a date reinvents the original sin.
The cone of uncertainty
Estimates are least accurate at the start of work — when you know the least — and narrow as reality is discovered. Corollaries: estimate in ranges, slice work small, de-risk the fuzziest parts first, and re-forecast as the cone narrows (2.2). Use it when: setting expectations at project start; explaining why an early "date" is a range wearing a costume. Limits: the cone narrows only if you do the discovering; unexamined uncertainty stays wide forever, and the model excuses nothing about failing to re-forecast once you know more.
One-way vs. two-way doors
Classifying decisions by reversibility: deliberate carefully on the hard-to-reverse (one-way doors), move fast on the reversible (two-way). The single most-used decision filter in this document (2.4, 4.1, 4.5). Use it when: allocating scrutiny; setting intervention thresholds; staging big bets so more of them become reversible. Limits: reversibility is often misjudged — "temporary" choices calcify (data models, contracts, vendors); when in doubt, treat the door as one-way until proven otherwise.
Incident command
A defined coordination role during incidents: one person owns coordination and communication so responders can focus on the fix. Priorities during an incident: restore service, communicate, then diagnose (2.3). Use it when: any incident beyond trivial — and decided before the incident, because during one is too late. At department scale, cross-team incidents need a commander with cross-team authority. Limits: a coordination structure, not a technical rescue; a commander who starts debugging has vacated the role.
Blameless post-mortems
Incident reviews that ask how the system allowed the failure and what to change — process, tooling, guardrails — rather than who to blame. The mechanism that makes honesty about failure safe, and therefore makes reliability improvable (2.3, 5.1). Use it when: after every significant incident or failed launch — most critically when stakes are highest and a senior person is involved, because that review is where the culture is actually written. Limits: blameless is not consequence-free — patterns of recklessness or unaccountability are performance matters handled separately; and a review whose actions die in a backlog is a ritual, not a fix.
Pre-mortems
Before committing to a plan, assume it has failed and ask the team to write down why. Legitimises dissent, surfaces risks optimism was suppressing, and is dramatically cheaper than the post-mortem it prevents. Use it when: the start of any significant initiative; especially where enthusiasm is high and disagreement has been quiet. Limits: produces candour only where safety already exists; in a low-trust room it generates the same silence as every other meeting.
DORA metrics
The research-validated delivery measures (from the DORA program, published in Accelerate): deployment frequency and change lead time (throughput), change failure rate and failed-deployment recovery time (stability), plus rework rate (2024). Deliberately team-level measures of the delivery system (3.5). Use it when: assessing and trending delivery health — a team against itself, or org-level trends at Expert altitude. Limits: never individual performance measures, and never a cross-team leaderboard; the moment they become targets, Goodhart's Law applies.
Error budgets and SLOs
From Google's Site Reliability Engineering practice: define a service-level objective (SLO), and treat the tolerable shortfall — the error budget — as a spendable resource that gates risk-taking: budget available, ship; budget exhausted, stabilise. Converts the reliability-versus-velocity argument into a shared, pre-agreed rule (2.3, 5.5). Use it when: recurring ship-versus-stabilise conflicts; making "reliability first" operational instead of decorative. Limits: only as good as leadership's willingness to obey it when inconvenient — shipping through an exhausted budget in front of the whole org teaches the real policy (5.5 Expert).
Contract testing
Automated tests that verify the agreement between a service and its consumers, catching breaking changes at the boundary before integration does. The technical half of "ownership and contract at the boundary" (2.4 Professional, 4.3). Use it when: teams repeatedly break each other's integrations; any widely-consumed API. Limits: verifies the contract that was written down; it cannot invent interface discipline (versioning, deprecation policy) where none exists.
Strategy and investment
Outcome vs. output framing
Framing work as the change you want in the world (outcome) rather than the thing you build (output). Outcomes define success and free the path; outputs do neither. The core translation move of 3.1. Use it when: goal-setting at every level; testing a roadmap item ("why is this here?"); writing OKRs that aren't task lists. Limits: some work is legitimately output-shaped (compliance, contractual); and an outcome nobody can influence is a wish, not a goal.
Core vs. context
Build what differentiates your business and where you need control (core); buy or adopt the commodity capabilities (context), freeing scarce engineers for differentiating work. The backbone of build-vs-buy (3.4). Use it when: any build/buy/partner decision, tested alongside total cost of ownership and — at Expert altitude — strategic control and dependency risk. Limits: the boundary moves — yesterday's differentiator commoditises; and "core" is about differentiation, not importance: email is important and almost never core.
Total cost of ownership (TCO)
The full lifetime cost of a capability: build cost plus forever-maintenance, or purchase price plus integration, lock-in, and exit cost. The corrective to sticker-price reasoning (3.4). Use it when: build-vs-buy, platform investment, vendor selection — any "cheaper" claim. Limits: long-horizon costs are estimates; the discipline is naming them explicitly, not computing them precisely.
Sunk-cost discipline
What has been spent is gone and argues for nothing; only the forward-looking comparison — value remaining versus cost remaining, against alternatives — counts. Governs half-done migrations, championed bets, and public commitments (3.4, 1.4 Expert). Use it when: any "we've come too far to stop" argument — especially when the bet is your own. Limits: the inverse error exists: abandoning sound long bets at the first fashionable alternative. Changed fundamentals justify switching; novelty does not.
Goodhart's Law
When a measure becomes a target, it ceases to be a good measure — people optimise the number, not the thing it stood for. The governing hazard of all measurement (3.5, 2.5 Expert). Use it when: designing any metric, incentive, or dashboard; diagnosing healthy-looking activity with flat outcomes. Limits: not an argument against measuring — it is an argument for balanced sets, outcome-anchored measures, and metrics as conversation-starters rather than verdicts.
Strategy / vision / roadmap distinction
A vision names the destination and why it matters; a strategy is a diagnosis plus a coherent set of choices — including what you will not do; a roadmap is the current sequence of bets that follows. (After Rumelt's Good Strategy Bad Strategy: diagnosis, guiding policy, coherent action.) A strategy that keeps every option open, or that everyone instantly agrees with, has decided nothing (3.1 Expert). Use it when: writing or reviewing any strategy document; diagnosing a "strategy" that is actually a wish list or a feature list. Limits: the artifacts matter less than the choices; a brilliant strategy nobody can recite governs nothing.
Technical stewardship
Conway's Law
Systems mirror the communication structures of the organisations that build them. Its practical corollary (the "inverse Conway manoeuvre," elaborated in Team Topologies): design the org to induce the architecture you want — because you will get an architecture shaped like your org chart either way (4.1, 2.4 Expert). Use it when: any reorg, any architecture decision, and any chronic boundary friction that process fixes haven't cured. Limits: directional, not deterministic; it tells you structure and system co-evolve, not which precise structure to pick.
The technical-debt quadrant
Martin Fowler's distinction: debt is deliberate or inadvertent, and prudent or reckless. Deliberate-prudent debt is a sensible trade, taken knowingly; reckless debt is just mess with a flattering name. The vocabulary that makes debt manageable (4.2). Use it when: classifying debt before arguing about it; setting repayment priority by interest rate — impact on delivery and risk versus cost to fix. Limits: classification changes nothing by itself; debt management is the visible tracking, priced impact, and scheduled repayment built on top of it.
The paved road
A well-supported default platform and toolchain that makes the good path the easiest path — teams may leave it, but they accept the ownership cost themselves. How large orgs get consistency without mandates (4.3 Expert). Use it when: balancing standardisation against autonomy at scale; replacing tool-mandate wars with adoption economics. Limits: the road must actually be good — a paved road nobody would choose voluntarily is a mandate wearing a costume, and earns the same resentment.
Aligned autonomy
Direction, priorities, and boundary standards set centrally; methods left to teams. The operating principle that resolves the centralisation-versus-autonomy argument at scale (2.5, 4.3). Use it when: designing an operating cadence, deciding what to standardise, diagnosing an org that is either chaotically fragmented or suffocatingly uniform. Limits: requires genuinely clear direction — autonomy aligned to ambiguity is just chaos with better branding.
Architecture review forums
A standing forum where significant designs get cross-team scrutiny early — most valuable when it advises, teaches, and catches cross-team consequences; least valuable as a gate every change must pass (4.1 Professional). Use it when: keeping architecture coherent across autonomous teams; growing engineers' design judgment by exposure. Limits: becomes a bottleneck and a rubber stamp the moment it reviews everything; scope it to decisions with cross-team or irreversible consequences.
Shaping culture
Psychological safety (Edmondson)
A shared belief that the environment is safe for interpersonal risk-taking — admitting error, asking, challenging. Defined by Amy Edmondson; identified by Google's Project Aristotle as the strongest differentiator of effective teams; repeatedly linked by DORA research to delivery outcomes. Independent of standards: the goal is high safety and high standards (5.1). Use it when: always — it is the precondition for every honest signal this document depends on: bad news, dissent, blameless reviews, upward feedback. Limits: not niceness, not comfort, and not the absence of conflict; measured badly it flatters itself — in a genuinely unsafe org, even anonymous surveys read too high (5.1 Professional).
Intrinsic motivation — autonomy, mastery, purpose
The finding (popularised by Daniel Pink's Drive) that lasting motivation for complex work comes from autonomy, mastery, and purpose; pay and perks prevent dissatisfaction but do not create engagement (5.4). Use it when: designing roles, diagnosing disengagement, resisting the reflex to solve morale with benefits. Limits: intrinsic motivation assumes fair compensation as the floor — purpose is not a salary substitute; and chronic overwork burns through all three drivers regardless.
Glue work
The essential, under-recognised work that makes teams function — coordination, documentation, onboarding, unblocking others (named by Tanya Reilly's "Being Glue"). Alongside it, the office housework: notes, scheduling, on-call coverage. Both tend to fall along predictable, inequitable lines unless managed (5.3). Use it when: auditing who does what; designing recognition and promotion criteria that don't punish the people holding the team together. Limits: the fix is valuing and distributing the work, not eliminating it — a team with no glue does not become efficient; it becomes unstuck.
RACI
A decision- and responsibility-clarifying map: who is Responsible, Accountable, Consulted, Informed. Useful shorthand for the recurring failure of everyone assuming someone else owns it. Use it when: cross-team initiatives, incident roles, any recurring "who decides this?" friction (1.1, 2.4). Limits: heavyweight if applied to everything; the durable version is the habit — every decision has one accountable owner — not the matrix.
Culture = what is rewarded, tolerated, and punished
Less a named model than the operating definition this document uses (5.5): culture is the accumulated pattern of actual behaviour — set by what leaders visibly do, reward, promote, and tolerate, far more than by stated values, policies, or announcements. Use it when: reading any org's real culture; planning culture change (realign the systems — hiring, promotion, recognition, consequences — behind the behaviour you want). Limits: implies patience — culture change is a multi-quarter realignment, and a single visible exception (the tolerated brilliant jerk, the value waived for a launch) can undo quarters of work.