Why Career Pathways Matter

The most expensive thing an engineering organisation does is hire senior engineers. The second most expensive is watching them leave because they couldn't see a future. Most attrition in engineering is not about pay - it is about ambiguity. People do not leave because they got a better offer. They leave because they stopped believing the current situation was going anywhere.

Career pathways exist to answer a simple question: what does progression look like here? When that question has no clear answer, three things happen. First, promotion becomes political - it goes to whoever the manager notices most, whoever advocates loudest for themselves, whoever has been there longest. Second, development conversations become vague - "just keep doing what you're doing" is not a development plan. Third, equity collapses - without a shared framework, different managers apply wildly different standards, and the demographic patterns in who gets promoted and who doesn't become very visible, very fast.

A career pathway is not a guarantee of promotion. It is not a checklist an engineer ticks and then expects a new job title. It is a shared language for talking about growth, contribution, and progression - a way for engineers and managers to have honest conversations about where someone is, where they want to go, and what the gap looks like.

The absence of one is not neutral. Absence is a choice that favours those who are comfortable navigating ambiguity and advocating loudly for themselves. That is not a random demographic.

What a Pathway Is Not

Before defining what a career pathway is, it is worth being precise about what it is not.

It is not a job description. Job descriptions describe a role at a point in time. A career pathway describes how impact, scope, and autonomy evolve across time and levels.

It is not a rubric grid. A rubric grid - the kind that has 8 dimensions and 6 levels and 48 cells filled with slightly different adjectives - is not a pathway. It is a compliance artefact. Nobody reads it. Nobody references it in real conversations. The signal that an organisation has confused rubric grids for career pathways is when promotion conversations reference the grid once, then proceed to operate entirely on vibes.

It is not a performance management tool. Performance management is about whether someone is doing their current job well. A career pathway is about what the next level looks like and how someone demonstrates they are operating there.

It is not a ladder that everyone must climb. The metaphor of a ladder implies that standing still means falling behind. A better metaphor is a landscape - there are different places to be, different routes to take, and the goal is to find where someone creates the most value and gets the most satisfaction, not to reach the highest altitude.

The Two Tracks

Every mature engineering career framework distinguishes between two tracks: the Individual Contributor (IC) track and the Leadership track. This distinction is important. It is not about whether one track is more senior or more respected than the other. It is about what kind of contribution creates the most value.

The IC track is for engineers who create value primarily through technical depth, technical breadth, or both. Their leverage comes from what they can build, design, and know. As they progress, the scope of their technical impact grows - from their immediate team, to their domain, to the organisation, to the industry. The most senior ICs are setting technical direction that influences how the entire organisation builds software.

The Leadership track is for engineers who create value primarily through the capability of others. Their leverage is multiplicative - a great engineering manager makes a team of six engineers deliver like a team of ten, because they remove friction, set direction, develop people, and handle the organisational complexity that would otherwise consume engineering time. As they progress, the scope of their organisational influence grows - from one team, to multiple teams, to an entire engineering function.

Both tracks are valid career destinations. Both require different strengths. The mistake most organisations make is treating leadership as the only legitimate form of seniority - with the result that technically exceptional engineers get promoted into management, become mediocre managers, and the organisation loses both a great engineer and gains a poor manager. The other mistake is treating IC as a holding pattern for people who are not ready for leadership.

The frame that works: IC is the path for people who want to grow their impact through technical excellence. Leadership is the path for people who want to grow their impact through the excellence of others.

Neither track should be a default. The fork should be a deliberate choice, made with good information, at the right time.

The IC Track: GE → JSE → ISE → SSE → LSE

The IC track in a mid-to-large engineering organisation typically runs through five levels. The titles vary by organisation, but the underlying structure of what changes at each level is consistent.

Graduate Engineer (GE)

A GE is learning to be a professional engineer. The scope of their work is the task - a ticket, a small feature, a defined unit of work with clear inputs and outputs. They are not yet expected to decompose ambiguous problems or make significant technical decisions. What is expected is that they learn fast, ask good questions, complete work to a standard, and show increasing independence over time.

The most important thing a GE needs is good mentorship and regular feedback. The most common failure mode is to assign them work and then ignore them until they struggle.

A GE typically reaches JSE within 12-24 months. If they haven't, that is a signal either that the work is not providing sufficient learning opportunities, or that there is a capability concern that needs addressing directly - not by waiting longer.

Junior Software Engineer (JSE)

A JSE can deliver defined work without constant supervision. They work on features rather than tasks - work that requires some judgement about implementation approach within a known technical context. They are not yet expected to identify what needs to be built, only to build it well once direction is set.

The key shift from GE to JSE is independence - the JSE does not need daily check-ins or step-by-step guidance. They navigate their own blockers, communicate proactively when stuck, and deliver work that requires minimal rework.

What a JSE is not yet doing: making significant architectural decisions, influencing technical direction, or operating effectively in genuinely ambiguous situations.

Intermediate Software Engineer (ISE)

The ISE level is the largest band in most organisations, and the longest tenure. An ISE owns components - not just features within a component, but the health, design, and evolution of meaningful pieces of a system. They make technical decisions within their area and can defend them. They are self-directed: given a problem, they can decompose it, identify options, recommend an approach, and deliver it.

The shift from JSE to ISE is about ownership. A JSE delivers work. An ISE owns outcomes. An ISE notices problems before they are raised, proposes solutions before they are asked, and takes responsibility for the quality of what they have built.

An ISE is also beginning to have influence beyond their own code - through code review, through mentoring JSEs, through contributing to team technical discussions. This influence is not yet a formal responsibility, but its presence is a signal of readiness for SSE.

Senior Software Engineer (SSE)

The SSE level is where the IC track begins to diverge meaningfully from the leadership track. At SSE, an engineer is operating at the system level - they can hold the whole design in their head, identify where the system is fragile, and make decisions that trade off competing concerns (performance, maintainability, testability, operability) with good judgement.

SSEs set technical direction. Not by being assigned to do so, but by doing it naturally. An SSE writes the ADR that defines how the team handles event sourcing. An SSE identifies the performance bottleneck that nobody else has noticed. An SSE raises the concern about the architectural decision three months before it becomes a problem.

The defining shift from ISE to SSE is moving from reacting to technical decisions to driving them. An SSE is not waiting for direction - they are providing it.

An SSE is also meaningfully developing others. Not as a manager, but as a technical leader. They pair with ISEs, they give substantive code review feedback, they run spike investigations and share what they learn. Their impact is multiplied through others, not just through their own output.

Lead Software Engineer (LSE)

The LSE is the senior individual contributor role. Their scope is the domain - a cluster of systems, a technical discipline, a significant technical challenge. They operate across multiple teams, they influence architecture at the organisational level, and they are a key voice in technical strategy.

An LSE does not need a manager to set their technical agenda. They identify the most important technical problems in their domain and work on them. They can do this because they have the credibility, the context, and the judgement to know what matters.

An LSE's time is split between deep technical work and technical leadership - writing code and writing strategy. The ratio shifts toward strategy as the organisation grows. If an LSE is spending more than 70% of their time writing code and less than 30% shaping technical direction, the organisation is not using them well.

The Leadership Track: TTL → EM → HoE

The leadership track typically runs through three levels in a mid-sized engineering organisation. The titles vary - Tech Lead Manager, Engineering Manager, and Head of Engineering are common - but the structure of what each level does is consistent.

Technical Team Lead (TTL)

The TTL is the most technically-hands-on leadership role. A TTL is typically the technical lead for one team - they are still writing code, still doing design, still in the pull request queue. But they are also managing the team's delivery rhythm, unblocking engineers, running ceremonies, and acting as the interface between the team and the rest of the organisation.

The TTL role is genuinely difficult because it requires operating in two modes simultaneously. As a technical contributor, you need deep focus. As a team lead, you need availability and responsiveness. These are in tension. The most common failure at TTL is defaulting entirely into one mode - either the engineer who happens to run the standup, or the manager who hasn't written meaningful code in six months.

The TTL level is also where the most important career conversations happen. This is the first moment where someone needs to decide whether leadership is actually what they want, or whether the technical track is the right home. Many TTLs discover leadership is not for them. That is not failure - it is important information. The failure is when organisations treat the TTL role as a mandatory step for senior engineers, rather than an optional entry point to the leadership track.

Engineering Manager (EM)

At EM, the shift is complete: this is a full-time leadership role. An EM is not writing production code. They are managing engineers - running 1:1s, doing performance management, hiring, handling interpersonal dynamics, coordinating delivery across teams, managing stakeholder relationships.

The EM's job is to create the conditions in which engineers can do their best work. That means removing blockers, setting direction clearly, ensuring people have the skills and context they need, and handling the organisational complexity that would otherwise land on engineers' desks.

What the EM is not doing: making technical decisions. The EM sets the conditions. The SSE or LSE on the team makes the technical decisions. Organisations that confuse these roles - where the EM is the de facto technical decision-maker - typically have engineers who feel disempowered and managers who are overloaded.

An EM typically manages 6-12 engineers directly. Below six, they are underloaded and tend to overreach into technical decisions. Above twelve, they are overloaded and tend to underinvest in individual development.

Head of Engineering (HoE)

The HoE is responsible for the engineering capability of a domain or department. This is a strategic leadership role - they are setting the engineering culture, making decisions about team structure, building the conditions for engineering excellence, and interfacing with product, design, and organisational leadership.

The HoE does not manage engineers directly (beyond a small number of senior individual contributors who report to them). They manage EMs. Their leverage comes from the quality of the management layer beneath them, which means their primary job is developing great engineering managers.

A HoE who is solving team-level problems directly has a management layer problem. If every significant issue escalates to the HoE, the EMs are not operating at the right level of capability or authority.

The Fork: Why SSE is the Decision Point

SSE is the natural inflection point for the IC vs leadership decision. At SSE, engineers have enough technical credibility and organisational experience to make an informed choice. Before SSE, the picture is incomplete - it is hard to know if you want to lead people when you haven't yet consistently led technical work.

The question to ask at the SSE level is not "do you want to be a manager?" - that is the wrong frame. The better question is: where do you get your energy?

Some engineers get their energy from deep technical work - from the flow state of building something complex, from the satisfaction of a well-crafted system, from the intellectual challenge of hard engineering problems. These engineers will be miserable in a full-time management role. They should stay on the IC track.

Some engineers get their energy from seeing others succeed - from the satisfaction of watching a junior engineer grow, from solving the people and process problems that are blocking a team, from the challenge of building a high-performing group. These engineers will be frustrated in a purely technical role. They should move to the leadership track.

Most engineers get energy from both. The question is which gives them more energy - and that question is worth asking directly in a career conversation, rather than letting it be answered implicitly by whoever gets promoted first.

How to Have This Conversation Well

The manager's job in this conversation is to present both tracks honestly - not to push the engineer toward a particular path. That means being clear about what leadership actually involves (calendar full of meetings, dealing with underperformance, navigating organisational politics, minimal deep technical work) rather than selling a romanticised version of it.

It also means being honest about what the IC track offers at senior levels - significant technical influence, the ability to shape engineering practice across the organisation, and the kind of autonomy that comes with genuine technical expertise.

The engineer's job is to reflect honestly on where their energy comes from, not on what seems like the "right" answer or what they think their manager wants to hear.

Neither track should be presented as the obvious choice. Both require different strengths. Both lead to different kinds of satisfaction. The conversation should make the fork visible and help the engineer navigate it with good information.

The Staff+ Question

In large organisations (typically 200+ engineers), it becomes worth introducing Staff Engineer and Principal Engineer levels above LSE. These are not honorary titles - they are roles with distinct responsibilities and genuine leverage.

Staff Engineer operates at the domain level, typically influencing multiple teams and setting technical direction for a significant technical area. They do not need direction from management on what technical problems to focus on. They have the credibility and context to identify what matters and the skill to address it.

Principal Engineer operates at the organisational level, shaping technical strategy across the entire engineering function. There are very few of them. Their influence is through technical vision, standards-setting, and the cultivation of engineering practice across the whole organisation.

Distinguished Engineer (rare, at very large organisations) operates at the industry level. Their work is visible outside the company. They are defining what modern engineering looks like, not just what engineering looks like at this specific organisation.

Do You Need These Levels?

Probably not if you have fewer than 150 engineers. The risk of introducing these levels prematurely is threefold:

First, you dilute the signal. If every strong SSE becomes a Staff Engineer, the title stops meaning anything and you have not solved your retention problem - you have just increased your payroll while creating a new set of ambiguity about what "Staff" actually means.

Second, you create expectation problems. Engineers who earn a Staff title expect Staff-level work - significant technical influence, meaty problems, real autonomy. If you cannot provide that work, you have promoted people into a role with no job to do, and they will leave anyway.

Third, you create a seniority arms race. Once you have Staff Engineers, you will soon have people lobbying for Principal. The inflation of titles is hard to stop once started.

The better question than "should we create these levels?" is "do we have engineers doing this kind of work and no way to recognise them?" If the answer is yes, create the levels. If the answer is "we think it might help us retain people," address the retention problem directly rather than through title inflation.

What Good Pathway Documentation Looks Like

Good pathway documentation is narrative, not tabular. It tells the story of what it looks like to operate at each level - the kinds of problems someone is working on, the decisions they are making, the impact they are having - rather than listing competencies in a grid.

A useful test: could an engineer read the description of the next level above them and understand clearly what they would need to be doing differently? If the answer is no, the documentation is not doing its job.

Structure for a Good Level Description

Each level description should include:

A one-sentence summary of what this level is fundamentally about. Not a list of responsibilities. A sentence that captures the essential shift.

The scope of impact. What size of problem does someone at this level own? A task, a feature, a component, a system, a domain?

The nature of autonomy. How much direction do they need to operate effectively? Daily guidance, weekly check-ins, quarterly direction-setting?

What they do that the level below them does not. This is the most important section. The transition criteria should be specific: not "demonstrates leadership" but "drives the technical direction of significant system design decisions without being asked."

What they are not yet doing. Every level has a ceiling as well as a floor. Being clear about what someone is not expected to do at a given level is just as important as being clear about what they are expected to do.

Concrete examples. Three or four specific, real-world examples of what operating at this level looks like. Not hypothetical. Not generic. Specific enough that an engineer can recognise whether they are doing them.

Common Failures

Vague Transition Criteria

"Demonstrates leadership potential" is not a promotion criterion. Neither is "shows strategic thinking" or "has executive presence." These phrases mean different things to different managers and are therefore not criteria - they are proxies for gut feel.

Good transition criteria are specific enough to generate evidence. "Has led the technical design of at least one significant system change, produced a design document that was reviewed and approved by the team, and demonstrated the ability to incorporate feedback and explain trade-offs clearly" is a criterion. "Shows technical leadership" is not.

Tenure-Based Promotion

The most common promotion failure in engineering organisations is promoting people after a given number of years, regardless of whether they are operating at the next level. This is not kindness - it is the absence of a decision. It creates a cohort of senior engineers who are not operating at a senior level, which is unfair to them (they have been set up to fail), unfair to their colleagues (they are a weight on team performance), and unfair to the organisation (senior engineer salaries without senior engineer impact).

The frame that prevents this: promotion should confirm what is already true, not reward loyalty. If someone is being promoted to SSE, they should already be doing SSE-level work. The promotion is the formal recognition of a reality, not the creation of a new one.

The "Leadership is the Only Real Career" Trap

In organisations where leadership is the only pathway to seniority and significant compensation, technically excellent engineers either become mediocre managers or they leave. The organisations that retain the best technical talent are the ones that have made the IC track as valued, as compensated, and as respected as the leadership track.

This is not just a policy question - it is a cultural one. If managers in calibration sessions consistently treat IC progression as less significant than leadership progression, the policy is irrelevant. The signal engineers receive from the culture is what they act on.

Pathway as a Document Nobody Reads

A career pathway that lives in a Confluence page and is referenced only during formal review cycles has failed. A career pathway should be a living tool that is used in every career conversation, referenced during project allocation ("this would be a stretch for them and that's good"), and updated when the organisation's needs change.

If an engineer cannot access and cite their career pathway document without help, it is not embedded enough to be useful.

Connection to Your Operating Model

Career pathways do not exist in isolation. They need to connect coherently with how the rest of your engineering operating model works.

Capability frameworks define what "good" looks like at each level - they are the detail that makes the pathway specific and assessable. A pathway without a capability framework is a destination without a map.

Role archetypes define the types of work and specialisation available within the organisation. The pathway describes vertical progression; the archetypes describe horizontal diversity. A senior engineer might progress up the IC track while specialising as a platform engineer, a backend engineer, or a data engineer - the pathway is consistent across archetypes even as the technical content differs.

Promotion and levelling processes operationalise the pathway. Without a fair, calibrated promotion process, the pathway is aspirational fiction. The process is what makes it real.

Career conversations are the mechanism through which individual engineers engage with the pathway. A pathway that is never discussed, never referenced, never brought into the conversation between a manager and an engineer is furniture - present but not useful.

The pathway is the spine. Everything else connects to it.