Pivoting Careers in Tech: My Job Board for Burned-Out Engineers

I built a job board because I kept getting the same email.

Not literally the same email, but close enough. Every few weeks, someone would read one of my articles about burnout or career transitions, and they'd send some version of: "I've been a software engineer for fifteen years. I'm good at it. I don't want to do it anymore. What else can I do?"

The first few times, I wrote long thoughtful replies. By the twentieth, I realized I was essentially maintaining a personal career counseling service in my inbox, and maybe I should just build the thing that answered the question at scale.

So I did. The Grizzly Peak Software job board is specifically designed for engineers who want to pivot — not out of tech entirely, but into roles that leverage their technical background without requiring them to ship production code every day.

This is the story of why I built it, how I built it, and what I've learned about career transitions for experienced engineers along the way.

---

The Pivot Problem

Here's the thing about being a senior software engineer who wants to change careers: you're simultaneously overqualified and underqualified for almost everything.

You've got fifteen or twenty years of problem-solving, system design, and technical communication skills. You understand how software gets built at every level. You can debug anything, architect solutions, evaluate tradeoffs, and explain complex concepts to non-technical people.

None of that matters when you're looking at a job listing for "Technical Product Manager" that requires "3+ years of product management experience." You don't have that experience, even though you've been informally doing product management your entire career — scoping features, prioritizing backlogs, translating user needs into technical specifications.

This is the pivot problem: the skills transfer, but the title doesn't. And most job boards are organized by title, not by transferable capability.

I wanted to build something that cut through that mismatch.

---

What Burned-Out Engineers Actually Want

Before I started building, I spent a few months paying attention to what people actually asked for. Not what career advice articles said they should want, but what they actually described wanting when they wrote to me or commented on my articles.

The patterns were remarkably consistent:

Less context-switching. Almost everyone mentioned feeling fragmented. They wanted roles with longer attention spans — fewer meetings, fewer interruptions, more sustained focus on one thing at a time.

More communication, less code. This surprised me at first. Many experienced engineers discover they're actually better at explaining technology than building it, and they find the explanation more satisfying. Technical writing, developer relations, solutions engineering — these roles let you use your depth of knowledge in a communication-oriented way.

Remote work, non-negotiable. After the pandemic reshuffling, almost everyone I heard from had structured their lives around remote work and wasn't willing to give it up. This is especially true for engineers over 40, who often have family, property, and community ties that make relocation impractical.

Meaningful work. This one sounds vague but it came up constantly. Engineers who'd spent years optimizing ad click-through rates or building features nobody used wanted to feel like their work mattered. Education, developer tools, open source, climate tech — the specific domains varied but the desire was the same.

Reasonable hours. Not "hustle culture." Not "we're a family." Not "unlimited PTO that nobody takes." Actual, honest-to-god reasonable hours with boundaries that the company respects.

---

The Categories That Matter

Based on those conversations, I identified fourteen career categories that represent realistic pivots for experienced software engineers. These aren't fantasy jobs. They're real roles at real companies that specifically value engineering backgrounds:

Developer Relations / Developer Advocacy — You already know how to talk to engineers because you are one. DevRel roles involve creating content, speaking at conferences, building sample applications, and serving as the bridge between a product team and its developer user base.

Technical Writing — Documentation, tutorials, API references, technical blog posts. The engineers who are best at this aren't the ones who love writing per se — they're the ones who love making complex things understandable. If you've ever spent an afternoon rewriting confusing documentation because it bothered you, this is your signal.

Solutions Engineering / Sales Engineering — You help potential customers understand how a technical product solves their specific problems. It's part engineering, part consulting, part relationship management. The pay is often excellent because it's directly tied to revenue.

Technical Product Management — Defining what gets built and why. If you've spent years frustrated that your product manager doesn't understand the technical implications of their decisions, this might be where you belong.

Engineering Management — I know, this one seems obvious. But a lot of engineers dismiss it because they tried it once at a company with bad management culture and hated it. At the right company, engineering management is a fundamentally different experience.

Technical Training / Education — Teaching other engineers. Bootcamps, corporate training, online courses, university positions. If you've ever mentored a junior engineer and found it more rewarding than your own feature work, pay attention to this category.

Data Engineering — Not the same as being a backend engineer, though the skills overlap. Data engineering involves designing and building the systems that collect, store, and process data. It's often a more focused role with less of the full-stack context-switching that burns people out.

And several others — QA/Test Engineering, Security Engineering, Cloud/Infrastructure, Technical Consulting, Technical Project Management, AI/ML Engineering, and open source work.

---

How I Built It in a Weekend

This is the part where my own burnout recovery story connects directly to the job board.

I built the entire system in a weekend using the same agentic AI workflow I've been writing about for the past year. Here's the architecture:

The job board pulls from multiple external APIs — RemoteOK, Remotive, Arbeitnow — on a daily schedule. A fetcher script aggregates new listings from all sources. Before any AI classification happens, a pre-filter eliminates standard software engineering roles. The whole point of the board is to surface alternatives, not more of the same.

The remaining jobs get classified by Claude Haiku into my fourteen career categories. The AI reads the job title, description, and requirements, and assigns it to the most appropriate category. This classification runs at scale — hundreds of jobs per day — for pennies.

var Anthropic = require("@anthropic-ai/sdk");

var classifyJob = function(job) {
    var client = new Anthropic();
    var prompt = "Classify this job into one of these categories: " +
        categories.join(", ") + "\n\n" +
        "Title: " + job.title + "\n" +
        "Description: " + job.description;

    return client.messages.create({
        model: "claude-3-haiku-20240307",
        max_tokens: 100,
        messages: [{ role: "user", content: prompt }]
    });
};

The classified jobs land in a PostgreSQL database. A node-cron scheduler runs the entire pipeline daily at 2 AM UTC. Jobs automatically expire after 30 days so the board stays fresh.

The frontend is server-rendered with Pug templates — no React, no client-side framework, just fast HTML. Category pages, search, individual job detail pages with structured data for SEO. An admin dashboard lets me monitor what's coming in, toggle jobs active or inactive, and track view counts.

The entire system — fetcher, classifier, scheduler, database schema, routes, templates, admin interface — was built in roughly two days. That's not because the system is simple. It's because the agentic workflow let me describe architecture and review implementation instead of typing every line myself.

Two years ago, this would have been a two-week side project that I'd never finish because I'd lose momentum halfway through. The ability to maintain velocity on side projects is, honestly, one of the most burnout-reducing things AI agents have given me. You get to build the things you want to build, and you get to finish them.

---

What the Data Shows

The job board has been running for a few months now, and the usage patterns are interesting.

The most-viewed categories, consistently, are Developer Relations and Technical Writing. These are the roles that most directly convert "I love technology but I'm tired of building it under pressure" into a career path. They're also the roles where the title mismatch is smallest — companies actively seek people with engineering backgrounds for these positions.

Solutions Engineering gets less traffic but higher engagement per visit. My interpretation: fewer engineers know this career path exists, but the ones who find it recognize themselves in it immediately.

Remote jobs get vastly more views than hybrid or on-site roles. This isn't surprising, but the magnitude is striking. Remote listings get roughly four times the views of equivalent on-site positions.

The geographic distribution of visitors skews heavily toward the US West Coast and Western Europe — regions with high software engineering salaries and high costs of living, which is exactly the demographic profile you'd expect for engineers considering career changes.

---

The Emotional Side of Pivoting

I want to talk about something that career advice articles usually skip: the identity crisis.

When you've been a software engineer for fifteen or twenty years, "software engineer" isn't just your job title. It's your identity. It's how you introduce yourself. It's how you think about your place in the world. It's the answer to "what do you do?" at every social gathering for two decades.

Leaving that — even to do something adjacent — feels like a kind of death. I don't think that's an exaggeration. You're letting go of a version of yourself that was functional and respected and clearly defined, and stepping into something uncertain.

I went through this when I shifted from full-time employment to independent consulting. Even though I was still writing code, the loss of the corporate engineer identity was disorienting. It took about six months before "independent consultant" felt real instead of like something I was pretending to be.

The people I talk to who are considering pivots are dealing with the same thing. They can see that a Technical Product Manager role or a DevRel position would use their skills and probably make them happier. But the voice in their head says: "You're an engineer. This is what you do. If you stop doing this, what are you?"

The answer, it turns out, is: someone who used to be an engineer and is now something else that benefits from having been an engineer. That's not a lesser identity. It's an evolved one.

---

Why I'm Not Selling Anything

The job board is free. No premium tier. No resume service. No "career coaching for $300/hour." The jobs come from public APIs and I display them without any paywall.

People ask me about this and the honest answer is that it's part of a content strategy, not a product strategy. The job board drives traffic to Grizzly Peak Software. Some of those visitors read my articles. Some of those readers buy my book. Some of those readers become consulting clients. The funnel is long and indirect and that's fine with me.

But there's also a philosophical reason. The people who visit the job board are, by definition, in a difficult professional moment. They're considering changing something fundamental about their careers. Putting a paywall in front of that feels wrong.

I've been where they are. I remember the specific feeling of Googling "alternatives to software engineering" at 11 PM on a Wednesday, hoping something would make sense. If someone had tried to sell me a career coaching package at that moment, I would have closed the tab. What I actually needed was information: what roles exist, what they pay, what the day-to-day looks like, and whether my skills would transfer. That's what the job board provides.

---

Advice for the Pivot-Curious

If you're reading this and you're somewhere in the burnout-to-pivot pipeline, here's what I'd tell you based on my own experience and the conversations I've had:

You don't have to decide right now. Exploring alternatives is not the same as committing to a change. Browse the categories. Read some job descriptions. See what resonates. You're allowed to be curious without being certain.

Your engineering skills are more transferable than you think. The ability to break down complex problems, communicate technical concepts, and think in systems is valuable in dozens of roles beyond traditional engineering. You're not starting over. You're applying a deep skill set in a new context.

Talk to people who've done it. The best thing I did during my own transition was find other engineers who'd made similar moves. Their stories were more useful than any career guide. LinkedIn is surprisingly good for this — search for people with "former software engineer" in their bios and read their career trajectories.

The money question is real but not as scary as you think. Some pivot roles pay less than senior engineering. Some pay the same or more. Solutions Engineering and Technical Product Management at well-funded companies often match or exceed senior IC engineering compensation. Do the research before assuming you'll take a pay cut.

Remote work is your leverage. If you're pivoting from a location-flexible engineering role, hold that standard for whatever you move into. The remote-friendly employers tend to also be the ones with better work culture generally. It's a useful filter.

---

Building What You Needed

The job board started because I kept getting emails I couldn't answer efficiently. It became something I'm genuinely proud of because it solves a real problem for real people at a moment when they need information more than they need motivation.

If you're in that moment — burned out, pivot-curious, wondering what comes next — go browse the board. Filter by category. Read some descriptions. See if anything lights up that part of your brain that used to get excited about solving interesting problems.

The problems are still interesting. Sometimes you just need to find different ones.

---

Shane is the founder of Grizzly Peak Software. He writes about AI-powered development, career transitions, and building software from a cabin in Caswell Lakes, Alaska.