Roles, levels and transitions

Your own developers become the customers. The subject changes: not a feature but reliability and tooling.

The shortest way in is through data and queues. You will have to pick up statistics, not just engineering.

Not a promotion: the horizon grows to several systems, and you will write less code.

A different profession with different measures of success. Roughly one in three comes back, and that is normal.

The neighbouring surface: the tools are different, the conversation about contracts is the same. You will have to take the browser seriously, not only the API.

Adds LLM evaluation, retrieval, tool use and model constraints.

Connect the client, API and data in one working product.

Start with threat modeling and access boundary testing.

Build a reproducible data pipeline with quality checks.

Turn a recurring team task into a self service capability.

Write documentation that lets someone complete a task independently.

Connect the software model with the constraints of a physical device.

Similar problems of state and navigation, a different runtime and a different release cycle through the stores.

Through BFF and APIs. You will have to pick up data and reliability in earnest.

A common trajectory: being close to the user helps, but the measures of success change completely.

A different job: you no longer have a task of your own, you have other people's.

Connect the client, API and data in one working product.

Test a user journey through prototyping and research.

Write documentation that lets someone complete a task independently.

The nearest neighbour in problems of state and navigation; the release cycle becomes far faster.

Through APIs and synchronisation. You will have to pick up data, transactions and load.

A different profession. It shows especially in mobile teams: the release cycle starts to run you rather than the other way round.

Connect the software model with the constraints of a physical device.

The usual trajectory, through SDET. You will have to pick up design in earnest, not just automation.

Through tests in CI and observability: the subject is the same — trust in the system.

QA is often the first to spot contradictions in the requirements — and that is half of an analyst's work.

Running quality is management: the subject becomes people and the flow of work rather than the checks. People come back into testing from it the same way they come back from any other management job.

Start with threat modeling and access boundary testing.

The move back is common and is not counted as a failure: operations experience makes an engineer worth more.

Whoever has held production sees non-functional requirements better — and that is half of an architect's work.

Through pipelines and storage. The infrastructure part is familiar, the statistics is not.

A different profession. A risk of its own: in an on-call team the manager quickly turns into an incident dispatcher.

Adds LLM evaluation, retrieval, tool use and model constraints.

Start with threat modeling and access boundary testing.

Turn a recurring team task into a self service capability.

Connect the software model with the constraints of a physical device.

The engineering part carries over almost entirely; the statistics goes away, the load arrives.

Data is the shared subject, but the analyst's customer sits inside the business rather than being a model.

The usual move for those who are tired of proving the value of a model and want to decide what gets built at all.

Through MLOps: the same pipelines and observability, only the subject is a model rather than a service.

Adds LLM evaluation, retrieval, tool use and model constraints.

Build a reproducible data pipeline with quality checks.

Connect a product question, data and a testable hypothesis.

One of the most common trajectories. The question changes: not 'how do we write this down correctly' but 'is this worth doing at all'.

Possible if you pick up engineering in earnest. Knowing the domain stays an advantage while you do.

Through data analytics. You will have to pick up statistics and the engineering of pipelines.

Adjacent work: acceptance criteria are the shared subject of both roles.

The shortest way in is through integrations and non-functional requirements. You will have to answer for the solution, not only for the description of it.

Test a user journey through prototyping and research.

Own dependencies, risks and delivery of an outcome.

Write documentation that lets someone complete a task independently.

Connect a product question, data and a testable hypothesis.

Going back into analysis is a normal move, especially if you would rather not answer for the commercial result.

Adjacent work with people, but the subject is different: not the team but the value for the user.

Through product analytics. You will have to stop ordering numbers and start counting them yourself.

Test a user journey through prototyping and research.

Own dependencies, risks and delivery of an outcome.

Write documentation that lets someone complete a task independently.

Connect a product question, data and a testable hypothesis.

Facilitate a process change and review its effect on team work.

Roughly one in three goes back into engineering, and that is good news. After a year in management a person is worth more than before.

Adjacent work. The subject of responsibility changes: not the team but the outcome for the user.

Back into the technical branch, but keeping the scale: several systems instead of one team.

A way back into engineering for those who did not come from the backend. Your hands do not reset, but the frameworks will have moved on while you were managing.

Own dependencies, risks and delivery of an outcome.

Facilitate a process change and review its effect on team work.

Going back into development is normal: an architect two years away from code starts designing blind.

A different profession at the same scale: there the subject is people, here it is systems.

Adjacent work: non-functional requirements and fault tolerance are the shared subject.

Start with threat modeling and access boundary testing.

Turn a recurring team task into a self service capability.

Focus shifts to API reliability, data and transactions rather than model quality.

Requires statistics, experimentation and model training beyond LLM integration.

The main work shifts toward infrastructure and service reliability.

Responsibility expands to system boundaries and technical decisions across teams.

Work shifts to people and team organization; technical depth requires separate attention.

Build a reproducible data pipeline with quality checks.