プレゼンテーション：開発者エクスペリエンスチームの最適な効率性を実現する

InfoQ Homepage Presentations Achieve Optimal Efficiency for Your Developer Experience Teams

Achieve Optimal Efficiency for Your Developer Experience Teams

Fabien Deshayes discusses the strategies behind Monzo’s Developer Velocity squad. He explains the "Platform as a Product" mindset, emphasizing the need for engineers with product acumen and tenure. He shares actionable frameworks for measuring DevEx impact through time, money, and cognitive load, demonstrating how a small, focused team can drive massive results in a regulated environment.

Fabien Deshayes is a Platform Engineering Manager at Monzo, where he leads the Developer Experience team in order to meaningfully increase velocity of engineers by landing exceptional developer experiences. Prior to Monzo, Fabien worked as an Engineering Manager at Spotify where he contributed to Backstage, the open source Developer Portal.

About the conference

Software is changing the world. QCon London empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.

Fabien Deshayes: What are we going to talk about? My name is Fabien Deshayes. I'm an engineering manager at Monzo. If you're from the UK, you have probably heard of Monzo. Basically, we're a digital bank that operates here. We have more than 11 million customers. We've achieved that with a fairly small engineering organization. We're roughly around 400, I think 412 is the last time I checked, is the number of engineers at Monzo. You'd think it's fairly small for a bank, especially with 11 million customers. I'd like to think of us as not a bank, actually, but a tech company that happens to run a bank. It's really about how I think and reason about Monzo.

Monzo's Dev Velocity Team

I want to talk to you about a DevEx team that we've built at Monzo, and what that team has achieved. In December 2023, we formed the Developer Velocity squad, these guys on that screen. It's roughly a team of three engineers, plus an engineering manager. This team has worked on something called the Experimentation Platform. What's the Experimentation Platform? I'm going to give you a simple example. This is a screen of a feature we called roundups. Every time you make a payment, it basically rounds up your payment to the highest pound, and puts that difference into an investment pot. It's very simple, it's pretty cool. Makes all of your numbers round, and makes it very easy to reason around. What we did for that experiment was have two versions.

On the left-hand side, our control version, which is basically explain what that feature does. On the right-hand side, it adds a little graph that says, based on the payments you've made over the past year, you would have put that much amount of money on an investment pot, and after 10 years, this would have grown to that much money. It's telling a story about what will happen with your money. What we did was present one of these two variations to our customers, and the experiment is basically trying to figure out which one will get the most conversion. How many people will click on that create investment pot button at the bottom? That's basically the experimentation platform.

What has the team achieved? Initially, we had an old in-house experimentation platform, which was ok, but not great, especially it was really hard to do data analysis on top of it. We've replaced that in seven months, and as a result, we doubled the number of experiments that we run in the company, from 70 to 134, looking in 2024 to 2025 for the first quarter. We've also halved the time to decision. Before, it would take 43 days to run an experiment and get to a decision and trying to know which option is the best. Now, it's only 21 days, and it cannot be really much less than that, because you still need a little bit of time to exposition and to gather enough data to make your good decision.

Assemble Your DevEx Team

How did we pull that off? That's what I'm going to talk to you about today. I think there's three elements that are part of how we made this a success in such a little time. First is being able to assemble a great dev team, so I'm going to talk about that. We built very impactful products, and here I'm going to insist on the product side, and communicate about the impact of your DevEx products. Let's dig into the first of them, assemble your DevEx team. When I did put together my slideshow, I thought, my team is a team of superheroes. I'm just going to call them the DEVEX-MEN. I thought that was a very nice thing.

Then I realized that it's not very inclusive and it's not very true. It needs to be diverse, and also the engineers are not superheroes. They're just like engineers you find in any company. We just manage to get the right skills in the right team, working the right way. I want to demystify the fact that you've got some ninja engineer or top star or rockstar. That's not the case. You don't need these people in order to build a great developer experience. You just need the right people. First, I think you need to find engineers who have some product acumen. That's basically the ability to make good judgments and make some quick decisions.

Basically, you have to think of other engineers in the company as your customers. They're going to be the ones that are going to use your product. Really think about them as customers. You also need to be able to make quick tradeoffs. You need to move fast. It's not because you're building an internal tool and you don't have a hard deadline because some marketing team said by that date we're going to release this new feature. It's not because of that, that you shouldn't move quickly and iterate fast. You still have people that are going to look at what you're doing, and say, what have you done last half, last quarter? You need to be able to think about how you move fast and make tradeoff decisions.

Finally, you need to be able to make this decision and think about long-term. It might not be intuitive when you're working on internal developer tools because you just want to test something or hack on the side. If it's successful, it's going to be here for like 10 years, 15 years. You really need to think about these decisions that are going to be potentially reversible or potentially irreversible. If they are irreversible, you better think really hard about them and you better have a good argument about why you took this decision instead of another. Really think of your platform as a product and all the consequence that comes with it.

The second thing that I think is super important in a DevEx team is to identify engineers who have tenure in the company. Why is that? Usually, if you've been in the company for some years, you probably have a little bit of a network with other engineers that you've worked in the past. You've joined the team, people have moved on to another team. You've done the same, maybe two, three teams over a span of a few years. That can give you free user research for your DevEx team. Again, thinking about you're building a product and you need to learn about your customers.

The best way to learn about that is just to speak to them. If you know someone that knows an engineer that is facing a problem with their developer experience, this is fantastic, you just have to talk to them. Also, people with tenure are more likely to be a little bit more senior and they'll be able to have a breadth of ambitions and ideas of what can be achieved in the company. Think about all of that and make sure that they bring all of these ideas with them to your team. I'll add a caveat to that. You could have engineers which have been here for a very long time and maybe they were stuck at some point in one team that had this very specific problem. Then they come to your DevEx team, very opinionated, thinking, "We should solve that problem. I've seen it in action. It was really painful". Maybe that problem was only happening in one team and not all the other teams. Really also think about the entirety of your engineering organization and not just the teams that your engineers have worked in previously.

Finally, soft skills. You're building a product. You're going to have to sell your product. I don't think you're going to get marketing teams working with you to sell your product. I don't think you'll even get one person to help with that. You're going to have to do the selling yourself, and selling is hard. You just need to be able to talk about what you're doing and convince people. If you manage to find people with great soft skills, bring them on. They're going to be so useful.

One thing I wanted to add on that is it might be counterintuitive because you think, my engineers who have the best soft skills, the one that speaks really well and you can put them in front of an audience, they might be the one that are closer to your end customers. They might sit down with some user research sessions. They might be just talking to users. I think there's also an argument for having them sitting in developer experience team, like platform, looking inward towards the company because without adoption and without people talking about your product, they're just not going to succeed as a developer experience team.

What does this give us? Basically, three aspects of what would be an ideal person in a developer experience team, and ideally, you would have someone who's bang on the middle. Don't worry, you don't have to have three, four engineers just in the middle. It's going to be very rare if you find that magic combination.

For example, at Monzo, what we've done is we had someone I consider was bang in the middle. We had someone with great soft skills and someone with tenure. That mix worked really well. We managed to build a well-rounded platform and product, and see a lot of great adoption within the company. I also think it's absolutely fine to have some people who are not within these circles. Some people may be less experienced or coming from a different background, as long as they're surrounded with people with these skills because then they can grow, they can absorb, and they can move within these circles.

Build Impactful Products

You've got your perfect developer experience team, now it's time to build, and build impactful products. Again, I'm going to insist and repeat, we're talking here about products, not projects, not solutions. The first thing I think is important is to align with your company values. Why? This will make it resonate with your user. One of our company values at Monzo, I'm not sure if it's a value in itself, but we keep talking about Monzo magic, how we make things magically simple. For example, you're at the restaurant with some friends, you're paying the bill, and then you want to split the bill. It's as simple as a touch in a mobile app. We really want to make these small things very easy. We try to replicate that in our experimentation platform.

An example of what we've done is just try to make cleaning up experiments as magical and as simple as possible. If you worked in experimentation platform, or even feature toggles, it's very easy to create new stuff, but it's always a lot harder to think about cleaning up, removing the code, understanding if it's safe to remove or not. Are we finished with our experiments or not? What we've done in our developer velocity team is built a little app, that little bot on Slack that just tells teams, you've got an experiment here that is ready to be cleaned up. How does it know it can be cleaned up? It's looking at all the evaluation. It's looking, is your experiment still evaluated, yes or no? If it's not evaluated, probably can be cleaned up. If it's always evaluated, but always returns the same value, it's probably that we've made