A career ladder for engineering managers

• Can delegate an outcome rather than a set of steps, stating the constraints and the level of authority that goes with it. PL-1.I1
• 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. PL-1.I2
• Can recognise the moment they are about to take delegated work back, and choose support over rescue. PL-1.I3

• Can delegate a whole team to a manager (its charter, its decisions, its outcomes) and stay accountable for the result without re-deciding it. PL-1.I4
• Can make decision rights explicit across several teams so that a disputed decision has a known owner before the dispute. PL-1.I5

• 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. PL-1.I6
• Can recognise when decisions are flowing upward because the design is wrong rather than because the people are weak. PL-1.I7

• Can give corrective feedback anchored in a specific situation and observable behaviour, and name its impact, without diagnosing intent. PL-2.I1
• Can hold a difficult conversation early rather than waiting for a review cycle or hoping the problem resolves. PL-2.I2
• Can invite and act on feedback about their own management from the people they lead. PL-2.I3

• Can give a manager feedback about their leadership (a pattern across several moments) with the same specificity as feedback about a task. PL-2.I4
• Can act on damning skip-level feedback about a manager by establishing the facts before confronting anyone. PL-2.I5

• Can give a senior leader feedback about their performance and their effect on the organisation, and follow it with consequences. PL-2.I6
• Can shape a feedback culture through what leadership visibly does with bad news. PL-2.I7

• Can run a structured interview against criteria defined before the process starts, and recognise the biases that unstructured evaluation invites. PL-3.I1
• Can assess what a candidate can do rather than which tools they were permitted, and distinguish capability from fluency. PL-3.I2
• Can design a first ninety days that gives a new hire explicit outcomes, a named guide, and early feedback. PL-3.I3

• Can appoint a manager for sound reasons (demonstrated judgment about people, not seniority or retention) and support them through the first six months. PL-3.I4
• Can calibrate the hiring bar across several teams so that the same capability earns the same decision regardless of interviewer. PL-3.I5

• 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. PL-3.I6
• Can run a hiring system that stays calibrated across an organisation and through growth. PL-3.I7

• Can diagnose whether an engineer's underperformance is a matter of skill, will, or the conditions they were given, before choosing a response. PL-4.I1
• Can set expectations explicitly enough that a later performance conversation refers to something the engineer already knew. PL-4.I2
• Can follow a fair process to an honest consequence, including a formal one, without avoiding it or rushing it. PL-4.I3

• Can manage a manager's performance, including the performance of their team, and distinguish a manager problem from a team problem. PL-4.I4
• Can run calibration across teams so that ratings are consistent, and challenge a manager's case that lacks evidence or fair process. PL-4.I5

• Can act on a leader's performance problem (including a loyal, long-tenured leader the organisation has outgrown) with fairness and without delay. PL-4.I6
• Can design a performance system that is consistent across the organisation and that people trust to be fair. PL-4.I7

• Can run a one-on-one that belongs to the report (their growth, their concerns) rather than to the manager's status needs. PL-5.I1
• 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. PL-5.I2
• Can help an engineer weigh the senior individual-contributor track against management without steering them toward the manager's own path. PL-5.I3

• Can create growth paths across teams (moves, stretch roles, the senior individual-contributor track) and see who is and is not getting them. PL-5.I4
• Can develop a manager's career deliberately, including toward roles that compete with their own. PL-5.I5

• Can design the career architecture (levels, the senior individual-contributor track, the leadership pipeline) and detect when it is producing the wrong people. PL-5.I6
• Can read succession as a structural property and act on key-person risk before it materialises. PL-5.I7

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. PL-6.I1
• 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. PL-6.I2
• Can hold a manager accountable for their team's outcomes and health without taking the team back from them. PL-6.I3
• Can set a span of control and a management structure that lets managers actually manage. PL-6.I4

• Can build a leadership team as a system (complementary strengths, clear scopes, shared accountability) rather than a set of individually strong leaders. PL-6.I5
• Can develop leaders of leaders, and recognise the signals that a leader is ready for a larger scope before they ask. PL-6.I6
• Can hold a senior leader accountable for an organisation's outcomes and health while acting through them, and know when to replace them. PL-6.I7

• Can sequence a team's work by value and cost of delay rather than by who asked loudest or most recently. DE-1.I1
• Can say no by surfacing the cost of yes ("we can do X, and Y slips") and let the stakeholder choose. DE-1.I2
• Can protect a team's focus against constant reprioritisation, and recognise when too much started work means nothing finishes. DE-1.I3

• Can prioritise across several teams against a shared bottleneck, and make the resulting trade-offs visible to every team that loses. DE-1.I4
• Can protect several teams' focus from department-level churn without becoming the only person who can say no. DE-1.I5

• 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. DE-1.I6
• Can hold a portfolio steady against executive-level churn while remaining genuinely open to a change in strategy. DE-1.I7

• Can distinguish an estimate from a commitment, and buffer the commitment deliberately rather than promising the estimate. DE-2.I1
• 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. DE-2.I2
• Can decline to give a date on the spot without an estimate, and say what it would take to give one. DE-2.I3

• Can make a commitment that depends on several teams by aggregating uncertainty honestly rather than adding up best cases. DE-2.I4
• Can detect status that has been shaded on its way up, and build reporting that surfaces trouble early. DE-2.I5

• Can build an organisation-wide planning cadence whose commitments the business can rely on, without demanding a certainty the work cannot provide. DE-2.I6
• Can ensure bad news about delivery reaches them in time to act, by design rather than by luck. DE-2.I7

• Can run an incident in progress in the right order (restore service, communicate, then find the cause) and resist debugging while users are down. DE-3.I1
• Can lead a blameless postmortem that changes the system rather than naming the person. DE-3.I2
• Can treat on-call load and service-level objectives as the team's operational ownership, not an interruption to real work. DE-3.I3

• Can establish ownership for a service or a class of failure that falls between teams, before the next incident. DE-3.I4
• Can design an on-call system across several teams that is sustainable, and read reliability trends across services rather than incident by incident. DE-3.I5

• Can treat reliability as a strategic property (investment, risk appetite, what the business is implicitly assuming) and argue for it at the executive table. DE-3.I6
• Can lead the organisation through a major failure (the incident, the communication, the learning, the accountability) in a way that leaves it stronger. DE-3.I7

• Can name a risk early, with its likelihood and impact, rather than hoping it does not materialise. DE-4.I1
• Can manage a dependency on another team by negotiating a timeline and a fallback, before escalating and before building around it. DE-4.I2
• Can trade scope before quality when a deadline is fixed, and say so. DE-4.I3

• 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. DE-4.I4
• 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. DE-4.I5

• 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. DE-4.I6
• Can govern programmes that span the organisation without a central plan that every team waits on. DE-4.I7

• Can choose the lightest process that solves the team's actual problem, and change it when the problem changes. DE-5.I1
• 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. DE-5.I2
• Can introduce AI-assisted tooling to a team's workflow with an explicit view of what it changes about review, testing and ownership. DE-5.I3

• Can decide which practices are standard across teams and which are each team's own (aligned autonomy) and explain the boundary. DE-5.I4
• Can invest in developer experience and AI-assisted workflows at department scale, measured by what teams can now do rather than by adoption. DE-5.I5

• Can design the organisation's operating system (cadence, standards, the developer platform) so that dozens of teams deliver without the executive in the room. DE-5.I6
• 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. DE-5.I7

• Can translate a business goal into the team's work as outcomes (the change wanted in the world) rather than a feature list. SV-1.I1
• Can ensure every engineer can say why their current work matters to the business. SV-1.I2
• Can re-derive the team's plan when circumstances change, instead of defending the original list. SV-1.I3

• Can write a department strategy with a connecting thesis (why these teams do these things) rather than assemble team wish lists. SV-1.I4
• Can defend a strategy against churn and encroachment, and change it when the evidence says so rather than when the pressure does. SV-1.I5

• Can author the engineering strategy (a written, arguable thesis connecting technical direction to the business's goals) and argue it at the executive table. SV-1.I6
• Can keep a strategy alive as the world changes, distinguishing a change in the evidence from a change in the pressure. SV-1.I7

• Can explain a technical trade-off to a non-engineering stakeholder in the language of their outcome, without jargon and without condescension. SV-2.I1
• Can partner with product and design as peers whose constraints are real, rather than as a queue of requests. SV-2.I2
• Can deliver bad news about a delivery to a stakeholder early, with options, rather than late with excuses. SV-2.I3

• Can partner with a product director and a design lead as peers, resolving disagreements about investment with evidence rather than escalation. SV-2.I4
• 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. SV-2.I5

• 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. SV-2.I6
• 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-2.I7

• 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. SV-3.I1
• Can present a team roadmap as bets with expected outcomes and confidence, not as a list of promised dates. SV-3.I2
• Can recognise when a roadmap is a wish list assembled bottom-up with no connecting thesis. SV-3.I3

• Can balance product delivery against platform and quality investment across several teams, including work no single team would fund. SV-3.I4
• Can present a department roadmap as bets and confidence levels to people who want dates. SV-3.I5

• Can set multi-year investment across product, platform and quality, and defend the platform's runway against every quarter's urgency. SV-3.I6
• Can decide when a roadmap should change and when it should hold, and explain the decision in terms the business accepts. SV-3.I7

• Can frame a build-versus-buy decision around total cost, differentiation and reversibility rather than engineering preference. SV-4.I1
• Can account for the cost of the team's delivery (people, vendors, infrastructure) well enough to argue for a change in it. SV-4.I2
• Can evaluate an AI service or vendor as a third option beside build and buy, with its own cost and risk profile. SV-4.I3

• Can plan and defend a department budget and headcount in terms of outcomes and cost of delivery. SV-4.I4
• Can make a vendor, build or AI-service decision at department scale, including the exit cost and who owns the relationship. SV-4.I5

• Can reason about the economics of the whole engineering function (cost of delivery, capital allocation, headcount as investment) and change them. SV-4.I6
• 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-4.I7

• Can choose delivery metrics that measure flow and stability rather than activity, and say what each one cannot show. SV-5.I1
• Can recognise when a metric has become a target and is being gamed. SV-5.I2
• Can decline to use a single productivity number for individuals, and explain why. SV-5.I3

• Can choose metrics that compare or aggregate teams without inviting the gaming that comparison creates. SV-5.I4
• Can measure the effect of AI assistance on delivery honestly, including where the numbers say it is not helping. SV-5.I5

• Can choose the measures by which the business judges engineering, and refuse measures that would make the organisation worse to hit. SV-5.I6
• Can report AI's effect on the organisation's delivery honestly to the board, including uncertainty and where the effect is negative. SV-5.I7

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. SV-6.I1
• Can lead several teams through a reorganisation, communicating the why, naming what changes and what does not, and staying present through the transition. SV-6.I2
• Can recognise when a structural problem is being treated as a people problem, and the reverse. SV-6.I3
• Can settle a charter dispute between teams at the level that sets charters. SV-6.I4

• 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. SV-6.I5
• Can lead an organisation through a major transition (a reorganisation, a merger, an acquisition) so that the change sticks and the cynicism does not. SV-6.I6
• Can weigh reorganisation options by their effect on leaders' scopes, ownership clarity and coordination cost, not by who is asking. SV-6.I7

• Can improve a design decision through questions (what does this assume, what happens when it fails, who has to coordinate) without taking it over. TJ-1.I1
• Can spend deliberation on the irreversible decisions and let reversible ones move fast. TJ-1.I2
• Can see a system boundary and a team boundary as one decision. TJ-1.I3

• Can keep architecture coherent across autonomous teams by setting standards at the boundaries rather than reviewing every design. TJ-1.I4
• Can make a deliberate platform bet on behalf of several teams and own its organisational consequences. TJ-1.I5

• Can own the organisation's technical strategy (the bet-the-company architectural decisions) and evaluate them by their organisational consequences over years. TJ-1.I6
• Can keep technical strategy coherent across acquired teams and systems without forcing uniformity where it is not worth its cost. TJ-1.I7

• Can make technical debt visible in terms stakeholders understand (what it costs per month, what it risks) rather than as an engineering complaint. TJ-2.I1
• Can distinguish debt worth repaying from debt worth carrying, and schedule repayment as ordinary work. TJ-2.I2
• Can recognise a proposed rewrite as a bet and evaluate it as one. TJ-2.I3

• Can make systemic technical debt that no single team owns visible, and fund its repayment at department level. TJ-2.I4
• Can weigh a large repayment programme against feature delivery with an explicit model of what each delays. TJ-2.I5

• 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. TJ-2.I6
• Can decide when a large modernisation is a necessity and when it is an engineering preference dressed as one. TJ-2.I7

• Can set a quality bar the team owns (tests, review, definition of done) and hold it under deadline pressure. TJ-3.I1
• Can shape a code-review culture that teaches rather than gatekeeps, and notice when review has become rubber-stamping. TJ-3.I2
• Can state what review must establish for AI-generated code, and who is accountable for it. TJ-3.I3

• 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. TJ-3.I4
• Can set standards for AI-generated code across teams (verification, ownership, disclosure) without prescribing each team's tools. TJ-3.I5

• 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. TJ-3.I6
• Can recognise when a quality failure at organisational scale is a leadership failure rather than an engineering one. TJ-3.I7

• Can stay close enough to the team's technical work to judge it (reading designs, reviewing selectively, asking sharp questions) without becoming its bottleneck. TJ-4.I1
• Can decide when to intervene in a technical decision and when to let the team own it, and know which decisions are theirs. TJ-4.I2
• Can resist doing the engineering themselves when the team is struggling, and choose the intervention that leaves the team stronger. TJ-4.I3

• 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. TJ-4.I4
• Can decide when a technical decision in one of their teams is theirs to override, and intervene through the manager rather than around them. TJ-4.I5

• Can decide which technical concerns belong on an executive's personal agenda and track them without displacing the leaders who own them. TJ-4.I6
• 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-4.I7

• Can introduce AI assistance to a team with explicit expectations for verification, ownership and disclosure. TJ-5.I1
• Can recognise the risks AI assistance introduces (unverified code, leaked data, eroded understanding) and put proportionate controls in place. TJ-5.I2
• Can distinguish where AI assistance genuinely helps the team from where it is being used to look fast. TJ-5.I3

• Can govern AI-assisted engineering across teams (what is permitted, what must be verified, what data may be used) proportionately to the risk. TJ-5.I4
• Can build the capability to use AI assistance well across a department, and recognise where it is eroding understanding rather than adding leverage. TJ-5.I5

• Can set the organisation's strategy for AI-assisted engineering (investment, governance, capability, risk) and say what changes about the work and the workforce. TJ-5.I6
• 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-5.I7

• 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. TJ-6.I1
• Can respond to a security finding proportionately (triage by exploitability and exposure) rather than freezing or ignoring it. TJ-6.I2
• Can recognise a privacy or access-control problem in an everyday decision before it becomes an incident. TJ-6.I3

• Can assign ownership for a class of security, privacy or compliance gap that spans teams and see the fix through. TJ-6.I4
• Can weigh a compliance requirement against delivery honestly, distinguishing what is mandatory from what is merely requested. TJ-6.I5

• Can own security, privacy and compliance as organisational risk (investment, accountability, what the business is exposed to) at executive level. TJ-6.I6
• Can lead the organisation through a mandate that requires re-architecting systems across it, sequencing the work by risk rather than by who shouts. TJ-6.I7

• Can respond to an admitted mistake, a naive question or a challenge to their idea with curiosity rather than punishment. CC-1.I1
• Can pair psychological safety with high standards, and recognise that "going easy" is not safety. CC-1.I2
• Can invite open disagreement about ideas and then expect commitment once the decision is made. CC-1.I3

• Can build psychological safety in the managers they lead and see when a manager's team has gone quiet. CC-1.I4
• Can resolve conflict between teams by making the underlying disagreement explicit rather than by separating the people. CC-1.I5

• 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. CC-1.I6
• Can make it safe to bring bad news to the top, and can tell when it has stopped being safe. CC-1.I7

• Can develop an engineer's judgment through questions rather than supplying the answer, and know when directing is the right exception. CC-2.I1
• Can recognise when they are rescuing rather than coaching, and what the team learns from each. CC-2.I2
• Can coach a senior engineer who is strong technically but does not mentor, document or lift others. CC-2.I3

• Can coach the coaches (develop a manager's judgment through questions) and resist solving their team's problems for them. CC-2.I4
• Can recognise a manager who is too hands-off or too hands-on and coach them toward the right distance. CC-2.I5

• Can develop the judgment of senior leaders through questions and exposure rather than instruction, and build a leadership culture that coaches. CC-2.I6
• Can recognise when the organisation has learned to wait for the executive's answer, and change what the executive does. CC-2.I7

• Can notice who on the team gets the stretch work, the visibility and the benefit of the doubt, and correct the pattern. CC-3.I1
• 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. CC-3.I2
• Can recognise glue work and ensure it is valued and distributed rather than left to whoever will not refuse it. CC-3.I3

• Can read promotion, opportunity and attrition patterns across teams and act on an inequity the numbers reveal. CC-3.I4
• Can hold managers accountable for equitable practice on their teams without making it a compliance exercise. CC-3.I5

• Can read the organisation's opportunity structure from its data (promotion, attrition, pay, who leads what) and change the structure, not only the outcomes. CC-3.I6
• Can hold the leadership team accountable for equity as a business responsibility rather than a programme. CC-3.I7

• Can recognise burnout and disengagement early from changes in behaviour, and respond to the person before the output. CC-4.I1
• Can protect a sustainable pace, and treat a run of heroics as a system failure rather than a badge. CC-4.I2
• Can recognise people specifically and in the way that person values, including on a distributed team where effort is not visible. CC-4.I3

• Can sustain motivation and pace across several teams, including distributed ones, through what they reward and what they refuse to normalise. CC-4.I4
• Can recognise department-wide burnout as a system property and change the system. CC-4.I5

• Can shape the organisation's relationship to pace (what leadership rewards, what it survives, what it refuses) including across distributed and hybrid teams. CC-4.I6
• Can sustain motivation through a long period of difficulty by telling the truth about it. CC-4.I7

• 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. CC-5.I1
• Can act on a values breach by a high performer rather than let results buy an exemption. CC-5.I2
• Can recognise when they are being asked to shade the truth about status and decline. CC-5.I3

• Can hold managers to the organisation's values, including when the manager who breaches them delivers. CC-5.I4
• Can decline to shade status, ratings or commitments upward, and absorb the cost of declining rather than passing it down. CC-5.I5

• 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. CC-5.I6
• Can exercise ethical judgment where the law, the policy and the pressure of the moment do not settle the question. CC-5.I7

• Can manage their own time and calendar so that the team's needs, not the inbox, determine where the hours go. CC-6.I1
• Can recognise their own overload and burnout, set boundaries, and ask for help before it reaches the team. CC-6.I2
• Can separate their own anxiety about a situation from the decision it needs. CC-6.I3

• Can manage their own effectiveness as the layer between teams and executives (time, attention, the temptation to be in every room) deliberately. CC-6.I4
• Can recognise when their own overload is degrading their judgment about people, and change their load before it changes their decisions. CC-6.I5

• Can sustain their own judgment and resilience under executive-scale consequence and visibility, and build the support that makes it possible. CC-6.I6
• Can recognise when their own state is shaping the organisation's, and act on themselves first. CC-6.I7