The bridge between people, product, AI, and code.
Not a résumé. A philosophy of leadership shaped by seventeen-plus years of shipping software, growing teams, and staying curious.
The first job that almost said no
My first role out of the gate was as a Software Developer at KIT — the Karlsruhe Institute of Technology, one of Germany's largest research institutions — in the heart of southwestern Germany's tech corridor. Early on, a supervisor told me, plainly, that I wasn’t suited for IT. It wasn’t cruel; it was just wrong. But it stuck, the way early judgments do.
I didn’t prove the point by arguing. I proved it by building — project after project, team after team, for more than seventeen years, starting right there at KIT. Looking back, that moment did me a favor: it forced me to define competence on my own terms rather than someone else's, and it's the reason resilience shows up in nearly everything I lead today. I've since sat on the other side of that conversation, evaluating apprentices and junior engineers, and I try hard never to hand anyone the verdict I was handed.
From writing code to owning outcomes
My career didn’t start with a leadership title — it started with a keyboard. I spent years as a developer first: PHP, JavaScript frameworks, TYPO3 sites, the unglamorous work of making things actually run. That hands-on stretch is why I lead the way I do now. I know what a bad requirement costs a sprint. I know what an ambiguous ticket does to a developer's afternoon. So the arc of my career has been a steady move from writing the software to owning what it needs to do and why — from developer, to requirements engineer, to product owner, to the person accountable for whether a team ships the right thing at all.
That's not a rejection of the technical work. It's what makes the leadership credible. I still read the architecture diagrams, still ask the annoying clarifying question in refinement, still know enough to tell when a scope is quietly ballooning. I just spend most of my time now on the layer above the code: what should we build, why, and for whom.
Leadership as service, not hierarchy
Somewhere between my first production incident and my first team of engineers, I settled on a belief that hasn’t moved since: people are an organization’s most valuable asset. Not a line in a values deck — an operating principle. Servant leadership, to me, means my job is to remove obstacles, grow people faster than the org chart requires, and make sure the people closest to the problem have the trust and context to solve it.
In practice that looks like unglamorous things: rewriting a vague requirement before it reaches a developer, sitting in on a stakeholder call so my team doesn't have to decode it secondhand, saying "that's my call, not yours to carry" when a decision goes sideways. Servant leadership isn't about being liked. It's about absorbing the ambiguity so the people building the thing can build it well.
Why the bridge matters
Every organization I’ve worked with eventually hits the same seam: the gap between what the business needs, what the product should be, what AI can now realistically do, and what the engineering team can ship well. Most failure modes live in that gap — not in bad code, but in a requirement nobody questioned, a scope nobody owned, a stakeholder expectation nobody managed.
My work is closing that gap — translating in both directions, writing requirements precise enough that "I thought you meant..." stops happening, setting technical direction that survives contact with reality, and building teams that don’t need a translator once the direction is clear. Requirements engineering and product ownership aren't separate disciplines from leadership, in my experience; they're the mechanism through which leadership actually reaches the code.
“I build the bridge between people, product, AI and code — and walk it first.” Sven Klassen
Curious how this plays out in practice?
See the leadership philosophy in action, or jump straight to the projects it shaped.