Where Software Developers Go Next (And What Actually Works)

Glen Chiacchieri spent seven years writing code at Google before he quit to become a therapist. When people heard this, they assumed he was throwing his career away. He thought so too, for a while.

Then he noticed something. Debugging a complex system and figuring out why a person is struggling emotionally require exactly the same cognitive moves. You observe symptoms. You form hypotheses. You eliminate possibilities. You find the root cause. The surface content could not be more different. The thinking underneath is nearly identical. "Your skills are transferable," he eventually wrote. "You are not your job."

If you are a software developer reading this in 2025 — employed but watching the job postings thin out, wondering whether to wait and see or actually move — Glen's insight is worth sitting with before looking at any data. AI-related layoffs surged 332% in 2025, hitting 54,836 US positions, and 40% of those cuts fell on software engineers specifically. A Stanford study found a 13% relative employment decline for early-career engineers in AI-exposed roles. The threat is structural, not anecdotal.

So the question shifts from "is this real?" to "where do people actually go, and does it work?" This article answers both, with honest timelines and the one thing you should do in the next 90 days.

The Five Realistic Exits — And What They Actually Cost

"Your skills transfer" is easy to say. The harder question is which destination is worth the journey given your specific constraints. Five paths come up repeatedly among developers who have made this work, and they differ sharply enough that enthusiasm for a job title is the wrong basis for choosing between them.

Borja del Santo made the transition most developers say they want: from Senior Software Engineer at Amazon to Senior Product Manager, in roughly one year, without a salary cut. His engineering background turned out to be an advantage, not a liability. Technical teams trusted his judgment in ways they would not have trusted a PM without that foundation. He called it an "incredible superpower." His story establishes that the PM path is real and that the financial fear is addressable — but his path took preparation, mentorship, and deliberate internal positioning before any formal move.

For developers weighing financial upside, the AI/ML engineering path carries the strongest market signal right now. Average salaries for AI engineers reached $206,000 in 2025 — a $50,000 increase from prior cycles — with demand outstripping supply at a ratio of 3.2 to 1. That gap will not last forever, but it is open now.

The table below maps all five paths across the variables that should actually drive the decision.

Destination Role | Typical Timeline | Pay Impact, Year 1 | Hardest Skill to Learn | First Credential Worth Getting --- | --- | --- | --- | --- AI/ML Engineer | 6–12 months | +15–55% immediately | Probabilistic / statistical thinking | AWS ML Specialty or project portfolio Product Manager | 3–6 months | –5 to –15% initially | Influence without authority | None — ship a product; portfolio beats credentials Cybersecurity Analyst | 3–9 months | –6% (recovers quickly) | Adversarial / attacker mindset | CompTIA Security+ Data Scientist | 6–12 months | –15% at non-tech firms | Hypothesis-driven statistical rigor | Project portfolio (Kaggle, GitHub) DevOps / SRE | 2–4 months | –10 to –20% | Minimal conceptual shift; tooling | None required; hands-on experience leads

The starkest finding here: the highest-paying transition and the most credential-friendly transition share nearly the same timeline window. Developers who are anxious about income should look hard at AI/ML engineering first. Developers who want the clearest path from credential to job offer should look at cybersecurity, where CompTIA Security+ functions as a genuine labor market gatekeeper — not a résumé decoration. The PM and data science paths reward portfolio-building and patience over speed.

But a table of roles and timelines answers "where" and "how long." It does not answer the question that every developer actually worries about: do the skills I already have count for anything in these fields, or am I starting from zero?

What Actually Transfers (It Is Not React or Kubernetes)

This is where Glen's observation becomes more than a curiosity about one person's unusual life.

He spent years at Google debugging complex distributed systems — observing anomalous behavior, forming hypotheses about root causes, eliminating possibilities systematically, verifying fixes. When he became a therapist, he noticed the cognitive moves were identical. A client presents symptoms. You form hypotheses about underlying causes. You eliminate possibilities. You find the root cause. He stated it plainly: "The ability to debug a complex system is basically the same skill as figuring out why a person is struggling emotionally." His point is not that coding and therapy are similar. It is that the thinking underneath both is the same.

That pattern generalizes directly to every path in the table above. The systematic hypothesis-generation that finds a memory leak is the same pattern that drives threat hunting in cybersecurity, model diagnostics in data science, and user research synthesis in product management. You already do this every day. You just call it something different.

Your skills are transferable. You are not your job.
— Glen Chiacchieri, Software Engineer turned Psychotherapist

Three specific capabilities transfer across nearly every destination role. First, systematic debugging: the trained ability to break an opaque system into testable components. Second, production-grade reliability thinking: the instinct to design for edge cases and failure modes, which most non-engineers simply do not develop. Third, automation instinct: the deeply ingrained impulse to eliminate repetitive manual work, which is rare and valuable in every field it touches.

These are not "soft skills." They are specific and uncommon in most destination fields, which is exactly why hiring managers in those fields actively value developer backgrounds when they can get them.

It is also worth naming one additional advantage for senior engineers: architectural and stakeholder-communication experience — knowing how to translate between business constraints and technical realities — is precisely what AI cannot yet replicate. The Stanford data's seniority split is not accidental. That kind of judgment is hard to automate. It is also directly applicable in PM, security architecture, and ML engineering roles.

About 54% of developers considered a career change or transitioned in the past year, according to Stack Overflow's 2025 survey. The ones who moved are not uniquely gifted. They used the same cognitive toolkit you have. They just found out it worked by testing it.

Knowing what transfers is necessary. But the developers who actually completed transitions share one more thing: they did not wait until they were certain. They ran a small experiment first — and that experiment looked the same across radically different destinations.

Why the Leap Is Not a Leap

Every successful voluntary transition in this research followed the same pattern: a cheap, low-stakes test in the target domain — weeks or months before any formal commitment — that either confirmed the direction or revealed a mismatch early enough to adjust without financial damage.

Borja spent time shadowing a PM friend and reading one foundational book before applying internally. Glen volunteered on a crisis line before applying to graduate school. Liam Hinzman spent 240 hours drawing before resigning from his tech startup — treating the side practice as an experiment, not a hobby. Each of these is a staged test, not a leap. The pattern holds whether the destination is adjacent (PM, DevOps) or radically different (therapy, art).

Your identity is bigger than your job title.
— Sam Jeet, Full-Stack Software Engineer and Founder of Life Between Titles

The contrast with Sam Jeet's experience makes this concrete. She was a full-stack developer at Pluralsight when a 20% workforce reduction eliminated her role and her entire team. What followed was over 100 job applications, multiple final-round rejections, and savings depleting against a mortgage. The involuntary, reactive nature of her search was the source of most of the damage — not her skills, which were real. She eventually landed a new engineering role at SixFifty, and she went on to build "Life Between Titles," a platform for displaced tech workers, using her engineering skills to construct it and her lived experience to make it matter. Something new emerged. But the compressed timeline and financial pressure made a hard process brutal.

Voluntary, staged transitions handle that same identity work and financial stress sequentially and at a chosen pace. The most common mistake among developers who delay: waiting for certainty before starting. Developers trained in deterministic systems want to know the answer before committing. Career transitions are probabilistic. You get better information by running a small, reversible experiment than by researching for six months and still not moving.

One practical note from the research: Glen built 18 months of savings before leaving Google; Liam saved aggressively for a full year before resigning. Staged transitions require financial runway — not a dramatic stockpile, but enough to give the experiment room to breathe. Calculate your own runway before you start the clock. The same logic applies regardless of which role you are targeting. The specific experiment differs — a Kaggle notebook versus a security lab versus a product spec — but the structure is identical.

Your Next 90 Days

Glen Chiacchieri's observation — "You are not your job" — was the hardest thing for him to believe, even after he had already left. The developers who have made this work did not resolve that question before moving. They ran a small experiment, and the experiment answered it for them.

Here is what that looks like in practice.

Week 1 through 2: run a role-specific test in four hours total. For the data science path, complete one Kaggle notebook on a dataset that interests you — aim for a clean documented analysis, not a winning model. For cybersecurity, work through one beginner room on TryHackMe or HackTheBox and assess whether the adversarial thinking feels engaging or draining. For PM, write a one-page product spec for a feature you wish existed in software you use daily, then share it with one person outside engineering and ask if it makes sense. For AI/ML, implement one end-to-end model from a tutorial, change one parameter, and observe what breaks. For DevOps, set up a basic CI/CD pipeline for a personal project from scratch.

Month 1: make one structured investment. Enroll in one course aligned with your target role — machine learning fundamentals for AI/ML, Security+ study materials for cybersecurity, a statistics course for data science. The goal is not completion. It is assessing whether the domain holds your attention under structured pressure.

Month 2 through 3: have one real conversation. Find one person already doing the job you are considering and ask for 20 minutes — not for advice, but for a reality check. Ask what surprised them most about the role and what they wish they had known before starting. That single conversation will surface information no article can provide.

Calculate your financial runway before you start. Even a 90-day experiment runs more honestly when you know how many months of savings stand between your current situation and genuine pressure. That number focuses the experiment.

Glen called his career change a debugging session. He observed symptoms, formed a hypothesis, and tested it. The hypothesis was right — but he did not know that until he ran the test. Neither will you. Start the experiment.

Recommended Tools & Resources