Kilian Niemegeerts

The through-line

Almost everything Kilian Niemegeerts says circles back to one idea: the job is to protect the customer's freedom to change their mind. Freedom to switch provider, continent or partner; freedom from a tool that was somebody else's preference; freedom from a platform layer nobody fully understands any more. Sovereignty, in his reading, is not a geography question but exactly this: "Soevereiniteit is voor mij vrijheid van keuze en beslissing" [4]. The technical expression of that conviction is agnosticism, containers and open standards; the commercial expression is the deliberately awkward line that "Hoe sneller een klant bij ons weg kan, hoe beter" [2].

Running alongside it, and increasingly in front of it, is the human half of the same argument. He frames DevOps not as a set of systems but as a communication and cultural problem between developers, operations, security and business [14][15], and he is candid that he had to change personally before he could lead a team at all: at thirty he was convinced he never would, because he was too demanding and nothing would ever be good enough [6].

On sovereignty as freedom of choice

He refuses the framing of sovereignty as a witch hunt against the hyperscalers, and he does not accept that it has to be an either/or story [4]. What he wants instead is that companies sharpen three questions for themselves: which risks they are willing to take, where the use cases sit in which sovereignty is the top priority, and how much they are willing to invest themselves in building a sovereign platform [4]. He is unimpressed by reassurance from vendors on this point. The kill switch may "niet echt bestaan" according to Microsoft, but a customer's own calculation of what firing the EU bazooka would cost came to more than one and a half million in extra cloud costs, and that, he notes drily, can kill you a different way [4].

The bigger blind spot he keeps hitting is the automatic equation of sovereignty with "alles in Europa" [8]. A Belgian product company with international ambitions came to him wanting American sovereignty, because its first big American prospect wanted control over its own data, in its own country, under its own rules [8]. The same trap works in both directions: one customer insisting it must absolutely not be an American cloud puts you in front of the same question as a customer for whom sovereignty means it has to run in America [1]. If you have put all your eggs in a European basket, that request is just as expensive as the reverse. Building the platform layer sovereignly, on open source and open standards, is what lets you place a customer on an American or a European cloud without rebuilding the foundation, which is as much a growth argument as a compliance one [8].

On staying agnostic

The defence against unknowable future decisions is architectural. Mergers are his example: last quarter there were 143 tech deals in the Benelux, and in a merger it is not always the best stack that wins, usually just the biggest or whoever pays the most, which makes the real question how easily you can move [1]. You cannot predict that, so his answer is always the same: work as agnostically as possible. Running on containers, Kubernetes and a Postgres makes that switch far simpler than sitting deep inside one provider's services [1]. The same reasoning shows up as a cost argument, since not being locked to one provider or one continent also keeps costs under control [8].

On the customer's right to leave

He tells the story of someone who spent four months working out how his own environment had ever been set up, purely so it could be moved [2]. In a managed service the environment is taken over by his team, which makes them precisely the sort of party capable of creating that situation, and he wants no customer ever saying it about them [2]. The safeguard is in small things: when they set up GitOps and IaC at a customer, it lives in the customer's repos, on the customer's account, so that if access is revoked tomorrow, nothing stops [2]. "Een klant moet altijd weg kunnen. Ook bij ons" [2], with the honest rider that of course he would rather keep them close.

On price versus the layer above it

When Hetzner raised its prices and was still much cheaper than a hyperscaler, the reflex he saw was to lay price lists side by side and calculate where it is cheapest, which he considers far too narrow a picture [9]. With a hyperscaler you are not only paying for infrastructure; a whole managed layer is thrown in, and that convenience is what you are paying for, which for many use cases is perfectly fine [9]. With European alternatives you usually pay a lot less, but what you mostly buy is the infrastructure, and the layer above it you largely build yourself. That demands expertise you have to build up or hire in, and that cost is the one half forgotten in the comparison [9]. His practical verdict is that it still tends to come out cheaper anyway, but the comparison itself has to be honest [9].

On simplicity and inherited complexity

Talk to a good CTO and the motto is always keep it simple, yet the complexity is rarely anybody's deliberate choice [7]. A tool here because it was the fastest option at the time, an exception there because a customer asked for it, and before you know it there is an environment nobody has full grip on any more [7]. He is deliberately generous about how that happens: every layer was a defensible choice at the moment it was made, even if together they now slow performance and get in the way of troubleshooting [7]. His team is comfortable in complex environments but always tries to bring the simplicity back, because a simple environment deploys more smoothly, usually runs more stably, and lets you find your way immediately when something breaks [7]. For anyone who can no longer see the wood for the trees in their platform layer, the offer is to rubber duck it together [7]. The related open question he puts on the table is whether an internal developer portal is the secret sauce of platform engineering [13].

On not being a team of sysadmins

FlowFactor deliberately did not celebrate SysAdmin Day, because this is not a team of sysadmins [3]. A sysadmin keeps a system upright, which is a clear and very important job, but it is too small a box for work that has to look wider than one system, since the problems of a development team do not respect that boundary [3]. A CTO put the point to him sharply: "Het aantal keren dat de infrastructuur de échte oorzaak is van wat een gebruiker voelt, is klein" [3]. What that CTO did not want was a party that washes its hands of the problem the moment it stops being an infra problem, and Niemegeerts agrees entirely. The ambition he states is to be the partner that takes everything between your code and production off your hands: keeping infrastructure up is part of it, getting features into production faster is part of it, and when something breaks they go into your logs and your code with you [3].

On why product CTOs outgrow their own infrastructure

One of the CTOs they take work off the hands of announced "IK HAAT ANSIBLE", and he is not an exception [11]. Niemegeerts keeps meeting product CTOs for whom infrastructure still sits on their own plate, sometimes set up together with a couple of very good interns, which he is careful not to disparage since his own internship team has excellent people and that arrangement genuinely works [11]. It stops working when the company grows, the number of developers keeps climbing and end users still have to stay happy [11]. What managed services add there is broad platform expertise as an extension of the team, knowledge built by setting up and running environments and pipelines in many different technologies across many different customers, which is not something you get in a single engineer [11].

On how technical decisions get made

He wants his engineers to disagree. When two of them arrive with different solutions, they have to convince each other with arguments about why solution x is best for this particular customer [5]. The one argument he pushes back on every time is "ik ken die technologie het beste, dus het is logisch dat we dat nemen", which he does not accept as valid [5]. Convince your colleagues first, and then you can be confident the solution was chosen on the basis of the customer's situation rather than your own [5].

The same discipline governs what gets proposed to customers. Too often the favourite tool of whoever installs it wins instead of the customer's reality [10]. Terraform is his team's usual go-to for Infrastructure as Code, but at a prospect with a single cloud engineer who asked for extra help and capacity to connect their environment safely and scalably to a partner's, they stayed with the customer's CDK [10]. The instinct to automate was right, but the customer does not use Terraform, and ramming in a new tool when someone has literally asked you for extra capacity only adds complexity and cost, cost that may not be immediately visible on an invoice but is there all the same [10].

On DevOps as a communication problem

He treats DevOps as being fundamentally about improving communication and collaboration between teams in software development, particularly between developers and infrastructure people, rather than about the technical systems themselves [14]. The aim is to strip out unnecessary procedures and rigid constraints and replace them with open communication in which teams actually listen to each other's needs, so developers keep the creative freedom to explore new technologies while infrastructure teams understand what developers require without imposing overly restrictive frameworks [14]. At FlowFactor the approach is the same: DevOps as primarily a cultural and communication challenge, with developers, operations, security and business aligned around shared KPIs and goals through extensive dialogue and interviews [15]. It is also his explanation for why digital transformation fails without a human focus [15].

On growing into leadership

At thirty he was certain he would never lead a team, because he was too demanding and it would never be good enough [6]. Telling someone "dat script trekt op niets, doe het opnieuw" cost him no thought at all about how it landed; from a technical angle it simply was not good, and for him the matter was closed [6]. He still likes the direct approach, but now he thinks hard about how it lands with his team, and that is the difference between being able to lead FlowFactor today and not being able to fifteen years ago [6]. He is clear he is not the only technical person who runs into this. For many CTOs in scale-ups it is the defining challenge: you are an excellent engineer, and the bigger the company gets, the further you drift from technology [6].

On governance for AI agents

Moderating a panel on AI in development, he found the audience asking the sharpest questions, and the point that came out strongest was that AI agents need governance too [12]. That applies especially to tools like OpenClaw, which are very powerful and where a lot can also go wrong [12]. He points to Red Hat's experiment of giving away free OpenClaw instances on OpenShift in their sandbox with one purpose, to try to break it so everyone can learn from the result, and he has already set his own team loose on it [12]. Setting up guardrails for your own AI experiment, whether on OpenShift or on a landing zone in any cloud, is work he is happy to help with [12].

Takeaways

• Treat sovereignty as freedom of choice and decision, then answer three concrete questions: which risks you accept, which use cases genuinely make it a top priority, and how much you will invest in building a sovereign platform yourself [4].
• Do not equate sovereignty with Europe. An American customer may define it as their data staying in America under their own rules, and an all-European foundation makes that request as expensive as the reverse [8][1].
• Build on containers, Kubernetes and Postgres rather than deep in one provider's services, because mergers, acquisitions and customer demands force switches you cannot see coming [1].
• Put GitOps and Infrastructure as Code in the customer's own repos on the customer's own account, so that revoking your partner's access stops nothing [2].
• When comparing a hyperscaler with a cheaper European provider, price the managed layer you will have to build and staff yourself; that expertise cost is the one everybody forgets [9].
• Reject "I know this technology best" as a reason to choose it, and stay on the customer's existing tooling, such as their CDK instead of your preferred Terraform, when they have asked for capacity and not for a new tool [5][10].
• Infrastructure is rarely the real cause of what a user feels, so a platform partner that stops at the infra boundary is the wrong partner [3].
• AI agents need governance and guardrails as much as any other powerful tool, and deliberately trying to break them in a sandbox is a legitimate way to learn where they fail [12].