This episode is for a very specific person. You’re a manager inside a fairly large company, and someone, possibly you, has decided you’re adopting Kubernetes. AI is right behind it. Do you restructure the teams first? Hire consultants? Do you need any of this? And every person you ask for a straight answer turns out to be selling something.
I wanted an answer from someone who isn’t. Markus Döpke is a senior solutions architect at AWS in Germany, and his job means he sees more production Kubernetes than most engineers see in a career. The inside of the clusters, the inside of the org charts, and the inside of the postmortems. We’ve worked together, and what stands out to me isn’t the title or the talks. He wants to understand, he wants to help, and he shares what he knows. That’s rarer than it should be.
So I started at day zero. A large enterprise decides it needs Kubernetes, and Markus gets the call. How did they get there?
Back to virtual machines
Markus’s first answer was that Kubernetes is so ubiquitous that there’s no single story. Look long enough and you’ll find a five-person carpenter shop somewhere in a Bavarian village running WordPress on it. But in the engagements where it was justified, the customer always wanted to scale something. A software company moving from perpetual licenses to SaaS. A company entering a new geography that doesn’t want to hire for a follow-the-sun model. A team that needs to experiment faster than its book of standards allows.
Then I asked where the decision usually comes from. Ideally from business goals, he said, with the tech people confirming the fit. But resume-driven development isn’t a cliche someone made up. Delegate the choice entirely to the engineering org, and the probability that you end up with Kubernetes goes up.
He shared a story where it wasn’t justified. A small German software company, talked into Kubernetes by a delivery partner who never looked at the whole picture. After a year the budget ran out, the product team had to take over something they hadn’t asked for, and a year after that management pulled the plug. Back to virtual machines. Markus’s take: the same time and money, spent on doing VM deployments well, would have solved the actual problem.
An organization is not a university
If you’ve rightfully decided on Kubernetes, is the next step a platform team? Markus’s warning is that you shouldn’t take the nerdiest people you have, let them build a platform, and have everyone throw their things on top. That’s unlikely to work.
What he recommends instead comes from Team Topologies, and he summarized the book in about two minutes, better than any AI would. There are four team types, and only one you really need to understand: the stream-aligned team, which creates the value in your organization, full stop. Every other team exists to remove its bottlenecks. The platform team looks at the value chain, finds where the stream-aligned teams aren’t self-sufficient, and builds self-service for that. The enablement team teaches people how to work with it. And the complicated subsystem team owns the legacy API nobody else should have to understand. (Give that one an MCP server, he suggests, and it becomes part of the platform.)
I pushed on the part that worried me. Over time the platform team understands the platform and the product team understands the product, and the gap between them grows. Isn’t that a risk?
“An organization is not a university.”
Some focus, some bounded context, is the price of flow. The product team shouldn’t be as deep in the Kubernetes trenches as the people operating the cluster. But the platform team’s mission is to support them, so they have to sit together, and the product teams have to take some ownership of the interfaces, because the poor people in the platform team are usually underfunded.
That led us to AI. Everyone is worried that AI creates knowledge gaps. I think those gaps existed long before AI in any large organization, in every team that maintained code it never saw written. Markus’s answer was a framing I liked on the spot: be explicit about where you dive deep and what you take for granted. We’ve been booking managed services for years. The question is whether the thing is differentiating for your business, and whether you can learn it when you need to. He also pointed out that these are words that can age very badly. We don’t know what happens in two weeks.
Mental load, not access rights
I asked whether a platform team cancels “you build it, you run it.” Markus answered with a story from his time as CTO of a SaaS startup. The company said it followed that model. When he joined, there was a hard cut between development and operations, and the reason wasn’t access rights. The developers had far too many of those. The reason was that doing anything in production was too much mental load for a vanilla Java developer, so outages were frequent and recovery was slow.
What he did about it was one of the simplest building blocks of their platform, and it involves an oil rig. I’d rather you hear that one from him.
It’s a platform group
My next worry: platform teams become a magnet. “Can you take care of this? You’re the platform team.” Markus’s answer is that the term is misleading. It’s a platform group. The moment you add an identity provider, database optimization, GPU management for fine-tuning, that’s a different part of the organization joining the platform, not three more things dropped on the same four people until they burn out.
And on justifying a team that doesn’t ship features: add a vocal person. A product manager for the platform who does the internal marketing and owns the KPIs, and maybe developer advocates showing how much faster the product teams move because of it. Markus sees the willingness to fund this growing, for one reason. Unless your AI is a chatbot answering questions about the product, you’re building a system that can manipulate state in your systems. Companies that never had a platform initiative are starting one for that.
“We bought Claude Code subscriptions”
That’s the sentence I keep hearing from engineering managers, followed by “so we’ve adopted AI.” I asked Markus whether that’s enough.
“You cannot expect to simply buy a tool, throw it over the fence and everyone in the organization figures out how to use it the right way.”
There are different implementations of an AI development lifecycle, from on-demand help in the IDE to loops that build the product with little human involvement, and you have to decide where you want to go before you decide how to get there. I grouped the companies I see into three buckets: bought a subscription, integrated AI into the IDE, and building a pipeline that works instead of developers. Then I asked whether he knows anyone actually in the third bucket. His answer involved a conference talk we both sat in and a prediction he made about me that turned out to be true.
My own position hasn’t changed. If someone tells you they know exactly how to integrate AI into your SDLC, they’re selling you something. We haven’t had the time as an industry to figure it out.
Markus’s idea for operations is a driving license for AI agents in production. The more you know about the system, the more autonomy the agent gets. If you’re just starting, give it read access and let it teach you. In the end it’s running kubectl and correlating with your observability stack, and if you pay attention, you learn how to approach problems in production. What he thinks of YOLO mode, you can guess.
What you would have told your juniors
We didn’t plan to talk about juniors, but we’d been texting about it. Markus told me about a friend, a project manager at an insurance company, who has stopped hiring juniors because he can prompt the agent himself and check the outcomes. Markus asked him whether that’s how he wants to spend the next five years. What you’re prompting is more or less what you would have told your juniors to do, and you’re still checking the outcomes. Not much changed. The work will change, but there will be junior tasks in the future too.
Markus also has a book recommendation, and it isn’t a technical one. John Gallagher’s question from the previous episode, about the most powerful emotion you feel, got the parent’s answer first and then a second answer that taught Markus to unlearn something. That part turns into the case for why achievements deserve to be celebrated, even the small ones inside a large German enterprise. His question for the next guest involves bees.
🎥 Watch on YouTube · 🎧 Spotify · 🍎 Apple Podcasts
Find Markus on LinkedIn.
