Career · Leadership · Life
Careers rarely follow a straight line. This map connects the experiences, interests and recurring themes that have crossed throughout mine.
Follow a line or start at any station. Interchanges show where different parts of the journey came together; select a station to read its story.
Legend
Each line represents a recurring theme rather than a single job or organizational structure.
Select any station or interchange to open its story. On smaller screens, scroll horizontally to explore the full map.
Where the journey started.
I graduated from Arnold Gymnasium in Neustadt bei Coburg before moving to Erlangen to study Computer Science. Not yet much of a career story—but every metro network needs a first station.
Back to the map ↩The technical foundation underneath everything else.
I studied Computer Science at Friedrich-Alexander University Erlangen-Nürnberg and graduated as Diplom-Informatiker in 2005. The analytical and systems-oriented way of thinking I learned there still influences how I approach technology, organizations and complex problems.
Back to the map ↩An unconventional first lesson in business.
I spent many school holidays working with my family at the carnival and state fair. It taught me early lessons about customers, operations, hard work and reliability—because when the fair opens, things simply have to work.
Back to the map ↩Leadership before I called it leadership.
During university I served as tutor and hall director of my student residence. Looking back, it was an early lesson in community, responsibility, organization and dealing with very different people and competing priorities—long before leadership became part of my job title.
Back to the map ↩Building the infrastructure behind the work.
Early in my career at Elektrobit, I worked on company-wide engineering infrastructure: processes, workflows and tools supporting areas such as issue management, code reviews, continuous integration and project management. It gave me an early appreciation for how much good infrastructure can enable—or hinder—engineering teams.
Back to the map ↩Good processes should make work easier.
I started my career defining and improving company-wide engineering processes and methods. One lesson has stayed with me ever since: compliance matters, but a process only creates value if people understand it, can use it and see why it helps.
Back to the map ↩A recurring thread throughout my career.
Automotive SPICE has accompanied me through very different roles—from defining compliant processes, to applying and improving them in projects, to assessments and organizational quality responsibility. It is a good example of how discipline and pragmatic engineering do not have to be opposites.
Back to the map ↩Knowledge only creates value when it travels.
I maintained and developed Elektrobit's company Wiki, supported teams in structuring and sharing knowledge, organized a Wiki community and facilitated retrospectives. It taught me that knowledge management is much less about storing information than about creating an environment in which people actually share and learn.
Back to the map ↩The start of a much longer Agile journey.
In 2008 I completed my Scrum Master certification with Boris Gloger. What started with Scrum soon became a broader interest in Lean, Kanban, self-organization, feedback loops and the question of how teams can continuously become more effective.
Back to the map ↩Learning became more valuable when shared.
Very early on, I started presenting what we were learning about Wikis, knowledge management, learning organizations and Agile ways of working—inside Elektrobit, at universities and in external communities. Teaching and sharing often forced me to understand the ideas more deeply myself.
Back to the map ↩Are Scrum teams learning teams?
In 2009, together with Kerstin Bücher, I spoke at Scrum Day Munich about the relationship between Scrum and learning organizations. It brought together two themes that fascinated me at the time: Agile teams and how organizations actually learn.
Back to the map ↩Agile was useful outside software, too.
One of my early experiments was introducing Scrum into our central Quality and Knowledge Management team—a non-development organization. Adapting development practices to a support function reinforced a belief I still hold today: the principles travel much further than the individual practices.
Back to the map ↩Helping the team improve the system.
As Scrum and Kanban Master, my role was not simply to facilitate meetings. I helped teams make work visible, remove impediments, identify bottlenecks and continuously improve their way of working—with the aim of making the team increasingly capable of doing this themselves.
Back to the map ↩From iterations to flow.
After using Scrum during feature development, we moved teams toward Kanban for stabilization and issue resolution. That experience strengthened my interest in Lean thinking: understanding flow, limiting unnecessary work and continuously improving the system rather than merely following a methodology.
Back to the map ↩Taking Lean into automotive software.
In 2014 I spoke at Agile Monday Nürnberg about Lean Development in the automotive industry. The interesting challenge was never whether Lean principles were useful, but how to apply them pragmatically in the very real constraints of automotive software development.
Back to the map ↩Sharing the adventure of becoming Agile.
In 2014 I gave a keynote at the BMW Developers Conference titled “The adventure of becoming a truly agile project.” It was an opportunity to share lessons from trying to make Agile work in real, large-scale automotive software projects rather than in an idealized textbook environment.
Back to the map ↩Turning experience into something reusable.
Together with Martin Dusch, I wrote about Lean Software Development for automotive software for heise Developer. Writing about practical experience forces you to separate the underlying principles from the specific circumstances—and makes the learning transferable to others.
Back to the map ↩Agile principles survived the move into leadership.
Moving into project leadership did not mean leaving Agile behind. Transparency, frequent working-software deliveries, customer feedback and adapting the way of working to the situation became important parts of how I led projects and organizations.
Back to the map ↩Scaling is more than making Scrum bigger.
Working with larger organizations taught me that scaling Agile is not about reproducing team-level ceremonies across more people. The real challenge is preserving transparency, feedback, ownership and alignment when many teams, locations and stakeholders have to work together.
Back to the map ↩Good questions can be more powerful than answers.
Over the years, coaching and mentoring have become increasingly important to me—both as someone receiving coaching and as a leader supporting others. I have learned that helping someone find their own answer is often more valuable than simply providing one.
Back to the map ↩Another perspective on organizational agility.
In 2022 I became a Certified SAFe 5 Agilist while involved in a Lean-Agile transformation. It added another perspective on how to coordinate products, teams and planning across a larger organization—without changing my belief that frameworks are tools, not goals.
Back to the map ↩A deliberate move closer to delivery.
In 2009 I moved from central Quality and process work into customer-facing engineering and project roles. That changed the perspective completely: from defining how work should happen to becoming directly responsible for teams, commitments, budgets, releases and customer results.
Back to the map ↩Turning expectations into something buildable.
Working in Requirements and Systems Engineering taught me how important the bridge between customer expectations and engineering really is. Good requirements are not bureaucracy—they create a shared understanding of what needs to be built, why it matters and how we will know that it works.
Back to the map ↩Software with very real consequences.
I led projects around emergency assistance and eCall functionality, from prototypes to production software. It was a particularly tangible reminder that automotive software is not abstract: what we develop can matter when somebody actually needs help on the road.
Back to the map ↩Software that reached millions of vehicles.
A major part of my project career was connected to Ford infotainment systems. I worked in international organizations developing, integrating and releasing software that ultimately reached millions of vehicles around the world.
Back to the map ↩Quality never really left.
Although I moved from Quality into engineering and project leadership in 2009, quality remained part of my daily responsibility: releases, process compliance, assessments, customer expectations and continuous improvement. Looking back, the Quality line was still there—it had simply become part of delivery.
Back to the map ↩Leadership across borders and cultures.
As projects grew, so did their international dimension. Leading distributed organizations meant aligning customers, teams and stakeholders across countries, time zones and cultures while still creating a shared understanding of priorities and commitments.
Back to the map ↩Leadership changes when scale changes.
My largest programs involved more than 200 people distributed across several countries and three continents. At that scale, leadership becomes less about managing individual activities and more about creating structures, transparency and an environment in which teams can succeed.
Back to the map ↩From one market to the world.
I led an international project organization launching and maintaining a global infotainment platform for a US automotive customer. The work combined suppliers, development, integration, validation and releases across Germany and the US, supporting vehicle programs in markets around the world.
Back to the map ↩From one project to a portfolio perspective.
Over time, the challenge broadened from leading individual projects to coordinating several customer activities and commitments in parallel. That meant balancing priorities, capacity, risks and escalation while keeping delivery predictable for customers and the organization.
Back to the map ↩From project responsibility to business responsibility.
In 2018 I became Head of Customer Projects for Ford, leading Project Managers and Software Architects. My responsibility expanded beyond successful project delivery to customer satisfaction, financial planning, capacity, RFQs and the long-term development of the customer business.
Back to the map ↩International work became international life.
In 2018 I moved to Detroit for an expatriate assignment. Living and working close to the customer turned international collaboration from something I managed into something I experienced personally—and became one of the most formative chapters of my career and life.
Back to the map ↩From applying the model to assessing it.
In 2022 I became an intacs-certified Automotive SPICE Provisional Assessor. It added the formal assessment perspective to years of experience defining processes, applying them in projects and working on process improvement.
Back to the map ↩Discipline and agility can reinforce each other.
Agile and Automotive SPICE are sometimes presented as opposites. I don't believe they need to be. In a 2023 guest lecture at FAU, I explored how good engineering discipline, traceability and quality practices can coexist with short feedback loops and adaptive development.
Back to the map ↩Less control does not mean less leadership.
Self-organization does not eliminate leadership—it changes what leadership is for. I believe leaders should provide direction, context and an enabling environment, then trust capable people to solve problems and continuously improve how they work.
Back to the map ↩Organizations grow when their people grow.
Strong organizations need more than roles and structures—they need people who continuously develop their capabilities. Learning and capability development is therefore an important part of EAX: building expertise, sharing knowledge and helping people prepare for what engineering will need next.
Back to the map ↩Still part of how I think.
My responsibilities have moved far beyond individual Agile teams, but the underlying ideas remain relevant: transparency, short feedback loops, continuous improvement and empowered teams. The Agile Chapter keeps that exchange alive across roles and organizational boundaries.
Back to the map ↩From improving projects to improving the system.
In 2021 I became Head of Processes, Methods & Tools. The challenge was no longer only improving individual projects, but building the bridge from process definition to sustainable deployment and practical usage across Elektrobit—while reducing administration that did not create value.
Back to the map ↩Back to where the journey started.
In July 2025 I took over Quality Management while retaining responsibility for Processes, Methods & Tools. Adding independent Quality Management and audits effectively made me Head of Quality for Elektrobit—and unexpectedly brought my career back to the Quality roots where it had started twenty years earlier.
Back to the map ↩An independent view matters.
Independent Quality Management and audits provide an objective perspective beyond the teams doing the work. The goal is not simply to find deviations, but to identify risks, create transparency and make sure our quality system is actually effective in practice.
Back to the map ↩Where many of the lines meet.
Since August 2026 I lead Engineering Advancement & Execution as Senior Director, reporting directly to the CTO. EAX combines line responsibility for key engineering execution roles with shared specialist services—bringing together many of the experiences represented by the different lines on this map.
Back to the map ↩Expertise where the organization needs it.
EAX provides shared specialist capabilities that projects and products can draw on, including Quality Engineering, Cybersecurity Management, Functional Safety, Data Intelligence and Learning. The aim is to make scarce expertise accessible and effective across organizational boundaries.
Back to the map ↩Creating the conditions for delivery.
EAX has line-management responsibility for Project Managers, Scrum Masters, Product Owners, Test Managers and Requirements Engineers. My role is not to execute every project, but to develop the people, capabilities and environment that enable reliable engineering execution across the company.
Back to the map ↩Curiosity travels surprisingly well.
I completed Harvard University's Science & Cooking course, combining two things I enjoy: understanding why things work and experimenting until the result gets better. Apparently, the mindset I apply to engineering processes works reasonably well in the kitchen too.
Back to the map ↩My longest-running improvement project.
I maintain my own cookbook, which has grown to more than 200 recipes. The process is familiar: experiment, learn, adjust and keep the version that works—although the feedback cycle is considerably more enjoyable when dinner is involved.
Back to the map ↩