Developer Relations at Camunda - 2018 Recap
The year is nearly done and I will deliver my last conference talk of 2018 tomorrow. It was a really busy but totally exciting year, and 2019 is going to be just as great. This is an ideal time for me to reflect on some amazing achievements, and to invite you to join the team for the year ahead.
I will start by bragging about some numbers, explain what I mean with developer relations and walk you through content I covered this year. And at the very end (when you know how awesome Camunda is) I want you to apply for a developer relations position :-)
Key facts
- We are more than 100 people, have established a great culture , a great product, a strong open source commitment and are recognized as thought leader in workflow and decision automation worldwide. (I’ll go into more details about this below).
- We are part of the ThoughtWorks Technology Radar .
- We recently raised € 25M Series A funding for future growth (as reported on e.g. TechCrunch). We are creating something big!
- We already have more than 200 enterprise customers globally and countless open source users. Companies like Zalando, T-Mobile, Goldman Sachs, Allianz, Sixt, NASA, and many more automate a big variety of business processes with Camunda. Selling insurances (and settling respective claims), trading stocks or handling e-commerce orders are the more common examples. But we’re also seeing workflow automation being applied for biotech lab robots, NASA space missions and the legalized marijuana industry.
In terms of events and developer relations in 2018 alone:
- We held our very own CamundaCon, a two day conference in Berlin with more than 350 attendees from different countries ,
- We gave over 50 talks at conferences or meetups in more than 15 countries,
- We held 19 Camunda Days all over the world.
- We supported more than 15 Camunda User Groups in 9 countries which meet regularly.
These are really impressive numbers. I am especially thrilled by the number of conference talks we did, because they were selected by independent advisory boards which simply liked the content! Which brings me to my next topic:
Developer relations (DevRel) are not marketing!
In Camunda we aim for thought leadership in our domain, which is workflow and decision automation. For example we wrote a book (Real-Life BPMN) back in 2010 which has sold almost 40,000 times worldwide by now. We’ve won a couple of awards. We were swimming against the tide back when we first began, at a time when big players sold BPMS products advocating low-code approaches. But we never believed in this approach. At that time we invested heavily in what we believed in, and still do: a developer-friendly workflow automation approach, provided on open source.
It payed off.
Make meaning — not money.
Guy Kawasaki
This year I concentrated on developer relations and basically worked as developer advocate. As a developer advocate you do many things (a good read is for example this post from Mark Mandel), my personal main focus was:
- Understanding certain tech communities and their problems and vocabulary. This allowed me to map our technology to their space to see if it solves a problem there. Or to understand what we have to adjust in the product to solve their problems. Or to understand how we have to talk about our product to be recognized. Or to realize that our product is not needed in that community at all.
- Generating traction , so that as many people as possible have heard of Camundaand give it a try.
- Being approachable in person (at conferences or online), learning and feeding knowledge back into product development. This opens an additional channel on top of others (like enterprise support contracts or the user forum) with a different focus.
- Understand new market development and future trends to make sure these are discussed within Camunda appropriately.
Very importantly: developer relations is not marketing! Within Camunda developer relations is part of the technical organization, so people report to Daniel, the greatest of all CTOs. It is about tech content. You not only write articles or give talks, you also write code! And you should love writing code.
This content can address different people and we focus on three audiences:
- Pre-workflow-awareness : Many people don’t know that workflow automation can solve a problem for them. Very often people cannot even articulate their problem. They only have a vague pain. Whenever you can catch their interest, you have a great opportunity to explain to them the nature of their problem and sketch concrete solution approaches (potentially using the Camunda stack along that way).
- Post-workflow-awareness : As soon as people realize that they need some kind of workflow automation, they still have a long way to go in understanding the market, evaluating concrete options and getting their feet wet in concrete proof of concepts. DevRels really care about the community. They provide helpful guidance not only to evaluate the product or to get started, but also to point out typical benefits, usage scenarios, pitfalls and risks. They answer any question, write helpful tutorials or code samples. They can also route users to the right channels to get further advice (forum, consulting, sales, …).
- Visibility : Sometimes you just want to be part of the buzz and speak at a certain conference with totally Camunda unrelated topics. This not only gives you more visibility but also improves your reputation to deliver quality content. And the DevRel world is small. Stephan(Mr. Devoxx) recently nailed it pretty well when he talked about “the flying circus of speakers” traveling around the world. That’s so true, so it’s good to be connected.
Content I talked about in 2018
Let’s make this more concrete and look into what I talked about in 2018.
I gave roughly 50 talks this year. The big chunk of that was actually made up of three main presentations I developed over that last 18 months:
Lost in transaction?, 3 common pitfalls of microservice integration and Complex event flows. These talks concentrate on problems around distributed systems and don’t talk about workflow automation upfront, so it is pre-awareness content. Recently I even created a small map to visualize my thoughts and how the talks map to them:
The narrative goes like this: Everybody is doing more and more remote communication , because we highly distribute systems nowadays (e.g. with microservices or serverless). This creates challenges for almost every software developer on the planet. And some challenges require solutions including state handling , e.g. stateful resilience patterns (like stateful retry) or solutions to address consistency in a world without ACID transactions (see e.g. the Saga pattern). In these cases it make sense to at least think about lightweight workflow engines.
To have not only slides, but also concrete source code I developed a comprehensive example application freely available on GitHub.
I also wrote a couple of articles, e.g. 5 Workflow Automation Use Cases You Might Not Have Considered ( TheNewStack ), 3 common pitfalls of microservices integration — and how to avoid them ( InfoWorld ) or Events, Flows and Long-Running Services: A Modern Approach to Workflow Automation ( InfoQ ).
I want to highlight it again: This is not us pushing our product onto the people. It is about helping them to understand their problem and envision solution approaches. And to make concrete examples you have to show code. I personally hate concept/slide only content — as it is often too vague to be true.
Architect always implements
Michael Stal
But no code can be shown without using concrete tools and frameworks. So I use, for example, a lot of Spring, Docker or Hystrix and if it comes to workflow, Camunda or Zeebe. But the important thing is, you could still use any other tool stack and apply the principles.
If our solution does not fit well, I am happy to speak about this too. It is actually quite important to explain boundaries and answer questions frankly about what is in or out of scope.
We are hiring
As you can see, we take developer relations very seriously at Camunda. It is crucial to make Camunda successful. And we still have blank spots on the world map above. So yes, of course we are hiring! And we are building something that truly matters in this world, especially with our Series A funding, which will be used to accelerate growth and traction. So it is a perfect time to join the team. If you need further persuasion, check out some more reasons to join us on our homepage.
I can only encourage you to contact me if you are interested in a DevRel position. Location? Does not matter too much! You might travel the world and rock stages in many countries anyway. Passion and enthusiasm is what we are looking for.
Bernd Ruecker is co-founder and developer advocate of Camunda. I am passionate about developer-friendly workflow automation technology. Follow me on Twitter or check out my homepage. As always, I love getting your feedback. Comment below or send me an email.
Top comments (0)