Intro

Charles Humble: Hello, and welcome to this episode of GOTO Unscripted. I'm Charles Humble, a freelance tech editor, author, and consultant. Today, we're joined by Meri Williams, an experienced CTO and leader of technology organizations, currently leading the technology team at Pleo. They particularly enjoy helping others level up as technical leaders and managers through micro-consultancy  ChromeRose. They've led teams ranging from 30 to 300 people across organizations from Procter & Gamble to the UK Government Digital Service, , award-winning online print company MOO, mobile-first challenger bank Monzo and patient-inspired AI-driven rare disease treatment discovery company Healx, amongst others.

A published author and international speaker. Meri is the chair of the Lead Developer Conference and a tech advisor for Kindred Capital VC. And as if that wasn't enough, together with their wife, they run a  micro charity, One Goes Up to help young women and other folks pursue STEM education interests.

Meri it's so lovely to have you on. Welcome to the podcast. Thank you for doing this.

Meri Williams: Thank you so much for having me. I'm delighted to be here.

Charles Humble: So maybe you could start by telling us a bit about your story. What got you interested in computing in the first place?

Meri Williams: I'm from a household that's not scared of technology or maths. My mum's an accountant, my dad's a mechanical engineer. Very young I would take things apart and try to fix them or find things that my dad had taken apart and not gotten around to fixing, and then sort it out. I built my first computer from parts of broken machines, and so was a little bit of a hardware hacker as a kid. I was very lucky. I got involved in school with the universities, the local universities' project to build South Africa's first satellites as well. So started off in this electronics and hardware side of things, and then realized that was in the 90s and realized that software was where a lot of the really interesting work was happening at the time.

When I went to university, I decided to study computer science, came to the UK to the University of Bath, and basically failed to go home because my wife and I met at uni.

From Hardware Hacker to Reluctant Manager

Charles Humble: Fantastic. That's brilliant. So what was your reason for choosing to go into management? Because obviously you started as a hardware hacker and a software engineer, that would seem like an obvious place to be. And then, you know, he obviously moves as management. So why did you choose to do that?

Meri Williams: The honest answer is there wasn't a choice. Where I was at the time, at P&G, there wasn't really a route where you could stay an individual contributor and continue to level up in the organization. So, really very early in my career I ended up as a line manager. The first two direct reports I had were both older than my dad, which was a very interesting dynamic for us to navigate together.

They were very affectionately known as Statler and Waldorf. You know, the two old men in the Muppets who set up on the balcony and shout to everybody. But they were wonderful to work with. But I remember them being very skeptical about this new idiot manager that they had, you know, one in a long line of young idiot managers that they'd had until the first really major issue we had when I was leading the team, and they took me into a meeting room because it was all still in the office at the time and kind of went, this thing's broken. And I went, oh, shit, that means that's going to be a problem, right? And they kind of looked at each other and then unfolded their arms and started having a conversation and solving it with me, because I'd at least understood the implications of the problem. And that was a new experience for them, I think.

I basically had to move into management because I was very ambitious and wanted to keep growing and keep moving up. But at P&G at the time, they had changed this now. But at the time there was only really a move into management. Much later, you know, a couple of years ago, I found out I'm autistic. And that made it make a lot more sense why I found it so challenging to move into management. Because I think I found it a real struggle at first, and I'd had a couple of bad managers and really didn't want to be one. Didn't want to be a bad manager. I mean, I accepted that I had to become a manager, but I didn't want to be bad at it, and I remember just looking for any research and books and anything that would teach me how to do this well. If I was going to affect other people's lives, I wanted to be decent at it. And that's how my management story started. Quite often people ask me whether I do anything different in my career. And the one thing I would have done very differently is if there'd been a route to staff engineer, principal engineer, at the time, I think I'd have stayed in that mode for a lot longer before moving into management.

Recommended talk: The Path to Becoming a Senior Engineering Manager • Denise Yu & Jiaqi Liu • GOTO 2021

Essential Management Skills and Modern Leadership

Charles Humble: Interestingly, there was that period where, as you say, if you wanted to go more senior than that was only the management route, which is interesting. you mentioned that you'd read various books and things as a way of learning your the skill of being a manager. So are there particular books you found helpful or books that you would recommend now?

Meri Williams: Peopleware is one of the classics of the people side of software. My favorite management book, which I appreciate is a very nerdy thing to say, is First Break All the Rules, which is a book that came out of a huge study that Gallup did trying to find the highest performing teams. But it reads very much as a way to have happy humans who enjoy their work. It's got a set of 12 questions that predict high performance, and the 12 questions, of course, is far too much to remember off the top of your head. But I also like Dan Pink's Drive, where he talks about purpose, autonomy, and mastery.

Those 12 questions fit quite well into that framework of purpose, autonomy and mastery. And the missing bit, I think, is inclusion. So that's the recipe for creating environments in which great work can happen that I've been using for most of my career.

Charles Humble: Drive had a huge effect on me as well. I'd say it's one of those that it's a real classic for a reason. I think, Peopleware actually that's some really good stuff in there stoll. So when you're building on that a bit, when you're managing a team, how to match people to roles that suit their intrinsic motivation.

Meri Williams: My favorite of those 12 questions I just mentioned is, do I have the opportunity to do what I do best every day? And I think that's a fantastic question. But it's also a really interesting way of starting a team. If you start with what's everybody's individual superpower, what does it add up to? And then go, okay, well, in this team we have a spike of brilliance on this and on this and on this. What's missing? What do we need to find. And I think it's probably one of the real, even today, current challenges of management is how do you cast people in the right roles and how do you let them get the best out of what they're great at? And not spend all their time leveling themselves out to be mediocre by working on the stuff they're terrible at. But instead going from good to amazing.

One of my favorite things to do is there's a retro format, which asks what you liked, loved, lacked, and longed for. And I've used that as almost like a career coaching exercise with a number of people now. So helping them reflect on what they really enjoy about their current role, what are they missing from it? And what do they, not just miss but really ache to do more of, and that's a really useful framework, but also a very useful discussion to have with somebody. I think, and so I've tended at an individual team level to do those kinds of conversations and then try to form the picture of what the team's total capabilities now are, and then staff accordingly if there's any gaps at all.

Charles Humble: I love that I've not heard of that before. That's brilliant. What a fantastic question to be asked as well. I was wondering if you feel that the skills you need as a manager have changed as technology has got more and more central to organizations?

Meri Williams: Yes. I think we've got remote working much more now where we're collaborating across countries and borders much more now. I remember having a team when I was early in my career at P&G, I had a team that was partly in Manila, partly in San Jose, Costa Rica, partly in Newcastle and partly in Cincinnati, which already is a very weird combination of cultures To get something out of.

The default answer from the US is always an enthusiastic yes. And the default answer from Manila and San Jose is a very cheerful yes. But possibly not completely clear on what’s being asked for. And then the default Newcastle answer is a very cheerful no. I remember just adapting to this reality that the no from Newcastle meant we've got to talk about this, and the yes from Manila might have meant we should have talked about that more before we agreed to it.

I think that in modern management, being able to lead people who are different to you is really important. And not just from a diversity and inclusion point of view, but from reality that you're going to have a lot of people who are from different backgrounds and different countries and languages and not just the languages we talked to the computers in, but the languages you talk to each other as well, and so I think that ability to flex your style as a manager and as a leader is become increasingly important.

I also think that leading has become more important. I think if you dial back 20 years, management was a lot of telling people what to do. And usually people who were doing the same job you used to do, and it hadn’t changed that much. And I think the reality these days is that many of us are leading people and managing people who are doing jobs that we've never done. Whether that's because you've never been a system reliability engineer or you've never developed things for iOS or Android. You know, it's very common to be an engineering manager or leader who has people from different sub disciplines under you. But I think it's also increasingly the case that you shouldn't be telling people what to do and how to do it anyway. You should be enabling them to figure it out themselves.

So I think we've moved from this very directive, authoritarian kind of model that's proven not to work as well. It just is not sufficient context for you to be right about exactly what people should do and how they should do it all the time, into a much more creating the conditions for success kind of approach to things. Crafting that environment in which great work can happen, I think is a different thing than what a lot of people assume management is. When they think of a manager, people still think of the pointy head boss in Dilbert. You know, clueless and useless and practices the seagull style of management, flies in, shouts at everybody, shits on everything and flies away again. And that's not even a successful mode at all. I mean, it never was. That's why it's funny. But I think it's even less appropriate than it was 20 years ago.

Charles Humble: I think that distinction that you were making there between management and leadership is a really important one. So maybe it's a pull on that a little bit more. What are some of the other qualities you think you need as a leader?

Meri Williams: I think there's so many different ways to lead, but I think having, I like the axiom of strong beliefs and strong ideas loosely held. So, having an opinion, but being willing to change it based on data and other people's input. I think increasingly leadership is about influence. And I don't mean in the Instagram influencer way, but in the how do you help people understand where you're coming from and try to get them to see the challenges that you're seeing and to rally around them. So I think there's an element of having a vision, there's an element of being able to engage others and to influence others.

I think increasingly for technologists, there's an element of commerciality. I think we for a long time had a lot of technical decision making and technical strategy almost in isolation from the rest of the organization or the business. And we just can't afford that any longer. We're not in the boom times where you can say, well, yes, the business needs whatever, but technology is different. I think we're part of the business and part of the organizations that are in a much bigger way now.

Recommended talk: How to Take Great Engineers & Make Them Great Technical Leaders • Courtney Hemphill • GOTO 2017

Scaling Challenges and the “Big Tech Trap”

Charles Humble: I think that's something I've always found, that distinction between the technologists and the business weird and unhelpful. I mean how do you think you get paid? It's just that I always find it very odd. But you're right. It's been there for a long, long time. There's another thread that I want to pull on from something that you mentioned, and I mean something that I've worked through a few times in my own career. And it's those kinds of inflection points. So like around 100 people, it's a classic one where suddenly you go from an organization where everybody knows what everyone else is doing to an organization where that's no longer true. And a lot of times all of our systems and processes break down and we kind of have to remake things and it's as a founder or CEO,a really uncomfortable situation because suddenly it's like the nature of this business has changed. Now, given your experience with both large organizations, but also rapidly scaling at gov.uk, I was wondering what advice you have for people in that sort of situation.

Meri Williams: I think the primary advice is to look for somebody who's 12 to 18 months ahead of you and take their advice. It's very easy to look at the Goggles and Apples and Netflixes and the Amazons of the world, and they share a lot about what they do. And it's very interesting. But it's always so funny to me when you've got a 100-person or 300-person organization and they're going, oh, but Google does it this way. Yeah. What did Google do when there were 300 people? Let's talk about that. And I think looking for guidance and advice, and mentorship from the right people at the right time. I think it's really important. There's this desire for, when you hit that 100 or 150, which is Dunbar's number, there's a desire to fix it and then never have to worry about it again. And I don't think that's realistic. I think as you evolve, you get to new inflection points. The bigger that you get as well. I think what a lot of organizations end up with is roughly 100, to 150 people units that then can know each other and trust each other, and work well together. That then all replicated and grouped together in different ways. And that's one way to do it. But remember that those inflection points are going to keep coming. You don't get to redesign your processes once and then never worry about it again. You're going to have to keep an eye on these things, and you have to care about how you do the work almost as much as the work itself. In order to stay nimble and react well to those changes in circumstances.

Charles Humble: There's a related thing that I've seen happen, which is where the culture of an organization breaks down. And it can happen even in situations where organizations have been very deliberative about their culture. And you could try to hire to values and promote values. And I think it's because I think it's sometimes anyway, because organizations will sacrifice culture, maybe for efficiency, or maybe they stop repeatedly communicating what the values are and what's expected is maybe another reason. But do you have any kind of thoughts on that?

Meri Williams: I mean, famously Enron's values that were something very aspirational even whilst they were destroying everything. And so there's, I can't remember whose quotes it is, but there's some quotes about the values on the big posters on the wall. They're what you do every day. The standard you walk past is a standard you accept. I think it is the military version of that axiom. And I do think that it feels very HRy to articulate your values and hire against them and to use them when you're managing people to check that they're acting the way that you want them to act, but you kind of have to because if you don't, then you're not holding people to the culture. You're not holding people to the standard.

So I think you have to integrate it not just in your hiring, but in your ongoing management of people, in your ongoing leadership of people, you have to be like, even if you're a leader who gets a lot done, if you're an asshole to everybody, that's not acceptable. You have to be in line with our values as well as be effective. That is an important message. But I think it too often becomes quite bland at the point that people try to translate their culture into values. I think you want those values to still mean something to you. You want somebody to look at them and go, yes, that's something I like. I actively want to be a part of that. Or no, that's not for me. If that's how decisions are going to be made, I don't want any part of that. If you've got to be opinionated about the people to opt in or out, I think.

Charles Humble: I agree with that point. I think, and it's difficult. I mean, I worked for one organization on the exec team where we went through the process of trying to codify what the culture was. And it's really hard, and it takes a lot of time. And one of the reasons I think you can end up balndyfying - is that that a word? We know as we mean. That was a bunch of meetings this past is because trying to get a bunch of people to agree on what the culture is, in retrospect, is hard. But if it's working, it starts working as a filter, if you get it right, then you know, these are the things we believe in. And therefore, if you don't believe in these things, that these things don't fit, then we shouldn't be doing them. We shouldn't have those people. And I think that that's really important. I wrote an article on that, which I will try to link to in the show notes, if I can find it. But I think it's a really interesting aspect of that because obviously values have such a terrible reputation. We all kind of imagine a bunch of executives going off and on an away day and picking some words out of hat f, like innovation and customer focus or something, and “yes those all sounds like things we agree with”

Meri Williams: I'm a very strong believer that values should be verbs, not nouns, because I think as soon as you can articulate it as an action you need to take, or a behavior you need to show, it's immediately so much stronger than when you just have a standalone noun like innovation or integrity or honesty. Cool but like, what do you mean? What you mean comes out when you say, we value honesty and kindness, tells you a lot more than just honesty on its own or those kinds of things like being kind and fair is a much better instruction than just fairness and kindness alone. If you see what I mean.

Charles Humble: Yes, 100%. That's a very good point. Absolutely.

Recommended talk: How to Deal with Software Complexity • Gail Murphy & Charles Humble • GOTO 2024

The UI Trap for Small Teams

Charles Humble: You touched on this a little bit already, but I want to explore it further. You talked about looking at the large tech companies, the Amazons and Googles and Metas, and trying to replicate what they're doing when you're a 100-person company is probably not wise.

It's top of mind for me because I've spent a lot of the last decade of my career in IT journalism, and  in IT journalism you tend to focus on the new stuff and the big successful companies because that's what people want to hear about. But I think sometimes it's unhelpful if you're a startup or a smaller company trying to replicate Google is not the way to go.  Can you expand on that point a bit?

Meri Williams: The 12 to 18 months ahead of you is the example to look at. You're much more likely to find that amongst your competitors, your peers, other folks who have been invested in by the same investors that you've got. I see a lot of those investor communities are quite interesting now, CTOs from different businesses that they've invested in talking with each other, even if they're different industries. It can be really useful.

I also think there's just a need to figure out what problem you're really solving, which is especially good advice when you're in this scale-up journey because there are so many things to fix, so many opportunities to make things better, but which of them are going to be the most impactful? And how do you do them in a way that you know what impact you've had? It's very easy to end up with messy experiments where you've changed too many variables at the same time, and then you don't know what caused the failure because you messed with it too much.

It's very tempting with people stuff. It's super tempting to just change everything, and very difficult then to unpick what the outputs and outcomes are.

The complexity you're dealing with is so different when you're in a thousands or hundreds of thousands person organization, and when you have the level of customers that those organizations have. You can move a button and it will be a multi-million pound decision if you're working on Amazon's homepage. I don't think that moving a button is anywhere near as impactful if you're 100 person start-up. You wish for a world where moving a button could have that kind of financial impact.

The other thing that happens with these big companies is that they become more and more invested in tiny, tiny incremental changes and tweaks and improvements, where when you're earlier on, you should be focusing on product market fit and building something that will stand up if you are successful.

You don't need the resilience that Google needs. You don't need the complexity that a lot of these organizations have to deal with because you're not at that stage yet. You can get so swept up in trying to emulate all of these things that you lose track of what really matters, which is who your users are, who are your customers, what do they need, and are you able to give it to them? Are you helping them be better at what they do?

Kathy Sierra wrote a fantastic book called Badass, which is all about how what we should really be focused on is making our users more awesome at whatever it is that they're doing. I think it's very easy for us to lose sight of that, particularly in tech. We get focused on what the tech is and how it works and how it's all fitting together and forget that it's fundamentally just a tool. If it's not the best tool, it's not going to do the best. We have to do better at those customer needs, user needs, making sure that we're really, deeply understanding what someone is trying to achieve and then figuring out the best way to help them.

One of my favorite examples of how thinking needed to be turned upside down when I was at GOV.UK was there was a web page that showed the public holidays in the UK. Somebody went, "You know what? Probably most of the time somebody comes to this web page, they just want to know whether Monday's a bank holiday." The most important information is when's the next one. So they redesigned the page and put "the next bank holiday is Monday" at the top.

We measured the success of that part of GOV.UK on how quickly people went away from it again, which is a very non-classic website metric to have. Most websites want to capture you and keep you as long as possible so they can show you ads. Actually, for GOV.UK we were like, the longer it takes someone to find an answer they need, the less productive the country is. So sometimes we want them to bounce really fast because they found out what they needed and they left.

It was a very different way of measuring success and a very different thing to think about - this productivity of the nation and whether you were wasting people's time by telling them things they didn't need to know, or making them search in a page for the information that was most relevant to them. It taught me a lot about success metrics and how to think differently about what you were really achieving when you were designing those behavioral metrics.

Charles Humble: I think part of that as well is talking to your actual customers or at least trying to be empathetic. I have a vaguely parallel story from a retail banking project I worked on years ago where they had two banks that had merged, but they ended up with two separate mainframe systems. So if you had a current account and a savings account, they could be on two completely different mainframes. The way the call center worked was you passed ID and verification, and while that's happening, your details are looked up on these two green mainframe screens and the person in the call-centre could flick between two screens

The thing was that it was a learning curve like a brick wall because it was just two pages of incredibly cryptic acronyms. I asked my team if we could redesign it and make it really pretty, which we did, and it looked amazing. Then we took it into the call center, and they hated it. The reason was because yes, the old system had a learning curve like a brick wall, but everything was in one of two places. Once you learned it, you could answer every question and go throughcall really fast. That's the job.

What we designed was very fast to learn, but once you learned it, it wasn't particularly quick because you had to keep going and fetching stuff. It's just a really good example of thinking about the problem completely wrong, which I think is a really easy trap to fall into.

Meri Williams: I had a very similar example when I was early at P&G where we replaced a system that was largely just a very complicated set of interconnected spreadsheets, and replaced it with something where it was very easy to learn and very easy to navigate with a mouse. But everybody was essentially doing data input, and so they were immensely frustrated with it being so slow once we made this nice UI — it was terrible for them because they couldn't keyboard shortcut to the things that they were used to.

We had the same thing when I was at M&S . We built the apps that the customer service agents would use. A lot of people who have been longtime M&S customers ring up and they know the item codes. They want to just read you all of the item codes and then have you add all those things to their basket, because some people are still shopping that way. We had a huge problem because you could only search for one thing at a time. The most impactful thing that team ever did was to make it so you could put in 12 search terms and it would deliver those 12 search results rather than making the call center agent do them one at a time, which was just an incredibly frustrating experience for them and for the end user. It happens so frequently, doesn't it?

Charles Humble: I love the way this bit of the conversation has gone, because I think so often we spend a lot of time focusing on the positives. You're clearly someone who cares a lot about being a good manager and doing the job well. But I think so often actually the things we learn are from the mistakes that we make, but we maybe don't always talk about those. 

Recommended talk: Lizard Optimization • Gojko Adzic & Dave Farley • GOTO 2024

The Hard Way: Learning to Lead

Charles Humble: Are there things you've got wrong along the way as a manager that might be worth sharing?

Meri Williams: Hugely. One of my biggest mistakes as a young manager was just completely misreading a cultural difference. It was someone who everybody around gave feedback that they came across as really arrogant, and they weren't listening to other people. It was actually an immensely insecure person and it was all bravado. I just didn't see it. I couldn't see that that's where it was coming from. So my coaching approach and my feedback approach was completely wrong; it broke them rather than helping them. I regret it to this day. It was really unhelpful that I didn't spot earlier the underlying reason for their behavior.

I’m proud of beng at Monzo but I  think I really messed up for most of my time there. I came in and was worried about the wrong things, couldn't understand that it was an organization that didn't have budgets figured out yet. It was just like, if you find a good engineer, just hire them. I was like, "But how? We have to have some sort of plan for how many we need, don't we?"

I think I was a little too early for the stage that we were at because I know myself quite well now and I'm good at the point where you know how to make money and now you need to do it faster and better. I think the earlier stages than that, I'm not as good at. I'm just not as good at finding product market fit and exploring your way to a great product. I'm good once the road is clear - the direction is clear, now it's about going there fast and efficiently. That's much more than my speed.

I joined Monzo at a point where we were still figuring out how to make money and how to be great for customers, but weren't necessarily great from a unit economics point of view. We kept thinking that we were unit economics positive and then turning out that we hadn't factored in this part of customer service or this cost or whatever.

I think I annoyed the hell out of Tom Blomfield when I was there because I was the whole time searching for structure that didn't exist and wanting certainty that didn't exist and not being able to deal with that. It actually led me to discovering very late in my career that I'm autistic and ADHD, so doubly neurodiverse. But partly it was because I struggled so much in this environment where there weren't the structures and guidelines and guardrails that I was used to having, whether that was budget or profit or super clear strategy or whatever else.

Charles Humble: That's fascinating. Thank you for sharing that. Something else that I seem to be spending a lot of time arguing with one of my clients about so I’m going to throw it in is around onboarding. I have this idea that investing heavily in onboarding is a really good thing to do. I was just interested in your perspective on that. Do you agree with me? Am I talking nonsense?

Meri Williams: I agree with you wholeheartedly. I think it's one of the highest leverage things that you can invest in. Not least because we have 3 to 6 months, you don't really get longer probation periods than six months. And it's not appropriate to have somebody unsure of themselves for that long anyway.

The shorter the period of onboarding, the better chance you have of seeing how somebody really performs. It made a massive difference at Monzo, where we went from it taking 6 to 8 weeks for people to be fully productive to getting it down to four weeks. That meant you got two, four months of performance to assess in their first three months. That was insanely valuable for us.

Especially when you spend so much time recruiting, you really want to have a clear view of how somebody is going to perform well once they’re in role.Making mistakes in probation is so much more risky and so much more devastating than making a mistake in hiring. It's okay if somebody doesn't work out, they can leave it off their CV and never speak of you again. But if it takes you six months to figure out that somebody is not a good fit and they're not going to perform, then a series of six month stints on your CV isn't good for anybody. It doesn't look good, it doesn't feel good, it isn't positive for the organization because they've invested so much in getting somebody up to speed and then found that they're not going to be able to stay and contribute.

I'm a big fan of investing in onboarding. I love it when you can have people join and have something in production ideally on their first day, but worst case their first week. I think that's worth investing in your processes, in your CI/CD and those kinds of things for the technical aspects to be easy, and your environment setup on your dev machine and those things.

But it also just pays off so well in the health of the organization over time, provided you're adding enough people. I think if you add one person a year or whatever, there's some percentage of change in staffing that I haven't figured out what the exact number is, but there's definitely a number where it's immensely worth investing in onboarding.

But a lot of people don't realize they should have invested in onboarding until a year after they hit that scaling inflection point where they should invest. They only realize a year later that they had half the team that were less than six months in role, and it takes six months to get useful. So we had half the team that weren't useful. That's a terrible situation to be in.

Diversity, Inclusion, and Building Better Products

Charles Humble: I want to change tack a little bit. I'm curious to ask you how you feel about DE&I, given what's happening in the world at the moment. I slightly hesitate to ask this question, but if I were to...

Meri Williams: I joke, but I'm the one the Daily Mail warns you about. I'm an immigrant who took a job. I'm seen as a woman by a lot of people. I'm non-binary, I'm disabled, and I'm neurodiverse, and I'm queer, and my wife is British. I'm over here stealing your women and your jobs. I'm the devil incarnate

But I grew up white in apartheid South Africa, so I'm also very aware of unasked and undeserved privilege. I had all these advantages just because I happen to be this kind of pale.

I think it's incredibly important that we're representative as an industry of the people that we're serving. We can't build great products and great companies if we don't understand the people who are going to be our customers. As long as those customers are a wide range of people from all different backgrounds and cultures and creeds and genders and whatnot, then we have to represent that in order to build great products.

I think it's particularly important for tech that we don't go along with the devastation of inclusion that's happening in the US right now, which is very worrying on a historical scale worrying what is happening right now

I've just seen it play out in my career so many times. When I was at Monzo, there were some early engineers who were trans, and they shared with their peers how awful it was when somebody called them by the wrong name or by the wrong gender. Monzo, to their credit, the person who led security and identification went, "Well, that's crap. Surely we can figure out a way around that."

Monzo, to this day, is one of the few banks that will never call you by your dead name, will never say "what's your real name?" Sometimes they need a document that might have a different gender and a different name on it, and they just go, "Cool. Can we get your official documentation and then tell us what you want to be called and we'll make sure we never get that wrong." I think if those early engineers hadn't been there and hadn't felt safe to share and hadn't talked about it with their colleagues, it would have been another bank that just is an awful experience for trans people.

A much simpler example was when we started working on savings at Monzo. There was one engineer who was a bit older and had kids who were doing their A-levels at the time, and she was the first engineer who could explain to the others why you might want to lock your savings up, because everybody else was 24.5 and didn't have any savings. They were like, "Why would you need a fixed term account? Why would you lock your money away for 12 months?" She was like, "Well, because it's for my kids' uni, they don't need it till they go to university, so why wouldn't I lock it away to get a better rate on it?" It was almost funny how much of an lightbulb moment it was for the other engineers in that situation.

I just continue to think that we have to be better in tech because we are comparatively such a small group of people who then build things that such a huge group of people use. It's the model of what we do as an industry. We have to be representative of those people in order to build the right thing for them.

Continuing to only have teams that are white or like Apple Watch famously when it first came out, didn't work if you had tattoos or darker skin, the pulse features didn't work. We just shouldn't be in a world where that can still happen, where you can get something all the way through to being launched and out in the world and not work for 80% of the population. We are a global minority whether we want to think of ourselves that way or not. We just have to get better at this stuff.

I think there's a lot of fear and uncertainty and dread at the moment about the whole DE&I topic. But equally, you wouldn't guess it from the headlines, but 60% of companies are spending more on DE&II this year than last year. We're just not having that conversation at all because it doesn't fit with the rhetoric that's coming to us politically.

Charles Humble: I think it's such an important point to make. I see this a lot when a particular narrative takes hold, and anything that doesn't fit the narrative we don't talk about, but actually so often the narrative is wrong. You see a lot with environmental stuff, which has been big area for me for the last couple of years. If you just read the newspapers, you think everything is terrible. But everything isn't terrible. Real progress has been made and continues to be made. It isn’t that things aren’t terrifying, it is, but things are much better than I thought they were a couple of years ago, but we don't talk about that.

I do have a related point, which is that I've seen organizations put an unreasonable level of pressure on the minority folks within them to fix stuff. I was just wondering if there were particular anti-patterns that you'd seen in the context of DE&I that we should be aware of?

Meri Williams: A huge one is assuming that the people who are affected are the ones who need to change, when in reality racism isn't coming from people of color. The day to day problem is where white people mostly are who need to change how they act and how we behave and what we do. In the same way, sexism isn't women doing things against each other.

I think you're right. I think it too often is a second or third job for people in those minorities. I think one part is it's good to have ERGs, employee resource groups or active communities, or there's a lot of different terms for them, but they have to be supported and they have to not have a load of work put on them. The answer to every question can't be, "Oh yes, why don't you do that?"

Early in my career, I was part of the first LGBT network that P&G had outside of the US. I remember we had to put the world map off Wikipedia with LGBT rights up for people to understand that there were still more places where we would be put to death than where we could get married. At the time, this was in 2002, and it made a whole bunch of people realize that actually, maybe this was a work related thing. There were a lot of people at the time who were just like, "Why do you want to talk about who you sleep with at work?” “That is not what we want to talk about."

So when you want to send me to Singapore for my next assignment, and Singapore literally has the death penalty under Sharia law for people who are queer, I don't feel safe being sent to Singapore for a few years, and we have to have that conversation in my career chat at some point. It's not a choice. You want me to go to Cincinnati for an assignment? I'm perfectly happy to do that. But America doesn't recognize my marriage to my wife, and so I'm going to have to leave her behind if I go to the States. That's a work-related thing. We have to talk about it.

I do think that on the one hand, you get people who are passionate and they want to bring that passion. We owe them protection against burnout and to make sure that we're putting our money where our mouth is, and really taking on that work collectively. There's the "nothing about us without us" saying that the LGBT community has. I think consultation really important, but putting all the work on those folks is not the right thing to do. But it is very common that that's the case and it can happen despite the best of intentions.

If you want to make sure that every engineer is interviewed by a woman, but you've got very few women in your team, you certainly, as a woman engineer in the team, start to feel like half your job is interviewing because you're who the people team calls on every time. That's not coming from a good place. We want to make sure we don't hire anybody without the opportunity to spot if they're really biased against women, because sadly, that's quite common in the engineering world. But you don't want it to become half the job of somebody who fundamentally wants to be technical and wants to be building things.

Charles Humble: That's really insightful. Thank you. We're coming to the end of our time, so I want to change tack a little bit. You're currently CTO at Pleo, but you're also an advisor to a number of companies, you're chair of the Lead Developer conference and so on and so on. What is it you like about having lots of different roles at once?

Meri Williams: I think my ADHD diagnosis shouldn't have been as much of a surprise as it was. Looking back, I was pretty sure I was autistic because I've managed so many autistic people. I was like, "Yeah, there's some definite similarities here." Then the ADHD diagnosis was completely out of left field for me. But I remember taking the meds for the first time and telling my psychiatrist, "I didn't know my brain was noisy until it went quiet."

My brain has 100 open tabs at all times with no choice about which tab is in focus. The meds let me choose which tab is in focus and lets the others fade into the background. It's a very interesting thing.

But I think where it came from originally, just doing lots of things and I've always done lots of things. When I was at school, I played sport, I played hockey and water polo and I did athletics and I did theater stuff, and I did computer club and whatever. Something in my makeup means that I always need something to be urgent. If you're busy, if you do enough things, then something is always a priority. Something's always urgent. If you're very urgency driven rather than importance driven, which is quite typical when you've got ADHD, it's a lot easier to just have a lot on and then there's always a pipeline for something urgent.

That works well. Advising at Kindred, which is the VC I advise, I've particularly enjoyed because I've gotten to meet so many and see so many different companies in their journeys and see them as they scale. That's been super interesting. More recently I've started doing board roles as well, and that's to some extent a bit of a retirement plan. It can be a successful strategy to start doing a series of board roles rather than a full time exec role.

Although every time I head in the direction of doing fewer things and consulting a bit more rather than taking a role, I then miss having my own team. I'm terrible. I tend to go back and forth between being permanent and being a consultant quite regularly and quite predictably.

In retrospect it was all about just needing to have things be urgent all the time and being busy enough that something was always urgent was successful for me. I learned very early how to context switch very efficiently. I've always been able to go from one thing to one minute between meetings and I'm on a completely different topic and it's totally fine. It doesn't discombobulate me at all. I think that that's been a useful skill.

Charles Humble: Do you have any other advice around that sort of work life balance? Balancing presumably a very demanding CTO role with all the other things that you're doing. How do you do that? I mean, I've been a CTO and the idea of being a CTO and doing anything else would be totally beyond me.

Meri Williams: Because of disability, I work a four day week and that really helps. I have an opportunity to rest, which helps a lot. I also just very early in my career, got used to doing quite long days. I'll do a normal day at Pleo and then I'll have an hour or two in the afternoon or sorry, in the evening, where I'll do other things, whether it's the advisory roles or assessing new companies or the conference stuff that I do.

But I think the overall work life balance has been positively impacted by me realizing that just doing nothing wasn't very restorative for me. I have found that for whatever reason, I need to do a thing that is restorative rather than trying to just rest. Video games, building really complicated Lego, when I'm in the sea whenever I can be. I love snorkeling, I love underwater, and I love underwater photography. Mostly because if I take a camera with me, then I can pay attention underwater for much longer because I get focused on taking photos of things rather than experiencing it as just being in the water for a very long time. I love scuba diving as well.

That's been the big unlock for me - realizing that I needed some sort of active restoration rather than just to not do things. Trying to just not do things when you've got your brain so busy with really complex and complicated and challenging problems, which is what a CTO role is very much like, is important.

Because I think I used to just go, "Oh, I'm exhausted. I'll just watch TV for the day or I'll try and read a book or whatever." I was just - my head was still worrying about that meeting on Friday or that executive presentation I've got coming or this board presentation that's coming next.

Figuring out what active rest and active recovery looked like was super important for me and has made a huge difference. But I've done my last four CTO roles four days a week. That's been transformative for me. But as I say, partly as a sort of disability adjustment and partly because I've just found that that schedule works. It works much better for me, but I don't think I do 80% of the role. I think I do 100% of the role for sure. I just do it slightly differently.

Charles Humble: I'm genuinely kind of blown away by how well you seem to know and understand yourself as well. It's just like, I don't know how to put it. It's just like, it's a really unusual thing to speak to someone who just has such a clear understanding of, this is what I need, and this is how I work, and I just find that kind of mind blowing.

Meri Williams: To be honest, some of it has been forced. About 15 years ago, I got a disability diagnosis where I've got something called Ehlers-Danlos syndrome, and all my joints dislocate, which is very painful and not very fun. I wake up every morning with dislocated joints and put them back in place before I can get up and do anything.

That was horrific at first, and I tried to just keep misioning through it. I used to work horribly long hours and I was humbled by it. It broke me. I've had to learn all of that stuff and had to learn how to be effective and how to be successful despite having a body that kind of betrays me a bit. I wouldn't necessarily recommend it, but it certainly teaches you a lot about yourself when you hit a brick wall and have to adjust to it.

Charles Humble: One last question. What are the things that excite you most from a technology point of view at the moment?

Meri Williams: I think everybody says AI. I'm excited at all of the messes I'm going to get to clean up because people think AI can do all their coding for them now. I made a career out of dealing with legacy. I joke sometimes that I've dealt with so much legacy older than myself. It was so legacy it was vintage.

I think there's going to be a lot of tech debt that's produced in the next couple of years because we will put code in production that we don't fully understand because it's been written by an LLM. So I think I'm excited about some of the side effects of the current AI craze, in a weird way.

But actually, I think how much cheaper and greener compute is becoming is going to be very exciting. I don't think LLMs are going to lead to generalized AI, for a variety of reasons. I'm from an AI background, so I have quite strong opinions about all of it.

But I do think that there's going to be some real upsides to us making technology much, much greener, much lower impact on the planet, both in terms of initial production but also in terms of ongoing running and maintenance. I think if Gen AI gives us one thing, which is immensely cheaper and greener compute, then I think that might be a really good thing for the long term, for the planet and for the industry. So I'm quite excited about that.

I'm excited that we're getting better as an industry at management and leadership. It's part of why we started Lead Dev - there was just no... I talk about it sometimes as a leadership conference disguised as a technology conference. We've always had three themes, which are team, tech and tools, and they always looked like they were sort of equal themes. But really the team bit was about 50% of the time, and the rest were a little bit less.

It's been wonderful to see that community grow and not just because the conference grew, but the community around it grew, because there's now just so many people who don't just want to be forced into management and be terrible at it, but actively want to be good at it, that realize that they can be multipliers. They can help 10 or 12 other people be the best they can be. It's actually a really rewarding role.

It's not quite the same dopamine hit you get from all your tests passing and pushing something to production multiple times a day. It's a much longer reward cycle for developing somebody and getting them promoted or getting them a new job or seeing them really excel. But it's still really exciting. I continue to be heartened by how much better we're getting as an industry at the management and leadership side of things as well.

Charles Humble: Meri, that's a brilliant place to leave it, I think. Thank you so much. I has been an absolute  joy to speak to. It really has been, thank you so much.

Meri Williams: Enjoyed it. Thank you so much for having me.