[00:00:09] Speaker A: In that case, maybe you could get started by telling us just kind of about your story, how you ended up as CTO and how you ended up at playo. Sure.
[00:00:15] Speaker B: So I'm South African originally and I grew up as a hardware hacker. My weird claim to fame is I built part of South Africa's first satellite as a teenager. So I have great parenting advice which is don't let your kids do anything cool when they're young because I can never be as cool as my gawky 16 year old self. Soldered something that went into space. And then I came to the UK and studied computer science. And then my wife and I met at university and so I failed to go home. She's British and she's an architect, like a real one. She builds hospitals.
That takes a long time to qualify. So we ended up staying in the UK. I spent the first 10 years of my career at Procter and Gamble, so big corporate IT kind of job. And then I realized I was a little far away from the tech that I loved and wanted to be closer to the cutting edge, where I used to joke that maybe P and G was the healing edge rather than the bleeding or the cutting edge.
And I was going to go to Google or to Amazon and this guy called Tom Loosemore rang me up and said, hey, we're going to fix the government and we should. This is a once in a lifetime opportunity. And he literally called my friends and got them to convince me to join the government digital service, as it was called. And I built the team that built Gov UK.
So that went from 30 to 300 people in nine months, which was very intense scaling. And then I did a couple of other jobs after that and then landed as CTO For M&S.com, marks & Spencers, which is a retailer here in the uk.
I then went on to be CTO at MOO at Monzo, which is a bank here in the uk, a digital bank, then a company called Helix that did AI driven drug discovery. And then I moved to Pleo in November 2022. So I've been two and a half years in this most recent role. And this most recent role has been quite interesting because it's not a scaling gig like all my previous CTO roles were scaling the team to a greater or lesser extent. So the smallest was doubling the team, the largest was 5Xing the team. And Pleo has been much more of a efficiency play. So we've had about 250 people in the tech team, 200 in engineering, 50 in data for the whole time that I've been here and obviously some people have left, some people have joined. It's not exactly the same people, but with that team at a sort of static size, we're now doing 300% the volume of work and we're 40% faster than we were.
And so that's been a really interesting journey to be on to make a team better without having much opportunity to scale it from a number of people.
[00:02:45] Speaker A: Wow. And I'm curious about your experience going from Procter and Gamble to really more the startup side. Procter and Gamble's got thousands and you said that when you switched your team started at like 25 and then scaled it to 250, something like that.
[00:02:57] Speaker B: Yeah.
[00:02:58] Speaker A: How much fear was there involved in that decision?
[00:03:00] Speaker B: Oh, a huge amount of fear in that decision. I was so worried. I'd been at P and G so long. I mean I'd done a lot of different roles. I did probably seven different roles in 10 years and I had quite close to what would have been a 20 year career anywhere else in 10 years. And so I had a lot of breadth and I had a lot of depth, but it was an environment I knew really well. It was a lot of people I knew really well. A lot of people stay a long time at P and G.
One of my mentors who was my first director just left after 33 years in the company and she got all the way to senior Vice President. She was amazing. But it was this very stable environment. So. And I didn't know at the time, but I now know that I'm autistic and I've got adhd and that's a really interesting combination in terms of wanting structure but needing novelty. And it was super scary. And then it was particularly scary to go into government because government and being a civil servant has a lot of rules and laws around it. In the UK you're not allowed to have a political opinion, you're not allowed to express any political opinions so that you can work for whoever gets elected, essentially.
But I found that both weird and difficult and the scaling the gov UK team did was absolutely.
Ridiculous is probably the right word. You know, I had 80 direct reports at 1.80, not 1 8. 81 to ones a month is too many for sure. It was a great learning experience but a very intense period of time and, and a really important thing to do as well. We were, you know, we were changing the, the source of information for an entire country and that was both interesting and fascinating and very intense.
[00:04:42] Speaker A: If you could go back. Would you make the same decision of going from this big corporate stable job? Probably a little bit soul sucking but I imagine the money was better than the 25 person government startup.
Or would you go to the startup again?
[00:04:56] Speaker B: I would do it again. I loved the Gov UK team. I really enjoyed working with everybody there. Tom and the team who had done the alpha which was kind of proving that agile ways of working could be relevant for government had done this amazing job and then they kind of were victims of their own success.
The government then said yes, do it and do it right now.
And it became a very challenging deadline to get it done by but it was absolutely a great experience and it was a moment in time where everybody knew about the government digital service in the UK. Everybody in London was talking about.
Tim O'Reilly came to visit and said it's kind of weird that the most interesting startup in London right now is in the government was the thing he said at the time and it was a really fantastic experience.
The thing I would do differently is I was only there a year because I had a disability diagnosis at the end of that year I found out on the day of our Christmas party that I have something called Ehlers Dunlos syndrome. So all my joints dislocate and it's like a collagen defect so every part of your body's affected and so I think if I'd known that was going to happen I would have probably stayed in that more stable environment while dealing with that health stuff ahead of moving.
But then there was only this one moment in time where Gov UK happened so I don't regret moving and doing it at all.
[00:06:26] Speaker A: Yeah and that's one of those things you just can't predict, you just can't know ahead of time. So it sounds like you've kind of moved from say like really big corporate to smaller startup. Now it seems like you're in a say a mid sized startup. What's been your experience kind of going from the very big to the very small to the kind of middle size. What are pros and cons of each? Where would you recommend that people if they're say searching in their career go?
[00:06:48] Speaker B: I definitely found that very early where there's not yet product market fit or clarity on what good looks like I find very stressful and I think that's partly because I'm autistic and I need a bit of structure and I enjoy novelty but I'm overwhelmed by it being completely unstructured. And then I was always in a corporate Setting the kind of renegade. I was the one who was very different and getting things done in an unusual way.
I was the project killer. At one point I was who you sent in if a project seemed to be at the point that we might be throwing good money after bad or bad money after good, or whichever way around that saying goes.
And I would get sent in to either finish it or kill it. And so I think in a corporate environment I was a little bit unusual and then in a startup environment I'm a little too corporate. And so the middle point for me is this sort of scale up size series C and beyond where hopefully you've found product market fit, you've got an idea of what good looks like. It's now about either growing well enough or becoming profitable or one of those things. And so I think I'm not well suited to those early days where you're still pivoting every few minutes or months to figure out what great looks like. I'm better in that moment where you know what great looks like. And now it's about doing it, you know, better, faster, stronger, harder.
And that scaling part of the journey is something that I, that I particularly excel at.
[00:08:19] Speaker A: You mentioned startups going to profitability, so I'm curious in the UK or in Europe in general how common that is. So give some context on this question. In the U.S. once you raise, you're pretty much guaranteed to either die or sell. There's really no push to profitability for, I mean I would say the vast majority of this, I hate to put a number on it, but I would say more than 90%. Like if you raise you're going to sell or die, there's just really no room for that stable kind of profitable growth. Is that something that's more common in the UK or is that similar to what it is like here?
[00:08:49] Speaker B: So I think that there's definitely some people who just some companies that just keep on raising and keep on growing as fast as they as humanly possible.
But I think that increasingly we're seeing that move to profitability matter and wanting to see companies become self sustaining because if your only option is to either raise again or to ipo, you either want to have a really great growth story or you want to have a great profitability story because people are either going to invest in you because you're going to keep growing and be a growth stock or they're going to invest in you because you're going to kick out some profit and provide some return on investment for people. And so I think that the switch to profitability is increasingly important. And we've also just seen a lot of startups in Europe where investors later on have not treated employees and investors from earlier on very well.
Fanduel is a famous example of that. And so there's a sentiment that perhaps it's better to not be completely dependent on continuing to raise.
Having the levers ready, the dials ready to turn to get yourself to be profitable and get yourself to be self sustaining or if not profitable and at least cashflow positive are increasingly important.
[00:10:10] Speaker A: Do you think that's due to mostly macroeconomic trends or do you think that's cultural? Because I would say in the US that's not even so much the case. Like here it's in startups, it's all the growth story. There's. I honestly cannot think of a single startup I know, and I'm fairly well connected in the startup community who's like, we want profitability. Like, I mean they all want it, but like if they could take profitability or growth, they're going to pick growth.
So do you think that trend is like, am I just out of touch and that's due to macroeconomics, people are pursuing profitability more or is that more of a cultural thing? What do you think?
[00:10:39] Speaker B: I think it's a macroeconomic thing because I think that you saw a load of VCs when things turned a bit in 2122.
You saw a lot of VCs suddenly being like, this is what cash flow positive means, this is what profitable means, this is what EBITDA is. And so I think that there were just a bunch of VCs who flipped from being growth only and growth at any cost to being like, well, how long is it going to take for you to get to the scale where you're actually going to going to be profitable? Like, how long do you have to keep reinvesting everything that you're making into continuing to grow? And so I think I'd agree it's stuck a bit more in Europe than it has in the States. I think, I think the States have kind of returned to the previous operating procedure a little faster than Europe has. But there's also just more skepticism around startups generally in Europe. I think, like if you're in the, if you're in the Bay Area or in New York and you're an engineer, you definitely know somebody who's been able to pay off their house or buy a house because they were at a startup early and it paid off for them. There's Just not as many of those success stories. There's not as many people who are in a great position because they were early at a. At a startup in Europe, unless you're a. A founder. There's. There's not as many of the early employees who've had a good exit in Europe as you see in the U.S. interesting.
[00:12:07] Speaker A: Yeah. So I have kind of like two opposing data points in my mind. It's like one, every founder I know who's raised is not pursuing profitability at the moment.
The other, or if they are, it's a secondary objective to growth.
And then the second is that. So Turnkey who runs this podcast? We run a business that helps subscript subscription businesses lower churn, and we have seen a pretty massive uptick recently in people who are looking to do this because they want to get their profitability in line.
So I don't know, just two kind of competing data points in my head. But you're right, it's interesting. Like that kind of balance there. And I feel like my hunch is that Americans are a little bit crazy and that just in general, we're probably less concerned about the profitability and more about user growth or whatever.
[00:12:51] Speaker B: Yeah.
[00:12:52] Speaker A: But changing topics a little bit. So I would like to hear about your experience building Play doh. And in particular, I would like to hear what are sort of the pathways you follow when. So just for clarity, are you guys pursuing profitability right now? As a.
[00:13:06] Speaker B: No, we're still on a growth journey right now, so we're still not growth at any cost. Like profitable growth is the watchword at the moment.
[00:13:16] Speaker A: Okay, perfect. That's perfect. So I'm curious as to your thoughts on sort of how you build a product or how you build this sort of culture of profitable growth on the engineering side when you're in a fairly competitive market. So. And maybe I'm a little bit out of touch, but I would say finance tools is like fairly competitive. You know, I don't know for sure. Okay, so what are your thoughts there?
[00:13:38] Speaker B: I think from an engineering perspective, a lot of it's about staying close to the customer. And one of the things that's tougher with something like finance tooling is, you know, engineers are not naturally a version of the customer themselves. Right. They've not been in a finance team, they've not done month end and operations and these kind of things that matter a lot in terms of the users of the tool. And so I think I really like seeing engineers attending customer research sessions, attending customer calls, talking to the sales teams. About what's going well and what's not.
We have a bunch of insight that gets shared with, with everybody in the company, but I particularly care about engineers paying attention to it to understand those customer problems. I think the other side of it, the sort of, the profitable growth side of it, is for engineers to increasingly have some more commercial acumen. So they understand, yes, we could build this thing, but it would take away an opportunity for us to build something else that is really, really essential to customers. And we could probably buy this thing off the shelf or we could use an open source option, or we could use a SaaS product or whatever. And I think you're increasingly seeing that that business reality needs to be something that's front of mind for regular engineers on the ground. Not just for tech leads, not just for architects, not just for your staff engineers or your principal engineers, but like everyday engineers need to care a lot about what the customer wants and needs to understand the trade offs that are being made and why some things are being built and why something's being bought and what, what goes into those decisions. We're even at a point now where like all of my engineering managers need to understand the difference between capex and OPEX for reporting purposes. And that's not something any of them had any idea about even two years ago.
So it's very, it's much more essential for people to understand the business side of things and the customer needs in depth than it ever used to be.
[00:15:40] Speaker A: And I think this is probably a common problem. It sounds like it's worse on your side. Like if they have to learn capex and opex, that's okay, that's rough. But I think it's probably a common problem like how do we get our engineers to understand our customer needs? How are you guys solving that problem?
[00:15:55] Speaker B: So a lot of it is having people attend customer calls and listen in when our customer success people are doing work or our customer ops people are doing work. When I was at M and S, we had a, we were, my particular team that I was first in. We were building tools for the people in the call centers to use. And we would go physically three hours on a train every two weeks to go sit and watch people in the call center using the tool we were building. And nothing beats that. Nothing beats seeing someone struggle with the modal that you thought was perfectly obvious or the part of the UI that you thought made total sense.
And then you suddenly realize that actually these are expert users, they need a different kind of interface than an amateur user needs. They don't need it to be really intuitive. They need it to be really fast.
And I think those kind of insights come from seeing real customers, and that makes a big difference. So we encourage engineers and whole teams to attend customer research sessions, user research sessions.
We try to include our customers in our all hands fairly regularly in our board meetings. Sometimes we've had live CFOs in our CFOs who are customers in our board meeting for the board to kind of ask questions of on occasion. And that's a really cool way of keeping that customer perspective really like front and center.
[00:17:22] Speaker A: And how are you building the culture in your engineering team that they are willing to listen to customers? The thing is, it's one thing to say you got to listen to customers, and it's another to say to get them to want to or to be willing to. Those are very different of challenges.
[00:17:37] Speaker B: I think one of our core values as a company is to obsess about the customer, to really care about it. And so it's something we actually look for at the recruitment stage. And we tend to not hire the people who are brilliant engineers but don't give a shit about how the code is used.
We tend to hire the people who do care about making a difference in someone's life. Now, I think that there's always a difference in, you know, people's connection to the purpose of the company is at different levels of abstraction sometimes. Right. So some people, they want to be. They want to know that they're saving the planet or lives. Right. My wife's one of these people. She builds hospitals. She's literally saving lives. And she's not really happy if, you know, you couldn't Twitter, are working on an office block and get the same engagement out of it. And I think that the same is true that there are engineers who the first question they ask isn't what language is it? Or what's your architectural strategy? Or whatever. The first question they ask is, what does the product do? And do the customers love it? And I think so you start by looking for that at recruitment stage. You emphasize it by caring a lot about people's alignment with your values and your values, including that focus on the customer. And then you make sure that part of how you reward people includes them caring about. About. About users and. And how they actually use the product.
[00:19:01] Speaker A: Oh, interesting. So can I dig into that a little bit as far as the rewards? So are your engineers incentivized to listen to customers or. What do you mean there?
[00:19:10] Speaker B: Yeah. So when we decide whether somebody's going to get promoted. We we have four company values, one of which is focused on the customer. The others are like we make it happen. So teamwork, we build to accelerate, which is about scaling and building for the future and succeed as a team. And so when we're assessing whether somebody's ready for a promotion, they are assessed not just on what they do, but on how they do it.
And so you can tick all the boxes in terms of what you do and how fast you ship and how good your code is and what your quality level is like and all of those things.
But if you're not showing that obsession with the customer or you know, the ability to play nicely with others, or the willingness to get shit done, or the forward thinkingness to plan for scaling and for acceleration, then you're very unlikely to get promoted. And so it's very obvious all the way along that we don't just value what you do, but also how you.
[00:20:10] Speaker A: Do it and shifting topics a bit. So you mentioned kind of building and planning for the future. I hear a lot of AI hype from the engineering side and I get called an idiot every single time I've said this. But I have not found a lot of use case for AI in my marketing side of the organization. Every now and again I will have a data analysis project that I don't want to spend an hour on and I'll get a pretty decent result with ChatGPT or something. But I'm curious as to what's your experience been using AI on the engineering side? How are you preparing for the future? There's.
[00:20:41] Speaker B: Yeah, so I mean, I'm at a point now as a cto, I don't code very much at all anymore. Right. I'm leading a really few hundred people.
My focus is more on tech strategy than it is on the coding level.
One of the advantages I've got, I chair a conference called Lead Dev, which is a leadership and technology conference that runs in London and Berlin and San Francisco and New York.
And one of the real advantages of that is I get to see what the calls proposals say. Right. So all the proposals that people have sent in for the talks they want to give is a really good read of the zeitgeist.
And so it's been really interesting. We had a great talk at the London conference in June and from Birgita Butler, who's at ThoughtWorks, who for the last two years has just been focused on how does AI coding help deliver better software and is it actually helping with delivery? And we're Seeing moderate results, I would say. I think we're seeing 10 to 20% efficiency improvement. And people who thought that it was going to be 50 or 100% have definitely been proven wrong. There was a little bit of a flurry of excitement in the last couple of weeks. There was a study that said on a large code base that people were unfamiliar with, they thought it made them faster, but actually it made them 24% slower using AI versus not using AI, which was really interesting. And so I think that there's a lot of opportunity. I think it's really interesting. I think it's hit stay. I don't think we're going to abandon AI and never use it, but I think that some of the.
It's really shown that some people don't understand that maintaining software and extending it is much harder than. Than writing it in the first place. I think everybody assumes that because they can vibe code something in a half a day and it looks fine, that they'll be able to add to it and improve it and refactor it and so on just as easily. And I think we all find that Greenfield is really easy.
Maintaining and improving things long term is what's tough. And certainly AI doesn't seem to have all the answers in that regard yet. But I think we're seeing things improve. We're seeing reduction in the, you know, the level of wrong, if that makes sense.
There was a point where it was almost silly to trust any code that was generated, and now we're at the point where it's not silly to trust it, but it's silly to trust it too blindly. And so you have to be quite skeptical and you have to be willing to take a step back and go, do I really deeply understand what this is doing in order to go ahead with it. But then that takes away this whole theory that you could vibe code and never have to look at the actual code. And I just don't think that's the reality that any engineers are finding these days. I think if you're building something to throw away for prototyping, it's fantastic. And it's great that designers and product managers and similar can prototype so much faster and so much better now and have something that actually works. It isn't just screens, but I think in terms of it being, you know, reusable, maintainable code, you're still having to get down into the code level and check what it's actually doing.
And so you have to have some engineering understanding and capability to be able to do that.
[00:24:10] Speaker A: So Going back to that study where engineers thought they were doing better with AI but were actually doing 24% worse. What do you think is the cause behind that?
[00:24:18] Speaker B: So it was an interesting study because they were looking at a large existing code base and that is sort of historically the hardest thing to do, like dealing with legacy. Dealing with existing systems is always harder. Reading somebody else's code is always harder than reading your own. And so I think it's interesting, I think that what's really happening is that understanding code somebody else has written almost always takes longer than writing the code yourself.
If you already understand what you're trying to achieve, just if you're fairly proficient, just writing that is quite fast.
Whereas prompting and then re prompting and then re prompting and reviewing the code each time is actually just. It takes a long time and it might be quite engaging while you're doing it. And so it feels like you're busy, but it might not have the impact quite as quickly as you hope.
[00:25:12] Speaker A: Interesting. So I think perhaps with that in mind, I would be curious as to your thoughts for people who are maybe in their career facing problems. Maybe, maybe that's fear of the future, maybe that's personal problems, illnesses, whatever that might be.
Do you have any advice for people who are in maybe disadvantaged situations or even just struggling to kind of cope with the future? I think right now there is a lot of doom and gloom and fear, especially for engineering. Any advice towards them is kind of where they should be taking their advice from, how they should handle difficult challenges in life, so on.
[00:25:42] Speaker B: Yeah, I mean, I certainly wouldn't replace your therapist with ChatGPT, which is, sadly, something a lot of people seem to be doing. And quite worryingly, because I, you know, there's some cases, particularly for young people, where, you know, it seems to have encouraged people towards suicide and things like that, which is. Which is very sad and very troubling. The best piece of career advice I ever got was not anything around, you know, doing what you love or following your heart, art or any of that. The best piece of career advice I ever got was figure out what you can't stop yourself from doing and then focus on that. And that was the most useful thing for me because I could be good at a number of things and could enjoy a number of things, but there's a much smaller set of things that I'm very uncomfortable having anybody else do. And so figuring out what those things are that are your kind of unique specialism and then building your career around that is, I suppose, the most useful advice I've ever gotten in terms of when people are in a tough place and feeling overwhelmed by all the change, I think it's not just allowed, but necessary sometimes to step away. It's so easy to get burnt out in tech. It's so easy to end up overworked and freaked out by all of this change that's happening and struggling to keep up. And sometimes just giving yourself some time to recover and then coming back with renewed energy is. Is a much, much better strategy than just trying to force your way through and never taking a rest and never taking a break. And I know that there'll be people listening to this who knew me early in my career who are laughing their heads off because I would not have listened to that advice earlier in my career.
And so, so I know it's. I recognize how hard it is to take that advice and listen to it, but I still think it's the right thing to sometimes just give yourself time to recover and to get back to a balance point before you keep pushing harder again.
[00:27:43] Speaker A: Amazing. And is there anything that I should have asked you that I was too dumb to ask you?
[00:27:48] Speaker B: No, not at all. I think we're in the middle of a really interesting period, right, where we've got this big change in the macroeconomic climate. We've got, you know, the end of zero interest rates meant that capital is not as easily available. And we've got this real existential challenge in AI to a load of these tech roles that in the past have been very lucrative and very in demand. And so I think it's a really fascinating moment for us as an industry.
I personally think that, you know, I've got a good few years, if not decades ahead of me, of some of it cleaning up the mess AI is going to make and some of it making sure that we build products that really meet human needs. And so I continue to be excited about tech as an industry and a place to be, but I do recognize it's very uncertain times and very challenging times right now for a lot of people.
[00:28:43] Speaker A: Mary, thank you so much for your time. If people want to learn more about you or what you're doing, where should they go?
[00:28:49] Speaker B: So I spend a lot of my time on lead
[email protected], and I'm on LinkedIn. If you search for Mary Williams M E R I, then you'll find me pretty awesome.
[00:29:00] Speaker A: And right now you're at Playo IO. Yes, I am awesome CTO. Well, thank you so much for hopping on Mary. It's a great podcast. Really appreciate it.
[00:29:08] Speaker B: Awesome.
