About this blog

In this blog, I will share my thoughts and learnings around software engineering, technical leadership, remote company culture and other related topics.

I will share what I have seen working and what I have seen failing in the past. All articles are deeply influenced (speak “biased”) by my experiences and my opinion on certain topics. Furthermore, just because something worked for me in the past, it neither means it will work for you nor is it guaranteed to work for me in the future.

Thus, for me, it is always important to understand the context, in which certain solutions are applied, and therefore I will try to share as much as context as possible to make it easier for you to understand my approaches or the approaches of BRYTER, the company, I am currently working for.

Some context (Q4/2021)

Currently, I am working at BRYTER since roughly 1.5 years. BRYTER is a hyper-growth startup in the no-code service automation space. And of course, we are hiring.
When I started with BRYTER, we were roughly 50-60 people, now we are over 200 and growing fast. We are remote-first from the beginning and thus had no problems growing during the pandemic at all.

BRYTER initially started in Germany and quickly began hiring across Europe, the United States and other countries that somehow work timezone-wise.

Compared to my previous workplaces (see more below), this is a unique and exciting environment to work in.

  • Diversity is super-high at BRYTER, we have people from all kinds of backgrounds.
  • People spend a lot of effort on creating an outstanding culture.
  • Folks are extremely motivated and enjoy their work.
  • We are growing fast and the culture, as well as structures, are constantly evolving.
  • We have money and can think big.

Some words about my personal history:

How it began

I started to develop software, when I was 10 years old. With 12, I started my first company doing web development, web design, web hosting, IT support and a bit of everything, mainly for small companies and individuals.

Seeing the growing complexity of the software that I was building, I felt the urge to learn more about how to build good software. Thus, I did my bachelor and master studies in computer science with focus on software systems architecture. I finished my masters degree in 2015.

The first job

Thereafter, I started as a Software Engineer and Architect at Dräger, a family-run company building medical devices and safety devices since 1889. Today, the company has roughly 15,000 employees and several subsidiaries. Also, because of the domain and the history, numerous processes and grown structures.

Back at the time, when I was working for Dräger, the company was growing more and more into software development as the demands of customers today are hardly to be satisfied in hardware only. Thus, we were hiring a lot of new software developers but also training older colleagues about software craft.

Aside of my work as developer and architect in one team that was building stationary gas detection systems, I was driving the adoption of Git and the acceptance of continuous integration and build automation. Furthermore, I was giving several trainings and mentorings about software testing, design patterns, continuous integration and version control, just to name a few areas.

Going remote

In 2018, I left Dräger to start the first remote team at Payone, a german payment service provider. Besides of building the team together with my team lead and doing interviews, my team was responsible for the fraud prevention system and for slowly refactoring this concern out of the monolithic backend service (PHP, Java) into a self-contained service (Java, Kotlin).

Furthermore, I helped to streamline the deployment process for several services and lead to an increase in deployments from once per month maximum to at least on deployment per week.


Beginning of 2020, just when the pandemic started, I decided to join BRYTER, as I was intrigued by the remote-first culture and the great people who were working there already. Also, the no-code space is a fascinating field to work in because we are solving similar challenges that developers are facing (i.e., maintainability, testing, product variations, deployments, …) but for non-tech people.

I started in the Case Management Unit, where our first task was to build embedded databases as a no-code feature into the platform. Quickly, I took on the technical leadership role in that unit. Starting the tech lead community at BRYTER with several other colleagues, was our way to improve the technical synchronisation between units that are working mostly independently. In this community, we were mostly looking at alignment issues between units at that time:

  • Where do we have accidental dependencies between units, that might slow them down?
  • Where do we see topics that fall through the cracks between units and thus do not get the attention that they should get?
  • Which units might lack a certain skillset to take on their area of responsibility fully?

During our weekly sessions, it became clear, that we were lacking a unit to take care of platform concerns and developer experience topics.

Platform concerns comprise building and maintaining components that are used by multiple units such as blob storage and email services or frameworks that enable units to use release toggles easily. Developer experience topics contain things like continuous integration and deployment pipelines, reducing build and test times, and providing tools and frameworks that make the lives of developers easier.

I started this unit as the tech and product lead of that unit with seven other colleagues beginning of Q2/2021.

That’s it!

And that’s it for now. That is the short version of the background and perspective, from which I am writing. I hope you find it interesting and helpful. Feel free to reach to via LinkedIn or Twitter.

Disclaimer: All thoughts and opinions in this blog are my own. ;-)

This blog post is based on my own opinion and experience. It is inspired by what worked for me and my team in our context. I recognize, that your context is different.
The “Just Sharing” Principle

Level-up your engineering and developer productivity!

With unblocked.engineering I am helping teams and companies to achieve better results in less time and optimize their structures, processes, tools and cultures for the goals they want to achieve.

As a starter, I am offering free coaching sessions, if you are unsure, if this is for you.

comments powered by Disqus