Presentation: 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. By Fabien Deshayes

InfoQ Homepage

Presentations

Achieve Optimal Efficiency for Your Developer Experience Teams

Culture & Methods

Achieve Optimal Efficiency for Your Developer Experience Teams

• Reading list

50:51

Summary

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.

Bio

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.

Transcript

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.

[...]

*Original source*