At Camunda, we build products that help customers automate some of the world’s most complex business processes. That sounds simple. It’s not!
Behind the scenes, our engineers are tackling challenges that span distributed systems, long-running workflows, event-driven architecture, and scale across multiple cloud environments. But what sets them apart isn’t just their technical skill, it’s how they think.
In this special “Meet a Camundi” series, we’re spotlighting the engineers behind the platform. You’ll get a window into the problems they’re solving, how they think about system design and debugging, and the mindsets that make them thrive at Camunda.
If you’re the kind of person who loves peeling back the layers of complex systems, who doesn’t wait to be told what to do, and who gets curious about the why, not just the what, you might belong here too!
Read on and find out!
Christopher Kujawa
What experiences have shaped your career and led you to where you are today?
I joined Camunda at the beginning of 2016, first actively working on Camunda 7 and joining (in 2017) the Zeebe team (which was named differently at this time).
You could say I was part of bootstrapping the Zeebe project, which was at this time still an experiment. We built everything from scratch: consensus, membership protocols, internal state management with our own key-value store (using extensible hashing), append-only logs, and many more.
I was always interested in distributed systems, performance, reliability, and improving our system. I did many refactorings, bug fixes, and deep investigations of the system, which taught me a lot about our system but also in general about architecture and system design.
Starting in 2019, I began introducing Chaos Engineering at Camunda. Running the first GameDays to improve our incident handling, and also the first manual chaos experiments, and later, automated ones.
Furthermore, I was always looking to improve the system related to stability and performance, so I ran regular load tests and investigated the reliability of the system.
All of this has taught me a lot about what matters to build a system that is reliable and observable. A system you can trust and have confidence in.
How did you learn about Camunda, and what motivated you to join the team?
Funny story: I was actually messaged on StackOverflow (yes, this was a thing in 2016) by Robert (the former CRO at Camunda) about whether I was interested in joining Camunda, and that he is real :D. First, I thought, well, this is what a head hunter or AI would write, right? But as I was looking for a job after my master’s, I tried it. Now I’m here almost 10 years later.
What’s a technical challenge you’re currently working on that you wish more engineers had exposure to?
I’m currently working on investing more effort in our approach to reliability testing. This means building the foundation for our load testing and chaos experimenting to make sure that our system works reliably. Besides the foundation, which can cover tools and infrastructure, we need to enable more engineers to run tests and cover more parts of our system.
What have you unlearned in order to be effective at Camunda?
Perfect doesn’t matter; be pragmatic. We don’t need to find the perfect solution or system (such a thing doesn’t exist). There are always trade-offs, and it always depends on the context and use case. Be pragmatic and take the solution or approach that brings the most value, with the least cost.
How do you approach problem-solving when you’re in completely uncharted territory?
Ask yourself what you know about the situation/context, and what you do not know. Then try to approach the unknowns incrementally. How can the knowns maybe help to discover the unknowns?
Try to find resources about this topic, someone who knows more than you about this topic, etc. Ask specific questions, clarify what you already know, and what you would like to understand. At best, summarize what you understand and ask for validation.
In your experience, what separates good engineers from great ones in distributed systems work?
An intrinsic mindset, and an eagerness to learn and understand how the system and dependencies work. Being able to understand complex systems and their interactions (especially in failure scenarios).
What kind of mindset or engineering values do you hope to model for others?
An intrinsic mindset, ambitious to resolve even the hardest challenges, and eager to learn new, unknown topics.
Openness for feedback and improvement (we can always improve and learn more).
Transparency about what you’re doing and learning, always trying to share context. Context always matters, and knowledge sharing is key in our fast-paced world.
What excites you the most about your work?
That every day is different. There is always a new challenge to tackle, new things to learn.
When investigating our system, it feels super rewarding to finally find the culprit and be able to improve it.
Where are you currently based, and how has your experience been working with teammates in a fully remote setup?
I’m based in Berlin, Germany. I have experienced both worlds, full office life and home office.
I love to work in the home office, and I’m able to fully focus on my topics but also to connect with my peers.
We have several team rituals to connect with our mates, like regular coffee chats, and in the past also open Zoom rooms to recreate the Office feeling. People were simply able to join, work, and ask questions more easily ad-hoc, etc.
What is a project or idea you’ve worked on at Camunda that you’re particularly proud of?
I’m proud to drive initiatives like reliability testing or introducing Chaos engineering (with GameDays, or Chaos Days) at Camunda
Product-related I’m proud to have recently led a project to create a new Camunda Exporter, part of our Camunda 8 re-architecture initiative.
What’s one piece of advice you’d share with someone considering an Engineering role at Camunda—especially someone earlier in their career?
My personal mantra is: There are no problems, only challenges, and every challenge is an opportunity to learn.
Personally, this helped me a lot when I was a junior, as I saw everything as a new opportunity to improve myself. Don’t be afraid to take challenges related to unknown topics or uncharted areas; be open. Take the next bug or refactoring and learn how the system works.
Don’t accept the status quo; always improve, may it be processes, systems, or your own skills and mindset.
Can you share something about your personal life that colleagues might not know about you?
When I was a kid, I didn’t plan to become a Software Engineer, I actually wanted to be a Policeman. My A levels were not good enough (I was young and not so interested in school), so I searched for a different study course. I applied to the Applied Science course of study and was first rejected. Somehow, they decided to accept all applications later (with the comment: most of you will anyway not make it), so I was able to start studying Computer Science. Within this study I found the interest in programming and my general ambition in learning. Now I’m here, and happy everything went this way.
Lightning Round
Favorite debugging tool or CLI command?
- JFR, async profiller
- VIM, jq
Blog, book, or podcast you recommend?
- General
- The Pragmatic Programmer Book by Andy Hunt and Dave Thomas
- Modern Software Engineering David Farley
- Software Engineering at Google Hyrum Wright, Titus Winters, and Tom Manshreck
- Java
- Effective Java Joshua Bloch
- Java Performance Scott Oaks
- Java Concurrency in Practice Brian Goetz
- Reliability
- Learning Chaos Engineering by Russ Miles
- Chaos Engineering Casey Rostenthal, Nora Jones
- Site reliability engineering book Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Richard Murphy
- Prometheus up & running Brian Brazil
Tabs or spaces? 😄
- SPACES – please no tabs!
What’s your engineering superpower?
- My ambition. One of my ex-colleages mentioned once that I’m like a terrier dog when debugging/investigating a challenge, not releasing, until I get down to the root of it.
One thing you wish more engineers understood?
- Concurrency, and you build it you ship it (not throwing things over the fence).
Come build with us
The work we do at Camunda isn’t for everyone but if this kind of thinking energizes you, you’ll likely feel right at home.
We’re looking for engineers who think in systems, who get excited by hard problems, and care deeply about building tools that other developers love to use.
Want to work with people like Chris? Explore our open roles here.
