Software engineering secrets: Celonis tech leaders share advice for managing and motivating developer teams

They built a data streaming platform that can ingest information on millions of process instances. They are creating enterprise apps with consumer scale and making corporate software that's as easy-to-use as a ride hailing app.

Overcoming technical hurdles requires not only passionate and highly-skilled developers, designers, product managers and the like, but also leaders with the knowledge and experience to build, manage and motivate their teams.

“Your initial instinct sometimes as a manager is to try to control things, be very hands on, and micromanage a little bit, because you feel all of this pressure, you want to do well as a manager,” said Dustin Jackson, SVP of Engineering at Celonis. “And it's actually the worst thing that you can possibly do.”

I had a chance to speak with Jackson and Celonis Engineering leaders Ari Wilson and Brian Williams during a trip to the Celonis Los Angeles office, located in Silicon Beach.

https://delivery-p141552-e1488202.adobeaemcloud.com/adobe/assets/urn:aaid:aem:cef4c636-61f5-4d78-9eff-0af1fbe74500/as/xX53Jcuos7ZANLopGm5QLJ.jpg
https://videos.celonis.com/watch/xX53Jcuos7ZANLopGm5QLJ

Dustin Jackson is Senior Vice President of Engineering at Celonis. He has degrees in computer science from Stanford University and more than 20 years experience in software development and engineering leadership. Brian Williams is Engineering Director at Celonis, is a graduate of MIT and has been a software engineer and manager for nearly two decades. Ari Wilson has multiple degrees from Vanderbilt University and is Engineering Director at Celonis. He has over 15 years experience as a programmer and engineering manager.

The trio walked me through some of the technical challenges the Celonis Engineering team is working on, how they approach hiring, what they look for in the perfect engineering candidate, how they keep their teams motivated and how they help their teams make the "best" engineering decisions.

The following is an extended transcript of our interview edited for readability.

Reinventing enterprise software from the ground up

Bill Detwiler: Before we talk about the how of building and managing teams to tackle tough technical challenges, let's talk about the what. What are some of those tough challenges that Celonis devs and engineers are working on right now?

Dustin Jackson: The problem that we're really focused on right now is basically reinventing the product that we're building from the ground up. Celonis has built an incredibly powerful set of tools that allows companies to detect problems and inefficiencies in their processes, but it requires a fairly high level of technical knowledge and expertise in order to use them. And so what the team is doing is trying to build a product that will actually meet customers, where they are and speak their language. And without a really high technical barrier to entry, give them the insights they're looking for to find places where they can improve the way their business works.

Ari Wilson: I would just add onto what Dustin is saying there, and I think this is a problem that only Celonis can solve. With our many years of expertise on what customers are doing with their data, understanding that data, being able to map that data to concepts that make sense to the business user, and sort of be able to answer their questions. That's really the technical challenge that we face underneath building an excellent product for users, like Dustin said.

Brian Williams: I mean, I think every day we struggle with that balance of how much of the power do we expose in the UI? But that's more controls, more options, more decisions users have to make. Or how do we simplify things? How do we make it really point click, really try to anticipate what users need, and make it more automatic. And there's a real tension between those two directions. And we're always balancing the engineering and the product decisions around, here's all this power, but how do we harness it and make it something users really find enjoyable and productive to sit down at their computer and use?

Celonis Excellence in Engineering

• Celonis engineering and product teams build enterprise software that’s powerful and easy-to-use
• API Automation: How Make and Celonis engineering teams are building consumer-ready apps at enterprise scale
• Celonis software engineer shares secrets of building enterprise apps with consumer scale
• Challenges in data engineering: Secrets on building a real-time streaming platform from Celonis’s head of streaming data and CEO of lenses.io

Hiring the perfect engineer: Essential skills and qualities

Bill Detwiler: It's always about balancing that ease of use with still having the ability to do some pretty powerful things, right? So let's talk about the how, here, let's shift gears. What are some of the qualities that you look for in engineering candidates? Because you're, again, building a team from scratch to tackle these really big challenges. So Dustin, what are some of those qualities you look for both technical and maybe non-technical?

Dustin Jackson: I usually start more on the non-technical side to be honest. I think, you can assume that someone has the engineering chops, but what is often a little more rare and hard to find is someone who also has the interest in the product side, and understanding how customers want to use our product and what their needs are, and what we do, that just is incredibly critical. Our team works hand in hand with product, in order to define the future strategy. And so we're always looking for people who can, yes, solve the really hard technical problem, but also can go deep into understanding why customers are there in the first place, and help brainstorm and come up with those big ideas that are going to really change the game in the years to come.

Brian Williams: I mean, I think kind of echoing a bit of what Dustin said there, the challenges we face are making, especially on the user platform team, we're making products for users. And one of the things I'll say is, it's one thing to build an API for a backend system for another backend system to call, but you can define that interface and you control both sides. But when you build a product for a user, the user is the API. And everyone is different and everyone sees a set of components on a screen and wants to do something different with them. So how do you build something for the most complicated API of all? Which is the people that we build these things for. And if you really like that challenge and you see the value in it, you're going to do well.

Bill Detwiler: Ari, what would you add? How do you balance the technical and the non-technical skills?

Ari Wilson: Well, I'm going to slightly disagree with Dustin, because we do actually need some technical skills here.

Dustin Jackson: I didn't say we didn't. I just said, it's all a rich tapestry.

Ari Wilson: We hire engineers and other folks skilled people in their profession, product managers, UX, et cetera. But, yeah, sort of widely applicable skills, things like Angular, React, Typescript, Postgres, sort of common technologies that underlie a lot of applications with Celonis as well, as well as the more specialized stuff, like what we're talking about with Dustin here.

I look for a passion for visualizations and making sense of big data and sort of that intersection of folks who's interested in that. As well as on the non-technical side, looking at passion and really understanding, does someone truly have a passion for software engineering? Are they on GitHub? Do they have side projects? Or are they passionate about what they do, generally? We want people here to express themselves in all the ways that they know how. And sort of be constantly questioning the assumptions we're making about the product, because my decisions are not going to be the best decision. And I want to have that variety of perspectives as well.

Managing and motivating software engineers and developers

Bill Detwiler: Well, let's talk about that passion a little bit. Because just to your point, Ari, when you're building a team that's going to continuously climb new mountains, that's always looking for that next challenge and gets excited by that. I imagine it can be tough as a manager to keep them motivated. So how do you approach that, Brian? How do you approach keeping a team excited about what's next?

Brian Williams: I mean, I think we always want people to be challenging themselves, and as a manager, you want to put people in a position where they feel like they're learning and they're learning new things and experiencing a different part of the engineering stack, or they're doing some backend development, where they've been doing only front end. But then you also want people to feel like they can use those skills and get a lot done.

So you don't want to churn people out of an area just as they're getting some confidence and some strengths in that area. So it's really about balancing like when to jump into something new and when to really leverage the knowledge to get more things done. And every person's different when they are ready to switch gears or where they want to stay in that gear for longer. So you really have to know all the people on your team to make that call with them.

Dustin Jackson: What I find interesting is I think every manager thinks they want this incredibly hungry, passionate go getter. It's actually a really hard manager problem, when you have people like that on your team. It's a double-edged sword. You have to work pretty hard as a manager to keep generating new problems that are going to keep them busy and occupied. But it also is something that is so incredibly valuable to the company and the contributions that they can make. But it keeps us on our toes. You got to stay ahead of that person, who's just going to knock it out, and then come back next week asking for the next mountain to climb.

Bill Detwiler: Because, otherwise, I guess they get bored and then move on, right?

Dustin Jackson: Move on, or invent problems on their own that maybe are not the problems that actually need to be solved, yeah.

https://delivery-p141552-e1488202.adobeaemcloud.com/adobe/assets/urn:aaid:aem:07058b3c-a0f3-4998-a1b6-df2169b16edc/as/celonis_la_engineering_leaders_interview_thumbnail_2.jpg

Celonis Engineering leaders speak with Bill Detwiler in Los Angeles. From left to right, Brian Williams, Dustin Jackson and Ari Wilson.

Bill Detwiler: No, I can see that. Ari, what would you add to that? How do you work with people along that balance of passion and managing that?

Ari Wilson: Well, I would say you have to, as a manager and as a person, get out of the way, get yourself out of the way. Because, often, what you're doing today is a growth opportunity for those folks as well. I've gone through this several times in my career from an individual contributor to a tech lead to a manager, a lot thanks to this guy here. And it's always been a great experience, although putting me out of my comfort zone, and I've always emerged with a stronger background in what I need to know on the other side.

Bill Detwiler: And so it sounds like it's a lot of a balancing act, right? Like you were talking about, Dustin, you need to guide that person, but you don't want to get in the way. Was that something that you had to learn Dustin or you all had to learn along the way? How to balance that, "Hey, I need to constantly be ahead of people, giving them things to do, but I don't want to do it in a way that's restrictive in any way."

Dustin Jackson: No, I definitely did. And I think that your initial instinct sometimes as a manager is to try to control things, be very hands on, and micromanage a little bit, because you feel all of this pressure, you want to do well as a manager. And it's actually the worst thing that you can possibly do. We hire incredibly smart, motivated people who want to do well, you don't have to give them that motivation. What you need to do is give them clarity on what the mission is, and be able to help them identify the roadblocks that get in the way, and clear them, when they arise.

Good engineering decisions aren’t always about the tech

Bill Detwiler: I can imagine that when you have this team of really passionate, really skilled, experienced people that those passions maybe get in the way sometimes, when you're trying to pick the right solution for a challenge. People are very... they will argue their point or they believe that their solution is the best. Brian, how do you manage that? How do you make sure that the best answer in the room gets chosen?

Brian Williams: I mean, I think that's a hard question. Thanks for asking me that one. The best answer takes into account the biggest picture possible, right? So it's maybe not just the best technical answer, like the textbook answer to a problem, it's what are we trying to do as a team? Is our goal to get the first version of something built, because there's so much demand for it?

Like picking maybe, what is not the most optimal technical answer, but is going to get us 90% of the way there, and it's going to see if we made the right decisions on the product side. It's going to let users start benefiting right away. And getting to the right answer means taking all those things into account. So I think that's really, making sure everyone's in agreement on the big goal, and then everyone can come to an agreement on how the best data get there is, and feel like it's a team decision.

Bill Detwiler: Ari, what would you add? How do you work with your team and the other teams to make those kind of calls?

Ari Wilson: There's two things. One is sort of like the good case, the best case, I like to rely on priorities like Brian mentioned. Is it very important that we ship on time? And principles, I've always found it really important to try to write out what our goals are, what our principles are, what we believe about users, what we believe about what our products should do, and have that be the guide to how we make decisions in the team.

The second thing is, I don't think escalation should be a dirty word. Sometimes if people just can't agree, that's why we have an escalation path. And as long as you present your case and it's fair, I think you should be willing to escalate, and willing to agree with the result, even if it goes against what you might initially have thought.

Bill Detwiler: Right, no doubt. And so, Dustin, I'll wrap this question up with you, because I imagine that a lot of those escalation questions land on your desk or in your Slack channel these days. So how do you balance that? How do you make sure that the teams are making the right call?

Dustin Jackson: No, it's true. And I'll just say, to be perfectly honest, this is my favorite part of the job. I love nothing more than a spirited debate within the group. And if I get to be the decider at the end, oh, so much the better. But I strongly agree with what Brian and Ari both said about the key is first making sure we're aligned on what the goal is. And are we arguing about what that goal is? Or are we arguing about the best way to solve it? Both are valid, but let's make sure we're not arguing about different solutions that are actually solving different problems.

And then the other thing that I think is, it's so important when you're having these arguments, that it's never personal. It's, everyone's on the same team, everyone's trying to figure out the best way to get to the same place. And it doesn't really matter whose idea it was. No one should be arguing for a particular position, so they get credit. Instead, it's all about coming up with the best collective solution at the end of the day. And that usually involves taking a lot of different pieces from a lot of different people's heads.

Bill Detwiler: That really is true. We do win and lose as a team, right? It is about that effort and attacking the problem, blaming the problem, not blaming the individual, but also celebrating as a team together.