Tech career pivots and how to make them.

Last week I held a Q&A where anyone could ask me anything. People asked a lot of amazing questions, but I noticed quite a few were around making career pivots in tech. Here are my thoughts and some quick advice which I find very useful.

Career pivots in big tech are the norm. It’s extremely rare that I meet someone who has been in their current job family since college. People get burnt out of writing code, or realize there is something else they would rather do. Managers know this and are more than happy to help you achieve your goals.

For any pivot, there are two principles that dramatically increase your odds of success:

You’ll see me mention these a few times throughout the rest of this letter.

This is an extremely common career move in big tech, and most of the Technical Program Managers (TPMs) I have worked with came from a software engineering background.

They key to pulling this one off (and you’ll notice a pattern pretty quickly here) is to lean into the core skills of the job family you want to move to before you go for a title change.

In this case, you want to highlight how you can manage schedules, create realistic deadlines, align stakeholders, work cross functionally, delegate work, define success, and deliver clear and concise updates to senior level and up leadership who don’t have time to hold your hand.

Most high performing software engineers already do these things, so you just need to lean into it a little more, and highlight that you are doing it.

This is also a very common pivot, and I have many friends who are working on this exact process right now. The key is once again to lean into the shared responsibilities between the job families.

For QA, learn as much as you can about the automation side of things. Start by writing simple scripts, then go deeper. Learn about testing frameworks, CI/CD pipelines, and the systems create what you eventually do QA on.

There is also a human aspect to this. Let’s say you do QA for weekly deployments of a software product. Meet the team who writes the software, help them understand your process and understand their process. Let them know you are interested in what they do, and that you’ve been getting better and better at coding / system design / automation. Offer to pick up a few tasks for them here and there. Become their friend, and next time a job opens up, they’ll ping you first. I’ve personally seen this many times.

This is one of the easiest pivots on this list. You already know how to code, and you’ve presumably worked with backend systems your entire career.

Start by learning whatever backend stack / framework your current company uses. Say you’re a React dev you integrate with a GraphQL API. Start by understanding exactly how GraphQL works, why it was chosen here, what the downsides of using it are (there are many). Then consider what happens when you make a call for some data. What underlying systems are invoked, where are they deployed, what language are they written in. This is your crash course in system design & distributed system architecture

Next learn a popular backend language + the flagship framework. For most people this usually ends up being Node + Express (because they already know JS), but Java + Spring is a super solid stack if you want to learn something new for enterprise, or Python + FastAPI if you are into AI stuff.

Start picking up tasks as close to the backend as you can. Offer to configure CORS on the backend next time it breaks. See if you can optimize your work to reduce load on backend APIs and explain what you did to the backend devs. TELL THEM you are interested in transferring.

Do this, and congrats, now you are a fullstack dev. No reason to go from frontend to backend when you can have it all.

Many of my coworkers at Amazon made this pivot, I think it’s one of the most underrated ways to get into SWE today. If you don’t know, Network Ops are the people who monitor and manage physical infra (networks, servers, devices), and configure / manage how they connect to each other. Currently a lot of this job is still done manually. SSHing onto servers to manually deploy configs, plugging a laptop into a router to make a change, etc.

In networking focused software orgs, knowing how to do this stuff is extremely valuable, outside of networking focused software orgs, much less so. So focus your SWE job search on networking orgs within companies that have large networking teams. Some examples are Amazon, Cisco, Oracle, SpaceX, Microsoft, and Google.

Unfortunately, you still have no shot at any of these jobs unless you also know how to code. Most network ops folks I have met have a strong command over the CLI, shell scripting, and python (all are used for basic network automation). They generally tend to fall short when it comes to writing clean, structured code. Focus on object oriented programming, software design patterns (singleton, builder, etc) and system design.

This move used to be very common, but it’s changing so quickly as the PM role changes (it’s becoming more and more technical). Let’s start by considering the shift in goals: As a software engineer, you’re rewarded for shipping high-quality code and reliable systems. As a Product Manager, you’re rewarded for driving customer outcomes, aligning stakeholders, and making clear trade-offs.

Just like the other pivots, the key is to start doing the job before you have the title.

Lean into PM responsibilities on your current team: help collect and clarify ambiguous requirements, write problem statements and user stories, define success metrics, document edge cases, calculate the ROI of each feature, and propose MVP cuts. Become the person who can explain why a feature matters and how you decided to build that feature over the 10 other features you could have built.

I always thought I would make this pivot at some point in my career. Hasn’t happened yet, but I’ve spoken to many managers who have so I feel qualified to write about it.

This is usually a lateral move. Start by getting promoted to manager level (senior engineer) before you try to make the transition. As a senior eng, focus on mentoring junior devs, task prioritization, unblocking teammates, building relationships and driving alignment across teams, and giving feedback to teammates. Shift your story from ‘I delivered X’ to ‘I enabled a team to deliver X.’

Becoming a manager is a big decision. Before you go for it, make sure you are comfortable making difficult decisions (who to fire, who to promote) and directly giving critical feedback. Many managers I know have come to regret the decisions. I suggest talking to your own manager about how they made the pivot, why they made it, and if they would do it again if given the chance to go back.

This is one that I came extremely close to making myself. If you like system design, architecture and talking to customers, this is a great one to consider.

The biggest issue most people have when trying to make this pivot is they are too technical, and only talk to deeply technical people when making decisions and considering trade offs. As an SA you need to be good at explaining technical tradeoffs to non-technical stakeholders, running proofs-of-concept, translating semi-vague requirements into architecture, and the dreaded pre-sales demos, diagrams, and RFCs.

You also need to understand both breadth and depth. For example, if you were targeting an AWS Solutions Architect role, you need to understand the most common AWS services, how they work together, and how companies commonly use those services. You should also be able to go deep in one or more areas. IE if you choose to use DynamoDB over RDS, how would you pick your partition key? What types of scaling limits can you expect to face? How would you migrate to another DB if needed?

So pick a company where you are familiar with the tech, learn the ropes and apply
Common companies to target: AWS, Google Cloud, Databricks, Snowflake, Palantir, enterprise SaaS

Good luck & see you next week.

Arjay