Get the guide to build your first AI agent directly in your inbox on newsletter signup:
The wrong question after the layoffs news is, “Am I good enough?”
That is the impostor syndrome question. It feels personal, but it is often the least useful way to understand what just happened.
You can be good and still be laid off.
Your work can be solid. But then the company moves the budget, shuts down a product, or decides your entire area no longer fits the strategy.
That does not prove you were an impostor. It proves your career risk was attached to something bigger than your performance.
The better question is not “Am I good enough?” It is “Is my work still attached to something the company wants to fund?”
A layoff-proof career strategy is not about becoming impossible to fire. It’s not about becoming a knowledge silo so people don’t fire you. The people who will fire you aren’t the people working with you directly.
We can’t find a layoff-proof job. But we can build a robust career strategy to avoid layoffs.
In this post, you’ll learn
How to build a layoff-proof career strategy
Why tech layoffs keep happening
How to show measurable software engineering impact
What to do if your engineering team looks exposed
A layoff-proof career strategy is not about becoming irreplaceable
The first mistake is trying to become “irreplaceable.”
Companies do not protect engineers in a perfect ranking from best to worst. They protect funded priorities. Sometimes, the person who knows the old system best is tied to the exact area leadership wants to leave behind.
Your manager's liking of your work matters. Your team being better with you matters. But layoffs often happen above that conversation.
There are 3 scenarios:
Your entire org will be laid off
Your org will be partially laid off
Your org won’t be impacted by layoffs.
Being very useful in your team only matters in the second case. For the others, it’s more about where you work than how you work.
A resilient software engineering career takes care of both the outside (where you work) and the inside (how you work)
Layoff-proof does not mean immune. It means less fragile.
Why tech layoffs keep happening in waves
The lazy explanation is “AI is taking jobs.” It’s all over the news, but it’s not the whole story.
The better model is resource reallocation.
COVID hiring created teams sized for demand that did not last in the same form.
Higher interest rates made executives care more about margins, efficiency, and profitability.
Hardware-heavy companies dealt with demand digestion after pandemic purchases.
Then AI pulled money, attention, and talent toward a new strategic story.
That is why layoffs arrive in waves. They are often not one cause. They are budgeting, moving from yesterday’s plan to tomorrow’s priority.
Remember, it’s not about relocating people, but relocating money. I’m sure many companies would keep having many engineers while investing billions in AI hardware.
But money is a zero-sum game. If you spend it on one item, you can’t spend it on another.
This is why good engineers still get cut. A strong engineer can sit in the wrong org at the wrong time, attached to a product with shrinking executive attention.
Doing important work for your team does not always protect you
You protect yourself if you work in something that makes money. If someone in a budget meeting can clearly explain why your work matters, your position is stronger.
Read more about aligning your work with company priorities instead of just staying busy:
AI layoff headlines have multiple risks in one single story.
If you think every AI layoff means “developers are being replaced,” you feel helpless. Why worry at all if AI will take over the world?
If you think none of it matters because a human with an LLM will still provide more value than the LLM by itself, you can do something.
I see three risks behind the layoffs headlines.
Automation risk: The company says, “This workflow now needs fewer people.”
And that’s true, I’ve automated an entire team’s work before AI. Watch for specific tasks being changed by AI and be the one who automates them. This way, you are not the one automated away, but the one who is providing value in the AI era for the company.
Headcount compression: The company says, “We can do more without adding headcount.”
You can watch for hiring slowing while the scope grows. In my team, we have doubled our services while having the same people. That’s also a way of headcount compression without having any layoffs. Your response is to show you can be the engineer who stays and handles 2x the load that you handled before.
Narrative risk: The company says, “AI transformation requires restructuring.”
I always watch for broad AI language (weasel words) without workflow detail. A lot of executives sell the AI promise without understanding AI at all. You should follow the money and see why something else became a priority over paying human workers.
The practical response depends on which risk you see.
The key is to prove yourself and prove your team so you’re not in the team that gets cut. And be judicious about your org’s health. Your leaders will tell you everything is great until you’re at the edge of the cliff. If you work at a public company, find the real numbers, find the memos from the leaders of the wider org.
Companies are changing what they evaluate faster than people re-skilling themselves.
Work closer to revenue, risk, or strategic priorities
If I wanted to reduce layoff exposure, I would first look at the budget map.
Which projects are newly funded? Which ones get executive reviews? Which incidents make leadership nervous?
I’ve worked in multiple orgs in projects that had executive attention. It’s never funny. Those people will create a lot of pressure on everyone around you, your closer managers will be pushy, and they will never accept your initila plan but try to compress it in half the time.
But during a reallocation cycle, that proximity matters.
This does not mean chasing a flashy AI project. Most of the time, the flashy project is just an experiment to see how far you can reach, but when it’s time to relocate resources, those experiments are killed. So focus on the boring project that is tied to a money-making machine. A boring migration in the payments system can be more protected than the flashy AI initiatives.
You can surely find a list of initiatives in your org. Once you have it, remove 20% of the initiatives, the 20% that seem less important
If your project is one that you’d remove, don’t panic. But stop treating the work as automatically safe. Try to finish it fast to move into something more valuable, or be selfish and look for moving into those higher-value areas.
Become visibly useful with AI, not just interested in AI
“Learn AI” is too vague to be career advice.
There are two useful paths. Go deep into AI systems, or become unusually effective at applying AI inside your current domain. The second path is the one that matters, it’s more practical for most software engineers (unless you’re doing research on AI, which is the minority of people reading this newsletter)
Your goal is to become the engineer who uses AI to write better docs, test risky changes, review AI-generated code, prototype faster, and debug faster, all without lowering standards.
I do not care if someone “played with agents” for a weekend. I care if they can show engineering standards applied to AI so that AI helps them in doing real engineering work.
AI has an adoption cost. The first parts of the learning curve feels bad because AI makes mistakes. It gives plausible answers. It writes code that works on the happy path and fails where the system is messy.
The strongest engineers have gone past those phases and started using AI instead of blindly delegating.
A useful next step is this breakdown of how to turn AI from a random code generator into a reliable teammate:
I have caught myself assuming good work explains itself. It does not.
Nobody is looking at you. You have to put your work in front of them.
And you can’t wait until a leader asks, “Which work matters most?” They won’t be asking you, they will be making the decision and later communicating it
You need proof before you think you need it.
A brag document should not read like a task log. “Implemented service X” is weak. It must link that action to business goals and to evaluation criteria for your role, showing you’re are a top performer
.
Many people got obsessed with the tokens leaderboards, to the point that companies removed them (see this article about Amazon removing it). The point wasn’t that you waste tokens. It’s about finding how to apply AI to your work to make it better
This also helps outside the company. In an interview, you’d apply the same linking between your actions and the business results and role guidelines. Your work is already done, but the perception of how valuable it is would be different depending on how you tell the story.
Do not wait for someone else to translate your engineering work into business evidence.
Read more about tracking achievements in a way that makes your impact easier to explain:
Conclusion: Your job can be cut, but your career can be designed
I do not like career advice that pretends you can outwork every market cycle.
It’s like selling an investment that always beats the market.
Sometimes you can do excellent work and still get caught in a company decision that was never really about you. That is not comforting, but it is clarifying.
Don’t wait for the layoff memo to find out whether your work still looks important.
You cannot make your job layoff-proof. You can make your career harder to break.
If you found value in this post:
❤️ Click the heart to help others find it.
✉️ Subscribe to get the next one in your inbox.
💬 Leave a comment with your biggest takeaway
Today’s article will allow you to do your work faster with AI, moving from phase 1 to phase 2. I’m building this system below for paid subscribers. Thanks for your continued support!
If you want to go deeper on building AI agents to help on your work, read this next:
A reasonable action from companies during layoff is that even if they let go an entire team, they should move the effective ones to another team for better resource allocation. But clearly that’s not how they usually do. Laying off an entire team is easier than spending time choosing who to let go.
A reasonable action from companies during layoff is that even if they let go an entire team, they should move the effective ones to another team for better resource allocation. But clearly that’s not how they usually do. Laying off an entire team is easier than spending time choosing who to let go.
it’s really not our fault if we are laid off!