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.