The full transcript

Oleg

Hi, everybody! Welcome to Devico Breakfast Bar! Here we speak with different people involved in the business landscape, share their expertise, delve into the latest tech trends, and explore the ins and outs of IT outsourcing. I'm Oleg Sadikov, and today I'm excited to have Julien Danjou, co-founder and the CEO of Mergify. Don't forget to subscribe and hit the notification bell so you don't miss our new episodes. Hi, Julien! Can you share with us your journey from your early days in the business world to becoming a co-founder and CEO of Mergify? What were some pivotal moments along the way?

Julien

Sure. Hi! So, I'm Julien. I'm an engineer. So, my career started as a software engineer – nothing fancy. I actually fell into the trap of open source many years ago or so. So, that's how I started working, which was contributing to open-source projects. I had to work at some point, so I found a job after university. I was already doing open-source stuff, and once upon a time, I met a guy in a company – an engineer, a fellow engineer – and we started working together, doing things. And at some point, we created something like software we found very useful. And we actually thought about adding values outside of just what we were doing on a day-to-day basis in our current job. So, we started thinking maybe trying to sell it in some way and starting a business out of that. And that's actually, I think, how we started the whole venture of Mergify. Just, you know, randomly creating software that might be useful for other software engineers. So, the people we work for are also software engineers. We do our software for engineers too. We know pretty well because it's ourselves. And we started that way, basically. I never intended to be a CEO or a co-founder. Just I had to take the job at some point to build a business and try to sell what we built.

Oleg

Okay. Great! Mergify focuses on providing automation or optimization services for engineering teams using GitHub. What were the challenges you faced in early stages?

Julien

I think the problem we met early on was the one that you meet for any startup. So, it was finding our first customers. We probably had an advantage, which is we are engineers, and we're trying to sell to people like us. So, that probably give us some unfair advantages where we could reach out to our peer and make sure that we were able to find your first users, even maybe not first customers, but finding the first people that were ready to give it a try, give you feedback, make sure that you work on the right things. I think this is something that most people have a problem with, which is, you know, making sure that your idea is actually a good idea, there's a market behind it. You're not even sure sometimes. The thing we created back in the day, we were not even sure people were going to buy it, which was different from starting something where there's already a market, you have competitors. We had nothing like that. We were alone. It's very hard to be sure that you're on the right road.So, it takes time and takes a lot of effort to be sure that you are going somewhere at the end of the day.

Oleg

In your experience, what are some common pain points or inefficiencies that engineering teams face when managing their workflows on GitHub?

Julien

There are multiple points where we actually try to solve those, which is that people tend to not do enough automation. Software engineers are very expensive, so you need to use their time in a very smart way. And they tend to not automate enough of their work, especially on GitHub and any platform that they use to manage code. So, they tend to do things manually, which might be mundane things, not very valuable, like triaging the pull request by adding labels, doing rebase operations – all of that. They have to do that manually, and they could automate some of that, but usually, the bar to automate is so high that they just postpone it forever. And that's where we actually bring values to the table, which is you can automate things in a few lines of YAML and make sure that your workflow is automated and you don't need to think twice about it. It’s then easy for new people being onboarded on your team to see how people work in your repository because everything is written in a YAML file, which is very easy for a human to read and understand. So, all this kind of thing that you do on a day-to-day basis where you like, ‘I should make that automated, but I don't do it because I'm not sure.’ You can do that step by step and actually spend more time writing code, thinking about what you need to build, which is where nothing is going to replace people, even AI. We're using AI for some of our solutions and software, but we use that to make sure that people spend time, especially engineers, where they actually add value to the table and not do things that could be done by bots.

Oleg

Yeah, so you don't believe that AI will replace people – engineers?

Julien

Not, but a lot of people are afraid of that. I think they're going to enhance them in the sense that they're going to make people better and more efficient, but they don't have the capacity yet, at least, you know, reasoning in their heads to think about the problem. A very large limitation right now on AI is the context size that you have.

So, you can ask them to write a piece of software, to debug some line of code. Then adding the whole architecture of a product in their head and reasoning about that – it's still not possible. Maybe in 5 years, 10 years, or maybe in 6 months. I don't know. It's going so fast these days. But this is where people are still needed and where actually engineers should spend their time. If you look at solutions, like GitHub Copilot, for example, which can write a lot of code for you, write tests, or whatever – again, mundane tasks, which are not things you really spend a lot of time thinking about – AI can do that now. So, it's great. It saves time. And then you need to move on the layer above, which is thinking. And we're trying to do that also making sure that people spend their time where it matters and not in doing things like clicking buttons.

Oleg

How do you see automation shaping the future of software development?

Julien

So, I think automation in the sense, which basically is what I was just saying, is like making sure people spend their time in the right way, and automation brings that to the table. So far, we've seen automation in a way where people had to spend a lot of time writing automation. So, you have to think about how to automate. I think we're going to a new era where people will not have to think about that. And we will see things like AI watching what you do every day and suggesting, for example, why you're doing that every day? I'm going to do that for you. And this kind of pattern is emerging because AI is going to be able to do that. It's very basic reasoning. It's pattern matching, machine learning, which is very easy to do and to build, and it's getting easier and easier. So, I think a lot of automation is going to be this way, where you're going to move from. I have to think about automation. Automation is done for me, and I don't have to think and do anything. It's just magic. So, you're going this way where there is no artwork of integration, of describing what you would like to automate. All of that is going to be complicated and far from perfect for us, but I think slowly but surely we'll go toward that.

Oleg

Okay. Collaboration and integration are crucial in modern software development. How does Mergify facilitate collaboration among the team members?

Julien

So, the way we do that is by making sure there's a common understanding between people. For example, making sure that you codify your automation rules. A process that is written somewhere makes it easier for people to know what they're talking about. We're seeing a lot of customers coming from... They don't have anything, basically, it's chaos, more or less, where they don't have any rules. They don't really know what should be the minimum set of testing, of goal, of approval, of what is your real process to do this or this. Like, how do you feel when things are going to be broken? For example, if you have an incident or something, how do you under the hotfix that you're going to put into predictions? What is the process? Often there is no process. There is a regular process where everything goes smooth, which is maybe 50% of the time, and the rest is, I don't know, we just improvise. While my work's fine for small teams, small startups as you grow, it's starting to be more and more difficult to use that system because there is a lot of incomprehension between people. They don't really understand what the process is, what it should be, what it's not respected sometimes. It's not to say it's written in marble, but you can express what you want in terms of automation in something like Mergify, and make sure that it's followed, and it's easy for anyone that is onboard on the team, for example, to understand, which is very valuable.

Oleg

Let's talk about your hobbies and personal interests. Many developers are 24/7 in coding. Are you that guy? Or you have other interests, except for development?

Julien

No! Yeah, no. I've... I think I used to be, maybe 10 or 20 years ago, but I moved on from that. I still like coding from time to time, but as a CEO, I have less time to code. I have to rely on my team to do that instead, which gets better than just me working on it during the night. So no, I do other stuff, which is not being far away from the computer. I mean, from doing sport, gardening, or cooking. I love cooking. I spent a lot of time in my kitchen or on my barbecue those last days. When the sun is there, at least. So yeah, I mean, doing other stuff I love. Computer science has been a passion of mine for the last 30 years or so, but you have to get out of it from time to time.

Oleg

What was the defining moment or experience that shaped your outlook on entrepreneurship?

Julien

I think it starts when you get your first customer or customers. That is the first one when you realize that you actually built something that has value for others, but you can add more value, and you can find more people. And there is a pattern there. You start something where you're like, 'Look, I'm not a software engineer anymore, just writing code, but I can actually solve problems from top to bottom.' You can solve everything, which also defines you then as an entrepreneur, as being the guy that needs to handle shit all day. You have to switch from just writing code, like we were saying, to where you have to talk to people, you have to do marketing, you have to do sales, you have to do accounting, you have to do a ton of things you don't want to do usually because you are a specialist in something, which might be engineering or maybe sales if you're coming from a different background. And you have to suddenly be very, very knowledgeable in a lot of different spaces where you have no clue. Now, I started to learn about finance, accounting, and forums I don't want to hear about – all of these things that you have to do. And you realize that you started something. You're labeled as an entrepreneur because you're doing all this stuff, and you're building a venture, but you started something from scratch, and now it goes somewhere, not really sure where it goes, how long it will take to go there, whatever, but this is the start of the new venture, and you go there. And I think really the first customer is where you have this kind of stamp, which says, 'Okay, there's something now. It's real. You can move on and continue. I'm not sure it's going to go on forever. You don't know what lies beyond the door, but there is something, so you can continue if you want or just give up.'

Oleg

Are there any professionals or leaders in your network who inspire you in your journey?

Julien

I don't think I have anyone in particular, especially because when I started, I did not know many people doing that. So, I had a few friends or people in my professional network that I knew started companies in like the DevTools space, for example. It's the space we are in. So, I have nobody, but I think as I grew and as I continued working on Mergify and building the company, I spent more and more time trying to collect and follow other people's journeys. I mean, at least people talking about it because you have to do this. Being an entrepreneur, I think, is something where you are very lonely. So, I have a co-founder, fortunately, so I'm not that lonely. I can talk to another guy when I have doubts, when I want to run ideas. But you tend to be very lonely, especially if you're a solo founder. So, you have to find other people to connect with, to share your ideas, your doubts, things that might go wrong, things that might be a problem for you because it's very hard. You know, in engineering, we have this kind of thing we call it the rubber duck debugging, where you talk to a rubber duck to try to solve issues. And you have to find this rubber duck when you are an entrepreneur. I think it helps. So, if you don't have that internally, because you don't have a team of co-founders, finding people along the way that might help you with that is a great way. So, I don't think I had anyone in mind when I started, but I started to find other people that could be an inspiration to me, and seeing them having the same issues helps a lot.

Oleg

Thanks. I know that you have an in-house development team. What factors have led you to abstain from considering IT outsourcing so far?

Julien

That's a good question. So, the thing we do is we provide software for developers, which means we are providing software for probably the worst people in the world. They don't want to buy anything. They don't want to buy software because they know how to write software. So, you will have to have a level of expertise in what you're doing. And if you ship something that is broken, they're going to laugh at you. If you ship software that is broken to a company whose field is not IT, for example, they're just going to say, 'Nah, IT sucks. It's always buggy.' Well, when you ship something like that to a customer and they're going to become a software engineer, they're going to say, 'Well, we could do better,' which might not be true, but they're going to think that. And they're going to be, 'Oh, we should build it ourselves,' which is something we see a lot from prospects coming to us and go, 'Oh, Mergify looks cool. We could do it yourself.' Which might be true, but it takes them two, three years to build Mergify internally. There is no point in doing so, but they could do that. So, it's like a threat. They rely, I mean, they use above your head. So, if you don't have your own IT experts that build it, that you keep over time, it's very hard, I think, by outsourcing where you have people that are outside of the company, and then you might have this kind of issue. I mean, it's not always like that, but you might have a higher turnover in the team, you might have people changing, you might have communication issues because they're not part of your company inside. So, they might lack knowledge, like product knowledge, whatever. So, it's very hard to go fast. I think as a startup, it's very complicated. You need to go fast to iterate very fast. So, if you start people outside of the company, depending on how you integrate your outsourcing company, of course, it might be more complicated to go fast, and to iterate, and to pivot. It really depends on how you work with other companies and your providers outside of your own team. But usually there is friction because it's two different brains working together.

Oleg

How about a mix? In-house and outsourcing?

Julien

I think it's a better model, basically. Outsourcing, I think, works if you're building a product, and you want to order something, build a product, and then use that as a base, or MVP – all of that. In the long run, if your core is IT, I think it's complicated. I think having a mix is a good way to outsource things you don't care about. It really depends on what you're trying to build. I don't think there's a good generalization on that. It really depends on the kind of technology you want to use. If you want to build something that is very generic, like your idea is to code a clone of Airbnb, well, it's been done plenty of times. If you want another version of Airbnb to do some other things, I don't think there's a lot of risk in building that. So, you could definitely outsource it and work with people outside or a mix of people inside doing some custom parts and people doing more generic parts because they're going to be easy to transmit and express to guys being outsourced. So, I think it really depends on what you build, and I think both might be a good trade-off.

Oleg

It sounded very funny: you can outsource what you don't care about. Okay. In which specific industries do you believe companies can gain the most from IT outsourcing?

Julien

It's hard for me to answer because I'm very focused in my lane, basically, but I think it tends to be for technologies and products where there is less risk in the sense that the risk is not on the technology but on the market itself. For example, if you're building something with a new fancy AI and LLM things and you're trying to follow the trends, it's very hard to work with an outsourcing company and moving because it's the core of what you're trying to do, what you’re trying to solve, you're trying to innovate. So, I think it's hard to do that. If you want to do, like I was saying, a clone of Airbnb or something that already exists, but for different markets, I think there is no point in trying to, like, your core is going to be focused on sales, on marketing, on targeting the market. There is no risk in technology. It just quotes basic execution like there's a roadmap – we need to build that feature. And it's been done plenty of times, so there is no risk in really building the thing because it's done on very good and well-known technologies. You're not going to use something fancy. You're going to use something that works, that has been proven over time. So, there is no point in trying to maybe build a heavy team. You can just do MVP, iterate from that, and even go into production with that. And because it works, and you validate that the market works, so for a startup, for example, it's better to do that than trying to build a team, which is going to expect to build something very large, maybe, or we will want to use new technologies, or we'll get bored. I mean, that's what software engineers are. They get bored. You say you use you something. All that works right. So, I think using a company outside of yours just to do the minimum that you need and then maybe stop for a while because you put the thing on pause until you validate the market. If you're a startup, I think that that is a great way to have flexibility in the way you work.

Oleg

Okay. If someone told you to select two, three activities that you could outsource, what would they be?

Julien

Again, it really depends on what you do. In general, I think the thing that you could outsource is probably the apps that are not part of your core. For example, if you need to build something that is not part of your core business in the sense that it's hard to, nowadays, I think, most companies are starting to become very core IT business. But if you have things that, you know, is not bringing really values for your customers to the table and that you just need to have like a tool, basically, if you need a tool to do something, and you need, okay, this tool should be IT, should be software, it's not your purpose to write this. It's not because you need a house that you're going to learn how to use brick and mortar and build this, right? It's just stupid. It's not a good use of your time. If your job is not building houses, just don't do that. So, for a company, it's the same. If your goal is not to build that tool that you need, just find a company that knows how to build that tool for you. You don't have to buy it off the shelf. You can have your own custom tool if you want because it sometimes might be better and more efficient to have your own customized tool integrated with your different existing tool and solution that you use. So, I think about going to a company saying, 'This is what we need. How can you build it for us?' is a great way. So, it could be anything, basically, in any area of a company, from HR to warehouse, to whatever you're doing. It could be just, I think, this company doing that for you because it's not your core business, and it's not going to add value to it while you have a team or engineers to do that internally because that's not what you do on a day-to-day basis.

Oleg

Okay, great. Julien, thanks for participating in my video podcast session. I think you are one of the few deep technical software guys – developers – who I invited. Usually, there are more business people there. It's always nice to speak with technical software engineers.

Julien

Thank you. I'm sure my answers are very different from the business guys.

Oleg

It's definitely different, but you’re a mix. Even though I think in your nature you're a software developer, now you're an entrepreneur, and you're the CEO of the company. So, I still feel a kind of mix, even though I think that you're a software engineer, there is a business view to the problem and the way you approach any issues. Thanks for your time. I'm sure the information you shared will be useful for our auditory, and I'm wishing you all the best in your entrepreneurship.

Julien

Thank you, Oleg.

Oleg

If you enjoy our discussion and want to stay updated on future episodes, don't forget to subscribe and hit the notification bell. That way, you will not miss out on the latest insights and conversations from Devico Breakfast Bar. See you in a week!