What this framework is
Every Engineering Management Academy examination is built against this framework. It names the twenty-nine competencies an engineering manager is assessed on, grouped into five domains, and it is published in full so that a candidate knows exactly what is examined and an employer knows exactly what a credential means.
The framework is a standard, not a syllabus. It says what capability looks like; it does not say how to acquire it. The Academy sells no training and endorses none, which is what allows the standard to be independent of any course, and why the credential certifies capability rather than attendance.
Three documents make up EMA Standard v3.0 and are released together:
- This framework: the competencies and their permanent IDs.
- The EMA Body of Knowledge: one knowledge unit per competency, written for judgment rather than recall, plus two cross-cutting chapters.
- The Exam Content Outlines: one per certification, stating for every competency how many questions it carries, what a certified holder can do, and what kinds of situations the questions present.
The five domains
Every examination weights the five domains equally: 20% each, which is 12 questions of 60 on EMA-I, 15 of 75 on EMP-II, and 18 of 90 on EME-III. The balance is deliberate. Engineering management fails at its weakest dimension; a brilliant strategist who cannot give feedback, or a beloved coach who cannot ship, is not yet the complete manager this credential certifies.
Within a domain, the questions are not spread evenly across competencies. Each certification's Exam Content Outline states the distribution for that level, and it changes with level: a competency that carries no questions on EMA-I may carry a third of its domain on EME-III.
Domain 1: People Leadership
Building, growing and retaining effective engineers, teams and, at scale, the leaders of teams.
| ID | Competency | One line |
|---|---|---|
| PL-1 | Delegation, ownership, and decision rights | matching scope to capability, making authority explicit, not taking work back |
| PL-2 | Feedback and difficult conversations | timely, specific, behaviour-anchored, in both directions |
| PL-3 | Hiring and onboarding | structured evaluation, calibrated standards, assessing capability rather than tool access |
| PL-4 | Performance management | expectations, support, honest consequences, and fair process |
| PL-5 | Career development and growth paths | one-on-ones, promotions, the Staff+ track, and the IC/manager choice |
| PL-6 | Leading through leaders | selecting, developing, and holding accountable the managers who report to you |
Domain 2: Delivery & Execution
Turning intent into shipped, reliable software, predictably, under constraints that never go away.
| ID | Competency | One line |
|---|---|---|
| DE-1 | Prioritisation under constraint | sequencing, trade-offs, saying no |
| DE-2 | Estimation, planning, and honest commitments | managing uncertainty rather than chasing accuracy |
| DE-3 | Reliability, incident response, and operational ownership | on-call, SLOs, postmortems, learning from failure |
| DE-4 | Managing scope, risk, and dependencies across workstreams | seeing the whole, naming the risk, negotiating the boundary |
| DE-5 | Designing how work flows | process selection, developer experience, and AI-assisted workflows |
Domain 3: Strategy & Vision
Connecting engineering effort to business outcomes and direction, and shaping the organisation that does the work.
| ID | Competency | One line |
|---|---|---|
| SV-1 | Engineering strategy | translating business goals into technical direction, and writing it down |
| SV-2 | Communicating and partnering across functions | product, design, executives, and non-engineering stakeholders |
| SV-3 | Roadmapping | balancing product delivery against platform and quality investment |
| SV-4 | Engineering economics | headcount, budget, cost of delivery, vendors, and build/buy/AI decisions |
| SV-5 | Engineering metrics and measurement | choosing, interpreting, and not gaming them, including measuring AI impact |
| SV-6 | Organisational design and leading change | team structures, ownership boundaries, reorgs, and transitions |
Domain 4: Technical Judgment
Exercising sound engineering judgment without doing the engineering, and owning the technical responsibilities that cannot be delegated away.
| ID | Competency | One line |
|---|---|---|
| TJ-1 | Evaluating architectural decisions and their organisational consequences | trade-offs, reversibility, and who has to coordinate because of this |
| TJ-2 | Technical debt | recognising, quantifying, and scheduling repayment |
| TJ-3 | Code review and quality standards | including standards for AI-generated code |
| TJ-4 | Technical credibility and intervention | staying close enough to judge, and knowing when to step in |
| TJ-5 | AI-assisted engineering | adoption, governance, capability-building, and risk |
| TJ-6 | Security, privacy, and compliance as engineering responsibilities | owned by engineering, not delegated to a function |
Domain 5: Culture & Coaching
Shaping the environment in which good engineering happens, developing the judgment of the people in it, and sustaining the manager who does both.
| ID | Competency | One line |
|---|---|---|
| CC-1 | Psychological safety and productive conflict | safe to speak, expected to disagree, committed once decided |
| CC-2 | Coaching versus directing | developing judgment in others |
| CC-3 | Inclusive practices and equitable opportunity distribution | who gets the stretch work, the visibility, and the benefit of the doubt |
| CC-4 | Motivation, recognition, and sustainable pace | including in distributed and hybrid teams |
| CC-5 | Values, integrity, and ethical judgment under pressure | what you do when the right call is the costly one |
| CC-6 | Self-management | the manager's own time, energy, boundaries, and resilience |
How the three certifications use one framework
All three certifications draw on the same twenty-nine competencies. EMA-I examines twenty-seven of them: leading through other leaders (PL-6) and organisational design (SV-6) begin at EMP-II. What changes between them is not the list but the scope at which judgment is exercised: the object being decided about, the time horizon, the ambiguity, the consequence of error, who the manager acts through, and how late the information arrives. An Associate delegates a project; a Professional delegates a team; an Expert delegates the design of the organisation. The competency is the same. The judgment is not.
The Body of Knowledge treats this once, in the chapter How Judgment Scales,
rather than three times per competency. Each knowledge unit carries a short
scaling note and tags its signals of strong and weak practice with the scope
where they apply ([team], [org], [exec]) and each Exam Content Outline
states, per competency, what a certified holder at that level can do.
| Certification | Scope of judgment | Typical role | Questions · time · pass standard |
|---|---|---|---|
| EMA-I Associate | one team, direct reports | first-line engineering manager or team lead | 60 · 90 minutes · 70% |
| EMP-II Professional | several teams, usually through other managers | manager of managers, senior manager, group lead | 75 · 105 minutes · 75% |
| EME-III Expert | an engineering organisation, largely through systems and other leaders | director, VP, head of engineering | 90 · 120 minutes · 80% |
The certifications are cumulative. A Professional is expected to meet every Associate indicator as well as the Professional ones; an Expert, all three.
Why these twenty-nine
The framework is deliberately not a list of everything a manager does. Each competency earns its place by being a distinct judgment (a kind of decision with its own failure modes, its own tensions and its own evidence) that a scenario question can test. Where two competencies turned out to be one judgment, they were merged (TJ-4). Where one competency was carrying two, it was split (PL-6 and SV-6 out of the old delegation and performance material). Where the job had changed since v1.0 and no competency covered the change, one was added (TJ-5, TJ-6, CC-6).
The cross-cutting chapters (How Judgment Scales and Distributed and Hybrid Work) are not competencies and are not examined directly. They are referenced from the competencies they touch.
About this version
v3.0, published with EMA Standard v3.0. The previous framework was v1.0 (June 2026); the Body of Knowledge was v2.0. From this release the framework, the Body of Knowledge and the Exam Content Outlines are versioned as one standard: a major version revises all three together and they share its number. A minor version revises one document and carries its number only there, as Body of Knowledge v3.1 does; this framework stays at v3.0. There is no framework v2.0; the number was skipped so that "v3.0" means the same release wherever it appears.
What changed from v1.0. Five domains and their equal weighting are unchanged, as are the five indexed domain pages. The twenty-five competencies of v1.0 became twenty-nine: twenty-three continue with the same scope or a wider one, two merged into one, and five are new. Every change is listed, with its reason, in the changelog.
What it means for existing credentials. A credential records the
framework version it was examined against; every credential issued before
the v3.0 effective date carries 1.0, and the public verification page and
API show it. Nothing about an existing credential changes. Examinations
continue to draw from the same five domains at the same weights; the
per-competency distributions in the Exam Content Outlines describe the
standard the question bank is being developed toward, and the outlines say so
plainly.
Governance. The framework is revised on a stated cadence (a major version at most annually, minor corrections quarterly) and a major revision is preceded by a public comment period. Development of examination questions is kept separate from development of the Body of Knowledge, so that the study material can never quietly become the answer key.