Make a lateral career move without starting from zero

A lateral move can make sense when you want different problems rather than a bigger version of your current job. It can also become a vague promise: keep doing everything you already do, add a new area, and perhaps receive a new title later. Define the move before you accept the extra work.

Describe the new work before comparing titles

Start with responsibility. What would you deliver? Which decisions would you make? Who would review uncertain work? What would a normal week contain? Two teams can use the same level name while expecting very different independence and depth.

Use the distinction between task execution and earlier judgement to describe your current scope. Then compare the destination against that scope rather than assuming a change of technical area resets your entire career. Some experience transfers directly; some needs translation; some genuinely does not transfer yet.

The career inventory in Kimberly Brown’s Next Move, Best Move is a useful starting idea: take stock before selecting the next step. The author’s public site identifies career strategy and self-advocacy as themes. The transfer map below is our developer-specific application, not a reproduced assessment from the book.

Try the decision

A backend developer wants to move into reliability work. What should the transition plan include?

Start again as if prior work has no valueMap transferable tasks, gaps and a supported first assignment

That hides transferable debugging and operational experience.

Next step: List what transfers and what genuinely needs support.

This is an illustrative decision with stated assumptions. It cannot establish your employer’s policy or predict an individual career outcome.

Make transferable experience visible

In an illustrative example, a web application developer wants to join a platform team. They have experience investigating failures, writing tests, and coordinating releases. They have not designed shared deployment infrastructure. “I have years of engineering experience” hides both the useful experience and the important gap.

A better conversation connects each claim to work. Investigating application failures may transfer to reading logs and testing hypotheses. Coordinating a release may transfer to understanding sequencing and communicating risk. Neither establishes expertise in deployment permissions or recovery procedures. Those require separate learning and review.

Prepare three short columns: experience you can demonstrate, a task in the new role that uses it, and the unfamiliar part. For example: “Maintained release checks / improve a deployment validation step / need review of the platform’s access model.” This gives the receiving manager something concrete to discuss.

Bring an example you are allowed to share, or explain the work at a level that protects confidential information. Do not export internal documents to a personal portfolio. The point is to make your reasoning understandable, not to overwhelm the new team with evidence you had no right to copy.

Agree on the conditions of the move

Discuss the starting scope, support, and review point. In the example, the developer could take responsibility for a small validation improvement while an experienced platform engineer reviews security-sensitive decisions. A named handover owner takes their old feature work. Without that handover, the move is two jobs rather than a transition.

Ask how performance will be judged while you learn the new area. Is the expectation immediate independence in every component, or reliable delivery within an agreed boundary? What access and documentation will be available? Who can answer questions when the usual reviewer is away?

Discuss compensation, level, reporting line, and any change in support duties explicitly. Do not rely on “we will sort that out later” for a condition that determines whether you would accept. An internal move can still have meaningful personal costs. The right agreement depends on the employer’s process, not on a universal rule about lateral moves.

Use a plain confirmation: “My initial responsibility is this bounded area. This person reviews unfamiliar decisions. These old responsibilities transfer to this owner. At the review, we will look at these examples of work.” End-to-end ownership helps identify responsibilities that might otherwise disappear between teams.

Avoid two false shortcuts

The first shortcut is overclaiming. Calling yourself a platform expert because you have used a deployment tool invites expectations you cannot yet meet. It also makes it harder to ask basic questions. State the gap before the team discovers it during a high-risk task.

The second is erasing your experience. Treating yourself as a complete beginner can hide useful judgement about testing, delivery, and collaboration. You can be experienced in engineering and new to a domain at the same time. A credible transition makes that combination explicit.

A move may not be available, even when your case is good. Headcount, timing, hiring rules, or the team’s need for immediate expertise can prevent it. That is not proof that the capabilities do not transfer. It may mean the opportunity and your current readiness do not match.

Review whether the move is doing its job

At the agreed review, inspect work rather than impressions. Which tasks can you now complete reliably? Which unfamiliar decisions still need support? Has the receiving team provided the access and review it promised? Are you actually spending time on the work that motivated the move?

If the direction remains uncertain, test another small slice of the role. A lateral move is useful when it changes the work in a way you value, not merely when it gives your CV another department name.