About Me

Following Curiosity Instead of Job Titles

People sometimes ask me how I eventually became a DevOps Engineer. I usually just smile because the answer is actually very simple: I never planned to become a DevOps Engineer.

If you only look at my LinkedIn profile, the journey seems fairly logical. It starts with Data Science and Machine Learning, then moves into Business Intelligence, Data Engineering, and finally DevOps. Looking back today, it almost seems as if I had a career plan from the very beginning.

The reality, however, is completely different.

Most of the important decisions in my career started with a question. Whenever I came across something I didn't truly understand, I wanted to dig a little deeper. The more I learned, the more I realized that behind every answer there was always another, even more interesting question waiting to be explored.

Looking back now, I don't think job titles can really tell the story of my career. The questions can.

It All Started with a University Project

The first question appeared during the second semester of my master's program.

One of the foundation courses was Business Intelligence, taught by a professor of Business Informatics. The main assignment was almost the size of a bachelor's thesis. Each group of four students had to work with real business data, clean and transform it, design a data model, build dashboards in Qlik Sense, define meaningful KPIs, give a thirty-minute presentation, write a report of more than forty pages, and finally pass the final examination.

The project was meant to be completed by a team of four.

I did it alone. Not because I wanted to, but simply because no group accepted me.

At the time, I just thought I had been a little unlucky. Looking back many years later, I now realize that this was probably one of the biggest turning points in my career.

Working alone meant I couldn't just be responsible for one part of the project like everyone else. I had to learn the entire Business Intelligence lifecycle by myself, from processing data and designing data models to building dashboards, defining KPIs, understanding the business, and presenting the final results. There was nobody I could ask, "Who is working on this part?" and nobody I could rely on whenever I didn't understand a concept. The only option was to figure it out myself.

By the end of the semester, I achieved the highest score in every assessment, completed the course with a final grade of 1.1, and became one of the top-performing students in the class.

What mattered far more than the grades, however, was something I had never expected. I discovered that I genuinely enjoyed working with data.

For the first time, I realized that data was much more than numbers stored in a database. Behind those numbers was the way an organization operates, the reasons why problems happen, and the foundation for making better decisions.

That project convinced me to choose Business Intelligence as one of my specializations during the final semester of my master's program. At that time, I had no idea that this decision would eventually lead me down a path completely different from anything I had imagined.

A Door into Data Science

Choosing Business Intelligence as one of my specializations unexpectedly opened another door that I had never thought about before.

Around the same time, I met the professor who would later become the first mentor to guide me into the field of Data Science. Unlike the professor who taught Business Intelligence, he was a professor of Statistics and Mathematics with a strong background in analytical methods.

Under his guidance, I began studying Data Mining, Machine Learning, and Statistics much more seriously. I wasn't doing it because the curriculum required it. I simply wanted to understand how these methods actually worked. Outside university, I spent countless hours teaching myself Python, reading books, taking online courses, exploring Kaggle, and experimenting with all kinds of datasets. The more I learned, the more convinced I became that this was the field I wanted to pursue.

Not long afterwards, I had the opportunity to work as his research assistant. When it came time to write my master's thesis, he also became my thesis supervisor.

Interestingly, just before I officially started my thesis, I received an internship offer from REWE Digital, which was still called REWE Systems at the time, as a Data Science Intern.

It was almost exactly the opportunity I had been hoping for.

Instead of finishing my thesis first and then entering industry like many students, I started both at almost the same time. During the day, I worked full-time as a Data Science Intern. In the evenings and on weekends, I continued researching and writing my master's thesis under my professor's supervision.

Looking back, it was probably one of the busiest periods of my life. It was also one of the periods in which I grew the most.

At work, I was exposed to real business problems, real data, and constraints that textbooks rarely talk about. Then I would return to my thesis and look at those same problems from a more academic perspective, analyzing them more carefully and asking even more questions. The two environments seemed very different, yet they complemented each other naturally.

My master's thesis focused on a challenging Machine Learning problem and was later awarded the Lorenz-Weegen Prize for the best master's thesis of the year.

When I completed my master's thesis, my professor encouraged me to continue in academia and pursue a PhD. It was an opportunity I truly appreciated, and I spent quite a long time thinking about it. In the end, I decided not to stay at the university, not because I had lost my passion for research, but because I wanted to step into industry and see how everything I had learned would be applied in real-world systems, where data is never perfect, requirements constantly change, and every technical decision has a direct impact on the business.

Business Intelligence Taught Me How to See Systems

If you only look at the job title of a BI Analyst, it is easy to assume that the work is mostly about building reports or dashboards. In reality, it was much broader than that.

Some days I was building dashboards and reports. On other days, I was involved in developing internal applications, learning about ETL, working on requirement engineering, automating reporting processes, or developing Machine Learning models for marketing campaigns. The work was incredibly diverse, and because of that, I had the opportunity to see many different aspects of how a system works.

The longer I worked in Business Intelligence, the more I realized that dashboards were never the most interesting part. Behind every dashboard was a much larger system. Data had to be collected from different sources, pass through pipelines, be processed, validated, stored in a data warehouse, and only then transformed into the numbers people eventually saw on the screen. Whenever something went wrong, the problem was almost never the chart itself.

What I really wanted to understand was everything behind it:

• Why was the data missing?
• Where had the pipeline failed?
• Why did different systems store the same information in completely different ways?
• Was there a manual process that could have been automated instead?

Without even noticing it, I found myself spending more and more time trying to understand the systems behind the data products rather than the data products themselves.

Looking back, I think Business Intelligence taught me much more than how to analyze data. It taught me how to see systems.

Then Infrastructure Became the Next Question

After a while, another question began to emerge.

Good software cannot run reliably if the infrastructure behind it is unreliable.

A beautifully designed pipeline loses much of its value if deployments constantly fail. An application may be well written, but if every developer works in a different environment, testing and debugging quickly become difficult. The more I observed, the more I realized that many of the problems I encountered every day were no longer Business Intelligence problems. They were problems related to infrastructure, development environments, and automation.

Nobody told me I needed to learn Linux.

There was no project that required me to learn Docker or CI/CD.

I simply wanted to understand what existed underneath the applications I had been building.

Interestingly, I only started learning Linux seriously after leaving my first Machine Learning job. Instead of spending all my time looking for the next position, the very first thing I did the following day was set up my own Linux environment so I could continue learning. At the time, I still wasn't thinking about becoming a DevOps Engineer. I only knew that there were many things I didn't yet understand, and Linux was one of them.

Looking back now, I realize that moving into DevOps was never a sudden career change. It was simply the next step in the same journey. First, I became curious about data. Then I became curious about the systems that produced the data. Eventually, I became curious about the infrastructure that allowed those systems to run reliably.

A Common Thread Across the Journey

It was only a few years ago that I began to notice a common thread running through all these different stages of my journey.

At first, I thought I was passionate about data. Later, I believed Business Intelligence was what truly interested me. Then I spent years learning about infrastructure, Linux, automation, and DevOps. Over time, I realized that none of those things were the real destination.

What has always fascinated me was never a particular technology. It was systems.

Whether I was working with a data warehouse, a Machine Learning pipeline, an internal business application, or an infrastructure platform, I found myself asking the same questions:

• Why was this system designed this way?
• Which parts were creating unnecessary complexity?
• Could knowledge be reused instead of being repeated in different places?
• If I had the chance to design this system from scratch, could it be simpler while still being more powerful?

I never deliberately went looking for answers to those questions. They simply appeared after every project, every job, and every time I learned something new.

I think that was also the reason why I gradually became interested in Domain-Driven Design, Knowledge Engineering, and software architecture. These fields don't answer every question, but they helped me look at systems from a higher level of abstraction. Instead of focusing primarily on technologies or frameworks, I became much more interested in understanding the problem itself, how knowledge is organized, and how a system can continue evolving over many years without becoming unnecessarily complex.

The Journey Continues

If someone asked me today what I am pursuing, I still wouldn't answer with a job title.

What fascinates me today is no longer just data or infrastructure, but the way knowledge can be organized, connected, and reused. I find myself spending more and more time learning about Knowledge Engineering, Domain-Driven Design, and wondering whether the same principles that have helped us build better software systems could also be applied to education and learning.

That is not a finished project yet. It feels more like a direction than a destination. Perhaps, in a few years, it will become a platform. Perhaps it will become a book, a community, or something that I cannot even imagine today.

And I'm perfectly fine with that.

When I look back at the journey that began with a Business Intelligence project at university and eventually led me here, I realize that none of the major turning points in my career were planned. Almost every new chapter started with a small question, and that question eventually opened the door to something completely new.

Perhaps that is the most important lesson I have learned over the years:

Don't spend too much time worrying about who you will become five or ten years from now. Stay curious long enough to follow a question wherever it leads.

You never know where it might take you.