10.3 Project Management Career Paths and Next Roles

Chapter 10.3 ← 10.0 Conclusion and Next Steps

Where This Skill Can Take You

The useful thing about project management as a career is that its core is not really about projects. Making things visible, holding decisions in place, and surfacing problems while they are still cheap — that is a general-purpose ability, and a surprising number of well-paid roles are mostly it with a different job title on top.

What actually transfers

It is worth being precise about which parts of this job travel, because it is not the part most people put on a CV. Nobody outside your current employer cares which tool you used or which document template you refined. What transfers is narrower and much more valuable:

• Turning vagueness into something specific enough to act on. Somebody says “we should improve onboarding”, and two weeks later there is a scope, an owner and a date. This is rarer than it sounds.
• Holding several unfinished things in mind without dropping any of them. Most people can do two. The job trains you well past that.
• Getting a decision out of people who would rather not make one. Almost every senior role is partly this.
• Saying an uncomfortable thing early, in a way that gets acted on rather than resented. The single most portable skill on the list.

Those four are why the directions below are open to you at all. They are also worth naming explicitly when you talk about your work, because “managed a £2m programme” describes the size of a thing, not what you are good at.

The directions the role widens in

Roughly ordered by how far each sits from what you do today. The nearer ones reuse almost everything; the further ones ask you to be accountable for something genuinely different.

Going deeper: bigger projects, then programmes

The most straightforward direction is more of the same at a higher stake. Projects with more money, more teams, more visible consequences and more senior people paying attention. This is not a change of skill so much as a change of nerve: the mechanics are familiar, but there are more of them at once and less room to quietly fix something before anyone notices.

Beyond that sits programme management, and the shift there is real rather than cosmetic. A project manager is accountable for delivering a thing. A programme manager is accountable for a group of related projects producing a benefit that none of them delivers alone — and increasingly for whether that benefit actually materialised. The uncomfortable part is that a programme can consist entirely of successfully delivered projects and still fail, because the benefit did not arrive. Learning to think that way — in outcomes, dependencies and trade-offs between projects rather than inside one — is the actual work of the transition.

Portfolio roles go a step further again: deciding which projects should exist at all, and stopping the ones that should not. That last part is the hardest thing in this entire discipline, because killing something that is 60% built is politically expensive and almost always correct.

Sideways: delivery leadership and coaching

Some organisations, particularly in software, separate the person who owns a project's scope and commercials from the person who owns how well the team works. Titles vary — delivery lead, delivery manager, agile coach, scrum master at the more junior end — but the common thread is that you are accountable for the flow of work rather than for a specific deliverable.

The appeal is that it plays to the half of project management that most people find more interesting: unblocking, improving, protecting the team's attention. The adjustment is that you lose the plan as a source of authority. You cannot point at a Gantt chart and say a date is at risk; you have to influence how people work, which is slower and less legible from outside. People who like being able to demonstrate what they achieved this week sometimes find this frustrating, and it is worth knowing that about yourself in advance.

Sideways: product management

Product management is the most commonly attempted jump and the one most often underestimated, because from a distance it looks like project management with more meetings about customers.

The difference is what you are accountable for. A project manager is judged on delivering the agreed thing. A product manager is judged on whether the agreed thing was worth building — which means being the person who chose, in public, and being visibly wrong sometimes. That is a genuinely different relationship with risk, and it uses skills that project work does not develop: reading customer evidence, understanding commercial models, saying no to a plausible idea because something else matters more.

What carries over is substantial, though: dependency management, stakeholder handling, and the discipline of making fuzzy intentions concrete. The most common route is lateral within a company you already know, because domain knowledge does a lot of the work early on. Trying to switch company and function at the same time is much harder.

Further out: operations, chief of staff, consulting

Operations roles and chief-of-staff positions look different on paper and feel familiar in practice. Both are largely about coordination under uncertainty, competing priorities and getting decisions out of senior people. The adjustment is that the work never finishes. There is no closure, no handover, no retrospective — and if you draw your satisfaction from finishing things, that absence takes some getting used to.

Independent consulting or contracting is the other direction, and it splits sharply. The delivery work is the same or easier; the difficulty is everything around it — finding clients, pricing, gaps between contracts, and having no organisation behind you when a project goes wrong. It suits people with a strong network and a tolerance for uneven income, and it punishes people who took the leap primarily to escape an employer.

The quiet multiplier: domain depth

One thing separates project managers who can be hired anywhere from those who are sought out specifically, and it is not certification. It is knowing an industry deeply enough to be useful in the conversation rather than just organising it.

A project manager who genuinely understands clinical trial regulation, or construction sequencing, or payments infrastructure, is worth considerably more than a generalist — because they catch the thing that is about to go wrong before it appears on any risk register. This is slow to acquire and cannot be shortcut, which is exactly why it holds its value.

The practical form of this is the shape people describe as T-shaped: broad competence across the general craft, plus one vertical of real depth. If you have spent four years in one industry, that depth is already accumulating whether or not you have been treating it as an asset. Most people undersell it.

A note on what is changing

It is reasonable to wonder how much of this role automation will absorb. The honest answer is that nobody has credible data on it yet, and that the parts most exposed are the parts that were never the point: assembling status reports, chasing updates, maintaining schedules, summarising meetings. Those are real work, and losing them to software is a gain rather than a threat.

What is not obviously automatable is the part this tutorial keeps returning to — noticing what nobody said out loud, getting a reluctant decision made, deciding what the team will not do, and being the person who says the uncomfortable thing early. It is worth being deliberate about which half of the job you are visibly good at, because the reporting half is the one that has always been easiest to replace and it is getting easier.

How to actually make a move

• Do the next role before you have it. Every one of these directions has a version you can take on inside your current job: coordinate across two projects, coach a struggling team, write the business case rather than the plan. Nobody promotes on potential when evidence is available.
• Change one variable at a time. New function at the same company, or the same function at a new company. Both at once means arriving with neither credibility nor context.
• Describe outcomes, not scale. “Ran a twelve-person programme” says how big it was. “Caught a dependency in month two that would have cost a quarter” says what you are for.
• Notice the comfort trap. The most common career mistake in this field is not a bad move; it is five good years at exactly the same difficulty, because things are going fine and nobody has any reason to complain.

How this looks in AB

Career moves in this field are argued from evidence, and the evidence is usually the record of what you have run. In AB Projects, closed projects stay intact and searchable — scope, dates, decisions, the wiki articles written along the way — so when you need to describe what you did, you are reading rather than reconstructing from memory two years later.

The same archive is what makes the moves above possible from the inside. Coordinating across two projects, spotting the dependency between them, writing the case for stopping one — these all get considerably easier when the work is visible in one place rather than spread across four tools and several people's inboxes.

Terms used on this page

Programme management

Coordinating a group of related projects that together deliver a benefit no single one achieves alone, managing the dependencies and trade-offs between them. More →

Benefits realisation

Checking, after delivery, whether the value a project was justified by actually arrived. It is the measure programmes are judged on, and the one most organisations quietly skip. More →

Product manager

The person accountable for deciding what gets built and why, based on customer and commercial evidence — as distinct from the person accountable for delivering it. More →

Delivery lead

A role focused on how work flows through a team — removing impediments, improving the way delivery happens — rather than on the scope and commercials of one project. More →

PMO

Project (or portfolio) management office — the function that sets standards, holds the overall view across projects, and often owns the decision about which ones proceed. More →

T-shaped

Broad competence across a craft combined with genuine depth in one area — for a project manager, usually one industry understood well enough to anticipate its specific failures. More →

Related reading