What a Slovak test engineer taught me about SRE career growth in a post-ZIRP world
This post was inspired by my chance meeting with a Slovak test engineer who had corporates fighting to hire him and sponsor his high-salary migration in a tight job market.
I can’t make up a story like this — and neither can GPT-5 (though it told me to use the em dash in this sentence).
I met a Slovak test engineer recently at a social event. When I go to these meetups, my goal is to unwind — not to talk about tech, or business, or the business of tech.
But within twenty minutes, we’d touched on all of it. He was simply happy to meet socially open people at our weekly pub gathering in my hometown.
And yet it all came out.
He’s a test engineer in the banking sector. I didn’t want to know more, but everyone else at the table did. So I got pulled into the vortex of systemizing his experience through the familiar frameworks and tropes of our industry.
Interestingly, he had no formal qualification in computing. No CS degree, minimal certifications, no fancy title. Yet every time a core-banking integration failed, everyone waited for him to show up.
He’d been seconded from his Slovak post at a multinational into a complex project serving one of Australia’s largest companies — think US$150 billion market cap. What was more interesting than his résumé was his approach to the problem.
He did not understand why everyone was jumping up and down, trying to keep him in country for the long-run. I did…
Projects like this, in the post-ZIRP world, after years of zero-interest rates and cheap capital fueling endless “digital transformations”, now have to justify every line of spend with actual reliability.
The same tightening is visible in Australia’s internal tech sector. During the ZIRP decade, domestic headcount grew on the back of cheap money and “digital-transformation” budgets that rewarded expansion over efficiency.
Now, with the cost of capital normalized, those roles are being quietly unwound through redundancies and restructures. What remains are the engineers who can stabilize systems — like our Slovak friend.
He’s the kind of engineer who has quietly mastered context, not code. Whether at a domain (banking) or a system (multi-service dependencies) level, he seeks beyond the baseline and digs deeper.
Most of us in the industry, especially those shaped by the traditional IT career pipeline, are products of a linear system. We’re trained early in life to think in progressions: clear the exam, earn the certification, reach the next title.
The whole infrastructure rewards throughput and correctness — not exploration.
The Slovak engineer had come up through something very different.
His early training was hands-on, constraint-driven, the kind you find in vocational settings with:
limited tooling
tight budgets
systems that had to keep running because no vendor contract could bail you out
He learned by fixing what broke, not by studying what should work and hoping that it would.
That’s the real divide I saw that night — not East versus West, or degree versus no degree — but theoretical progression versus practical insight.
He’d been forced to see systems for what they really are, and how they behave in reality, not how they’re diagrammed in a Visio document.
Where many engineers measure growth in certifications, he measured it in failure modes understood.
That’s why he looked puzzled when people praised him or tried to negotiate hard to keep him. In his world, competence wasn’t a résumé advantage. It was the minimum requirement for keeping the system alive.
At one point, he squirmed on his hardwood stool as I mentioned the likely negotiations between his seconding firm and the Australian companies trying to secure him permanently.
I expected pride. Instead, he shrugged. He cared more about what he could do with the system and the problems it threw at him. That was the real excitement for him.
So how does he system up?
In every outage call, he wasn’t asking “What failed?”
He was asking, “Why did the system allow this to fail?”
That question alone places him a decade ahead of most engineers in leadership capability.
It’s easy to romanticize stories like this, but a real shift is happening underneath:
The industry is rediscovering that sensemaking of systems beats formal credentials.
He didn’t strategize ways to climb up fast; he dug deep and was rewarded with a faster climb up than any certification could deliver.
He tested through shaky pipelines until they whispered their secrets.
He understood the underlying system’s personality — its hidden assumptions and dependencies built up through years of tech debt. He’s the kind of engineer high-paying Australian banks are quietly fighting to keep long-term.
That encounter reminded me of something we often miss in our own careers, especially in the Indian tech ecosystem, which I’ve become more cognizant of in recent years.
Many engineers are trained to think in levels — L4 to L5, Senior to Staff, Team Lead to Manager. Every promotion signals a “level up in capability.” But does it count in an era when systems literacy is critical in managing incidents?
Reliability work doesn’t reward hierarchy. It rewards systems literacy: the ability to see across components, people, and processes, and to hold that complexity in your head while you’re trying to fix things.
“Leveling up” is about scope and title.
“Systeming up” is about building insight and ownership.
It’s the difference between managing a dashboard and understanding the feedback loop behind it.
When I run workshops with senior engineers, I don’t care how many frameworks they’ve memorized. I care whether they can answer:
“When the alert fires, what happens next in the real world — and why?”
That question separates framework followers from system thinkers.
The best engineers — whether from India, the United States, or central Europe — are no longer measured by tenure, but by how reliably they can stabilize the systems that keep the enterprise — and everyone’s salary — running.
So if you’re planning your growth in this career of reliability engineering, don’t just chase a higher level.
Map the system you operate in and
Find the failure modes no one else has taken the time to understand.
That’s how you truly level up in your SRE career.