Career Paths: Role-Based Sequences From Entry to Senior

Career progression in technical roles is less about accumulating technologies than most job adverts suggest. The move from junior to mid is largely about reliability; from mid to senior it is about judgement and scope; beyond that it is almost entirely about the effect you have on other people's work.

These paths sequence what to learn for each role, using material published on this site. They make no claim to be the only route, and none of them require a course.

The pattern that repeats in every role#

Junior — can complete a defined task. Given a well-scoped piece of work, you produce something that works and does not surprise anyone. The skill being built is competence with the tools.

Mid — can be given an ambiguous problem. You break it down yourself, notice what was not said, ask the right question early rather than the obvious question late, and deliver without supervision. The skill is judgement about scope.

Senior — improves the work of people around you. Your design decisions hold up a year later, your reviews teach, and problems that would have become incidents quietly do not. The skill is foresight and communication.

The most common stall is at mid: engineers who keep adding technologies when the constraint has become the ability to handle ambiguity and to say what they are not going to do.

Path — Backend / platform engineer#

Entry: one language properly, version control, Linux basics, how to read an error. Build small things end to end.

Mid: testing beyond happy paths · DevOps — pipelines, rollback, on-call · Docker · data engineering fundamentals · security basics from cyber security. Own a service in production, including being paged for it.

Senior: architecture — the decisions that are expensive to reverse · Kubernetes if your estate justifies it · cloud and AWS cost and identity · writing decision records people can use.

The step that matters most is being on call for something you built. Nothing else teaches operability as quickly.

Path — AI / ML engineer#

Entry: solid software engineering first. The most common weakness in this role is people who can call an API and cannot write maintainable, tested code around it.

Mid: RAG properly — chunking, hybrid retrieval, permissions, measurement · prompt engineering · AI testing — evaluating systems that vary between runs · cost and latency as first-class concerns.

Senior: AI agents — bounded autonomy, tool blast radius, spend caps · architecture for AI systems · AI governance and the compliance surface · knowing when the answer is that a language model is the wrong tool.

That last point is what distinguishes senior in this role. The field rewards people who can say "this is a lookup, not a generation problem" before six months have been spent.

Path — DevOps / SRE#

Entry: Linux genuinely — processes, permissions, disks, logs, signals · networking basics · one scripting language · version control beyond commit and push.

Mid: Docker · CI/CD from DevOps · infrastructure as code · monitoring that distinguishes "up" from "working" · cloud and one provider such as AWS in depth.

Senior: Kubernetes if it is warranted · reliability practice — error budgets, blameless review · security posture · reducing toil rather than automating around it.

Path — Business analyst / delivery#

Entry: BRD and requirements that can be tested · stakeholder interviewing · the project charter.

Mid: FRD · RTM · UAT · change management · risk register that changes decisions · agile, scrum, kanban.

Senior: SRS and working with engineering on non-functional requirements · enterprise architecture portfolio thinking · running lessons learned that change the next project · saying no with evidence.

What actually gets you promoted#

Uncomfortable but consistent across organisations:

Finishing things. People who complete unglamorous work reliably are promoted ahead of people who start impressive work.

Being trusted with bad news early. Engineers who surface a slipping date in week two are worth more than those who deliver a surprise in week eight, however good the eventual result.

Writing. The senior people whose influence exceeds their seniority are almost always the ones who write clearly — decision records, incident reviews, a paragraph that ends an argument.

Scope, not technology. Nobody is promoted for learning a framework. They are promoted for handling a larger, vaguer problem than last year.

FAQ#

How long does each level take?#

Typically two to four years per step early on, then it depends far more on the opportunities available than on time served. Someone given real scope moves faster than someone doing junior work competently for five years — which is a reason to weigh what you will be asked to do above the title offered.

Do I need a computer science degree?#

No, and it matters less each year. It helps with fundamentals and with some hiring filters. What is consistently checked in practice is whether you can build something that works, explain your decisions, and operate what you built.

Should I specialise or stay broad?#

Deep in one area and functional in the neighbouring ones. Pure specialists are vulnerable when the area falls out of favour; pure generalists struggle to be trusted with the hard problems. Depth in one thing is what gets you hired; the breadth is what makes you useful once inside.

Is management the only way up?#

No, though it is the better-signposted route. Most organisations of reasonable size have a senior individual-contributor track. The distinction worth understanding: management scales through people, senior IC scales through decisions and systems. Both are leadership; only one involves line management.

How do I move into AI from another engineering role?#

From a strong software engineering base, it is one of the shorter transitions available — the scarce skill is not model knowledge but the ability to build reliable systems around unreliable components. Start with RAG and AI testing, and build something real.

What if my current job will not give me the next level's work?#

Then you have useful information. Ask explicitly for the scope you want and see what happens; if the answer is no twice, the constraint is the role rather than your readiness. Building something substantial outside work is a slower substitute but a real one — see Projects.

Are certifications worth it for progression?#

Occasionally for hiring filters, rarely for the work itself. See Certifications for which ones hold value and which do not.

Related Articles#

Work through Courses for the reading order, practise with Exercises, build something substantial with Projects, and prepare with Interview Questions.

What else is coming for Career Paths