The tech job market has changed. So has the definition of an engineer a company really wants to keep.
There’s a fairly simple way to understand how much the tech job market has changed.
Talk to someone who has been watching it long enough.
While working on this article, we spoke with an HR Director we know - someone with 15+ years of experience across IT and technology businesses.
Over the years, she has been involved in thousands of hires, from junior roles to senior technical experts and executives. But recruitment is only part of the picture. Her experience spans performance management, compensation, team building, restructuring, retention, terminations, and the countless HR and operational processes that rarely make headlines but often determine how strong a business actually is on the inside.
We asked her what she’s seeing in the technical talent market right now.
“I have never received this many messages from strong senior technical professionals asking me to help them find a job. Never.”
Not juniors. Not people who finished a bootcamp last month. Senior Engineers. DevOps Engineers. Technical Leads. People with serious experience.
A few years ago, companies were chasing them. Today, some of them are messaging HR leaders on LinkedIn: “If you hear of anything, let me know.”
The world has shifted.
And it’s not just one HR Director’s anecdotal experience.
After the massive tech hiring boom, the market went through several years of layoffs and slower hiring. In 2025, Indeed reported that even senior and management tech job postings in the US remained well below their 2022 peak, while employers were increasingly raising experience requirements.
In 2026, software development hiring finally started showing signs of recovery. But there’s an interesting detail.
71% of the growth in software development job postings between May 2025 and May 2026 came from senior roles.
So this isn’t a story about engineers suddenly becoming unnecessary. It’s more interesting than that.
Companies are still willing to pay for strong technical talent. They’re just becoming much more careful about what, exactly, they’re paying for.
And that changes the game.
Being a good engineer used to be enough
Let’s exaggerate a little.
You’re a Senior DevOps Engineer.
The infrastructure works. Deployments happen. The pager doesn’t scream every night. AWS isn’t on fire. At least not literally.
You deliver your work, support developers, resolve incidents, and know several terrifying things about production that are probably best left undocumented.
You’re good at your job. A year passes. Performance review time.
I delivered.
My feedback is good.
Inflation was X%.
I think it’s time to revisit my compensation.
Reasonable. And not that long ago, that was often enough to start the conversation.
Today, there’s another question increasingly appearing on the other side of the table:
“What did the business actually get from your work this year?”
That’s a less comfortable question. Especially because “Well… the infrastructure works.” is a perfectly valid technical answer.
It’s just not a particularly informative financial one.
Doing good work and creating measurable value aren’t exactly the same thing
Engineering culture has traditionally measured seniority through technical complexity.
What systems can you build? What scale can you handle? How complex an incident can you untangle? How quickly can you find the problem everyone else has been staring at for six hours?
None of that is going away.
But another dimension of seniority is becoming increasingly important:
Do you understand which technical decisions cost the business money?
Not just how much RAM a service consumes. How much the company pays for that RAM.
Not just whether an architecture can scale. Whether the business should be paying for that scale in the first place.
Not only: “How do we fix this?”
But occasionally: “Why the hell are we paying for this at all?”
The new seniority isn’t only about solving harder technical problems.
It’s about understanding which technical problems show up in the company’s numbers.
Meet two Senior DevOps Engineers
Same level. Comparable compensation. Both reliable. Both technically strong.
Engineer #1 receives tasks and executes them well. Ticket appears. Ticket gets picked up. Ticket gets closed. Infrastructure works. Everyone’s happy.
Engineer #2 does all of that too. But one day, they notice something else.
Dozens of dev and test environments keep running at night. And on Saturday. And Sunday. And for a surprising number of hours when their main purpose appears to be making AWS money.
They could drop a message in Slack: Guys, looks like we’re wasting some money here. And move on.
Instead, they dig deeper. They look at usage. They identify idle hours. They calculate the cost. They estimate the savings opportunity.
And then they go to the CTO. Not with: “I found a cool tool.”
But with:
This infrastructure currently costs us €X per year.
Roughly €Y of that appears to be spent during hours when nobody is using it.
Here’s how we can automate it.
Here’s the cost.
Here are the risks.
Here’s the potential ROI
A few months later, the company is saving money. Actual money.
Not story points. Not closed Jira tickets. Not an impressive dashboard. Money.
Then that engineer finds another optimization opportunity. And another.
Now imagine a less pleasant quarter. The owner says: “We need to cut engineering costs by 15%.”
The CTO has two Senior DevOps Engineers. One is a good engineer. The other is a good engineer who found ways to save the company tens of thousands of euros over the past year - and keeps finding more.
Suddenly, the conversation looks a little different.
Nobody is truly unfireable
No list of career hacks can guarantee anyone a job.
You can be an exceptional engineer and still get laid off. A company can shut down a product. Move a team. Automate a function. Run out of money. Get acquired. Change strategy. Things happen.
But there is a huge difference between being irreplaceable and being expensive to lose.
The first is mostly a myth. The second is absolutely achievable.
Start thinking like more than an engineer
We’re not suggesting that every DevOps Engineer should open Excel tomorrow morning and declare themselves CFO. Please don’t.
We’re suggesting something simpler. Every once in a while, look at technology through the eyes of the person paying for it.
Where are we losing money?
What are we paying for that nobody is using?
What could be automated?
Where has technical debt become financial debt?
What could we make cheaper without hurting reliability?
What keeps consuming engineering time?
What are we doing manually over and over again?
Where could a technical decision improve margin, speed, or revenue?
And, most importantly: Can I prove it with numbers?
That’s where a different kind of seniority begins.
Engineering is getting closer to the P&L
This isn’t just a nice theory.
The State of FinOps 2026 report draws on 1,192 respondents from organizations representing more than $83 billion in annual cloud spend.
The direction is clear. FinOps is moving beyond simply explaining where the money went. It is increasingly involved in deciding where technology money should go in the first place.
The conversation is no longer just about managing cloud cost. It’s about managing the business value of technology.
McKinsey, analyzing more than $3 billion in cloud spend, identified another 10–20% in potential savings across the organizations studied.
Think about that. 10–20%.
For a company spending €1 million on cloud infrastructure, that could represent €100,000–€200,000.
And some of that money may currently be sitting there at 3 a.m., quietly powering infrastructure nobody is using.
This changes the CTO’s job too
Now let’s look at the other side of the table.
Not that long ago, this was a reasonably survivable management model: If it works, don’t touch it.
Production is alive. Releases are shipping. The team looks busy. Headcount is roughly on plan. Great.
Today, owners, CEOs and CFOs increasingly want better answers.
Why does engineering cost this much? What got faster this year? What got cheaper? What did we automate? Where are the bottlenecks? Why did the cloud bill grow 30% if revenue grew 12%? What exactly do we get if we hire three more engineers?
And one of the hardest questions: What business value does the next €1 invested in technology create?
“Everyone seems very busy” is becoming a less convincing answer.
The “it works, don’t touch it” era is ending
For systems. And for teams.
More and more engineering activity can be connected to measurable data: cloud spend, resource utilization, idle time, deployment frequency, lead time, incident rates, MTTR, automation, infrastructure cost.
The economic impact of technical decisions is becoming easier to see.
Which means one of the most important responsibilities of a modern CTO isn’t simply building a strong engineering organization. It’s understanding the weight of that organization.
What does this function create for the business? What does this investment change? Where does a person create leverage? Where does a team save money? Where does it help make money? Where does it maintain something business-critical - which can be enormously valuable too, provided that value can be explained?
This does not mean turning every developer into a row in a spreadsheet.
It means engineering can no longer operate indefinitely as a black box:
€3 million goes in.
Technology comes out.
Please don’t ask follow-up questions.
That era is ending.
For engineers, visibility of value is becoming part of career resilience.
For CTOs, the ability to see and explain that value is becoming part of the job.
Fine. What can you actually do tomorrow morning?
Start with something boring. The bill.
Look at your non-production infrastructure: Dev. Test. QA. Staging. Demo environments.
How much does it cost? Now look at when people actually use it.
Say an environment is needed ten hours a day, five days a week. A week has 168 hours. You’re using it for 50.
Which leaves one fairly obvious question: What happens during the other 118?
If the answer is: “Well… it keeps running.” we have bad news and good news.
The bad news: you’re paying for it.
The good news: you’re paying for it.
Because now you know where to look for money.
And no, you don’t even have to calculate all of this yourself
At this point, we could give a Senior DevOps Engineer another project.
Export the usage data. Analyze the last month. Identify idle hours. Map them to instance types and regions. Calculate the cost. Rank the worst offenders. Build a business case. Make a presentation. Then try to steal half an hour from the CTO’s calendar.
Sounds fantastic. Especially for someone who clearly has nothing else to do.
So we already did the first part for you.
Idle Audit is free.
Connect AWS or Google Cloud in read-only mode, and Idle Audit analyzes the previous 30 days of usage data already collected by your cloud provider.
It installs nothing. Stops nothing. Changes nothing. And it doesn’t require a credit card.
What you get is much more useful than: “I have a feeling we’re wasting money somewhere.”
You can see how many idle hours were detected, their estimated cost, which specific instances created the most waste, their type and region, and a weekly hourly map showing when the waste actually happens.
So your first conversation with the CTO doesn’t have to begin with: “I think we might be able to save some money.”
It can begin with: “Here’s our own data. Take a look.”
That’s a very different conversation
The Audit finds the waste. Idlefy keeps it from coming back.
If the Audit shows there isn’t a meaningful opportunity, great. You spent a few minutes and got your answer. You do not need to buy Idlefy just because we built it.
But if the numbers are interesting, that’s where the second part begins.
Idlefy changes the default state of development infrastructure: stopped becomes the default.
Need a machine? An engineer starts it through Slack, Telegram, or the web for however long they need it.
Need more time? Extend the lease. Finished early? Release it. Forgot? When the lease expires, the machine stops automatically.
Not because some algorithm decided: “Hmm. Sergey hasn’t moved his mouse for a while. Shut down production.”
No. The engineer decides how long the resource is needed.
Idlefy simply makes sure “I’ll remember to shut it down later” is no longer part of your cloud cost strategy.
But the savings are only half the story
Remember where we started? Creating value matters. Being able to show that value matters too.
Once Idlefy is running, the story doesn’t end with: Money saved. Job done.
You retain visibility into infrastructure usage and an audit trail of who started resources, when, and for how long.
And, crucially, the result of the optimization becomes visible.
Not: “I think our cloud bill is lower now.” Data.
Idlefy already has a published real-world example:
17 servers.
141 days.
1,048 rentals.
$42,983 saved.
82% cost reduction.
Now imagine that number somewhere other than our website.
Imagine it in your next performance review.
$42,983.
With a small line underneath: Initiative proposed and implemented by me.
That conversation hits differently.
And you won’t be the only one using those numbers
Because the same conversation happens at every level of the organization.
The DevOps Engineer explains value to the Head of Engineering. The Head of Engineering explains the function’s efficiency to the CTO. The CTO explains technology spend to the CEO, CFO, or owner.
And at every step, nice words become less useful. People want data.
So one engineer’s initiative can solve several problems at once.
It identifies inefficient spend. It reduces it. It gives leadership better visibility into infrastructure usage. And it makes the result measurable.
At that point, the engineer has done much more than introduce another tool.
They found the waste; brought the evidence; proposed a solution; helped implement it; and made the outcome visible to the business.
Those are the people who become expensive to lose.
Steal 15 minutes from your CTO
Actually, don’t even start with a demo.
Start with the free Idle Audit.
Look at your own data.
Nothing meaningful to optimize? Great. We’ll survive.
But if there is, now you have a reason to walk into your CTO’s office.
Not: Hey, some SaaS company wants 15 minutes of our time.
But:
I looked at our non-production infrastructure.
Here’s what happens outside working hours.
Here are the instances generating the largest idle costs.
Here’s roughly what that’s costing us.
There’s a way to automate this.
Give me 15 minutes and I’ll show you.
Now book the demo.
We don’t need to convince your CTO that Idlefy looks cool. We just need to look at the math together.
If the math doesn’t work, don’t buy it. Seriously.
But if it does, you’ve just done something far more interesting than finding another DevOps tool.
You found money the company didn’t realize it was losing.
Do something valuable. Then make sure people can see the value.
We like to believe good work speaks for itself.
Unfortunately, good work is terrible at speaking for itself.
Especially when there are two layers of management, five dashboards, and a quarterly P&L between the engineer doing the work and the person making budget decisions.
So one of the most useful habits a technical specialist can develop today is this:
Don’t just create value. Make the value visible.
For one company, that might mean cloud optimization. For another, automation. Architecture. Developer productivity. Prevented downtime. Faster time to market. Or a technical initiative that directly helps the company generate more revenue.
Idlefy is only one concrete example. The principle is much bigger.
Find it. Measure it. Do it. Then learn how to explain what changed.
Maybe that’s the new career insurance
Not certification.
Not another technology in your LinkedIn headline.
Not even closing more tickets.
Maybe it’s the habit of asking: “Where can my technical expertise change the numbers of this business?”
Because a good engineer solves technical problems.
A strong senior understands which problems are actually worth solving.
And the kind of technical specialist who becomes very expensive to lose understands one more thing:
How solving a technical problem shows up in the numbers of the business.
Nobody is truly unfireable.
But you can become very expensive to lose.
And sometimes it starts with one perfectly reasonable engineering question:
“Why the hell are we paying for this at 3 a.m.?”
Top comments (0)