Skip to content
Body of Knowledge · Cross-cutting chapter

How Judgment Scales

The single treatment of altitude: how one competency changes with the scope at which judgment is exercised, and how to read the scope tags.

12 min read · updated 2026-09-22
Scope tagsteam one team, direct reportsorg several teams, through managersexec an engineering organisationHow to read them

Why one chapter instead of seventy-five bands

The three certifications assess the same twenty-nine competencies. What separates an Associate from a Professional from an Expert is not which competencies they hold but the scope at which each one is exercised. The previous edition of this standard expressed that by writing every competency three times, once per level. Readers found the bands repetitive, and the repetition hid the real pattern: scope changes every competency in the same handful of ways. This chapter states those ways once. Each knowledge unit then carries a short scaling note and tags its signals of strong and weak practice with the scope where they apply, and the Exam Content Outlines say what each level's questions expect.

Read this chapter before the domain units. It teaches the pattern every unit follows, and it is the key to the scope tags.

The six dimensions of scope

Scope is not seniority and not headcount. A manager with thirty reports in one team is still exercising team-scope judgment; a director with twelve people across three teams is not. Scope is what changes about a decision when the object of the decision gets larger. Six things change, and they change together.

1. The object of judgment

The most useful question about any competency is: what is being decided about? At team scope the object is concrete and close — a task, an engineer, a sprint, a service, a conversation. At organisational scope the object is a class of those things — a team's charter, a manager's judgment, a delivery system, a platform, a hiring bar. At executive scope the object is the system that produces the class — the structure that decides who owns what, the leadership pipeline, the operating cadence, the technical strategy, the culture. The table in the next section gives the object for every competency. It is the single most important thing to understand about how a competency scales, because the same instinct applied to the wrong object is the most common way strong managers fail after promotion.

2. Time horizon

Team-scope decisions resolve in days or weeks; their feedback arrives before the next similar decision. Organisational decisions play out over quarters: a manager appointment, a team split, a platform bet. Executive decisions play out over years, and some of the most consequential — a technical strategy, an organisational design, a culture — are only judged in hindsight by people who will not know what the alternatives were. The longer the horizon, the less the decision can be corrected by iteration and the more it must be right on first principles.

3. Ambiguity

At team scope the goal is usually given and the question is how to reach it. At organisational scope the goals of different teams conflict and the question is which to favour. At executive scope the goal itself is often unclear, contested or shifting, and part of the work is deciding what the question is. Strong judgment at each level is comfortable with the ambiguity that level carries and does not manufacture false certainty to escape it — nor does it import ambiguity the level does not have. An Associate who treats a clear sprint goal as a strategic question is as mis-scoped as an Expert who treats a strategic question as a scheduling problem.

4. Consequence and reversibility

A bad delegation costs a week and teaches everyone something. A bad manager appointment costs a team a year. A bad organisational design costs a company the ability to execute for as long as it stands. As scope widens, the cost of error rises and the chance to reverse falls, so deliberation should be spent where the door is one-way. The complementary failure is real too: executives who bring executive-grade deliberation to every reversible decision slow the whole organisation to their own pace.

5. Who you act through

At team scope you act directly: you have the conversation, you review the design, you make the call. At organisational scope you act mostly through the managers who report to you, and your leverage comes from what you delegate to them, how you develop them, and what you hold them to. At executive scope you act largely through systems — structures, cadences, standards, incentives — and through leaders you rarely see day to day. Each step removes you from the work and adds a layer whose judgment you must develop and trust. Every competency in this standard has a "through others" form, and the temptation to skip the layer and act directly is the signature failure of the newly promoted at every level.

6. Information latency and filtering

The further you are from the work, the later and more filtered your information arrives. A team lead hears about a problem the day it happens. A director hears a version of it in a weekly update, after the manager has decided how to present it. An executive hears a narrative, weeks later, shaped by everyone it passed through. Strong judgment at scope compensates deliberately: skip-level conversations, direct observation of artifacts, metrics that do not pass through a person, and a visible reaction to bad news that makes it safe to deliver early. Weak judgment at scope mistakes the absence of bad news for its absence.

The object of judgment, competency by competency

The table below is the reference the scaling note in each unit points to. For each competency it names what is being decided about at each of the three scopes. Read down a column to see a level; read across a row to see how one competency changes shape.

ID Competency Team Organisation Executive
PL-1 Delegation, ownership, and decision rights a task or project, and the authority that goes with it a team's charter, and a manager's decision rights the organisation's decision-rights design: who decides what, at which level
PL-2 Feedback and difficult conversations an engineer's behaviour and its impact a manager's leadership, and feedback that crosses team boundaries a leader's performance, and the feedback culture the organisation rewards
PL-3 Hiring and onboarding an individual hire and their first quarter a team's hiring bar, and the appointment of managers the hiring system: calibration across the organisation, senior and executive appointments
PL-4 Performance management an engineer's performance against clear expectations a manager's performance, including the performance of their team the performance system: fairness, consistency and consequences across the organisation
PL-5 Career development and growth paths an individual's growth and next step the growth paths available across teams, and who gets them the career architecture: levels, tracks, and the leadership pipeline
PL-6 Leading through leaders — (not exercised at team scope) the managers who report to you: selection, development, accountability the leadership team as a system, and the leaders of leaders
DE-1 Prioritisation under constraint the team's queue competing priorities across teams, and the shared bottleneck the portfolio: which bets the organisation makes and which it declines
DE-2 Estimation, planning, and honest commitments the team's forecast and its commitment commitments that depend on several teams, and the truthfulness of rolled-up status the organisation's planning cadence and the credibility of its commitments to the business
DE-3 Reliability, incident response, and operational ownership an incident in progress, and one service's operational health reliability across services, ownership gaps, and the on-call system reliability as a strategic property: investment, risk appetite, and the resilience the business assumes
DE-4 Managing scope, risk, and dependencies one workstream's scope and risks dependencies between teams, and risks that fall between them systemic risk: the dependencies the organisation does not see, and the programmes that span it
DE-5 Designing how work flows the team's process and tools consistency and autonomy across teams; the developer platform the organisation's operating system: cadence, standards, and the investment in developer experience
SV-1 Engineering strategy translating a given strategy into the team's work a department strategy that connects several teams to business outcomes the engineering strategy itself, argued at the executive table
SV-2 Communicating and partnering across functions the team's product and design partners; a stakeholder pressing for a date department-level partners; executives who need trade-offs explained the executive team and the board; engineering's standing in the company
SV-3 Roadmapping the team's roadmap and its platform debt a department roadmap balancing several teams' product and platform work multi-year investment across product, platform and quality
SV-4 Engineering economics a build-versus-buy call for the team; the team's cost a department budget and headcount plan; vendor decisions the economics of engineering as a whole: cost of delivery, capital allocation, make/buy/AI at scale
SV-5 Engineering metrics and measurement the team's metrics and what they hide metrics that compare or aggregate teams, and the gaming they invite the measures the business uses to judge engineering, including AI's effect on them
SV-6 Organisational design and leading change — (not exercised at team scope) team boundaries and ownership within a department; a reorg of several teams the shape of the organisation: structure, transitions, mergers, and the change that follows
TJ-1 Evaluating architectural decisions one team's design decisions and their reversibility architecture across teams: standards at boundaries, platform bets the technical strategy: the bet-the-company decisions and their organisational consequences
TJ-2 Technical debt the team's debt and its repayment schedule systemic debt that no single team owns; department-level investment debt as a strategic liability: the platform's runway and the business's exposure
TJ-3 Code review and quality standards the team's review practice and quality bar consistent standards across autonomous teams, including for AI-generated code the organisation's quality posture and the systems that maintain it
TJ-4 Technical credibility and intervention when to step into a design or a fix, and when not to staying close enough to several teams' work to judge it without doing it technical credibility at executive level: what to track personally, and when to intervene at all
TJ-5 AI-assisted engineering how the team uses AI assistance, and the review it needs adoption and governance across teams; capability-building the organisation's AI strategy for engineering: investment, risk, and what changes about the work
TJ-6 Security, privacy, and compliance the team's security practice and a vulnerability in its service a class of gap across several teams; ownership of the fix security, privacy and compliance as organisational risk, owned at executive level
CC-1 Psychological safety and productive conflict safety in the room: how you react to bad news and dissent safety between teams and in the managers you lead; conflict between teams trust in leadership across the organisation, and what leadership visibly does
CC-2 Coaching versus directing developing an engineer's judgment rather than supplying the answer coaching the coaches: developing managers' judgment developing leaders' judgment, and a leadership culture that coaches
CC-3 Inclusive practices and equitable opportunity who on the team gets the stretch work and the visibility equity across teams: promotion and opportunity patterns the organisation's opportunity structure and the data that reveals it
CC-4 Motivation, recognition, and sustainable pace one team's motivation and pace, in the room or distributed motivation and pace across teams; recognition that crosses boundaries the organisation's relationship to pace: what leadership rewards, and what it survives
CC-5 Values, integrity, and ethical judgment the costly right call in front of the team holding managers to the values; the brilliant-jerk decision at department scale values under company-level pressure: what leadership does when it is expensive
CC-6 Self-management your own time, energy and boundaries as a first-line manager your own effectiveness as the layer between teams and executives your own resilience and boundaries under executive-scale consequence and visibility

Two competencies, PL-6 and SV-6, have no team-scope object. Leading through leaders requires leaders to lead through, and organisational design requires an organisation to design. Both are therefore assessed from EMP-II upward; the EMA-I Exam Content Outline lists them explicitly as not assessed.

Reading the scope tags

Each unit's judgment section lists signals of strong practice and failure modes as one list, and tags an item with the scope where it applies:

  • [team] — one team, direct reports; the manager acts directly.
  • [org] — several teams, usually through other managers.
  • [exec] — an engineering organisation, largely through systems and other leaders.

An item with no tag applies at every scope. An item tagged [org] [exec] applies at both of those and not at team scope. The tags map onto the certifications — EMA-I assesses [team], EMP-II adds [org], EME-III adds [exec] — but they are a property of the judgment, not of the reader. A first-line manager reading an [exec] item is reading about the scope their own manager's manager works at, which is useful for understanding the decisions that arrive from above and for knowing what the next level of the job actually is.

The Exam Content Outlines use the same three words as the scope of every proficiency indicator. Because the certifications are cumulative, a Professional is held to every team indicator as well as every org one.

What does not scale

Some things do not change with scope, and it is worth being explicit. The obligation to tell the truth about status does not become more negotiable with seniority; if anything the consequence of shading it grows. The distinction between an estimate and a commitment is the same at every level. The reaction to bad news that makes it safe to deliver is the same reaction whether the messenger is an engineer or a vice-president. And the question that tests any plan — pick any item and ask the person doing it why it is there — works at every altitude.

Judgment scales. Integrity does not need to.