Chapter 3: For the Love of Technology

What happens when curiosity meets cutting-edge tech? Gero’s journey through academia and process optimization at HPI birthed a vision. Listen to this chapter to discover how one idea sparked a global movement for business transformation.

www.linkedin.com/in/gerodecker/

Transcript

It all started at the Hasso-Plattner-Institute (HPI) in Potsdam, Germany. As a relatively new academic institution, HPI was focused on excellence in everything they did. I was fascinated by their mission, building a rigorous, resource-rich environment that didn’t just treat students as learners but as contributors to cutting-edge projects. HPI created an atmosphere where you felt empowered, with access to everything you needed to take ambitious ideas and run with them. Like I mentioned earlier, I imagined my future as a lawyer at some point - like a hero straight out of a John Grisham novel, fighting against the bad in the world. Luckily, life has a way of guiding us toward where we’re meant to be.

My father’s friend, who had been with SAP in its early days, encouraged me to consider HPI. On my first day there, I had a long conversation with Professor Wendt, the founding mind behind the institute. His insights offered a new perspective: building sophisticated algorithms wasn’t necessarily the biggest challenge in the software space. The true difficulty, he argued, was how to get hundreds or thousands of engineers to work together effectively, communicating the same understanding of a complex system from different angles, and to make sure the software actually solved the user problem. 

In one of my first lectures there, we explored business processes to better understand how entire organizations function and how software could help to optimize workflow efficiencies. I was super fascinated by this topic, but to be honest I hadn’t at this point started to realize that this could become more than just a field of study. There was something both artistic and highly practical in figuring out ways to improve organizational processes, something that felt meaningful and rewarding.

An avid traveler already, I had always dreamed of visiting Australia. For my master’s thesis, I joined the research team at the Queensland University of Technology (QUT) in Brisbane. My colleagues Marlon Dumas, a professor at QUT, and Alistair Barros, one of the senior researchers of SAP Brisbane, were truly inspiring, and working with people who saw technology as a gateway to bigger possibilities helped me deepen my understanding of software and process management.

It was difficult to come back to Germany. Queensland’s environment was irresistible - perfect beach weather, beautiful landscapes, and a laid-back lifestyle - and the prospect of leaving it all was a tough call. My professor, Mathias Weske, was smart enough to lure me back to Potsdam with a PhD position I couldn’t resist. It offered maximum freedom in my research and an unlimited travel budget for conferences. 

Looking back, the return to Germany was a turning point for me, even if I didn’t realize it at the time. Taking the PhD position would place me at the center of the ecosystem that would eventually lead to the creation of Signavio. In a way, it was the start of something much bigger than I could have ever imagined.

For the first few months back in Potsdam, I enjoyed every minute of it. I was surrounded by brilliant minds, tackling issues no one else had managed to solve. My office mate, Hagen Rother, was a true visionary - a rare type of person whose ideas seemed to belong in a science fiction novel. Hagen would come into the office every day around noon, having worked late into the night, and tell me, “Gero, you won’t believe it but I have seen the future last night.” Some of his revelations were interesting, others were too abstract to understand, but one day, he added, “And this time, I can actually show it to you.” Intrigued, I watched as he simply opened his MacBook to a blank Safari web browser window. 

“Gero,” he said, “in the future, computers will not have a hard drive any more. They will have a screen, a keyboard and they are connected to the Internet. They will not have any applications installed. Everything that you do on the computer will come through the web browser and all data will sit somewhere in the cloud.”

This was 2006, a time when the idea of web-based applications was mostly limited to things like Google search, eBay, and the early days of Facebook. Most professional software still relied on locally installed applications like Microsoft Office. Google Chrome didn’t exist yet and the most cutting edge web browser was Mozilla Firefox in version 1.0. Hagen’s idea seemed radical, almost far-fetched. Yet, the potential was undeniable. We spent hours that day searching the web for any signs of browser-based applications that were beginning to push the envelope. 

There wasn’t much out there, but one application did catch our attention; Writely, a web-based text editor that Google had recently acquired. It was the first what-you-see-is-what-you-get (WYSIWYG) text editor that lived inside the web browser, not as refined as Microsoft Word, but it was revolutionary in its own way. Seeing it in action planted a seed in our minds. If something as fundamental as a text editor could live in a web browser, what else could be brought online?

For Hagen and I, the next question was obvious - what could we build that was more complex, something that could truly test the limits of browser-based technology? Given our backgrounds, a web-based flowcharting tool made perfect sense. Flowcharts have a certain elegance in their simplicity. They’re just boxes and arrows that map out a process, like fulfilling an order or handling a customer service inquiry. It was a field that had always intrigued me, as flowcharts are fundamental to understanding and improving business processes. 

The timing was perfect. HPI had a tradition of end-of-study projects, and a team of bachelor’s students - made up of Willi Tscheschner, Nicolas Peters, Martin Czuchra, and Daniel Polak - to develop the tool. We launched it as an open source project, and like many other open source projects in those days, we felt it needed an animal name. “Oryx.” The name had a certain allure; the oryx is a graceful, fast-moving antelope that thrives in groups. We liked the symbolism, and the name stuck. So if you ever wonder where the Signavio logo came from, this is it: the open source project Oryx.

Nico and Willi each brought unique strengths to our journey, but it was the intersection of their talents and personalities that made their bond truly special. Nico was always a calm, thoughtful presence in the room. 

“I met Willi during a math pre-course in 2004, and it clicked very quickly.” Nico said to me as we reflected on this time. He laughed. “I’m not entirely sure why though.”

Willi was the energetic spark. He loved exploring new technology and pushing the boundaries of what could be done. What they loved was that every challenge was an opportunity to create something innovative and impactful. This balance between them was evident in their shared approach to their bachelor project. 

“It wasn’t the process modeling itself that excited us,” Nico said. “It was the technology - the chance to create something truly new.”

Their collaboration never stopped. Even as their initial advisor lost interest, they stayed dedicated. It was during this time that I first met them. 

“When you took over the project, it became something more,” Nico explained. Our relationship quickly became a strong partnership.

After completing their bachelor’s work, they each spent time abroad - Willi in the U.S. and Nico in India - gaining new perspectives but always staying in touch. When they returned, they eagerly resumed work on their original project. 

When I asked Willi about it he said, “Looking back on all our years, I think our different personalities are why we were so successful. Nico was calm and thoughtful, I was more of the open-minded visionary. But we always respected each other completely.” 

This respect, coupled with their complementary strengths, formed the backbone of what would become Signavio - a culture of trust, collaboration, and the belief that together, they could tackle anything.

As the years passed by and the company grew, that bond remained a core part of our success. Their inseparable partnership set the tone for the culture we built - focused on respect, mutual support, and a shared drive to innovate.

Over the next six months, the student team worked hard on the web-based editor, while I contributed as a sounding board, offering useful tips and encouragement. Hagen and I debated intensely about the direction of the project. He wanted to use a custom modeling language, something unique to his PhD research, while I saw value in adopting an emerging industry standard, called Business Process Modeling Notation (BPMN). I believed open standards were the future and could make our project accessible to a broader audience. Eventually, I managed to convince him, and we structured the system to be adaptable, allowing other notations to be added later. BPMN was just starting to mature, evolving toward a version that would support data interchange in a format that software vendors could universally understand. We even became the first team to implement this standard, and that sense of being on the cutting edge gave us momentum.

When demo day arrived in the spring of 2007, Willi and Nico presented Oryx to a roomful of faculty, students, and guests. I encouraged them to be bold in their presentation, framing the project as part of Hagen’s larger vision of everything moving to the web. They titled it “The Future of Enterprise Computing is Here,” and with the energy of true believers, they explained how applications in the future would all run through a web browser. The response of the audience in the room was good but not enthusiastic, and I assumed this would be the end of our small experiment. I imagined the students would move on, Hagen would go back to his research, and I would return to the daily rhythm of academic life. Then, something unexpected happened.

The next morning, at 10:22am exactly, our server crashed. Typically, open source projects like ours lived on GitHub or similar repositories, where other developers could download the source code and run it locally. But because our tool was web-based, we hosted it on a server so that users could try it out themselves, without installing anything. The server was an old, somewhat underpowered computer that sat under my desk, enough to host a few dozen visitors on a normal day. That morning, though, more than 20,000 people logged on within 20 minutes. Our little server couldn’t handle it and simply folded under the load.

We could not explain where the sudden influx of traffic had come from until we discovered that several blogs and tech news sites had picked up on Nico and Willi’s story about the future of enterprise computing. People seemed to be fascinated by the possibility that complex applications might one day all be web-based, and wanted to check out the prototype for themselves. 

Moments like these are absolutely golden for a geek - seeing people connect with something you built, not just as a product, but as a glimpse into a possible future. This was the motivation we needed to keep moving with our project.

I went to Mathias and made a case for rerouting some of his research funding to support the open source project. Thankfully, he agreed, and with the additional budget, we were able to bring on more students to work on Oryx. Many of them would become integral members of the future Signavio team, including Stefan Krumnow, Philipp Maschke, Sven Wagner-Boysen, Björn Wagner, Robert Gurol, Jan-Felix Schwarz and Philipp Giese. 

Hagen’s interest in the project gradually faded away as the focus shifted from an academic experiment to more practical, user-centered development. We began to realize that this wasn’t just a prototype anymore; people were actually using it in real scenarios, finding value in it despite its limitations. Oryx continued to gain traction in the academic community. Professors and researchers from other universities began using it, contributing extensions and modifications. But it wasn’t all smooth sailing; unsurprising, given that Oryx was still rudimentary in many ways. 

One memorable experience during this early phase was a gentleman that called me one day on my university phone. 

“Are you Gero Decker?”, he asked. “I found your name on the Oryx homepage. I can’t access the system anymore and I urgently need the process maps I have built for a meeting this afternoon.”

I tried to access the system myself, but couldn’t. I figured that, this time, the power cord had fallen out. The server was still standing underneath my desk and I must have kicked it with my foot. I plugged the cable back in and while the server was rebooting, I asked more about this gentleman’s use case. He told me that he was working for a large logistics company that was undergoing a massive transformation project, revisiting the way they operated in many parts of the business. 

I was surprised to hear that someone was actually productively using our software. At the time, our tool had a big sticker at the top of the page which said “This is an academic prototype. Your data might be lost any time.” I asked him whether he had not seen the sticker. He said he did, but the software was just so useful to him that he had ignored the advice. 

“On top of your application, there is a long combination of characters and numbers.” He continued, “If I copy that, paste it into an email and send it to a colleague, that colleague can actually click on it and will see the exact same thing like I am seeing on my screen.” What he was referring to was a plain web link or URL that, of course, showed on every page of our application - because it was web-based.

When I asked why that was so important to him, he explained that it allowed him to very easily involve hundreds of colleagues in the project. Simply being able to share his view with colleagues across the country by copying and sending a link to the diagram was a “magic feature” that solved his biggest challenge: COLLABORATION. This wasn’t something we thought of as revolutionary, but it revealed a huge need for collaborative capabilities in process management tools. I instantly knew this was a lightbulb moment.

Our open source project was beyond exciting, but after two years of working on academic research, I felt a growing sense of disillusionment in my job. The focus on inventing topics, publishing papers, and chasing conference presentations started to feel like an endless cycle. My research involved mapping out process choreographies - business processes that link multiple organizations. It was intellectually stimulating, yet felt disconnected from anything practical or impactful.

It turned into a game for me: How can I churn out a maximum number of publications in the shortest possible time? I knew this would make me a successful researcher and more importantly, it would allow me to travel to present my papers. And there are many conferences where I could get this opportunity. A conference in Hong Kong? Great, I have never been there, let’s submit. In Rome? Fantastic, I love the city. In Hawaii? Hell, yeah!

I optimized my strategy for maximum travel, seeing as much of the world as I could, spending nearly as much time away as I did in my office in Potsdam. At one point, in Sydney, I had a heated debate for three hours with another researcher. It was about which theoretical foundation was most suited to detect non-realizable behavior in synchronous multi-party interaction contracts that get translated into an asynchronous communication protocol. If you don’t understand what this means or why it’s relevant; you are right. I realized I was spending precious time solving imaginary problems that no one outside academia would care about. It was a wake-up call. I wanted to do something relevant, something that could make a true difference.

When I returned to Potsdam, I knew I was ready to move on. The cycle of writing papers, presenting them, and diving back into research had started to feel repetitive, and I found myself craving work with real-world impact. So, I went to Mathias, my advisor, and told him directly - I wanted to wrap up my PhD as soon as possible. At that point, I had published more than enough papers, and in my mind, I had completed what I came to do. But Mathias didn’t see it that way. 

“You can’t submit now. You are not even two years into your PhD,” he replied. “In computer science, a normal PhD takes four years. How will this look if I let someone graduate in half the time? You will have to stay longer until you can submit your thesis.”

I was devastated. I felt stuck, like I was trapped in a system that had its own timelines and requirements, regardless of what I felt I had achieved. Some friends of mine had canceled their PhD because they were just as frustrated as I was. On the other hand, I had come so far that it would be a waste to leave the university without the title “Dr. Decker”.

With all of this in mind, I returned to Mathias and proposed taking an unpaid leave of absence, during which I would explore opportunities outside of academia. If I could come back later with new skills and perspectives, I reasoned, my research might even benefit. He thought about it for a short while and said “That sounds logical, Gero. Fine with me.” 

Hallelujah! This was my ticket to freedom. Finally some fresh air. Let’s get out of here!

With this newfound freedom, I wanted to dive into something difficult, something that would stretch me in ways my research hadn’t. I started by considering two paths that had a reputation for being intense: investment banking at Goldman Sachs and consulting at McKinsey. Both were highly competitive, known for their high standards and steep learning curves. I did not have enough knowledge in banking, so I applied at McKinsey.

I agreed with my professor that I would be gone for the summer and be back to help with the lectures in October, then submitted my application at McKinsey. Fun fact: this is the only job interview I would ever have in my life. 

Justifiably, preparing for the interview process was unlike anything I had done before. As a researcher, I was used to digging into complex problems, but at my own pace, with time to reflect and iterate on my work. This was different; I needed to learn how to communicate my thought process clearly, efficiently, and under time constraints. It was both nerve-wracking and thrilling, and it gave me a new appreciation for the skill of turning ideas into immediate, actionable steps. The experience of preparing for the interviews alone felt like a growth moment, challenging me to think differently and present myself in a new light.

Receiving the offer was remarkable; I felt incredibly lucky to have made it. This was the undertaking I had been craving - a job that would push me hard and offer a complete contrast to my academic life. My research had often felt isolated, with progress measured in conference and journal publications. Here, I was joining a team where the results of our work would be immediate and visible, impacting real clients and businesses.

On day three of the job, I was tasked with designing the emergency call strategy for our client’s new internet protocol (IP)-based telephone infrastructure. My boss gave me the rest of the day to solve this challenge. The question was how to physically locate a person who calls 112 in Germany (the equivalent of calling 911 in the United States) through voice over IP. I had very limited knowledge about voice over IP at the time. McKinsey had helped telco operators in Mexico and the Middle East switch to IP-based infrastructure previously, so I called the colleagues abroad and absorbed all the info I could get. We checked the regulatory requirements around emergency calls in Germany and calculated the risk, the cost and the benefit of the different solution options. Could we embed GPS tracking in every end point device? Could we redesign customer onboarding to limit the physical movement of end points? Or should we simply do nothing and craft a PR campaign for the case when an ambulance arrives at the wrong destination? Our Powerpoint team took my hand scribbled drafts and produced beautiful slides in the corporate design of our client. Eventually, seven hours after starting the task, still day three of the job, I presented the recommended strategy to the senior leadership team of our client. They all nodded and agreed and thanked us for the solid work we had done. 

I loved it: The energy, the speed, the new intellectual challenges. We worked from eight in the morning until eleven in the evening every single day. On Saturdays, I was so exhausted that I slept most of the day. On Sundays, I already counted down the hours before I could get back to the project. I loved the hustle and couldn’t wait to board the plane on Monday morning.

When I returned to HPI for the winter semester, I felt renewed. I left McKinsey having promised my manager to be back once finished with my PhD, and set myself up with a plan to wrap up my thesis within the next six months. 

As I dug deeper into the research on collaboration, I began to see this concept was much more pragmatic than just a buzzword. It was evolving into a central theme for how organizations could work better. I read about crowd-sourced innovation, user-generated content, and the potential of enterprise social networks to empower teams, not just in tech companies but in any field where people shared knowledge and worked together across distances. Gartner had even started writing about “business process analysis for the masses,” predicting a future where these tools would empower employees at every level of an organization. That phrase - "for the masses" - stuck with me. Maybe we hadn’t just created a prototype but something that could drive real change in how people collaborated across organizations.

The idea that Oryx might have real customer value was both humbling and exciting. Until then, we had built it out of curiosity and the thrill of experimentation. Now, we saw it through a different lens: maybe this was something people actually needed. And with this realization came a new sense of responsibility. If Oryx really was more than just a student project, how could we ensure it had a life beyond our time at university? I knew that if we left Oryx as just another open source project, it might not survive. Open source projects can be fragile without committed contributors, and Nico, Willi, and the other HPI students were carrying most of the load. Once we graduated, Oryx, without us, would likely die.

With Nico and Willi enrolled in a lecture on entrepreneurship, we saw a chance to explore the idea of turning Oryx into something more. Could we form a company around it? It wasn’t an obvious choice back then. Berlin was a very different place than it is today, with few tech startups and even fewer resources for new ventures. The startup scene was just beginning to emerge, mostly focused on e-commerce, and many of the startups we saw were heavily influenced by Rocket Internet’s copycat approach. Enterprise software companies like ours were an exception, and I wasn’t sure I wanted to take that path. 

The work I had done at McKinsey had shown me a world of fast-paced problem-solving that I loved, and I was ready to return to that. My McKinsey contract was sitting on my desk, waiting for a start date and my signature. I figured I’d stay long enough to help Nico and Willi establish the company, then step back and return to McKinsey.

But as much as I wanted to return to consulting, I couldn’t ignore the fact that Nico and Willi would need someone to handle the business side. They were talented developers with impressive technical abilities, but they had little interest in managing finance, marketing, or sales. These were areas they would need help with if Oryx were to succeed as a company. I began reaching out to people in my network, looking for someone interested in joining our founding team. Many were impressed by the prototype, but nearly everyone doubted its commercial viability. The general feedback was that free process design tools would soon dominate the market, and it was hard to imagine that anyone would pay for ours.

I reached out to Torben Schreiter, a university friend who had recently started as a presales consultant at a local business process management company. Torben had experience with the market and had a good sense of what users wanted in a process management tool. He knew the sales landscape, and when I shared our idea, he was interested right away. He offered to leave his current job and join us - under one condition. “Gero,” he said. “I think Oryx is not uninteresting at all. It could indeed work in the market. But I will only do this together with you. And don't dare to drop out a few months later and go back to McKinsey. We are in this together.” I had to commit fully to the startup and put aside my McKinsey plans. Torben made that very clear.

This condition brought me to a real crossroads. On the one hand, I was still eager to go back to consulting. On the other, I sensed that this was a rare chance to create something lasting, and Torben’s commitment made me rethink my own. To help me decide, I called my manager at McKinsey, hoping for guidance. 

To my surprise, he encouraged me to take the leap and start the company, sharing that he had always wanted to do something similar but never found the courage. He told me that McKinsey would still be there waiting for me if things didn’t work out.

With his encouragement, I finally made up my mind. For the first time, I let go of my consulting plans and threw myself fully into building this company. The decision was daunting but invigorating. I felt the weight of uncertainty, remembering the journey of my father, knowing we had no guarantees of success, but the excitement of starting something from scratch overshadowed my doubts. I also had the security of people I trusted absolutely, driven by a clear purpose and a shared sense of adventure.

Now, I could fully focus on bringing the new company to life.