Job Security is a Lie (And Technical Purity Won't Save You)
Between 2022 and 2024, 250,000 tech workers were laid off. Technical excellence didn't protect them. Here's what does.
The market doesn’t pay you to write beautiful code. It pays you to solve business problems. Forget the tech stack; learn the balance sheet.
The Myth of the 10x Coder Shield
The tech industry spent a decade building a religion around craft. The right language. The right patterns. Twelve terminal tabs and a mechanical keyboard. If you could pass the FAANG interview gauntlet - the graph traversals, the system design whiteboard, the O(n log n) proofs - you were untouchable. The story was seductive: master the tools and you would never be in someone’s spreadsheet.
Then the spreadsheets arrived anyway.
Between 2022 and 2024, more than 250,000 tech workers were laid off across hundreds of companies. The cuts didn’t spare the engineers with the perfect LeetCode scores or the pristine microservice architectures. Senior engineers with fifteen years of experience and impeccable GitHub profiles got the same calendar invite as everyone else. The calendar invite that blocks off thirty minutes on a Tuesday with HR and no agenda.
Technical excellence didn’t fail those engineers. It just didn’t protect them. A skill can be genuinely valuable and still provide zero leverage when a CFO needs to shave eight percent from headcount before the next board meeting. The engineers who survived those rounds weren’t necessarily better engineers. They were harder to replace in a specific business context - contextually irreplaceable in ways that showed up on the spreadsheet before the cuts did.
Generic Skill Was Always the Commodity
AI is collapsing the price of generic technical labor to near zero - not eliminating programmers, but collapsing the price of programmers who are interchangeable. If your value proposition is “I know React,” you are now competing with a tool that writes React components on demand, doesn’t take PTO, and doesn’t need health insurance.
A team builds a feature request intake system. They pick Next.js, set up the routing, wire the API calls, write the types. Clean code. Good tests. Takes three engineers two sprints. Six months later, a product manager uses an AI tool to prototype the same system in an afternoon to validate the concept. The prototype isn’t production-grade - but it didn’t need to be. The question it answered was whether the feature was worth building at all. Three engineers, two sprints, and the real discovery was that nobody needed the feature.
The engineers who are safe aren’t the ones who are faster at the parts AI can already do. They’re the ones who can answer the question the product manager should have asked before the sprint started - the ones who understand the business well enough to say, “before we build the intake system, let’s confirm that the bottleneck is actually intake, not triage.” That sentence is worth more than six weeks of clean React components.
Generic coding skill was always a commodity. AI is just making the commodity price visible. The engineers who built their careers on being fluent in this framework or that cloud provider are finding out that fluency was never the moat. The moat was always the judgment that sat behind the typing.
What AI Cannot Steer Itself Through
Point an AI code generator at a well-specified problem in a stable domain and it will produce working code faster than any engineer. But “well-specified” and “stable domain” are doing enormous amounts of work in that sentence.
A healthcare startup tries to use AI to automate their prior authorization workflows. The AI writes the logic. The logic is technically correct. It also doesn’t account for the fact that payer X uses a different definition of “medical necessity” than payer Y, that the appeal window differs by state, and that one specific combination of procedure code and diagnosis code triggers a manual review that no one documented anywhere - it lives in the head of the one person who’s been doing this for eleven years. The AI-generated code passes unit tests and fails in production for fourteen different reasons that require fourteen different phone calls to fourteen different humans at fourteen different insurance companies to untangle.
The engineer who survives that situation isn’t the one who writes the best code. It’s the one who knew to ask about payer X before writing the first line. Who knew the undocumented edge cases existed. Who understood that “prior authorization” in this context means something different from what the official documentation says.
Domain knowledge is not just context. It is the difference between software that ships and software that becomes a three-month incident. The AI will handle the implementation. You need to handle the reality check. And you can only handle the reality check if you understand the domain well enough to know where the bodies are buried - which requires working in or adjacent to the business, not just the codebase.
Follow the Money
There is a simple test for whether you’re expendable: can you name which features your work contributed to, what business outcome those features drove, and roughly what that outcome is worth? Not in engineering terms. In revenue terms.
Most engineers can’t pass it. They know what they built. They don’t know what it did for the business. That’s not laziness - it’s a structural problem. Engineering teams are often insulated from business metrics by layers of product management and organizational hierarchy. The metrics the team celebrates are deployment frequency and p99 latency. Useful metrics. Not the metrics anyone looks at when headcount is on the table.
The engineers who survived the last round of layoffs had different resumes than the ones who didn’t. One kind listed technology migrations - “led migration from monolith to microservices,” “upgraded from Node 14 to Node 18,” “implemented new CI/CD pipeline.” The other kind listed outcomes - “reduced checkout abandonment by 12% by fixing mobile payment latency,” “cut enterprise onboarding time from 6 days to 1, which unblocked two Q3 renewals,” “rebuilt the export feature that was the number-one support ticket driver.”
Both engineers might have done the same technical work. One of them knows how to describe it in a language the business speaks. The other is describing it in a language that’s invisible to anyone with budget authority.
The question isn’t what you built. It’s what changed because of what you built. If you don’t know the answer, find out. Ask the product manager. Look at the dashboards. Sit in on sales calls if you can. The closer you are to understanding the revenue engine, the more clearly your work speaks for itself when it needs to.
Treat Your Employer Like a Client
The engineers who stay valuable think like consultants - not in the cynical, disengaged sense, not the “I’m just a contractor, not my problem” sense, but in the opposite sense. A good consultant is highly motivated to understand the client’s business, because their value is entirely contingent on the client’s success. A good consultant doesn’t show up with a predefined solution and look for problems to fit it. They ask what the client is trying to accomplish, where they’re stuck, what’s expensive, what’s embarrassing, what keeps the CEO up at night. Then they figure out how to help.
An engineer with a consultant mindset asks a different set of questions before starting any project. Not just “how do I build this?” but “what is this supposed to fix?” Not just “what are the requirements?” but “what does the business need to be true for this project to be worth doing?” If you can’t answer the second question, you are optimizing for the wrong thing. You are polishing the implementation of a possibly wrong decision.
The practical version of this: before you write the first line, write a one-sentence statement of what success looks like in business terms. Not “the feature ships” - that’s table stakes. Something like: “enterprise customers can complete onboarding without a call from support, and we measure this by tracking whether support tickets tagged ‘onboarding’ drop by at least 30% in the 60 days after release.” Now you have a north star that isn’t about the code. Now you can make tradeoffs with clarity - because you know what you’re trading toward.
The engineer who outlasts the next round of cuts is the one who, when the cuts are being discussed, has a list of specific business outcomes attached to their name - and that list exists because they spent their career close enough to the business to understand what their work actually changed.