↓ Skip to main content

AI Is the Excuse. The Exit Strategy Is the Question.

·1982 words·10 mins
Ronny Roethof
Author
Ronny Roethof
A security-minded sysadmin who fights corporate BS with open source weapons and sarcasm
Table of Contents

I still remember running SUSE Linux 6.2 on my own PC. This was long before SUSE became the enterprise Linux company we know today, before Kubernetes, cloud-native architectures and the apparently endless need to put AI in front of everything.

Back then, I was hosting Eggdrop IRC bots. For those who remember IRC, Eggdrop was a popular bot that could manage channels, respond to commands and perform all sorts of useful, and occasionally completely pointless, tasks.

Those little bots were also my first steps into scripting and automation.

If I wanted a bot to do something it couldn’t do out of the box, I had to figure out how to make it happen. That meant experimenting with Tcl scripts, reading documentation, breaking things, fixing them and occasionally spending an entire evening trying to understand why something that worked perfectly five minutes earlier had suddenly stopped working.

There was no AI assistant to explain the error message. No Stack Overflow either, at least not in those early days. You had documentation, mailing lists, IRC channels and whatever knowledge you could gather from other people who were just as curious as you were.

And somehow, we managed.

Looking back, those Eggdrop bots taught me more than I realised at the time. They introduced me to scripting, automation, troubleshooting and the idea that software wasn’t something you simply had to accept as delivered. You could modify it, extend it and make it do things its original developers had never considered.

That was part of the beauty of Linux and open source.

SUSE was one of the distributions that made that possible for me. It wasn’t about enterprise subscriptions, service-level agreements or quarterly financial results. It was about having a Linux system on your own computer and discovering what you could do with it.

Those were good times.

So when I read that SUSE is reportedly cutting roughly 10% of its workforce, with artificial intelligence being cited as part of the reason, it caught my attention.

Not because I believe companies should never reorganise. Not because I think AI is useless. Quite the opposite.

But because there is something rather ironic about a company whose software helped people like me discover automation now presenting automation as a reason to employ fewer people.

Apparently, AI Is the New Restructuring Strategy
#

According to recent reporting, SUSE is reducing its workforce by approximately 10%, affecting around 190 employees. CEO Dirk-Peter van Leeuwen has reportedly pointed to AI and automation as factors behind the changes.

At the same time, SUSE’s owner, private equity firm EQT, has reportedly been exploring a potential sale of the company, with a valuation around $6 billion being discussed.

Now, these two developments aren’t necessarily connected. Companies restructure all the time, and AI genuinely is changing how software organisations operate. It would be irresponsible to claim that the layoffs are simply an attempt to make SUSE more attractive to potential buyers without evidence.

But it would be equally naive to ignore the financial context.

Private equity firms generally don’t acquire companies because they have developed an emotional attachment to the Linux kernel. They invest with the expectation of generating a return, and eventually that usually involves selling the investment.

There’s nothing particularly mysterious about that. It’s how the business model works.

The interesting question is what happens when the financial lifecycle of an investment starts influencing the long-term development of a technology company.

Especially one whose customers depend on stability, continuity and technical expertise.

And that brings us back to AI.

Over the past few years, we’ve seen an increasing number of companies announce layoffs while simultaneously talking about AI-driven transformation, operational efficiency and new ways of working.

Sometimes those explanations may be entirely legitimate. AI can eliminate repetitive tasks, accelerate development and reduce the amount of manual work required to maintain certain processes.

But when an organisation announces workforce reductions and presents AI as a major factor, I think it’s reasonable to ask what actually changed.

Which tasks have been automated? Which processes no longer require human intervention? What measurable productivity improvements justify reducing the workforce?

Or has AI simply become a more fashionable way of announcing another cost-cutting exercise?

Automation Was Supposed to Help Us Build More
#

I’ve spent a considerable part of my career working with Linux, infrastructure, automation and security. I use automation because doing the same thing manually fifty times is usually a terrible idea.

If I can deploy servers consistently with Ansible instead of configuring each one by hand, that’s an improvement. If I can automate security checks, configuration validation or routine maintenance, even better.

And yes, I use AI too.

It’s useful for analysing problems, generating initial code, reviewing configurations and speeding up repetitive work. Sometimes it saves a remarkable amount of time. Sometimes it confidently produces complete nonsense, which is why understanding what you’re doing remains rather important.

The goal of automation, at least from my perspective, has always been to spend less time on repetitive work and more time solving interesting problems.

Not to eliminate everyone who understands the systems being automated.

That’s the part of the current AI discussion that bothers me.

If a team of engineers becomes 20% more productive because of better tools, why does the conversation so often immediately turn to reducing headcount?

Why not use that additional capacity to improve software quality, eliminate technical debt, strengthen security, improve documentation or develop new functionality?

Anyone who has worked with enterprise infrastructure knows there is rarely a shortage of useful work waiting to be done.

There’s always another outdated component, another fragile integration, another manual process that should have been automated years ago or another piece of infrastructure that everyone is afraid to touch because nobody fully understands why it was configured that way.

Greater productivity doesn’t automatically mean fewer people are needed.

It can also mean the same people finally have time to do the work that has been postponed for years.

Enterprise Linux Is More Than a Subscription
#

There’s another aspect to this story that deserves attention.

SUSE isn’t just another software company selling an application that customers can replace next month.

Enterprise Linux is part of the foundation on which organisations run critical infrastructure. Customers don’t pay simply because they want access to Linux packages. Much of that software is already available through open-source projects.

They pay for tested distributions, security maintenance, predictable release cycles, support, compatibility and confidence that somebody will still understand their environment several years from now.

That confidence depends heavily on people.

Experienced engineers know things that aren’t necessarily written down. They understand historical design decisions, obscure compatibility problems, strange customer environments and the reasons certain components behave differently from what the documentation suggests.

Some of that knowledge can be documented. Some can be automated. AI can certainly help retrieve and analyse it.

But pretending that an AI model automatically replaces years of accumulated engineering experience is a dangerous oversimplification.

Especially when production systems start behaving in ways nobody expected.

An AI assistant might generate a perfectly reasonable configuration. It might even explain why that configuration should work.

But when the configuration brings down a critical production environment at three in the morning, someone still needs to understand what happened, determine the consequences and take responsibility for fixing it.

That someone is usually an engineer.

And if you’ve spent years reducing the number of experienced engineers because your spreadsheets suggested they were becoming less necessary, you may eventually discover that the remaining people are extremely productive right up until something goes seriously wrong.

Then suddenly, experience becomes expensive again.

The Private Equity Question
#

One of the more interesting comments I saw in the discussion about SUSE came from Gerald Pfeifer, who pointed out that SUSE belongs to EQT VIII, an investment fund with a defined lifecycle.

His observation was straightforward: a potential sale shouldn’t be particularly surprising.

But he raised a much more interesting question.

If AI is making an organisation more efficient, why not invest those efficiencies into growth and innovation?

That’s precisely the question I would like to see answered.

Of course, a company may have perfectly legitimate reasons to reduce its workforce. Market conditions change. Products evolve. Some activities become less relevant, and others require different skills.

No organisation is obligated to maintain the same staffing levels indefinitely.

But there’s a fundamental difference between restructuring because the business genuinely requires different capabilities and reducing costs because a future transaction might benefit from a more attractive financial picture.

We don’t know which considerations played the largest role in SUSE’s decisions.

What we do know is that enterprise Linux customers generally think in years, sometimes decades, while investment funds operate according to their own financial timelines.

Those interests can coexist. But they aren’t automatically identical.

A customer running critical infrastructure wants long-term predictability. An investor eventually wants a return.

The difficult decisions happen when those priorities start pulling in different directions.

And if AI becomes the convenient explanation for those decisions, customers and employees deserve a little more detail than a generic statement about transformation.

The People Behind the Technology
#

Perhaps I’m looking at this through slightly nostalgic eyes.

After all, I remember a time when SUSE Linux came in a box, Linux distributions were something you experimented with on your own hardware, and getting an IRC bot to behave properly could keep you entertained for an entire weekend.

But nostalgia isn’t really the point.

Linux has changed enormously since those days, and mostly for the better. The tooling is more sophisticated, hardware support is better, automation is everywhere and running serious infrastructure on Linux has become completely normal.

I wouldn’t trade modern automation for manually maintaining dozens of servers with handwritten configuration notes.

And I certainly wouldn’t want to go back to the days when every problem meant spending hours searching through mailing-list archives.

Progress is a good thing.

What hasn’t changed is that progress depends on people who understand technology, question assumptions and keep experimenting.

People who write scripts because something annoys them. People who investigate problems because they want to know how things work. People who improve systems because they can see a better way of doing things.

That’s how many of us got started.

My Eggdrop bots didn’t replace anyone. They helped me learn how to automate things. That curiosity eventually became part of my professional life.

And I suspect plenty of the engineers working on enterprise Linux today have similar stories, even if their first experiments involved something other than IRC.

AI is another tool in that long history of automation. A powerful one, certainly, but still a tool.

It doesn’t decide how a company should value its engineers. It doesn’t determine whether productivity gains should be invested in innovation or converted into lower operating costs.

Those are management decisions.

So when a company announces that AI is transforming its operations and that hundreds of people are no longer needed, I don’t automatically assume the technology made those positions redundant.

I want to understand the business decision behind it.

And in SUSE’s case, with a potential change of ownership being discussed, that question becomes even more relevant.

Maybe AI really has made certain roles unnecessary. Maybe the company needs to adapt its organisation. Maybe the timing of the potential sale is entirely coincidental.

All of those possibilities deserve consideration.

But let’s not pretend that artificial intelligence independently walked into a boardroom and decided to lay off 190 people.

AI didn’t make that decision. Management did.

And if the technology really is making engineers more productive, perhaps the most interesting question isn’t how many people a company can afford to lose.

It’s what those people could have built if the company had decided to keep them.


Inspired by a discussion from It’s FOSS on LinkedIn about SUSE’s reported workforce reductions, AI and its potential sale by EQT.

Related

The Office Is Not a Productivity Metric

·1831 words·9 mins
After years of working remotely, corporate harmonisation is bringing mandatory office attendance back. But sitting in an office has never been a measure of productivity.

You Can't Pay the Mortgage with a Football Table

·1689 words·8 mins
A football table, unlimited holidays and free Friday drinks won’t compensate for a poor salary. What really matters when experienced IT professionals consider changing jobs?