A year ago, I joined Körber with the mission of building a platform to support software development, drive standardization and efficiency, and improve developer experience. Twelve months later, the journey has not been what I expected, but that was expected – more details ahead.

Why Körber?

My previous professional adventures were in consulting. I was ready for a change. Consulting teaches you to move fast, adapt quickly, and deliver under pressure. But projects end. You hand over your work, move on to the next client, and rarely see the long-term impact of what you’ve built.

I wanted to return to the long-term thinking that building a product requires. Within my first two months, after understanding “roughly” the current state of the platform, I created a 3-year roadmap. Of course, now that I’m writing this post, I’m also updating and adjusting that same roadmap — that’s the nature of product work.

I joined OneIT, Körber’s central unit that provides IT services across the entire organization. It’s the kind of position where your work touches every team, every product line. That reach was exactly what I was looking for.

A year in, that decision feels right. There’s a different kind of satisfaction in nurturing something over time, watching it grow, and knowing you’ll be there to see where it leads.

Why Platform Engineering?

My background is in DevOps. I’ve spent years designing and building pipelines for delivering software. The deployment pipeline is my favorite place — where culture joins technology, providing an automated path for developers to build and deliver software.

Platform engineering felt like the logical next step. A self-service DevOps at scale, but with a product mindset. Instead of building pipelines for one team or project, you’re building a platform that serves the entire organization. You’re not just shipping features to customers; you’re shaping how every team builds and delivers. The leverage is immense — the right foundations can multiply the impact of dozens of teams. Or as I learned from the Frictionless book: compound impact.

The technology side

Let’s be honest: the technical work is often the straightforward part. Over the year, we pushed GitHub and Copilot adoption and rolled out JFrog Artifactory as the standard tool for artifact management.

I also defined the Tech Landscape framework,  inspired by Thoughtworks’ Tech Radar, to qualify tools and technologies across the organization. The goal was to create visibility, build a shared knowledge base, and establish a path toward standardization.

Beyond the platform work and tooling, I took on a second mission: defining and implementing a governance process for Microsoft Power Platform. This low-code platform enables business teams to digitize and automate their processes through Power Apps and Power Automate. The challenge was bringing structure to how these solutions were developed and supported — ensuring business agility didn’t come at the cost of sustainability or risk.

These were important foundational steps. They brought consistency and clarity across teams.

But they were only the beginning.

The organizational reality

The real challenge started once the tools were in place.

Organizational Complexity

Körber combines disciplinary and functional structures, with teams distributed across geographies. Defining stakeholders in such an environment is non-trivial. Mapping ownership meant navigating a matrix across organizational, functional, and regional dimensions.

Governance and Procurement

Approval and procurement processes reflect the same complexity. They take time. A lot of time. After all, I’m working in an enterprise with enterprise processes. Progress required patience, persistence, and continuous alignment across stakeholders.  Being technically right was never enough.

On the positive side, there is a clear project management process. Not always the best process—but clear enough to disagree, commit, and move forward.

Uneven Team Maturity

The development landscape is highly diverse. Some products involve over 200 developers; others are maintained by teams of five. Technical maturity varies just as widely.

This diversity is both a challenge and an opportunity. A platform that only works for one end of that spectrum will fail.

Voluntary Adoption

Adoption of the platform by development teams is voluntary. Development teams must see real value in the platform to be willing to pay for using it. That changes everything about how you build and communicate.

Roadmaps become value hypotheses. Communication becomes as important as features. Success is measured not by rollout completion, but by sustained usage.

A platform that nobody uses is just infrastructure.

A Culture of Listening

What I really appreciate is the grown-up culture shared across the organization. People know what to do, and they do it — which makes everyone’s life easier and avoids ‘chasing people’ as a sport.

Right from the start, I was introduced to the Think Tank Software community. It was great to see spaces for knowledge sharing already in place. I had the opportunity to attend an in-person OneIT gathering, a Körber investment to bring people together.  As a co-organizer of a DevOps community, I believe internal communities are the best way to share knowledge, so finding this already embedded in Körber’s culture felt like home.

That culture of listening shaped how I approached the platform work. I implemented monthly sessions to share the platform’s evolution and collect feedback from stakeholders. I also started conducting stakeholder interviews — an instrument I use to identify friction points and opportunities. These practices became essential, not just for communication, but for building trust. A platform nobody uses is just infrastructure. Adoption requires listening.

And it was in one of those stakeholder interviews that I had my biggest realization.

The Aha Moment

We were discussing the platform’s role, and I compared it to curling — the platform as the broom, helping sweep the path clear for teams.

The stakeholder corrected me: “The platform isn’t the broom. It’s the ice rink.”

That reframing was an aha moment. The broom is a tool you wield directly in the game. But the ice rink? That’s what makes the game possible in the first place.

That’s what platform engineering is. You’re not playing the game. You’re creating the conditions for others to play their best.

Where I Am Now

A year in, I have a much better view of the mountaintop. The organization is larger and more complex than I initially grasped. The summit is higher than I expected.

But I’ve found my climbing pace.

I’ve learned that progress in platform engineering isn’t always measured in deployments or tools shipped. Sometimes it’s measured in conversations had, alignment built, and trust earned. The work is slower than I imagined, but it compounds.

What’s Next

I’m heading into year two with a clearer vision and a steadier rhythm. There’s still a mountain to climb — standardization to deepen, adoption to consolidate, developer experience to refine. But I’m no longer surprised by the complexity. I’m comfortable with it.

Themes I’m exploring: evolving the platform, deepening stakeholder relationships, and AI in the software development lifecycle.

If you’re considering a platform engineering role, especially in a large organization, here’s my advice: bring a vision and a willingness to learn. The technical challenges are real, but the organizational ones will put you to the test. Not everyone will agree with your vision — that’s fine. Listen to them and learn from them. After all, the platform is for them.