# Engineering management career ladder
Template from https://www.engineeringmanagement.academy/framework/career-ladder. Each level is also held to every level before it.
- **Level 1 · Team:** One team, direct reports; the manager acts directly.
- **Level 2 · Organisation:** Several teams, usually through other managers.
- **Level 3 · Executive:** An engineering organisation, largely through systems and other leaders.
## People Leadership
| Competency | Level 1 · Team | Level 2 · Organisation | Level 3 · Executive |
|---|---|---|---|
| **PL-1 Delegation, ownership, and decision rights** | • Can delegate an outcome rather than a set of steps, stating the constraints and the level of authority that goes with it.
• Can match the scope of what they hand off to a person's demonstrated capability on that kind of work, with a deliberate stretch and a safety net.
• Can recognise the moment they are about to take delegated work back, and choose support over rescue. | • Can delegate a whole team to a manager (its charter, its decisions, its outcomes) and stay accountable for the result without re-deciding it.
• Can make decision rights explicit across several teams so that a disputed decision has a known owner before the dispute. | • Can design the organisation's decision rights (which decisions are made at which level, and how that is made visible) so that most decisions never reach them.
• Can recognise when decisions are flowing upward because the design is wrong rather than because the people are weak. |
| **PL-2 Feedback and difficult conversations** | • Can give corrective feedback anchored in a specific situation and observable behaviour, and name its impact, without diagnosing intent.
• Can hold a difficult conversation early rather than waiting for a review cycle or hoping the problem resolves.
• Can invite and act on feedback about their own management from the people they lead. | • Can give a manager feedback about their leadership (a pattern across several moments) with the same specificity as feedback about a task.
• Can act on damning skip-level feedback about a manager by establishing the facts before confronting anyone. | • Can give a senior leader feedback about their performance and their effect on the organisation, and follow it with consequences.
• Can shape a feedback culture through what leadership visibly does with bad news. |
| **PL-3 Hiring and onboarding** | • Can run a structured interview against criteria defined before the process starts, and recognise the biases that unstructured evaluation invites.
• Can assess what a candidate can do rather than which tools they were permitted, and distinguish capability from fluency.
• Can design a first ninety days that gives a new hire explicit outcomes, a named guide, and early feedback. | • Can appoint a manager for sound reasons (demonstrated judgment about people, not seniority or retention) and support them through the first six months.
• Can calibrate the hiring bar across several teams so that the same capability earns the same decision regardless of interviewer. | • Can make a senior or executive appointment (including the choice between an unproven internal candidate and a proven external one) and own what the choice commits the organisation to.
• Can run a hiring system that stays calibrated across an organisation and through growth. |
| **PL-4 Performance management** | • Can diagnose whether an engineer's underperformance is a matter of skill, will, or the conditions they were given, before choosing a response.
• Can set expectations explicitly enough that a later performance conversation refers to something the engineer already knew.
• Can follow a fair process to an honest consequence, including a formal one, without avoiding it or rushing it. | • Can manage a manager's performance, including the performance of their team, and distinguish a manager problem from a team problem.
• Can run calibration across teams so that ratings are consistent, and challenge a manager's case that lacks evidence or fair process. | • Can act on a leader's performance problem (including a loyal, long-tenured leader the organisation has outgrown) with fairness and without delay.
• Can design a performance system that is consistent across the organisation and that people trust to be fair. |
| **PL-5 Career development and growth paths** | • Can run a one-on-one that belongs to the report (their growth, their concerns) rather than to the manager's status needs.
• Can respond to a promotion request with evidence, a named gap, and a path, rather than a yes to retain or a no without reasons.
• Can help an engineer weigh the senior individual-contributor track against management without steering them toward the manager's own path. | • Can create growth paths across teams (moves, stretch roles, the senior individual-contributor track) and see who is and is not getting them.
• Can develop a manager's career deliberately, including toward roles that compete with their own. | • Can design the career architecture (levels, the senior individual-contributor track, the leadership pipeline) and detect when it is producing the wrong people.
• Can read succession as a structural property and act on key-person risk before it materialises. |
| **PL-6 Leading through leaders** | *No expectation at this level; the competency starts higher.* | • Can select managers on evidence of judgment about people and delivery, and decline to appoint the strongest engineer by default.
• Can develop the managers who report to them through their own one-on-ones, coaching and honest feedback, rather than by sending them on a course.
• Can hold a manager accountable for their team's outcomes and health without taking the team back from them.
• Can set a span of control and a management structure that lets managers actually manage. | • Can build a leadership team as a system (complementary strengths, clear scopes, shared accountability) rather than a set of individually strong leaders.
• Can develop leaders of leaders, and recognise the signals that a leader is ready for a larger scope before they ask.
• Can hold a senior leader accountable for an organisation's outcomes and health while acting through them, and know when to replace them. |
## Delivery & Execution
| Competency | Level 1 · Team | Level 2 · Organisation | Level 3 · Executive |
|---|---|---|---|
| **DE-1 Prioritisation under constraint** | • Can sequence a team's work by value and cost of delay rather than by who asked loudest or most recently.
• Can say no by surfacing the cost of yes ("we can do X, and Y slips") and let the stakeholder choose.
• Can protect a team's focus against constant reprioritisation, and recognise when too much started work means nothing finishes. | • Can prioritise across several teams against a shared bottleneck, and make the resulting trade-offs visible to every team that loses.
• Can protect several teams' focus from department-level churn without becoming the only person who can say no. | • Can manage the organisation's portfolio (which bets it makes, which it declines, and when it stops one) and communicate the declined ones as clearly as the funded.
• Can hold a portfolio steady against executive-level churn while remaining genuinely open to a change in strategy. |
| **DE-2 Estimation, planning, and honest commitments** | • Can distinguish an estimate from a commitment, and buffer the commitment deliberately rather than promising the estimate.
• Can re-plan openly when a commitment is at risk, giving stakeholders the choice between scope, date and quality rather than absorbing the gap with overtime.
• Can decline to give a date on the spot without an estimate, and say what it would take to give one. | • Can make a commitment that depends on several teams by aggregating uncertainty honestly rather than adding up best cases.
• Can detect status that has been shaded on its way up, and build reporting that surfaces trouble early. | • Can build an organisation-wide planning cadence whose commitments the business can rely on, without demanding a certainty the work cannot provide.
• Can ensure bad news about delivery reaches them in time to act, by design rather than by luck. |
| **DE-3 Reliability, incident response, and operational ownership** | • Can run an incident in progress in the right order (restore service, communicate, then find the cause) and resist debugging while users are down.
• Can lead a blameless postmortem that changes the system rather than naming the person.
• Can treat on-call load and service-level objectives as the team's operational ownership, not an interruption to real work. | • Can establish ownership for a service or a class of failure that falls between teams, before the next incident.
• Can design an on-call system across several teams that is sustainable, and read reliability trends across services rather than incident by incident. | • Can treat reliability as a strategic property (investment, risk appetite, what the business is implicitly assuming) and argue for it at the executive table.
• Can lead the organisation through a major failure (the incident, the communication, the learning, the accountability) in a way that leaves it stronger. |
| **DE-4 Managing scope, risk, and dependencies across workstreams** | • Can name a risk early, with its likelihood and impact, rather than hoping it does not materialise.
• Can manage a dependency on another team by negotiating a timeline and a fallback, before escalating and before building around it.
• Can trade scope before quality when a deadline is fixed, and say so. | • Can see and manage the dependencies between their teams, and the risks that fall between them because each team's view stops at its boundary.
• Can run a programme that spans several teams with a single view of scope and risk, without making every team wait on a central plan. | • Can see the systemic risks and dependencies an organisation does not see (the ones no team's view contains) and build the information flow that surfaces them.
• Can govern programmes that span the organisation without a central plan that every team waits on. |
| **DE-5 Designing how work flows** | • Can choose the lightest process that solves the team's actual problem, and change it when the problem changes.
• Can recognise when a drop in throughput is caused by interruptions and fragmentation rather than effort, and change the flow of work rather than push the people.
• Can introduce AI-assisted tooling to a team's workflow with an explicit view of what it changes about review, testing and ownership. | • Can decide which practices are standard across teams and which are each team's own (aligned autonomy) and explain the boundary.
• Can invest in developer experience and AI-assisted workflows at department scale, measured by what teams can now do rather than by adoption. | • Can design the organisation's operating system (cadence, standards, the developer platform) so that dozens of teams deliver without the executive in the room.
• Can decide the organisation's investment in developer experience and AI-assisted work as a strategic bet, measured by what the organisation can now do. |
## Strategy & Vision
| Competency | Level 1 · Team | Level 2 · Organisation | Level 3 · Executive |
|---|---|---|---|
| **SV-1 Engineering strategy** | • Can translate a business goal into the team's work as outcomes (the change wanted in the world) rather than a feature list.
• Can ensure every engineer can say why their current work matters to the business.
• Can re-derive the team's plan when circumstances change, instead of defending the original list. | • Can write a department strategy with a connecting thesis (why these teams do these things) rather than assemble team wish lists.
• Can defend a strategy against churn and encroachment, and change it when the evidence says so rather than when the pressure does. | • Can author the engineering strategy (a written, arguable thesis connecting technical direction to the business's goals) and argue it at the executive table.
• Can keep a strategy alive as the world changes, distinguishing a change in the evidence from a change in the pressure. |
| **SV-2 Communicating and partnering across functions** | • Can explain a technical trade-off to a non-engineering stakeholder in the language of their outcome, without jargon and without condescension.
• Can partner with product and design as peers whose constraints are real, rather than as a queue of requests.
• Can deliver bad news about a delivery to a stakeholder early, with options, rather than late with excuses. | • Can partner with a product director and a design lead as peers, resolving disagreements about investment with evidence rather than escalation.
• Can represent engineering's trade-offs to executives so that they make an informed choice, and accept the choice when it goes the other way. | • Can communicate engineering's position, risks and trade-offs to the executive team and the board in their terms, and secure decisions rather than sympathy.
• Can build engineering's standing in the company through what it delivers and how it partners, so that it is consulted before decisions rather than informed after. |
| **SV-3 Roadmapping** | • Can hold a defined share of a team's capacity for platform and quality work and defend it with evidence of what its absence costs.
• Can present a team roadmap as bets with expected outcomes and confidence, not as a list of promised dates.
• Can recognise when a roadmap is a wish list assembled bottom-up with no connecting thesis. | • Can balance product delivery against platform and quality investment across several teams, including work no single team would fund.
• Can present a department roadmap as bets and confidence levels to people who want dates. | • Can set multi-year investment across product, platform and quality, and defend the platform's runway against every quarter's urgency.
• Can decide when a roadmap should change and when it should hold, and explain the decision in terms the business accepts. |
| **SV-4 Engineering economics** | • Can frame a build-versus-buy decision around total cost, differentiation and reversibility rather than engineering preference.
• Can account for the cost of the team's delivery (people, vendors, infrastructure) well enough to argue for a change in it.
• Can evaluate an AI service or vendor as a third option beside build and buy, with its own cost and risk profile. | • Can plan and defend a department budget and headcount in terms of outcomes and cost of delivery.
• Can make a vendor, build or AI-service decision at department scale, including the exit cost and who owns the relationship. | • Can reason about the economics of the whole engineering function (cost of delivery, capital allocation, headcount as investment) and change them.
• Can make a make, buy or AI decision at organisational scale, including the infrastructure the products will increasingly depend on, with an explicit view of exit cost and strategic dependence. |
| **SV-5 Engineering metrics and measurement** | • Can choose delivery metrics that measure flow and stability rather than activity, and say what each one cannot show.
• Can recognise when a metric has become a target and is being gamed.
• Can decline to use a single productivity number for individuals, and explain why. | • Can choose metrics that compare or aggregate teams without inviting the gaming that comparison creates.
• Can measure the effect of AI assistance on delivery honestly, including where the numbers say it is not helping. | • Can choose the measures by which the business judges engineering, and refuse measures that would make the organisation worse to hit.
• Can report AI's effect on the organisation's delivery honestly to the board, including uncertainty and where the effect is negative. |
| **SV-6 Organisational design and leading change** | *No expectation at this level; the competency starts higher.* | • Can design team boundaries around ownership and cognitive load, and see a team boundary and a system boundary as one decision.
• Can lead several teams through a reorganisation, communicating the why, naming what changes and what does not, and staying present through the transition.
• Can recognise when a structural problem is being treated as a people problem, and the reverse.
• Can settle a charter dispute between teams at the level that sets charters. | • Can design the shape of the organisation (structure, ownership boundaries, the layers between them and the work) around the strategy, and know what each design makes easy and hard.
• Can lead an organisation through a major transition (a reorganisation, a merger, an acquisition) so that the change sticks and the cynicism does not.
• Can weigh reorganisation options by their effect on leaders' scopes, ownership clarity and coordination cost, not by who is asking. |
## Technical Judgment
| Competency | Level 1 · Team | Level 2 · Organisation | Level 3 · Executive |
|---|---|---|---|
| **TJ-1 Evaluating architectural decisions and their organisational consequences** | • Can improve a design decision through questions (what does this assume, what happens when it fails, who has to coordinate) without taking it over.
• Can spend deliberation on the irreversible decisions and let reversible ones move fast.
• Can see a system boundary and a team boundary as one decision. | • Can keep architecture coherent across autonomous teams by setting standards at the boundaries rather than reviewing every design.
• Can make a deliberate platform bet on behalf of several teams and own its organisational consequences. | • Can own the organisation's technical strategy (the bet-the-company architectural decisions) and evaluate them by their organisational consequences over years.
• Can keep technical strategy coherent across acquired teams and systems without forcing uniformity where it is not worth its cost. |
| **TJ-2 Technical debt** | • Can make technical debt visible in terms stakeholders understand (what it costs per month, what it risks) rather than as an engineering complaint.
• Can distinguish debt worth repaying from debt worth carrying, and schedule repayment as ordinary work.
• Can recognise a proposed rewrite as a bet and evaluate it as one. | • Can make systemic technical debt that no single team owns visible, and fund its repayment at department level.
• Can weigh a large repayment programme against feature delivery with an explicit model of what each delays. | • Can present technical debt as a strategic liability (the platform's runway, the business's exposure) and win investment against it at the executive table.
• Can decide when a large modernisation is a necessity and when it is an engineering preference dressed as one. |
| **TJ-3 Code review and quality standards** | • Can set a quality bar the team owns (tests, review, definition of done) and hold it under deadline pressure.
• Can shape a code-review culture that teaches rather than gatekeeps, and notice when review has become rubber-stamping.
• Can state what review must establish for AI-generated code, and who is accountable for it. | • Can set an organisation-level quality bar that autonomous teams meet in their own way, and see when it is being met on paper only.
• Can set standards for AI-generated code across teams (verification, ownership, disclosure) without prescribing each team's tools. | • Can set the organisation's quality posture and the systems that maintain it (including standards for AI-generated code) without owning any team's practice.
• Can recognise when a quality failure at organisational scale is a leadership failure rather than an engineering one. |
| **TJ-4 Technical credibility and intervention** | • Can stay close enough to the team's technical work to judge it (reading designs, reviewing selectively, asking sharp questions) without becoming its bottleneck.
• Can decide when to intervene in a technical decision and when to let the team own it, and know which decisions are theirs.
• Can resist doing the engineering themselves when the team is struggling, and choose the intervention that leaves the team stronger. | • Can stay close enough to several teams' technical work to judge it (through design reviews, architecture forums and the artifacts themselves) without doing it or blocking it.
• Can decide when a technical decision in one of their teams is theirs to override, and intervene through the manager rather than around them. | • Can decide which technical concerns belong on an executive's personal agenda and track them without displacing the leaders who own them.
• Can stay technically credible at executive scope (able to judge a strategy, a risk, a claim) without pretending to a closeness to the code they no longer have. |
| **TJ-5 AI-assisted engineering** | • Can introduce AI assistance to a team with explicit expectations for verification, ownership and disclosure.
• Can recognise the risks AI assistance introduces (unverified code, leaked data, eroded understanding) and put proportionate controls in place.
• Can distinguish where AI assistance genuinely helps the team from where it is being used to look fast. | • Can govern AI-assisted engineering across teams (what is permitted, what must be verified, what data may be used) proportionately to the risk.
• Can build the capability to use AI assistance well across a department, and recognise where it is eroding understanding rather than adding leverage. | • Can set the organisation's strategy for AI-assisted engineering (investment, governance, capability, risk) and say what changes about the work and the workforce.
• Can evaluate an emerging AI capability that could be transformative and is unproven, and decide how much of the organisation to bet on it. |
| **TJ-6 Security, privacy, and compliance as engineering responsibilities** | • Can treat a security vulnerability, a privacy obligation or a compliance requirement as the team's own work, prioritised by risk rather than deferred to a function.
• Can respond to a security finding proportionately (triage by exploitability and exposure) rather than freezing or ignoring it.
• Can recognise a privacy or access-control problem in an everyday decision before it becomes an incident. | • Can assign ownership for a class of security, privacy or compliance gap that spans teams and see the fix through.
• Can weigh a compliance requirement against delivery honestly, distinguishing what is mandatory from what is merely requested. | • Can own security, privacy and compliance as organisational risk (investment, accountability, what the business is exposed to) at executive level.
• Can lead the organisation through a mandate that requires re-architecting systems across it, sequencing the work by risk rather than by who shouts. |
## Culture & Coaching
| Competency | Level 1 · Team | Level 2 · Organisation | Level 3 · Executive |
|---|---|---|---|
| **CC-1 Psychological safety and productive conflict** | • Can respond to an admitted mistake, a naive question or a challenge to their idea with curiosity rather than punishment.
• Can pair psychological safety with high standards, and recognise that "going easy" is not safety.
• Can invite open disagreement about ideas and then expect commitment once the decision is made. | • Can build psychological safety in the managers they lead and see when a manager's team has gone quiet.
• Can resolve conflict between teams by making the underlying disagreement explicit rather than by separating the people. | • Can build trust in leadership across an organisation, knowing it is created in visible moments, spent by inconsistency, and repaid only by behaviour over time.
• Can make it safe to bring bad news to the top, and can tell when it has stopped being safe. |
| **CC-2 Coaching versus directing** | • Can develop an engineer's judgment through questions rather than supplying the answer, and know when directing is the right exception.
• Can recognise when they are rescuing rather than coaching, and what the team learns from each.
• Can coach a senior engineer who is strong technically but does not mentor, document or lift others. | • Can coach the coaches (develop a manager's judgment through questions) and resist solving their team's problems for them.
• Can recognise a manager who is too hands-off or too hands-on and coach them toward the right distance. | • Can develop the judgment of senior leaders through questions and exposure rather than instruction, and build a leadership culture that coaches.
• Can recognise when the organisation has learned to wait for the executive's answer, and change what the executive does. |
| **CC-3 Inclusive practices and equitable opportunity distribution** | • Can notice who on the team gets the stretch work, the visibility and the benefit of the doubt, and correct the pattern.
• Can run team rituals (meetings, reviews, on-call, recognition) so that they do not systematically favour the loudest, the most present or the most similar to the manager.
• Can recognise glue work and ensure it is valued and distributed rather than left to whoever will not refuse it. | • Can read promotion, opportunity and attrition patterns across teams and act on an inequity the numbers reveal.
• Can hold managers accountable for equitable practice on their teams without making it a compliance exercise. | • Can read the organisation's opportunity structure from its data (promotion, attrition, pay, who leads what) and change the structure, not only the outcomes.
• Can hold the leadership team accountable for equity as a business responsibility rather than a programme. |
| **CC-4 Motivation, recognition, and sustainable pace** | • Can recognise burnout and disengagement early from changes in behaviour, and respond to the person before the output.
• Can protect a sustainable pace, and treat a run of heroics as a system failure rather than a badge.
• Can recognise people specifically and in the way that person values, including on a distributed team where effort is not visible. | • Can sustain motivation and pace across several teams, including distributed ones, through what they reward and what they refuse to normalise.
• Can recognise department-wide burnout as a system property and change the system. | • Can shape the organisation's relationship to pace (what leadership rewards, what it survives, what it refuses) including across distributed and hybrid teams.
• Can sustain motivation through a long period of difficulty by telling the truth about it. |
| **CC-5 Values, integrity, and ethical judgment under pressure** | • Can make the costly right call (on quality, on honesty, on a person) when pressure points the other way, and know that the team is watching.
• Can act on a values breach by a high performer rather than let results buy an exemption.
• Can recognise when they are being asked to shade the truth about status and decline. | • Can hold managers to the organisation's values, including when the manager who breaches them delivers.
• Can decline to shade status, ratings or commitments upward, and absorb the cost of declining rather than passing it down. | • Can act on the organisation's values when it is expensive at company level (a launch, a customer, a leader) and knows that this is the moment the culture is actually set.
• Can exercise ethical judgment where the law, the policy and the pressure of the moment do not settle the question. |
| **CC-6 Self-management** | • Can manage their own time and calendar so that the team's needs, not the inbox, determine where the hours go.
• Can recognise their own overload and burnout, set boundaries, and ask for help before it reaches the team.
• Can separate their own anxiety about a situation from the decision it needs. | • Can manage their own effectiveness as the layer between teams and executives (time, attention, the temptation to be in every room) deliberately.
• Can recognise when their own overload is degrading their judgment about people, and change their load before it changes their decisions. | • Can sustain their own judgment and resilience under executive-scale consequence and visibility, and build the support that makes it possible.
• Can recognise when their own state is shaping the organisation's, and act on themselves first. |
---
Adapted from the competency list and proficiency indicators of the EMA Competency Framework v3.0 and its Exam Content Outlines, by the Engineering Management Academy (https://www.engineeringmanagement.academy/framework), licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Changes were made.