Eliminating Software Development Process w/ Adam Carmi of Applitools

**Dan** (0:02)
What would happen if you eliminated all of the processes that surround your software development teams today?
And what if you only ever hired senior developers? This was the vision Adam Carmi decided to undertake when he co-founded Applitools nine years ago. Now, after working with the most elite software teams around the world, he opens up about how his methodology works and why you need to start eliminating processes too.

**SPEAKER_3** (0:30)
This episode is sponsored by LinearB. Give your dev team the power to improve with team-based metrics, high-risk code alerts, and the world's first project board based on real-time Git activity.
Sign up free at linearb.io.

**Dan** (0:45)
Hey, Adam, thanks so much for joining us.

**Adam Carmi** (0:48)
Thanks, Dan, for having me. It's a pleasure to be here.

**Dan** (0:51)
Yeah, yeah. Really excited to have you on the pod today. We are going to dive into Dev team processes.
And as you probably know, there are a lot of processes that are surrounding software development, like Agile processes, Sprint reviews, PR reviews. There's tons of security processes. It seems actually we're kind of like a process-driven community.
But I know for you, and this is kind of why we have you on the pod here today, you don't necessarily feel the same way about processes or running your team at Applitools in that way. Can you talk to me about what you guys are doing?

**Adam Carmi** (1:42)
Yeah, so actually we accidentally stumbled upon, let's say, a development culture that actually tries to eliminate process by relying on our developers being extremely professional and capable and also empowering them to take ownership on all the activities that they do. Now by being able to rely on them to get it done, basically we don't need a lot of processes to make sure that things actually get done.

**Dan** (2:17)
This is so cool. I don't think that I've ever talked with anyone that says we're not enforcing processes or we're trying to eliminate processes. So yeah, I would love to hear, how did you stumble upon this way of working?

**Adam Carmi** (2:33)
In the previous company I worked for, it was called Safen, it was an endpoint security company, and I had the privilege of joining as the fourth employee when the company just started, and I stayed for eight years until the company was acquired. So that gave me a lot of perspective on what happens to an engineering team from the moment it gets burned, it's burned until the company gets acquired, and there are close to 100 people there, and you can see exactly how the choices that you've made along the way, how they affected and turned into monsters that are very difficult to battle a few years later.
And one thing that I noticed is that although we started out as a core team of very, very professional and experienced developers and engineers, along the way, that somehow changed, very slowly over the years. And the interesting thing that became very real to me, and I think that maybe most listeners will identify with what I'm saying, is that I found that in every team, there was one guy who knew the answers to all the questions, who could solve the problems that all the other developers in the team could struggle with for days and weeks. He somehow could work. When he was working, he was doing the job of five people. And we can call these the A players.
And what I found is as time progressed, it became much harder and harder for me to retain those A players. They were unhappy because the other people that they were working with were not A players. And it made my job very difficult because I spent a lot of time trying to convince these guys to stay and that the world is beautiful and they're actually imagining things and all of that. So what I decided to do when I started Applitools is that I decided to try real hard only to hire A players. So never compromise.
In any case, no matter what pressure I have to grow the team. Now, what started as an experiment eventually evolved into the state that we are today. By having so many extremely experienced and smart and capable engineers on the team, we started to realize that they can actually solve everything by themselves. We didn't really need so many meetings because first of all, they knew most of the answers to the questions, but they could also just reach out to their peers and ask the questions when they needed them. I didn't need to have meetings to make sure that these discussions go on.