We're joined by the incredible Sarah Wells. Sarah's most recently worked as Technical Director for Engineering Enablement at the Financial Times, where she spent the last 11 years leading tech teams as well as defining the tech strategy and product roadmap inside the FT. Sarah's also a frequent conference speaker presenting on topics ranging from microservices to engineering productivity.
In this episode we discuss Sarah's experience of working at the Financial Times, learn the secrets behind successful Engineering Enablement, and learn how to create a Golden Path. Sarah also shares how the FT increased diversity in tech plus shares some great new book recommendations.
Listen on your favourite podcast provider.
Scroll down to read the full transcript of our chat with Sarah
Sarah's quick fire answers
Sarah frequently recommends Accelerate, Team Topologies, and The Manager's Path, all firm favourites of Human+Tech guests. She wanted to recommend us something new, so Sarah's top book recommendations are Inside the Nudge Unit by David Halpern and The Checklist Manifesto by Atul Gawande.
Twitter is Sarah's favourite way to keep up with the industry.
She's inspired by Tanya Reilly for her amazing storytelling abilities and for her blogpost and talk on glue work.
Sarah is a keen home cook. She's recently been cooking from the Every Grain of Rice cookbook.
In this episode we cover
- Highlights from Sarah's time at the Financial Times [00:1:33]
- The power of a sponsor, and how to set up successful sponsorship relationships [00:05:13]
- Asking for what you want [00:10:12]
- Sarah's experience of moving into directorship [00:13:49]
- How technology contributes to the success of the Financial Times [00:17:44]
- Chart Builder - a tool to allow journalists to turn spreadsheets into FT charts [00:19:08]
- The Golden Path; how to create a paved road that engineers want to follow [00:23:31]
- Biz Ops service registry and how it came about [00:29:31]
- How a bot helps with DNS approvals [00:35:42]
- On when to set up an Engineering Enablement team [00:37:33]
- Achieving greater diversity - how the FT teams became 35% women and non-binary [00:41:00]
- Sarah's upcoming book on enabling microservice success [00:47:59]
Find out more, and follow Sarah
You can follow Sarah on Twitter @sarahjwells
Full transcript
Aaron Randall 0:01
Welcome to the Humans+Tech Podcast. I'm Aaron Randall and this is Amy Phillips.
Amy Phillips 0:05
Hi.
Aaron Randall 0:06
And today we are so excited to be talking to the incredible Sarah Wells, Sarah's most recently been technical director for engineering enablement at the Financial Times, where she spent the last 11 years leading tech teams as well as defining the tech strategy and product roadmap inside the FT. Sarah's also a frequent conference speaker presenting on topics ranging from microservices to engineering productivity, Sarah, welcome to the show.
Sarah Wells 0:29
Hi, there, it's a pleasure to be here.
Aaron Randall 0:32
Awesome. So great to have you. And one of the things that we'd like to do for all of our Humans+Tech guests is to draw a doodle of them. And I'd like to show you yours and kind of get your thoughts and feedback now.
Sarah Wells 0:43
Okay, go ahead. I have been I've been looking at the other ones and wondering what this is gonna look like, Oh, boy.
Aaron Randall 0:48
Probably very similar.
Amy Phillips 0:52
Looking here for your, your critique.
Sarah Wells 0:57
I think I look like Meri Williams, I think there's a thing about like, dark hair and glasses where you just always end up looking very similar. It's the most distinctive thing.
Aaron Randall 1:13
That's probably, yeah, they're all pretty, pretty generic all pretty much the same. But yeah, no, I see that. I see that as well actually nice. Well, moving on to the important stuff in so you know, as I mentioned in that intro, you have worked at the Financial Times for a long time, 11 years, and that's a really long time to work in one place. What were some of your highlights?
Sarah Wells 1:33
Ah, well, it is it was a long time it what's interesting about that is I did several different jobs there, which I think is what kept me there for so long. So I probably did, did about four different jobs, all for about three years. Some of my highlights Well, I mean, I joined as a senior developer, and when I, when I joined the Financial Times, I'd been working in IT for about 15 years, I've pretty much been a senior developer the whole time. So I, I was a career changer. So when I started in IT I very quickly started running a team, because I was really experienced in terms of that kind of side of work, I think. And so I've been, if you look at my career, it's like this very sort of steady line of I do this job, I run a tech lead. So the FT was the first place where I had the opportunity, and people encouraged me to step up. So it's a real big change from being a senior developer to being a technical director. And at every point, people would say to me, you know, you can, if you're interested in doing this next thing, you definitely could do it. And then the other thing is that there'd be a problem that I wanted to solve. And the best way to do it was to, was to step into a role that allowed me to, to have more kind of ownership of it. So so the highlight probably is a complete different, like career path, because I'd never really thought before I joined the FT that I could see myself being a technical director. Beyond that, actually, there's, if you want, basically, when you leave a company, and the FT is a, because it's a newspaper, one of the really nice things that sometimes happens to you when you leave, particularly if you've been there for a long time is that they create a front page for you. Which is like and I was really super lucky because they even printed it on FT paper. So I've got this, like page of the FT that that, that people, you know, told stories and mentioned things that I'd done. And a lot of them is like pointing out silly things. But you do kind of go Oh, yeah. So one thing would be the FT's internal tech conference called Engine Room. And that's been going I think, for seven years now. And I helped set it up in the first place helped run the first one, I've run two or three of them. It's very established part of the engineering culture there. It's changed from year to year. But I particularly enjoyed it in 2020, and 2021. Because we basically had to go online and really made a like made the most of that. You know I felt like we managed to gain from the ability from moving away from having to book the conference suite to being able to do it online. There would be lots of people talking, there would be loads of chat in the sidebar in any you know, in meet, it would be be great, but it's something that some that's helped provide an opportunity for people to share what they know and to try out being on a panel, try out speaking. It helps set the culture of the department and it's something that I always think is a really powerful, powerful thing. So I think that's something I'd consider to be part of the legacy for me at the FT is that I mean there's tons of other things I could talk about, it's like, you know, I feel like I can look back at what I was doing when I was at the FT and see, see an impact, which is just really exciting.
Aaron Randall 5:12
I love that. You mentioned there as well, at the beginning about having people in the FT encourage you to step up. Is it fair to say, you had advocates or incredible managers that are really supportive and helping you to sort of develop and grow.
Sarah Wells 5:26
Yes, yes. Yeah. I mean, yes. But also beyond that, as well, because I think there's something really powerful about someone senior who's not actually day to day responsible for for you as a manager, saying, oh, you know, you could, you could do this. So, so one kind of, I think a real sort of impact for me was when Cait O'Riordan, who was the CIO, approached me actually at the Christmas party and said, I want to mentor you, we're gonna have a mentoring discussion in January. Okay, we actually had only had one at the time. But she basically, it was really succinct. She just said, I want you to know that if you want to be a CTO, that's, that's something you could do if if you want to, and that there are different types of CTOs. So if you were CTO, you wouldn't have to look like our current CTO. And at the time, I was a principal engineer. So it's two steps from there, tech director, CTO. So, actually to have someone say, not just you could do the next job up, but actually to say you could do the job two above that. I couldn't believe the impact it had on me. Because it wasn't something that I even remotely had thought about. And, actually, there was quite a nice culture, I think, at the FT of people, sponsoring people. And I, probably about five years ago, I got sent on a, an internal program called Talent Acceleration program. But basically, they identified women who were about to step into leadership positions across the FT, it wasn't a tech specific thing. And we got sent on some training about things like building your brand, how to be resilient. And one of them was about sponsorship and mentoring. They talked about that. And it's that kind of really important difference between the two. Because you know, people always talk about mentoring. And Lara Hogan says, you know, that people are over, women particularly, are over mentored, and under sponsored, it's really easy to say I'm going to mentor you. But actually, the thing that matters is, does someone go into a room and say Sarah could do that? And particularly do they say Sarah could do that when every other person who's ever done it looks different from me. And that definitely happened to me, at the FT. And actually, after I had been done this training course, I realized that I did have a sponsor, quite accidentally, and you don't go and ask for a sponsor, you kind of attract a sponsor, and the sponsor sponsors you because they can see that you can do something, they can see that you're going to deliver something that they need that you know that they are betting on your ability to do something. When that sponsor left the FT, I consciously thought who is my sponsor? Now? I think that's, that's something I think it's really important is to understand, who is the person who is in a position to give you opportunities? And and do they understand what you can do and what you want to do? Because because I think we all kind of would love that our managers or our leaders would recognize our innate brilliance and give us some opportunity. But I know that like if someone says to me, Oh, I'd like to get someone to to speak at this conference have you got anyone, I'm far more likely to have the name come to mind of someone who said to me, I'd really like to speak, could you help me out with that? So I think it's really important to think about making sure that the people who can give you opportunities, understand what you're interested in.
Amy Phillips 9:11
How did you go about doing that? Because that feels like I mean, it's so like, it sounds so obvious, but like, yeah, you kind of mentioned like, you don't really go and seek a sponsor, you attract a sponsor. So how did you go about sort of setting up the new sponsor and making sure they knew what you wanted to do?
Sarah Wells 9:24
Well it was actually so the person who had been sponsoring me was the CTO at the time. When he left I thought, there was a director of engineering, he wasn't my actual manager. My manager was the head of software development, but I was a principal engineer and I, I basically, I had a good relationship with him - his name is Rob Shilston, he's fantastic. He was really influential person for me in my career. Rob and I had a great relationship anyway, but we didn't have kind of managerial relationship, but I actually asked him if we could meet monthly, because I was like, I'm a Principal Engineer. I should understand what the director of engineering needs from me. So then I had that regular thing anyway. And so so when I was thinking, Well, Rob is clearly the person who's who can now sponsor me, we already had that. So I think it's I think the thing that was surprising to me about that was, its the first time I'd actively asked for something like that. And you, you sort of, I think, and I think particularly probably, as a woman, you're a little less likely to say, Can I have this thing. But around that time, I realized that quite often you can ask for things, and it can work out. So for example, I wasn't an architect. There was an architect's forum at the FT at the time. And lots of things got discussed there that I was really interested in. And at some point, I just went to the director of architecture and said, Can I start coming to the forum? And he just said, Oh, yeah. And it's just like, Oh, my God, it's been annoying me for ages that I'm not involved in those decisions. And all I had to do was say, can I come? And maybe he'd have said, No, and then I'd have had some explanation of why and that would have would have helped. So I do think it's worth asking for things that probably aren't a massive commitment for someone. And if you're chatting to people anyway, that's good. Yeah, definitely.
Aaron Randall 11:20
How has that influenced how you think about sponsoring others?
Sarah Wells 11:26
I, I think I'm really conscious that I try to encourage people to think about who sponsors them. And to be clear about what it is that they're looking for. Definitely, and I'm actually more interested, really in sponsorship than mentoring. Partly because the kind of role that I had at the FT I had the opportunity to, to have, you know, to put people into places where they would learn something new or get or get some new experience. And I think, I mean, I do mentor people as well, I'm not I'm never convinced that how good I am as a mentor. And I think there's a lot of overlap between mentoring, coaching, etc. What I know I can do is kind of sponsor people and talk to them about what they're what they're interested in, in doing. Although I think if you spoke to a lot of people who I've mentored or sponsored, they'd say, Sarah's answer to everything is you should start talking. I know it's not the answer for everybody, because it's, you know, like, it's one of those things, that it can be one of the things people are most scared about standing up and talking in public. But if you are someone who can, who can find a way to communicate, if it's not talking, you know writing is exactly the same. It's like there's so much to gain from being able to put your thoughts in order and communicate them. And I don't think that I realized when I was more junior how, how much of a skill it is that's useful in, in work as well as kind of outside but also how it helps you build a network. It helps you get to know lots of people who can answer a question for you and save you so much time. Like when the FT would be trying to do something new. It's amazing if you can go and find someone who's already done it and say, Well, how did you introduce this into your company? Any tips on how we can not get this wrong?
Amy Phillips 13:22
Yeah, it's so important, isn't it? Wow, I have so many follow up questions. So how about maybe? So I'm kind of curious, actually, I suppose. So, you know, you did move through a lot of roles at the FT and I'm really curious about how did you find that like how what was it actually like to sort of, to end up being a director, like compared to having previously been an engineer?
Sarah Wells 13:49
I, I didn't feel, they always felt like, it always felt like the move was sensible. So So I was a senior engineer, and then the architect on the project, I got promoted to principal engineer, then the architect left the company. And I was having a conversation about who was going to replace him to lead the project. And and I just remember thinking, Well, I don't know if it should be me, but I really don't want it to be someone else that's going to come in and we're six weeks away from launch. I don't want someone to come in and go, Oh, we should change our our approach right now. That would be really, really bad. And I kind of found a useful thing, which was that I just said, I'd like to be considered. I think I wouldn't have gone I should have this job. But I was able to sort of say I'd like to be interviewed for it. And then once I'm in the processes, you kind of get excited about everything and a bit competitive. The move to technical director, I was pretty lucky I think which was, I'm kind of assuming a lot of stuff here, I've never actually asked but the CTO at the time. There was a director of operations who had just written a proposal for how we would handle out of hours, support for all the new systems we'd recently built. And we'd kind of moved to a far more. So it was all microservices, it was much more you build it, you run it, we were trying to work out how do we have developers doing some level of support for these systems, because they're too complicated. There's too many different parts, compared to our old stack. That was literally everything was running in Tomcat, with Apache in front of it. I had so many bits of feedback on the proposal, because we'd been doing this for a couple of a couple of years in my team, that I ended up writing a counter proposal because I had that thing where you put comments in a Google Doc and actually the comments are now pages down below. So I just wrote a counter proposal. And I didn't know that the director of operations was was going to leave. But I think I kind of, I kind of like
Amy Phillips 16:01
because of the comments?
Aaron Randall 16:02
Yeah, because of the comments
Sarah Wells 16:03
no, no, no, what I think happened is the CTO thought, well, we've got someone internal, who's actually really deeply interested in some of this, some of these areas, and it felt like I'd kind of said, Oh, no, but I think this, this and this, and so you know, I really wanted to apply and, and see if I could do it. And as a tech director role, it was it was really perfect, because it was a small group, it there weren't that many, it wasn't a massive change in the number of people that I would be managing, or anything like that, although I did take over the role and then go, Oh, I'm kind of responsible for business continuity. Well, that's interesting. But I don't even know what that is. And then engineering enablement, which was the last thing I did, it was, again, it was one of these things where you're looking at how the group is structured, and you have opinions about oh, well, you know, if we could move some teams around it, we'd have some we'd have a definite everyone in this group is focused on engineers as customers. So it's really interesting when you can see, yeah, it's seeing that there's a problem. And if you can just do this and get into the place you can, you can deal with it. I did actually, one of my colleagues at the FT, I was talking to her about another role, because at one point, I got feedback that maybe I needed to move into a tech director role that got me more exposure to business stakeholders. So I was talking to someone about one of those roles. And she said, "You turned up to ask me about it. And you just started with what's wrong? What needs fixing?" And you never asked me what was good about it. I was like, Yeah, I think I'm a problem solver. I'm interested in, I'm interested in what's what we needed to fix.
Aaron Randall 17:44
I'm fascinated by the fact that the FT was founded, like, all the way back in 1888. And like your organization's been around for such a long time. And what role today does tech played in organizations that has existed long before websites and apps were even a thing?
Sarah Wells 18:03
Oh, well, I mean, this is a very kind of tech, I'm going to give you the tech answer. If you were to talk to editorial. I mean, if you spoke to the business, generally, editorial are the core of the FT. That's what, that's what the FT does, like we tell, do the news. But over the time that I was at the FT, you know, you're starting to realize that technology is really important in being able to tell in being able to tell news stories, and I kind of hope that we managed to move people from the idea that technology is just a cost center, to the idea that technology actually can provide value and be be something that allows you to, you know, to make the business more successful. And that was things like having, having teams that technology teams sat in the newsroom working with editorial, building, building tools. An early example was a thing called Chart Doctor. That meant that if you had a if you had a spreadsheet as a journalist, you could create an a good FT chart to put in your story. And you didn't have to go and find the team that created charts and get them to make it for you. You can make it yourself. If you look at the look at all the stuff around the Coronavirus that the Financial Times published, their data, their charts is just the visualization is just absolutely excellent. That's enabled by very, very tech literate journalists and technologists working closely alongside them. But there's it's obviously what it's obviously wider than that. But I think that there's a there's a recognition that you solve. You basically make the business work by using technology by having a strong product strategy as well,
Aaron Randall 20:01
and how to how do journalists get involved in in kind of influencing what you do build, how do they get? How does their voice get represented in the product strategy?
Sarah Wells 20:09
Ah, so this is not my this is really not my area, because I've consistently worked a kind of a few removes from the business, you know, it's building the content platform and APIs, and then doing engineering enablement, where effectively, I'm sort of supporting all of the all of the teams. But in general, there are, there are boards related to particular parts of our product strategy, like our mission, mission control, I think they've been called. And they involve people from editorial and other commercial areas as well, along with tech leadership, so that they are working together to talk about the product roadmap to make decisions about what the priorities are, with the idea being that if that group all agree, then you know, you don't have that thing where marketing would like you to build this thing. And editorial would like you to build something else, and you're stuck in the middle. If that discussion happens with everyone in the room first, then hopefully, you're able to say, but we all agreed that the first thing we were going to do was this, this thing? I think certainly, it felt to me, like we worked a lot more closely with people from other parts of the business by the time I left than when I when I first joined.
Aaron Randall 21:25
Hmm, it's really interesting. I just love the fact that there, there are industries where I've worked at so many different tech companies, where developers are kind of the superstars, you know, the special team that does all of this amazing work. And actually, it's so kind of refreshing to, like, hear about the FT and think about other organizations were actually, as you said, like the editorial team are cool. Like they're the superstars. Not not the developers in this organization, which is kind of an interesting dynamic.
Sarah Wells 21:50
It is it is it is very different from from tech, it's very interesting. So one of one of the things that I was involved with was the, the response to the pandemic, because it started off as a business continuity issue, which was in February 2020, thinking, we're probably all gonna be working from home in a month's time, what can we do to make sure we can succeed with that? And then after that, it was how do we, you know, are we coming back? What are we going to do? What's really interesting is that the tech team, the tech department feel quite differently about quite a lot of these things from other parts of the business. And it's a challenge, because, because, because actually, for people in the tech team at the Financial Times, if we left the FT, it's not necessarily the case that we're going to work in another newspaper organization. Whereas, you know, if you work as a journalist at the FT, the place you're going to go to next is likely to be a newspaper or some other journalism thing as anything else. So you're competing against different against different markets. So whereas you know, in journalism, you might, the FT might win out because we're not making people come back to the office five days a week and and say the telegraph is, with tech, you're also competing against all the companies that have decided that they're perfectly happy being remote only. So I think it's really interesting. Because you are competing against companies where developers are the rockstar, where product or product is king and products not It's not going to be the, you know, the, the rockstar in an organization that isn't a tech focused organization, I think.
Aaron Randall 23:30
really interesting.
Amy Phillips 23:31
And maybe that gives us a nice sort of transition into actually engineering enablement. Because one thing, and I know you've kind of mentioned is the importance of the golden path. And this idea of like building a path that people actually want to follow. And, not like, they have to follow it, but actually, they choose to. And I guess, like, it sounds like, certainly an interesting one, I guess, kind of interested in the balance of the must be some golden path that it's you want to follow because you're at the FT, but also some golden path you want to follow because you're a developer and actually, this is what the the cool, the cool tech is. So how does the first maybe like, what is the golden path that like, how do you actually go and set that up?
Sarah Wells 24:14
Well, so during the time that I was at the FT, we went from, everything's written in Java, it's runs, in Tomcat. It's got Apache in front of it, to a kind of explosion of things that you could use in one database, whatever to bring pretty much an explosion of you can use lots of different things. So we started three big projects around the same time they were all microservice based. They introduced a lot of different technology. And that's great because you, you, you end up being quite autonomous when you're doing that and you're not held up so you can make progress. But you're a couple of years in and you've all basically solved the same problems. So you've got eight different solutions for a particular thing. and actually people start to get get to a point where I'd really want to be focused on the business stuff. I don't want to be like maintaining our own version of the build pipelines, or, you know, I want to just be able to do infrastructure as code and not kind of invent it from scratch every time. So there's, there's always going to be some level of things where you think well, could you? How much of it could you could you take away and provide to people, so. So we used AWS, among other things at the FT, got a team there that are building tooling around that. You want to build things that people most care about having. So you want to build something that's well documented self service, automated, you know, you have these principles behind what you're building, to, to test that, that what you're building is useful. Because I think that if you've got autonomous teams, for a lot of, in a lot of cases, they could choose not to use whatever you build, you don't want to be, you don't want to be in the position where everyone is forced to use your stuff that they don't like you want to build something that is better than having to build it from scratch. So the idea of the golden path is that you, you basically say, okay, we need to do there are certain things you need to do to deploy code into a live environment. How much of those things can we provide you with a really simple way to do it so that you don't take too much time on it. And the idea is that sometimes you might say it's paved road, you can choose not to follow the golden path. But it should be easier to walk on the road than it is to hack your way through the undergrowth. And if you do decide you're going to hack your way through the undergrowth, then I think the thing that you are, basically that you have to do is meet all of the requirements that the golden path does. So you can build your own version of this, but you better have logging and it had better be patched regularly. And you're the ones that are going to wake up at two in the morning, if it breaks, and it's being used for a critical system. So it sort of feels like if you're doing engineering enablement, within a within a company, you should be able to build something that people like, because you're right next to your customers, and you only have to solve the needs of the people in your organization. And you should be able to to be better than them having to build everything from scratch. So engineering enablement is about that. And I think when you have a very complicated distributed systems architecture, you know, when you have 1000s of different moving parts and services, and so microservices, serverless, all of these things. It's worth investing in some people that just provide a sort of stable, a stable sort of, under underlay for that.
Amy Phillips 28:07
How do you go about like, so I guess, if you're like, kind of setting up teams like this, like, where do you begin? Because, I mean, I get like, after some time, you probably have a great tool or project that people want to use, but like what does the sort of early stage look like?
Sarah Wells 28:22
So I think the way you begin when you're setting up the teams, for me, it was finding people who wanted to solve this kind of problem. And who had a natural instinct to go and talk to their customers. I mean, effectively, you are you have, you're building a kind of a product, and you're kind of, you're still you should still care about research and feedback and everything like that. You probably, like so, so what we would do is we talk to people about what they were finding was painful so we'd survey or we'd interview or we'd look at what people said in Slack about something. So you know, if you see lots of complaints about a particular bit of technology, then you could probably have that as a target you do look at or certainly I always thought we should try and deliver regular, a regular set of things. So looking for things that don't take a lot of time that you can get something out the door that people will like, but also thinking about what can we build that maybe take a bit longer, but it will make more of a significant difference. We started with what we had. So we kind of had the idea of a registry for systems. But it wasn't really built in a way that made it easy to extend. So it was effectively largely about runbooks It was basically a kind of, it was more like a relational database. You just had rows for each system. So now if I moved from one team to another, and I was the tech lead for over 150 of the systems, you had to go and update 150 rows effectively. So it's better if you think about that as a graph. So the first thing we did was we converted that to be a graph. And then the graph was there with the ability very easily to add new new nodes. And so we have a, there's a thing at the FT called Biz Ops, which is basically, a systems registry, but it's more than that. It's like every service linked to the teams that own it, we've been able to bring in information about GitHub repositories, AWS resources, because we already had a standard from a long time ago about having unique system codes for systems, you can tie lots of things together. And then you can start exploring it. And it's got a GraphQL API, so you can ask interesting questions and say, Can you find me all the services that aren't that are not owned right now? But can you find me all the services were? So one of the interesting things we did quite early on was, Are there services that have S3 buckets that are open, publicly open, where we've said that this service has PII information in it? Because that's immediately telling you something really interesting that like, this is one we should probably focus on is it and actually, quite often, you'll find out that the stuff that's in the in S3 is actually fine. But you should at least have to have that thought. So being able to automate the kind of questions that that you ask as well. But also, we spent quite a lot of time just selling, selling what we were doing internally to, to our customers. So I always took every opportunity to talk at tech all hands or to run a panel at the internal conference, or to write a blog post, to try and find out what people were where people were frustrated with something and where we can help. It is difficult, because you always require teams to work with you a bit when you're adding some new feature, and they're all busy with their own, like their own needs. So So part of it is can you give people enough notice, like in six months time, can you spare a team for a few weeks or more? I think that that kind of helps? Or can you send someone to go and sit in that team and do the thing for them as well?
Aaron Randall 32:24
What was the most popular tool or software you shipped in the engineering enablement team?
Sarah Wells 32:34
Well, I honestly think Biz Ops is still like, it's still just really the fact that you could go and look things up. And I knew we were doing well at the point where people who weren't in our team would post a link to Biz Ops when someone would say "Does anyone know who owns this service?" and someone else would post the URL and you go, well, that's, that's good. But on top of that, there was quite a lot of nice sort of visualization. So there's a tool called SOS, which was system operability score. And this was at a point where we had lots of services that didn't have a very good runbook. I mean, mostly, they just didn't have a runbook. So we automated scoring, the runbooks. So it was it was, you know, a little bit like, okay, it's really important that the service is owned by a team. If it's a if it's one of our most important services, is there an out of hours rota? Is there anything in the section about failovers? And a lot of it was quite straightforward. It was like, is there something there at all. So you know, it could literally be someone's gone to be filled in later. Although I think we did look for things that just said to do, basically, we can score, we could score the runbook. And then we can aggregate the scoring, and show teams, how they were doing. And then groups how they were doing. And then we could basically compare, basically show people how they were doing compared with the other groups. There were two things about this. For some people, they're really competitive. So we would have people who would come to us and say, I want to get 100%, what do I have to do to get to 100%. And sometimes that was actually difficult, because maybe there was a like, there just wasn't a way to do it. But we would try and this and that. And you would see people posting screenshots in Slack saying, "Hey, we've overtaken you". So that worked in one respect. And what I hadn't realized, was around the same time the FT started doing OKRs. And the thing about so objectives and key results. The thing about this is you set an objective, and your key result is something that you can measure. It's even better if you can measure how you're doing throughout the quarter to see that you're making progress. Well, it turns out if you've basically given a score, you've just given people the ability, a really simple way to set a key result related to observability. So people would say we're going to improve our SOS to be from 70 to 90. And so that had quite a big impact. It only lasts for a certain amount of time, because it isn't as good at catching the place the point where someone's information is out of date, if there's information in there, but it's wrong, that's a lot harder to automate. And we did have a manual follow up, which was that our first line operations team would review all of the critical systems yearly to look at that information and do a manual review of it as well. But that kind of shows, you know, you might get a lot of feedback here, lots of great stuff out of something, but it's not going to work forever. Sooner or later that's not the problem, something else is the problem. And that's where you need to be to be focusing, focusing your time. So I think, yeah, I think that worked. But generally, another one that people have liked recently is that the team that managed DNS configuration, we had to move DNS providers two or three years ago. And as part of that move, they basically moved DNS to be infrastructure as code. So you can make you can make DNS changes by by in a GitHub repo and raise a PR, however, there's still feedback, saying, it just takes a while for you to review the changes. So they looked at the kinds of changes that people made, and they identified some changes that are really low risk. And they added some rules. So that basically, if you raise a if you were to raise a PR, and it's adding a new section, or deleting just a section as a whole, they could just automatically approve it. Or if it was something that when they knew the cyberSec team orght to have a an opinion, they could automatically add that someone from the cyberSec team onto that PR. So they just started, there's a really good blog post on the FTs technical blog, which is on medium, it's FT product technology, about this, which is basically, you know, here's, here's where we started, started the work. And I think that's something that I really liked, because it's, it's automation, it's listening to our customers, and it's like having a balanced view of like, of risk versus autonomy. Because I think you've always you want teams to be able to autonomous, but you also want to protect them from making mistakes that you want to protect someone from accidentally deleting the DNS entry for something critical. I think that's, that's something that you ought to do as a platform team.
Amy Phillips 37:30
Yes, it sounds like a great idea.
Sarah Wells 37:32
Yeah.
Amy Phillips 37:33
And I suppose, like, at the FT, you know, it's like, a very large organization, like, super critical, highly visible. So, you know, I can see it makes like tons of sense to have engineering enablement to sort of set these things up. There's, I'm curious, like, on your thoughts of like, should every company have something like this? Or like, what's the point where you actually say, engineering enablement, is actually going to really help us and we should, we should go and get that set up?
Sarah Wells 38:01
I think it's probably to do with it has to do with how many people you have working in engineering, I think it has to do with whether you have enough people doing work where you want to end up with a slightly more complicated architecture, in order to allow them all to make progress. So, you know, I wouldn't recommend people adopt a microservices architecture when there's one team of people working on something. But when you have five or six, maybe maybe you might introduce some level of that. And when you get up to like, 250 people working in a tech team, you probably go a bit further, once you get to that point, I think you're going to have people that are spending time doing this sort of stuff, whether they're one person in a team who's dealing with all of the little niggles, or whether you actually extract those people and have them work for something that solves it, let you know, do you do you solve it locally? Or do you solve it more globally? And I think, often you want a bit mix of both, because some things are very specific to a particular team. But some things it's like that you're looking at those local problem solvers. And actually, they're they're doing stuff that other people are also doing. And it's just not it's not the most effective use of people's time. So I think it will, it's like it's a classic consultant answer to say it depends, but I think what it comes down to is, does it speed you up for your other teams having this? And you could, you could try it out by saying, you know, we know this is a particular problem. Let's form a feature team that's going to work on it for a month and see, does it have an impact? Does it change our ability to to make business changes. Early on at the FT and it's kind of before I was really involved in this because there's been a move towards this for a long, long time. Now when I when I first joined we did 12 releases a year for the website. And if you wanted to get a new build a new system you'd buy a server and put it in the server room, and everything. So there was investment then to, like make it much quicker to, to spin up a server. And you could actually see, you could see the impact of that point, you could see like, we're releasing code a lot more frequently, it takes less time for us to get that first release out. After a while, it's much harder to measure it. Because you're already like the FT does pretty well on the accelerate metrics probably do 30,000 changes a year. So you know, we're doing a lot of change. And when people say, How can you? How can you show that your team is providing value, it's actually quite hard without removing that team. But but it is still there and removing some of that like pain for day to day, you know, you need to tend to your tend to your software estate, and the people in engineering enablement teams tend to do that.
Aaron Randall 40:58
I love that. I'd love to switch now and talk about the team itself, kind of the makeup of the team. And I read a quote that you said previously about when the fact that when you joined the FT as a senior developer, you were one of four or five women in development team. And now in London, your team's around 35% women and non binary, what steps did you take to achieve that improvement as an organization?
Sarah Wells 41:24
Ah, I mean, I think there are, there are lots of parts to that. But probably probably a main one is actually Cait O'Riordan, saying we're going to do it. And we have a target to be 50/50 by 2023. I can't actually remember the exact details. But but to say here is a here is a target we have for our department, and then to be to be specifying OKRs for it, quarter after quarter. And everyone knowing that this is kind of an expectation. So. So you're, you're thinking in terms of how are we doing in terms of our hiring, and being willing to say, we've got 100 CVs in for this role, and they're all men, go back to the go back to the to the recruiters and say, this is this doesn't seem possible, really, that there are no women at all. And women's just one aspect, obviously, there's tons of other aspects of diversity that are really important, we probably made more progress initially, on women, and that's partly because it was one of the bits of data that we also had. So when I was I was the first woman tech director. There'd been no, there have been no women architects, we kind of didn't, we moved away from architects and moved to principal engineers. But there were no women architects, I was the first woman principal engineer. But then we got to the point where probably 40-50% of Principal engineers, were woman, technical director, by the time I left, we were the majority women, on the technical directors, you know, only only marginally, but it's amazing compared to pretty much anywhere else. Partly it's that people see, they see the path. And, and it's perfectly normal for a senior person in the discussion in the technology team at the FT to be a woman, which I just think sets that like expectation. But it's it's really around the data. So when I became a tech director, every time that we did a promotions round, we'd look at the data. Were we putting forward men and women at similar numbers? What were the current salary distributions within each role for men versus women, because you want to make sure that there isn't some systematic bias there. And you want to do the same for other aspects of diversity. But it's harder to do that until you have that data. So the FT did introduce into the HR system, the ability to say, to say more about yourself, you know, to say, what's your background, you know, all kinds of levels really. And I think having that data and actually looking, looking at it is, is useful. It's difficult sometimes, because there may just not be enough people in a particular area for it to be meaningful, a meaningful thing, but at least it just gives you a framework for going oh, you know what, this person's definitely not being rewarded the way that their peer is, it takes time as well because you know, when you start from a position where there hasn't been a very obvious pay band, so we'd introduced like we introduced about there is a pay band. And initially there was a lot of, well, here's our here's our sort of internally shared not really very public with everybody, but the hiring managers knew about it. And then we'd look at where the outliers were. Because then the first thing you're trying to do is make sure that you're fixing those. And we started off with pay bands that had a definite overlap, because, because basically, otherwise, you had so many outliers. But I do, I do think that like, you start with that, but actually, it gets easier, the more that you already have people in place, because quite often you get recommendations, or people, you know, people come and join you because they've heard its a good place to work. And you're, you go from having to make a special effort to make sure that you have a diverse interviewing panel, which, you know, incidentally, has an impact on the people who are, who are showing that it's diverse. Because if you as a woman engineer are in every interview, because we're trying to show that there are women here, what you're not doing is the other stuff that could get you promoted, so you have to make sure that it's rewarded for them. But eventually, it just becomes much easier, because it's just natural that you have a diverse interview panel.
Aaron Randall 46:11
That's really inspiring. Great. I mean, so many things you mentioned there and like OKR setting, I guess setting it from the top having leadership talk about it. You mentioned Cait really driving a bit of that, hiring and pipeline diverse interview panels, that kind of stuff. Really impressive. What was the biggest challenge in doing all of this?
Sarah Wells 46:30
Ah, I mean, I think that, that there's an element of people feeling frustrated that it's not perfect, but people want you to be really, it takes time to do anything. It takes time to do anything like this. And along the way, it's, it's, it can be frustrating for people, I guess that's a challenge. It is a challenge I think for for white men, who are thinking, where's my opportunity gonna come from? You know, I've had people say to me, Well, of course, I'm not going to get promoted, because I'm a white man. And it's like, well, you know, it's that quote, of if you're, if you're used to your privilege, you know equality looks like oppression. And I think that can be can be really, you have to recognize it. It's, I think, what I would try and say is, it's mediocre white men are not gonna get promoted, right, that's, that's what's mostly happening is you're picking the best people. And now you're actually making sure that if those best people aren't white men, that you're actually gonna see them in, you're actually going to consider them. And there's definitely an element of like changing what people think it looks like to be a leader. You should recognize different, different styles as being valid.
Amy Phillips 47:57
Wow. So we are so nearly at time, I want to just ask you one final question, Sarah, before we jump into our kind of wrap up quickfire questions, but you've shared so many amazing stories and experiences of your time at the FT now we know that you did recently leave and you're enjoying some time off. But can we ask like, what's gonna come next, do you know?
Sarah Wells 48:18
Um, yeah, I do know, I, I left because I'd been there a long time. And I was quite exhausted, I really did need a bit of a break. But amazingly, I've agreed to write a book for O'Reilly. So pretty much now I'm going to start, I'm going to start writing it. It's about microservices. It's called Enabling Microservice Success. And it's really, about how microservices, if you want to be successful, is about more than the technology. It's about the organizational cultural setup that you need for that as well. So, so I'll be looking at, you know, what do you need to do? And, and where are the things that can really trip you up? If you don't, like change the way you think about how you build. How you build software
Amy Phillips 49:08
Wow, that sounds incredible. I'm very excited to read that.
Sarah Wells 49:11
I am really excited. I'm so excited.
Amy Phillips 49:16
Okay, so we do just have our final quickfire questions to wrap up. So what's your top book recommendation?
Sarah Wells 49:25
So the two books, three books that I always end up recommending to people, and I noticed, actually, actually, within like, looking back at your other podcast, people have mentioned them Accelerate, Team Topologies and The Manager's Path are the three that I often end up recommending to people. So I'm going to recommend something different, which is I found it's really interesting to read things that are not specifically sort of aimed at software development, and think about how they have an impact. So two that that I found Inside the Nudge Unit which is about behavioral economics in the UK Government. So it's about how do you influence people to do things. And so things like if you put someone's name in a letter, or if you say 95% of people have completed their tax return by the end of November, you kind of encourage people to do stuff. And it's much cheaper than spending money to, to invest in, in more sort of infrastructure or anything. I find it really interesting because it really when I look at it, I went, Oh, this is how we influence people within software development too you know, this is you make it attractive, you make it easy, you're your social, you use that like sense of other people. So it's good. It's a good book for that. And it's based on, there's a book called Nudge Theory. But this one is specifically Inside the Nudge Unit is more about how government used it. I just found it quite interesting. And related to that The Checklist Manifesto, which is Atul Gawande. And he's talking about how they, how they how they had a group of people who wanted to improve healthcare outcomes across the world. So they didn't want it to be about spending money, because they wanted it to work everywhere. And they found that by borrowing the idea of checklists from the aviation industry, you could make a significant difference in terms of outcomes for things like surgery. And the checklist isn't here's how you do it, it's here are things that if you do that, you may not automatically think about but that just gives you more of a chance for success. So for example, if a surgical team introduced themselves to each other, and tell each other their names before they start the surgery, it's more likely things won't go wrong, because it's more likely people will speak up when they see something. Like when they see someone trying to cut the wrong leg off, you know, it's like, you know, you know the name of the surgeon, you're able to, you're more likely, I mean, this sounds silly, but this is the kind of thing that can get rid of those stupid mistakes. So it's a really interesting book, it's not very, it's not very long, I always like books that aren't super long to read. And you can totally see again, how that impacts how you could use that in software development.
Amy Phillips 52:01
Great recommendations. Okay, so number two, then What are Who is your number one tip for keeping up with the industry.
Sarah Wells 52:10
So I just find Twitter, like Twitter works for me, like, I think you can curate the people that you follow. And it's quite sort of bite size and you see people you know, saying something that makes you think, or they provide a link and as long as you find a way to kind of squirrel those away so you can go back to them later I find I've found that a really good way for me to to keep up to date with what's going on in the industry, basically.
Amy Phillips 52:41
And then number three is Who inspires you.
Sarah Wells 52:44
Um, so I I want to say Tanya Reilly because she is so good at telling a story about technology. And her talk and blogpost about glue work is something that I recommend to people frequently because so so the idea is that glue work is stuff that's important. But it's not necessarily something that companies promote people for. So you need to be really conscious if you're doing that glue work you know like organizing stuff, fixing small problems, being the person that documents things, you need to make sure that it's recognized in your organization as something of value and you know at the Financial Times people will will say this is glue work I want some you know, I want to find someone different to pick this one up. So I think I just I really, I really like Tanya I find her like very engaging and she's writing a book at the moment about staff plus path and it's going to be excellent.
Amy Phillips 53:48
Fantastic. Okay, great. Another book. Okay, then we have our final question. This is a special one for you Sarah because we know you are a very keen cook. So what is your favorite dish to cook?
Sarah Wells 54:01
Ah, um so yeah, so basically lock down has totally got me into like, elaborate, elaborate cooking because I'm not like commuting back from London. The two things so recently pasta we've been making pasta so like actually making ravioli which has just been really good fun. But before that it was it we got really into cooking sichuan Chinese
Amy Phillips 54:30
Wow
Sarah Wells 54:30
We bought this book called Every Grain of Rice by Fuchsia Dunlop and just started cooking things from it and it is absolutely fantastic. It's really hot. Generally, like there's a lot of different chili in in the recipes but like we often cook it and look at the things you've cooked and go. I can't believe we've cooked that it actually looks like we know what we're doing.
Amy Phillips 54:56
Okay, so then finally, Sarah, where can people find out more about you?
Sarah Wells 55:01
Twitter. So I'm on. I'm on Twitter, @sarahjwells. That's probably that's probably the best way. So I literally I literally bought myself a domain to set up a blog about three years ago and I still haven't published a blog post. So it turns out I need a deadline, basically.
Amy Phillips 55:24
Fantastic. Well, thank you so much Sarah, this has been incredible, like so many great stories. So lovely to hear about, like all the things you've achieved at the FT. And I mean, like, congratulations, I think well done, because it sounds like you and the rest of the team, but you've really made some massive changes there. So yeah, thanks for sharing about them.
Sarah Wells 55:43
Well, thank you. It's been a pleasure.
Aaron Randall 55:45
Thanks a lot, Sarah.
Amy Phillips 55:49
We'll be sharing all the links and show notes plus the all important doodle over on humansplus.tech. I'm Amy Phillips. This is Aaron Randall, and you've been listening to the Humans+Tech podcast.
Get the latest posts delivered right to your inbox.