Why one chapter instead of seventy-five bands
The three certifications draw on the same twenty-nine competencies, and EMA-I examines twenty-seven of them (PL-6 and SV-6 begin at EMP-II). An Associate, a Professional and a Leader hold the same competencies; what separates them is 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, which is that 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 neither seniority nor 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 to ask of 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 it is a class of those things, such as a team's charter, a manager's judgment, a delivery system, a platform or a hiring bar. At executive scope it is the system that produces the class, whether that is the structure that decides who owns what, the leadership pipeline, the operating cadence, the technical strategy or the culture. The table in the next section gives the object for every competency. Of everything about how a competency scales, this matters most, because applying the same instinct to the wrong object is the commonest way strong managers fail after promotion.
2. Time horizon
Team-scope decisions resolve in days or weeks, and 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. Some of the most consequential, such as a technical strategy, an organisational design or a culture, are judged only in hindsight, by people who will not know what the alternatives were. The longer the horizon, the less a decision can be corrected by iteration and the more it has to 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. It does not manufacture false certainty to escape it, and it does not import ambiguity the level does not have. An Associate who treats a clear sprint goal as a strategic question is as mis-scoped as a Leader 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 belongs where the door is one-way. The opposite failure exists as well. 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, review the design and 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 takes you further from the work and adds a layer whose judgment you have to develop and trust. Every competency in this standard has a "through others" form. At every level, the newly promoted are most recognisable by the temptation to skip the layer and act directly.
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 on purpose, with 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 hears no bad news and concludes there is none.
The object of judgment, competency by competency
Each unit's scaling note points to the table below. For each competency it names what is being decided about at each of the three scopes. Read down a column to see a level, or 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, and the EMA-I Exam Content Outline lists them explicitly as not assessed.
Reading the scope tags
Each unit's judgment section puts signals of strong practice and failure modes in 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] and EML-III adds [exec]. Even so, they describe the judgment, whoever is reading. A first-line manager reading an [exec] item is reading about the scope at which their own manager's manager works. That helps in understanding the decisions that arrive from above, and in knowing what the next level of the job involves.
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 stay the same at every scope, and they are worth naming. 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 works at every altitude: pick any item and ask the person doing it why it is there.