How To Build a Diverse Team to Unlock True Success
13 Aug 2024 · 57 min
Mary, CTO at Pleo, shares how she builds diverse engineering teams across roles at Procter & Gamble, the UK Government, Monzo, and others. She uses a three-question diagnostic in her first 90 days to spot improvement areas, treats managers as multipliers, and partners with coding schools to recruit underrepresented talent.
Chapters
Welcome back everyone to another episode of Mastering Tech Growth. Today we have Mary, who's a well-sought-after CTO here in UK, and we have amazing topics. We got high-performing teams and the importance of diversity and inclusion for the high-performing teams. Welcome, Mary.
Brilliant. Thank you for having me.
Tell us who Mary is, how you ended up in tech, and what you're currently doing.
Sure. So I'm South African originally, but I've been living in the UK for a long time now. I came here to study and then failed to go home. I started out as a hardware hacker in South Africa as a kid, built my own computer from broken pieces when I was young, and then ended up studying computer science. So I came to the UK and studied computer science here at the University of Bath. And then I joined Procter Gamble after that. So I did my first 10 years of my career at P&G. And then since then, I've been in increasingly larger CTO roles out in mostly startups and scaleups. Today, I'm CTO at Pleo. I lead a team of about 250 people in engineering and data.
How did you end up in startups? I mean, that's— because you mentioned Procter Gamble, that's like a big enterprise, right? Thousands of people. And then you just went like, okay, I'm going to go back to the startups.
Yeah. It was interesting. I, when I left P&G, I was planning to go to Google or Amazon and a guy called Tom Lewis rang me up and said, hey, we're going to fix the UK government. Come help us do that instead. And so I joined the Government Digital Service. So the first thing I did after P&G, I was actually in the government in the UK and the GDS was a really interesting thing. It was kind of like a startup within the government. And so that was when I got the taste for these sort of smaller organizations within bigger organizations. And then after that, I did a couple of other big companies, Vodafone and M&S. But then I got hired by Moo, and they do fancy printing, digital printing. And I really enjoyed that experience. And then I went on to work at Monzo after Moo, having mentored the co-founder CTO at Monzo for a couple of years. So I think it was partly moving to London to work for GDS and then getting exposed to the startup scene, and then just found that I really enjoyed slightly smaller teams. I love, you know, in a team of a couple of hundred people, I can know everybody's name and I can get to know them all. Pretty well. So I enjoy that a lot.
Would you say it's easier because of that, because you can build those relationships and be much closer to people? And when I say easier, easier to lead, easier to scale, easier to have influence on people's lives?
I think it's easier in some ways, because there's not as many layers of abstraction. You do get to know people much more directly. You do get to lead them much more directly. But then there's also stuff that I miss, right? There's there's a lot of well-oiled process somewhere like P&G. It's really well-defined how to get things done and how to ask for things. And so, I tend to do the slightly later-stage startup scale-ups because then things are a little bit better organized. It's not quite so chaotic. I'm autistic and ADHD, and that combination means that I quite enjoy doing lots of different things, but I also quite like structure. And so, I definitely there's a part of me that prefers the scale-up part of the journey because it's a little less chaotic than the very early stages. So I think it's easier in some ways and more difficult in other ways.
So you find your spot effectively. The early startups, very wild, wild west, things are coming left and right, no structure, no processes to scale really. Bigger organizations, maybe not enough challenges to actually go ahead and fix things or improve things. So you're just in the middle at that scale-up. And, uh, you know, main question, right? It's all about the people. You know, people get things done. So the better the teams you have, the more likely you're going to achieve. So what's your approach when you're coming in in new organizations? And you did that, you know, multiple times. You're inheriting this team. It's like, what do you look first for high-impact areas of improvements?
Yeah. So, the first thing I do, and I've done this in a few different organizations now, is I go meet every team. And I ask them, what are they proud of? What are they worried about? And if I had a magic wand, what should I do with it? And that gives me some really good insight into what people are doing well already, in terms of what they're proud of. It tells me where Maybe tools and processes and ways of working aren't good enough yet. I get a lot of that from what they're worried about and what they wish I would do with a magic wand. And by going and meeting all of those teams, I think I hear very directly what the challenges in the organization are. And so, by doing that and grounding my first kind of 90 days in the company, really, and listening to the teams. I, of course, also listen to senior stakeholders and my fellow executives on the exec team and various other folks around the organization. But the thing I find the most useful is to go and meet the actual teams and ask them those 3 questions.
What was the biggest challenge, if you were able to disclose without disclosing too much, as they say, where you came in, you have these conversations, and you were like, that's going to be an Everest to climb?
Yes. So, at Moo, it was the fact that we were still on-prem in our infrastructure. And so, there were pets rather than cattle in the servers. So, they were very individually named and set up and everything else. And we were already at a point where scaling that business was being held back by the technology. So, we were having to not do sales, or when we did a sale, it would bring the website down and those kind of things. And so, doing a lift and shift at Moo from, you know, from on-prem to cloud in a really short period of time, we did it in under 9 months, was the primary challenge there. When I joined Monzo, it was about keeping up with the rate of growth. So, I joined when there were about 50 engineers and we were 150 in less than 12 months. And so, we had a point where everybody in the company, half of the people in engineering had been in the company less than 3 months. And so, making onboarding really, really good and making sure that those people who came in could be productive and that they were a good add to the culture rather than taking away from the culture was one of the challenges. And then at Pleo, quite a classic story, a bit of tech debt, a monolith that wasn't scaling very well, that was fragile and difficult for people to change. And so, over the last, my first year at Pleo, We've done a lot to unpick that and to replace that monolith with more atomic services.
So, that's such a cliché, that technical depth just coming back and becoming a much bigger problem and bigger problem. That's at least how it sounds with Clio and Moo. I mean, that's all affected technical decisions, trade-offs being made early in the business where later you know, we need, we need Matty coming in and basically fixing all of that. So that rate of growth though, how does that look like, you know, from your perspective? So you were, you coming in Monzo, you're like, okay, we're gonna scale from 50 to 150. You got 9 months or 12 months. So, you know, you're gonna be doing like huge hiring campaigns. You still need to make sure the people fit culturally, you know, onboarding you mentioned. So that, that piece of onboarding, how do you get someone coming in, in a scale-up and getting them producing value as soon as possible? Like, is there like a secret sauce Matti has?
So at Monzo, actually, a lot of the work had been done already by the team before I joined. They'd set out really clear engineering principles and ways of working, and that made it very easy for new people to come in. And then the other thing that we spotted was that there were particular engineering managers and tech leads who seemed to onboard people really, really well. And so, we went and said to them, you know, what are you doing differently? And a lot of it was about curating the work that somebody did in their first month to make sure that it gave them kind of enough exposure to the codebase that they could get to feeling quite confident in a broad amount of the codebase, but also going in depth enough and doing things repetitively enough that they could feel really confident after that month. And so, we basically found these few tech leads and eng managers who were doing a really fantastic job of onboarding people, and then figured out what they were doing, and then tried to replicate that across the organization. So, we advised the different teams on how to, you know, what kind of work is good work to save up almost for new people as they come in, what kind of work do you chain together to give a really good learning experience to somebody, and then you can get them to be kind of individually, independently productive, sorry, as quickly as possible. And if somebody can be independently productive within the first 6 weeks that they're in the company, then your first 3 months of probation, you get a really good idea of whether they're going to succeed or not. And so that was a— but I was building on great work that had already been done before I arrived, for sure.
I love that. I mean, the, the ability to teach others, it's, uh, we probably will call it as a soft skill, but, uh, that character trait, uh, recognizing what it means to be part of a team and what it means to be a good team player, you will need to teach juniors, and effectively your team will do as good as everybody else does. So spreading that knowledge, is that something you would be looking when you hire people in scale-ups, like when you hire you know, team leads or developer managers or tech leads, is there your way of looking at what you need character traits-wise, you know, and the hard skills, you know, let's just leave it on the side, it's just more about like characters and cultural fits.
Yeah. So I think in engineering managers, I really look for people who want to develop others. I think a great engineering manager can be such a point of leverage, they can be a multiplier, they can help help, you know, 10, 12 people be the best that they can be. And so, in engineering managers, I'm really looking for people who are keen to develop others, who have invested in their ability to coach and to mentor, and then who are, you know, really willing to put the work in to develop folks. For tech leads, looking for the technical aspects, of course, but also for them to be willing to do what Tanya Reilly refers to as glue work. The little bits of work that help a team be more productive, even when it's not the sexiest work, maybe. You know, when you look at what glue work is, it's, you know, making sure that team and this team talk to each other and making sure the processes of the team are running really well and those kinds of things. And so, in tech leads, I'm looking for someone who, again, wants to coach and mentor, is willing to spend time on developing others, but from a day-to-day point of view is also going to take those moments and go, "Can we make the process better for this team? Can we make not just the technology better, but also the way that we work better?" And I think that's really important when I'm looking for really good tech leads. I think the best tech leads have also learned how to teach, but I think we've got to recognize that teaching is a separate skill. It's not one that you automatically learn when you're coming up as an entry-level, and then a mid-level, and then a senior engineer. I don't think you necessarily always learn how to learn or learn how to teach. And so helping people understand how, what the science of learning looks like and then how to make the most out of everyday learning in the job, I think is really important.
It's excellent points, Mary. Thank you for that. You mentioned Multipliers. Is that the book by Liz? Which played in your mind, or is it just a word you used?
It's actually Camille Fournier is who I learned it from. She did a great talk called You Can't Clone Yourself, How to Be— You've Got to Become a Multiplier. And that's, you know, from, you know, 10 years ago, probably where I learned it.
Yeah, it's such an interesting concept, multiplying people around yourself. And sometimes, you know, the best of us without really realizing diminishing people around us as we lead in such a subtle game you play. But if you do that right, you know, people actually are growing around you. So that's a, yeah, that's a very strong notion. That glue work, as you mentioned, not being the sexiest. How important— technically it's very important, right? But if we go like senior developers, do we look for this as well? You know, do you look at mids? Do you look at juniors, or are there any different criteria you look when you're putting a high-performing team at these different levels of, you know, individuals within the team?
I mean, I think, I think the universal thing that everybody needs is the ability to learn and the willingness to learn, because tech changes so much, we have to keep up. You can't just do a computer science degree or, you know, a conversion or an academy or a code school or similar, and then never learn again. You have to keep learning along the way. And so I think that willingness to learn and to put effort into to learn is pretty universal and is true at all levels. I think at entry-level and mid-level, you're just looking for increasing amounts of independence. So, people being able to handle bigger and bigger tasks on their own. At senior, I'm looking for them to also coach and mentor others, to also help others in the team, to be the one who spots that somebody is blocked and goes and helps them and pairs with them or or similar. And so, I think at senior level, you want them to be able to take on quite large chunks of work, whole features, whole projects themselves, and lead those, but also for them to be able to lead others. Not manage others, because I think management is almost a separate career, and a lot of the— it's career change rather than a promotion most of the time when people become a manager, because it's a it's a whole skill set that we haven't been taught along the way as engineers. We have to suddenly learn it at the point that we become managers. But I think a lot of the coaching, mentoring, teaching, learning can be learned along the way when you're becoming a senior engineer and then a tech lead.
That's an interesting point. And I definitely echo the fact that when individual contributors jump from being hands-on coder, every day to something like a team lead, which now they are, you know, a leader of people and they're responsible to getting results with and through the people. That's a totally different ballgame. And it seems that when we promote people internally, we don't really give them coaching on going like, look, you're going to be playing maybe the same game, but it's a different league. Like, different things will apply. How do you approach that? You know, like, if you're promoting internally, do you You know, maybe do an interview of recognizing leadership skills, or do you give like a heads up, you know, look, there's going to be a couple of things you'll need to do, you know, go read some books or like, what's your approach?
Yeah. So what, what I tend to do is to give people an opportunity that where they're doing a bit of both for a while. So I'm not a big fan of the tech lead manager role, like permanently. I think being an IC at the same time as you're trying to manage a team is really difficult. It's the manager make a schedule kind of difference, right? Being very interrupted, very meeting-driven is what a manager's life is like. And then what works best for individual contribution is lots of focus time and lack of interruption, ideally. And so, I don't think it works long-term. Google would tell me differently, but I I think that you start by taking someone and giving them 2 or 3 people to look after and still being an individual contributor at the same time. And then, if they do well with those 2 or 3 people, then you, over time, increase the number and have them, you know, go up to 8 to 12 people in a full-time engineering management role. In terms of training and development, we actually run a— in a couple of places I've been, we've run like an EM school kind of thing. I actually run a workshop called Be a Brilliant People Developer as part of Lead Dev, which is basically like People Management 101 for engineers, with a lot of the science behind it. Because I think a lot of HR-type training tends to just tell you what to do and not why. And that doesn't go down very well with engineers. We all want to understand the reasons behind. And so, I found this course that I run quite successful, because it talks about the underlying science of motivation. And talks about why people do or don't enjoy work, how they learn and how they develop new skills, how to mentor, how to coach, how to run good one-to-ones, those kinds of things. And so, I'll try to either put folks through that, or at Pleo, I ran it internally for our engineering management community. I've been used by the Financial Times and a few other companies as bringing that training inside when they're developing up a load of people internally to move into management roles as well. And I kind of ended up developing it because there wasn't really anything in the market already for people who were this sort of very scientific mindset, engineering background, wanting to become managers. There was a lot of very sort of standard HR training, but that told you a lot of what to do and not a lot of why. And that tended not to be very successful with folks who are very inquisitive about how things work.
And that program, is it, you run it internally or you run it as well externally? So people listening and they go like, hmm, that sounds good. Would they be able to reach out somewhere or is it just internal thing?
Yes. So I run it alongside the Lead Dev Conference. So I'm running it again in June and in middle of June '24, and I'll run it in November in Berlin as well. So we run it a few times a year.
Excellent. Well, we'll have details in the show notes for everyone listening. So jumping back into the team composition, which we briefly discussed in various ways, did you have an example, a situation where you came in, you saw the team and you're like, I know what you're missing. You're missing a good team lead or a good developer manager or, you know, something else. And you made that change or you hired new or you replaced people and the team just came alive. Like, is there any wins like that in your background, Mary?
Yeah. I think I've seen times where what was really missing was engineering managers, where there just wasn't somebody helping everybody individually to, achieve at their best and nobody helping the team to be really smooth running. And so there's some places where introducing eng managers has been the sort of unlock for that performance. But then I've also, in almost every role I've been in, ended up needing to formalize a little bit what does tech lead mean. And I think in a team, tech lead is a counterpoint and a counterpart to a product manager, someone who works with the PM and the designer on early-stage thinking on what's possible, on what's going to be easy, what's going to be difficult. And just making that role a little bit better understood tends to really pay dividends. So articulating what they do do and what they don't, they're not the line manager for the team, they're not trying to do the personal development for everybody in the team, but they are trying to lead from a tenor technical perspective. And I think clarifying that and then making sure those roles are well-staffed has been really essential in a number of the roles that I've been in.
Is that as simple as, you know, here's a memo from Mary, that's what, you know, team lead does? Or is it more like official, like, you know, DACI matrix or ACI matrix, where you have responsibilities, accountabilities, keeping people informed, and it's, you know, it's become more HR-y?
That's dependent really on the culture of the company. So, there's, you know, some places it was just going, "Hey, one of you is probably the tech lead. Let's just figure out who it is and, you know, put a star next to your name so that people know who to go to." And then some places it's been, "Hey, this is a whole new set of expectations. Here's a written document of what's expected of you. I want every team to go through this, figure out who's in a good place. And if there's nobody in your team who could play the tech lead role, then let's have a discussion about how to staff that. And so, I think there's been various sort of levels of formality in introducing it, and it depends a little bit on how the teams are at the point of joining. Quite often, tech leads emerge from the team organically, and then the value of making it a bit more formal is just that the expectations are clearer. They're, not feeling like they're not doing their job right, if they aren't spending enough, you know, if they're not spending all of their time on coding, which you don't want a tech lead to do, you want them to spend time on the team and on coaching others and on architecture and those kinds of things. And so, sometimes it's just about giving people permission to do the thing right that they already kind of realized was necessary.
So, it's contextual effectively, depends on organizational size, where organization are in their lifecycle. That, that makes perfect sense. Um, so talking about cultures, um, uh, the coaching you have of, uh, and sort of the name escaped me, but it's effectively about making people better leaders, right? So the coaching you have, effectively you come in, it will have some type of values defined to it, right? It will be like, look, if you want to do one-to-ones, well, you know, here's some concepts or ways of doing that. If you want people to respond to you, you know, build trust. And this is how— ways you do it. So you want to know that sets a tone for, for a cultural approach towards leading people. So you have that vision now, you know, you join an organization, you have that vision. How do you go and nurture that culture so it really never escapes the whole organization?
Yeah, I suppose I come with the philosophy that, um, there's a great book called Drive by Dan Pink, which talks about the different things that matter for people to be motivated to come to work, to be excited to come to work on a Monday. And he talks about purpose, autonomy, and mastery. And then I think there's a fourth one that's missing from that list, which is inclusion. And so I think that if you've got purpose, so people understand why, if you've got autonomy, people get a say in what, you've got mastery, they're proud of how, and then they've got inclusion, they feel like they belong, then that's the sort of recipe for a really high performing teams. And then what that looks like when I enter an organization is a bit of diagnosis of where is the problem. Do people not understand what we're trying to achieve as an organization, why we're here, why we exist for customers? Do people not feel like their opinions are listened to? Do they not feel like they've got enough say in what gets built and what they try to achieve. Interestingly, mastery is the most frequent one that's a challenge. People like to do good work and they like to feel like they're top of their game from a specialism point of view. And then inclusion, that feeling of, you know, I can be myself and I can be successful here is really important. And so I tend to come in and do a little bit of a diagnostic on which of those areas is the most urgent and the most important, and then try to work on that. And then check back in on those factors quite regularly to see how people are feeling. So, at Pleo, for instance, a lot of the challenge was mastery. We had a lot of people who the experience they were having at Pleo was it was the largest system and the most customers and the biggest thing they'd ever experienced. And so, they didn't have other people to learn from who had seen bigger things and experienced some of these challenges before. And so at Pleo, we've brought in some more experienced people, and we've invested a lot in training for the existing engineers so that they can feel that feeling of mastery and feel more confident in the work that they're doing and the things that they're producing.
I love that Drive book. It's such a Bible. You hear it everywhere. Autonomy, Mastery, and Purpose. They're just like comes up in every conversation. So, um, what if, what if I don't care about business values? Like, did you ever have that situation where, let's say I'm like a cloud architect and, you know, I'm like, I care about my bubble, so I, you know, I want to be, uh, I want to have some values which is, you know, for cloud engineering, but when it comes to the whole organization, you know, let it be like finance or healthcare, like I don't really resonate that much, but with the product itself or with the service or with the offering, but I just want to be in my own bubble and, you know, have those three things within my bubble, but not that the whole organization is that healthy. Like, do we, do we, do we like that? Do we, you know, we don't.
Yeah, I think it happens. One of the things that I say is one of the most fascinating things about, about managing somebody new is figuring out where their connection to purpose And so some people, their connection to purpose is at a really high level. They want to be saving the world, saving lives. They have to feel like what they do is important in a kind of global sense, right? My wife is one of those people. She builds hospitals. And so it really matters to her that she is literally doing something that will save lives if she does her job well. And I think that those people are fascinating and wonderful to have. And it's great if you've got somebody who they're their sense of purpose is really aligned to the purpose of the organization. Equally, there are people who their sense of purpose, the altitude at which their purpose connection happens is much more individual, much more person-to-person. So, I've known people who they feel a sense of purpose if they just are helping one other human in the organization, if they're helping customers or they're helping their colleagues or they're helping someone. And so, I think you get this variation in the altitude at which people connect to purpose. And so, often what I would find with somebody like the cloud architect example that you're giving is they're not feeling a great sense of connection to the overall purpose of the organization, but maybe they're feeling a great sense of mastery. So, they want to do great work. And who that work is for and how it fits in maybe doesn't matter so much to them. I think what's dangerous in that situation though is Maybe it's not the same for everybody else in their team. Maybe some of the people in the team need that sense of attachment to the purpose of the organization, to their team, to the individuals. Maybe they need it at all levels or at higher levels than that individual leader does. And then that mismatch gets problematic. I think the ideal is that you have your business purpose aligned with your individual motivation. But I don't think it's always possible. If it were essential, there are definitely some companies in the world who do things that aren't necessarily so good for the world. And it would be, if everybody felt exactly the same way about purpose, then they might never have any employees, right? But they clearly exist and they continue to do well.
Yeah, I do echo that. And I felt on a receiving end many, many times where people don't really resonate with the business purpose or even some of the values, but they have their own, as you put it, individual purpose, which is enough to be still part of a team and still be part of that organization. I love the danger zone which you just put it in because that's sort of, uh, you know, mismatches a people. But would that— if we'll keep it positive— would that actually lead to diversity of thought, where people would just have different opinions about the problems given to the team? Or would you still feel like that could create some frictions where, you know, someone would make much, much broader, much more global decisions, and, and other people would be like, you know what, I don't see what you mean, because, you know, I just care about my small bubble? Again, for the sake argument, cloud architect.
Yeah, yeah. So, I think it can end up quite, yeah, quite dangerous, because I think you end up with suboptimal decision-making. You end up with local maxima. And actually, it's one of the big challenges in large organizations is to have people not just focus on their own area that's big enough, you know, that's big, but small enough for them to understand, but for them to see how things are interconnected and make sure they're doing the right thing for the the customer, for the company, rather than just for their own individual area. The one thing I find is nice about startups and scaleups is people feel much, much closer to purpose. A lot of people who join startups and scaleups are there because of the purpose of the company, and they're willing to learn whatever skills are needed to improve their mastery, to improve their autonomy, to improve inclusion in order to achieve that purpose. But yeah, I think the biggest risk is that you end up with sort of local maxima and not making holistic decisions if people don't care enough. There's always the example of, you know, an engineer who wants to do CV-driven development. So they want to use the very latest technology all the time so that they get to say on their CV that they've used it, whether that's right for the customer and the business or not. And I think that's one of the most classic examples where this sense of purpose is really valuable is if somebody's overriding desire is to help with the overall purpose of the company, then they're much more likely to make good holistic decisions about technology choices, about how to run a project, how to get things done.
Okay. I like that. So, if we talk about diversity of thought or just general diversity within the team. In your view, Mary, how important is that? Do you proactively seek it? And if so, like, what's your more tactical advice if someone would want to increase diversity within the team and maybe even broader organization?
Yeah. So I think, I think true diversity is really important. I, I think diversity of thought is sometimes used as an excuse to avoid real diversity. I think we sometimes are like, well, if people think differently, then it's just as good as if they were different. And I think you can only think differently to a sort of surface level if you're, if you're the same in lots of other ways. Right. And so I think actual diversity where people are from different backgrounds, different demographics, different life experiences is much more likely to lead to true diversity and true different thinking. The trick is, or the difficulty is, that it's harder. And the reason that diverse teams are more innovative, are more productive, are more likely to be profitable, are more likely to succeed, is because it's harder, not because it's easier. It's because you're taking all these different inputs and different perspectives and then getting that group of people to be a team that still pulls in the same direction. And so, I think that that's why inclusion is so important. Is that just having people who are different isn't enough. You have to also make it so that they can be a really great team and they can be successful together. And in terms of more sort of specific advice, I think there's a model I use that I developed over the years, which is I think that people are asking themselves 3 questions when they're deciding whether to join, whether to stay, whether to say yes to a promotion, whether to to leave and go somewhere else. They're always asking themselves, usually subliminally, am I expected here? Is someone like me even meant to be here? Am I respected here? Are my features, are my differences seen as a feature or a bug? And then can I be myself and be successful here? Or do I need to spend a lot of energy pretending to be something that I'm not? And so I think that in terms of improving diversity and inclusion and the sense of belonging, that people feel at work, you actually have to take those questions in reverse order. So the first one is— the most important one rather is the third one, which, you know, can I be myself and be successful here? And so making it an environment where lots of different people can be themselves and still succeed is the litmus test for whether you've got the right to go and get those people who are different in the first place. If you're going to bring them into an environment where they have to spend all their time pretending to be whatever the default is, then that's not going to be positive. I think, am I respected here? People tend to evaluate at interview a lot. So, it's about how they're interacted with, what, you know, how their time is used, how the interviewers treat them, how people talk to them, you know, whether people make stupid microaggressions, like, you know, a lot of women engineers, they'll go for an interview and somebody will be like, oh, are you here for the design job? And there's nothing wrong with being a designer, but being assumed to not be an engineer just because you're a woman kind of sucks. But it happens over and over and over again, and it gets quite tedious that it happens so often. And then I think the "Am I expected?" one is about your website and how your company appears. I'll have companies come to me sometimes, they're like, "I just don't understand why we can't hire anybody who's not, you know, a straight white 23-year-old dude." And I'm like, well, the only benefits you list on your website are the foosball table and Beer Wednesdays. Maybe that's why nobody who's, you know, over 30 or a woman or anything else is not applying, right? And so I think there's something in that, am I expected, about just showing that different types of people are expected to be there. And what that means to you individually will be about what different groups you're a part of, right? So I joke sometimes, I'm the one the Daily Mail warns you about. I'm an immigrant with a job. I'm a woman working in tech. I'm queer and I'm disabled and I'm neurodiverse. And my wife is British, so I'm over here stealing their women and their jobs. But that joke is growing on her at this point. And so I'm different in all these different ways, right? I'm also white and I grew up in apartheid South Africa, so I've got immense privilege from that and immense opportunities that were offered to me because of the color of my skin that weren't offered to my friends who were born a different color. And so, do I have this sort of mental checklist that says, are they going to be okay with immigrants? Are they going to be okay with all these other aspects of who I am. To some extent, yes. You know, I'm looking for whether they refer to parental leave rather than mat leave and pat leave because it's a more inclusive term. I'm looking for whether the disability I've got means I can— sometimes I can walk and sometimes I'm in a wheelchair and sometimes I'm on crutches. I've never interviewed anywhere where I knew in advance whether I could get to the interview room if I was having a bad day and was on crutches. If you're a devout Muslim, you want to know if there's a prayer room. And so it's all of these sort of— they're quite small indicators, but somewhere that's put the effort in to make sure that it's clear on the website that there is a prayer room, that there is a nursing room, that there is the right kind of benefits for if you've got children and you've got dependents and you need to have healthcare and those kind of things. I think all of that, it's sending messages whether you plan to or not. What is there and what isn't there sends a message. And so people are always listening out for it. It's like a dog whistle.
Especially the ones which are tuned to listen more, which coming from that, effectively, different space, if I could call it like that. So let's say I open all the doors and I open all the windows, and that's, you know, that's the last question you ask. So, so the website, how we positioning yourself, our values, it's all there. So, you know, we open up the doors. Statistically speaking though, in your experience, the applicants you get, is it spread equally or you still have a leaning?
It depends on, on how you go out to market. So I think You know, we know that there are only 15% of women on computer science courses. And so, if you insist that all of your engineers have to have a computer science degree, then you're obviously going to get an 85% male pool of candidates at that point. And so, that's where being open-minded about where your candidates are coming from, making alliances with organizations like coding schools and similar to say, "Hey, it's just as good to take somebody who realized a little later in life that they wanted to move into engineering and they've learned to code and they come in. What I've tended to find is that you need to have your recruitment team spend almost all of their sourcing time very deliberately looking for the people that you lack at the moment. And with that strategy, with making partnerships with these, with meetups and organizations that are for the different kind of parts of diversity, whether that's you know, women in tech or LGBTQ or, you know, organizations like Black Girl Code, who obviously are doing great stuff for women of color and similar. I think if you put the effort in to go out and say, hey, we're a good place, we're really trying to be a great place for people like you, there's so few companies that do that that it actually makes a really big impression. And so, even though, you know, the stats tell you it shouldn't be possible, I've had organizations which were 30 to 40% women in the engineering team, because women in tech are like the future. We're here, we're just not evenly distributed. And so, as soon as you have some folks, and they're having a good time, and they feel like they can be themselves, they tell their friends, they tell their communities they're a part of, and you attract more and more people as time goes on.
Which is one of your probably main key KPIs as a leader, is to actually be, uh, talent attraction, or set up your business and, and your public image to be talent attraction. So I had the same challenges, and that's where actually that question is coming from. I wanted to increase diversity in a business which I, you know, joined, inherited, and, and that was lacking very clearly, but going to normal or casual or most common recruitment companies actually yielded quite low results. And statistically speaking, again, the applicants I would get would not be where I want to be. But then I found dedicated recruitment companies who specialize having, you know, a backlog of candidates which come in from diverse backgrounds, and that had a much better results and much better impact. So I think, you know, you're actually right. It depends on how you go to the market, what the roles you have. If there's conscious decisions, you know, or strategic decisions or placements being made to increase diversity, you will be more successful than just winging it and going like, yes, we want it, but at the same time we're not proactively doing anything about it. and we just, you know, going for these roles, well, for these talents. So, um, I want to talk about the return of investment, or maybe not a return of investment, but more of a, uh, how do you measure results of diverse teams? So it's not about returns of investment, let me, you know, scratch that, but it's more about here's a team I have and I know it's— it would benefit from this and this and that, and I go build that diversity within the team? And how do you go like, you know, here's a use case, let's say, back to the stakeholders, we should do that across the whole business if they are, for whatever reason, challenging your notion.
Yeah. I mean, I think you measure it the same way you measure any performance of a team, which is just, you know, are they able to set ambitious goals and are they able to meet them? I think in engineering, the DORA metrics from Accelerate are really helpful. Helpful to use to, you know, measuring engineering throughput and cycle time and time to review and so on. And very honestly, usually you can see that a team is performing better just from those metrics. And over time, I think you see an improvement in quality and an improvement in attention to detail and customer focus as well, when you hire the right people and put them together into the right team. But I think you're right, the unit of delivery is the team. The team is what matters and how they as a whole have those different aspects, those different perspectives is what really, really matters. And so, it's not about ticking boxes, it's about the actual value that comes from there being these different perspectives and each person who joins adding to the culture rather than just fitting with it. I think culture fit is important. It's important to make sure you don't hire people who will not work in the way that your company works. But I think a more interesting question is, how is this person going to add to our culture? How are they going to make us better than we were without them?
These are very healthy questions. I feel like when you go through interview process, people just go like, can you code? Here's a home test, you know, 'Like, do this exercise,' and then, you know, there's a chat at the end, which just seems so broken when you think about bigger picture, longer picture, and an actual performance of a team. And it still, you know, happens at scale in my experience. Do you have a situation to share, Mary, where you came in in a business and you inherited, again, a team, a couple of teams, and you went like, 'I'll need to do a proper diversity and inclusion work over here'?
Yes, 100%. And I think part of what people are hiring when they hire me is somebody who cares about that a lot. And so, I don't tend to join companies where they don't think it's important or they don't think it's worth investing in because it's so integral to my own values. It's such a big part of who I am and how I work that I, you know, I tend to take the roles where there's alignment at the company level that that's important as well. As well. But yeah, pretty much every role I've ever taken, there's been some kind of opportunity or some kind of need, whether it's on, you know, from an LGBTQ inclusion point of view or from a people of color inclusion point of view or from a gender point of view or a religion point of view. Like, I've never been anywhere that was fantastic on all of those dimensions, right? It's very difficult to find places that are fantastic at all of those But I'd like to think I've left everywhere that I, that I joined better than it was when I, when I got there.
I'm sure, I'm sure you did, Mary. I'm sure you did. And I love how you put it, that it's, it's not, you know, it's very hard. That's why it's not happening. You know, it's like nothing of value comes easy in life. So, you know, so the big Everest we want to climb, the most likely, you know, there's a much bigger value to gain So it's, you know, it's a very valid and real observation that it's quite hard to get this done well and in general at scale. But then if you do, there's so much benefit which comes out of that, which leads me to my next question regarding scaling that ideal, you know, team. So let's say you come in, you know, you have 8 people or maybe 20, which is still quite small number. So it's going to be quite easy to, you know, to get that picture in a much better shape. And, uh, you know, you'll get better results. Diversity and inclusion is there, you know, everyone's performing, the relationship is great, you know, we're setting values, everyone's getting the autonomy and the purpose and master, everything is working. But then now you need to sort of replicate that multiple times, you know, again, 20 people, again, 20 people, again, 20 people, at which point you start compromising on what you're doing with the teams? Because I imagine, you know, you don't have years and years to actually wait for the ideal candidate, so you need to make some trade-offs eventually. In your experience, you know, when things start changing, maybe culturally, maybe values start changing, when the picture effectively starts, you know, fading to some extent and becoming some new picture?
So, I mean, I think in an ideal world that the importance of that range of skills and range of experiences doesn't become less important. It actually becomes easier to achieve as you get bigger because one of the realities with startups is they are and they feel quite risky to people. And so, a lot of folks who are maybe in a diverse from some aspect, they know that the chances that they jump from the frying pan into the fire is higher, right? So, every time they make a change, there's always a risk that it's a much worse environment for them because we're not awash with fantastic environments for all kinds of people, unfortunately, in the tech industry. And so, actually, what I found is that as you scale and as you get bigger, it becomes easier to attract people who are different because there's now more chance that they're not the only one who's different. There's more opportunity to meet more people and to become more convinced. And it tends to be a less risky proposition, right? Very early-stage startups are a big risk and not everybody's in a position financially or emotionally or similar to take those kinds of risks. And so I've actually found that The bigger you get, the easier it is to prioritize this. And the more momentum you have as an organization attracting and recruiting people, the easier it is to then be picky. You've got more options, you've got more people applying in the first place. And then it becomes about keeping track of your funnel and watching for anomalies, right? So, if you've got, whatever, let's call it whatever it is, if you've got 50/50 at the top, if you're really, really lucky, you've got 50/50 in terms of who's applying gender-wise, for instance. If by the time you get to the bottom of the funnel, it's all men, something in your process is wrong because it's statistically super unlikely that you would end up with all men at the end unless something in your process was putting people off or filtering out the wrong people. And so some of it's about going, whatever the top of your funnel looks like, what does the bottom of your funnel look like? And then trying to get to a point where at least when you get to shortlist, it's a balanced shortlist. Because there's, there's some quite interesting research that shows if you've got one, just one candidate who's different, that one candidate who's different, they don't get compared to each other candidate. They can get compared to the sum of all the other candidates. Candidates. And it's really, it's impossible if you're, you know, if you're the one woman on the list and you're being compared to all the best aspects of the 5 men on the list, that's really, it's almost impossible for you to be selected. Whereas if you've got a balanced shortlist, then it's much more likely that you'll make a fair decision at the end of the day.
It would be good to read that paper. I mean, maybe we can put it to show notes if you have a link Now you put it, I'm trying to imagine, but yeah, it's interesting. So effectively, if you won out of, you know, 5, what you're gonna get compared, you will be compared over sum of all of the other candidates as best one. Okay, it's interesting. So I drifted a little bit in my mind, I was like, what was that, Mary?
I said it's almost like a binary search. Yeah, just are first deciding, do they want a man or a woman? And then they decide which one. And you don't want that to be the, the what's happening. You want them to be, to be deciding which candidates are good enough and then choosing from the good enough candidates who's the best one. And it's just a way of switching that, that around in people's heads.
I love that. I love that you made me think and lose sight of the conversation about this because I just went We're going through like a, you know, big hiring process right now. You know, we need to fill like 60 seats and there's a lot of interviews and you mentioned this and I'm like, hmm, how does our funnel look like? And my brain drifted a little bit. So thank you for that. You just made me think, which is always good on Friday. So looking ahead, Mary, what may be unique or new initiatives you have or planning to do to continue, you know, building and scaling high-performing teams? You know, is there something new within your toolset? Maybe you read, maybe you developed. It's like, you know, how's the Maddie's go-to looks like right now?
Yeah. So what we're running right now at Pleo, two things that I'm really proud of. One is a tech lead curriculum in partnership with a company called Skillawale who do this sort of very interesting diagnostic interactive training. So you do an assessment upfront about what you don't know and don't know, and then they only send you on the parts of the course that are most relevant for you. And then the course is basically individual, well, sort of small groups in live coaching sessions. And so I'm really proud of us doing that at Pleo right now. The other thing that we're investing in is we're bringing more entry-level folks back into the team. We'd had a couple of years of largely hiring more senior people, and we're just really missing that energy that you get from people early in their career. And so we took a cohort of 5 in at the beginning of May. We'll take another 5 or 6 in at the beginning of September. And we're basically bringing them in, and the first 3 months they spend embedded in a team, doing kind of a project of their own. And then after 3 months, they go off into a permanent team. So in the first 6 months, they'll get experience in a couple of teams, and they'll, they'll get experience with different parts of the codebase. And so we're really excited about that. And from a diversity and inclusion point of view, we've been really lucky that we've actually had loads of applications for those entry-level roles. And so we were able to, you know, we're able to find really fantastic candidates but we were also really able to find that mix of demographic. So, you know, there were 60% of the folks who came in in the most recent round were women. And, you know, if I can keep that happening, then as they grow in the organization, we'll end up with a whole bunch of senior women in time.
That's good to sound— good to sound— that's good to hear, Mary, sorry. So that's 3 different big things that you guys doing. And I love the grad selection as well. When you were talking, I drifted back to my own startup times, and we had a relationship with, with one of London colleges. And, you know, we were one of the companies they could choose. And, you know, we would go see what the grads are doing for the, you know, last job— another last job, but I forgot how it's called. But when they finish the studies, they have to present the project they did. And you would have conversations and you bring in the— there you go. And do you have a program for this? Like, are you doing that yourself or do you maybe use like a partner in between who says, you know, selects the grads for you?
No. So at the moment we cast our net really, really wide. So we don't only take people who are finishing university. We also take folks who've done coding bootcamps and people who are returning to tech from having some time out, whether they were parents for a while or switching careers or similar. And so, we've actually found we're lucky our profile is quite high. We actually, for the first 5 that joined in May, I posted about it on LinkedIn and it kind of took off a little bit and we got 2,000 applications for the 5 roles that we had. And so, we had this amazing amount—
Oh my God, 2,000.
—that was there to sift through. And then, we were We were really lucky to find some really fantastic folks through doing that. But, you know, we opened our role for the September cohort about a week ago, and already we've had hundreds of applications. So, I think there's just a lot of people who are very keen to get that early career opportunity at the moment. And maybe, I think, sadly, it's affected early career roles a lot, what's happened in the industry in the last couple of years. I think a lot of teams are going, "Well, can I really afford the time to coach and mentor and help somebody who's earlier in their career? Or do I just want someone who's going to come in at senior level and just be immediately a workhorse?" And I think it's a bit short-sighted. And it's problematic for us as an industry if we have these gaps where we didn't take people in and develop them up enough in the early years of their career.
Yeah, I fully agree. I fully agree, Mary. And it's good to hear you guys doing so well and, you know, having such a positive impact on the market, you know, positioning yourself as a, as a great company doing well, you know, you doing well as well. I enjoyed this conversation, Mary. Thank you very much for coming, you know, sharing your ways, sharing tactical advice as how people can go think about high-performing teams and, and the importance of diversity and inclusion for those teams. Thank you again for coming.
Thanks very much for having me.
Cheers!
More from Ben
How to Validate an AI SaaS Idea by Building It in a Weekend — with Richardson Dackam