Technical Leadership in Media: Architecture, Communication, and AI Challenges at the FT

Managing the Editorial and Commercial Groups as Stakeholders at Financial Times

Charles Humble: Hello and welcome to this episode of GOTO Unscripted. I'm Charles Humble, I'm a freelance techie, editor, author, and consultant, and this is part of a series of podcasts that I'm doing for GOTO talking to software engineering leaders. Today, I'm delighted to be joined by Alice Bartlett. She is a tech director at the Financial Times, the world's leading paper on business and economic news, and at the FT she oversees the team that builds and maintains ft.com and the apps. She's been at the FT for about ten years and prior to joining the FT, she was a senior developer for Government Digital Services here in the UK. Alice, welcome to the show.

Alice Bartlett: Thank you. Hi. Great to be here.

Charles Humble: Lovely to have you on. I can't resist asking you about the FT's pink paper, which is the thing that I think certainly I - it's the first thing I think of when I think of the FT is the color. And I was thinking as I was preparing this morning because you work on digital products, that color must be a nightmare because it's terrible for contrast and stuff.

Alice Bartlett: It limits the colors we can use with it. But also that color, when I'm giving talks, it's something I have to think about a lot because that color reads when projected as white. So although I want my slide deck to be on brand, I actually have to use an off brand color, not the hexadecimal color we used for the website for the slides, because otherwise it just looks like I've put something on white, and I do want it to seem pink and FT like.

Charles Humble: Where does that color come from originally? What’s the story there?.

Alice Bartlett: That's undyed. So it used to be that pink was cheaper a hundred years ago when we started printing. It's not cheaper anymore because processes have changed and improved, and so maintaining that pink is actually more expensive. But it's such a core part of the brand that obviously we just have to pay more.

Charles Humble: Yes, yes. Before we get specifically into talking about your role, I'm interested in exploring the FT's editorial team as stakeholders because with print media, traditionally, I think they tended to see the web very much as just another place where we put the newspaper - that very legacy way of thinking. But I think the editorial at the FT was maybe a bit more progressive. So how involved are they in thinking about technology and how it might help them to tell the kind of stories they want to tell?

Alice Bartlett: I think we've got - the editorial is about 600 people at the FT. And so, some of them are more progressive, some of them are less. It's what we would call a destination employer as well. So the churn at the FT and the average age of a person working in editorial is older, and they've been here longer. And so they tend to hold a variety of views, but some people really are still thinking very much that print is what they care about the most, because they just have worked for the FT for like 30 years and the website is just this tiny thing that's just happened as far as they're concerned.

But we have some really great people who've also worked for the FT for a long time now, come to think of it, who really think less about print and digital as channels, but more like the storytelling capabilities of each medium. And so we do a lot of work with editorial, where we are talking to them about how they want to tell a story, and they're really only thinking about the digital aspect of that, because the print way of telling a story hasn't changed. So that's what interactive elements can we put in the story and how can we create these rich and immersive experiences in service of journalism? So we do have some really progressive people in editorial, certainly, who think about digital more than just where the words go.

Charles Humble: Right. And who are your main competitors in terms of both technology and storytelling?

Alice Bartlett: The people that internally we talk about the most are the New York Times and the Wall Street Journal. And then Bloomberg is a competitor in terms of financial news, but they are quite a different proposition in terms of what they're publishing. It's just that our customers are often both Bloomberg customers and FT customers because that's the finance sector.

Charles Humble: You were quite early to put a paywall up. And that's the shift to being a subscription business first and foremost. So presumably you have as well as the editorial group, I presume you have a commercial or a subscription group who are primarily concerned with getting people to subscribe. So what's that intersection like? How do you balance their needs against editorial needs?

Alice Bartlett: It's a challenge actually, because they are both important stakeholders. And we have different teams whose focus is different stakeholders. So the storytelling in my group - I've got about 70 engineers. There are storytelling teams basically that are focused on aspects of the editorial experience. And then we have acquisition teams, we have an ad team, and they are more - they're dealing more with the commercial side of the business. It's not that they're completely siloed. Often there's crossover. But generally speaking, the acquisition and lifecycle team, as we call them now, are dealing with retaining customers and acquiring new customers. And then not thinking about what goes on on the article page.

Charles Humble: I'm guessing as well, because you were quite early in the whole internet thing - I mean, you were a relatively early adopter of the internet as a channel. So given that, how much legacy do you have to deal with from a tech point of view? Killing legacy features tends to be quite hard.

Alice Bartlett: I think that within my area, the oldest code base is the app, actually, which is, I want to say 15 years old, which is obviously absolutely ancient, especially for an app. That is ridiculous. And then the website got rebuilt and relaunched in 2016. So there's - and there's some 2016 code still knocking around, but it's been - we've managed to keep it constantly worked on. So there's not too much. When it was rebuilt, it was written in Node. So microservices - very modern cutting edge for 2016. So actually it doesn't really feel very legacy. There's some much more legacy stuff around the rest of the FT. Particularly around our publishing API like the API layer.

Charles Humble: Right.

Alice Bartlett: But even that is being slowly modernized.

From Developer to Tech Director: A Decade at the Financial Times

Charles Humble: With the as background C can you tell me about your role at the FT? Because I said in the intro, you've been there quite a long time and you started, I think, as a principal engineer more or less, and then shifted to being a tech director over time. So can you talk about that a bit? What was the role of a principal engineer like at the FT, and how did that transition happen?

Alice Bartlett: I started nine and a half years ago, in the Origami team, which is a team that creates the component library. And then I joined the group I'm in now - customer products. I was a principal engineer, overseeing various teams and leading various bits of work. And then about two years ago, I became the tech director. 

And the principal engineer role here up until literally January when we changed it finally, was not a principal engineer like how most companies have that role. It was not an individual contributor role. It was engineering leadership. But you would be doing some managing of managers, some strategy and leadership and technical leadership stuff. And it was very - there was much less hands on stuff than a lot of principal engineer roles elsewhere have.

Charles Humble: Alongside that, how's the organization changed in the time you've been AT the FT? Because you said the role has changed, but has the FT itself changed in terms of how it runs the technology organization in the time you've been there?

Alice Bartlett: It has, but not majorly. The technology department hasn't really changed because the code always routes you in reality, you can't - it's very hard to shift people and responsibilities around because there's all this software that has to be maintained, and you can't just get rid of it. Whereas if you are in a product management org, it's possible to make much more drastic changes quite easily. So the technology hasn't really changed.

We had one major thing a few years ago where we spun up some near-shoring in Sofia. So I've got a load of colleagues in Bulgaria now. And then that coincided with separating, like rearranging the technical domains to be around stakeholders. And so we had an internal products team that manages all of the Salesforce stuff. They also build and maintain Spark, which is our CMS. And then all of the stuff in customer products is front end customer facing. And that's where I am. But there's not been any major upheaval since I've been here. Just I think because it's so hard to make those changes with technology.

What has changed - we announced it at the beginning of this year - was the creation of an IC track at the FT. So previously we had individual contributors, but there wasn't in the career progression framework any calling out of that. And so what that meant was that at the senior two level for engineers, for example, some people would be able to evidence that they were managing people and doing leadership through management. And some people who didn't want to manage weren't able to. And they would have to find other ways to do that, which is possible. But it also meant that you could sit in the middle not being a very strong technical contributor or a very strong people manager, because at no point was it defined narrowly enough that you knew that you had to be good, or great at all of these things. So we split those two roles out to give people more clarity on what their jobs are. And yeah, that's the change we made at the beginning of this year.

Charles Humble: Right. That's fascinating, actually. So can you tell me about your current team? What are you responsible for at the FT?

Alice Bartlett: So ft.com, not all of it, but the majority of it, most of the customer experiences that happen on that. Then the app, and the Edit, which is an eight stories a day micro subscription.

Charles Humble: It's like a lower price point subscription? 

Alice Bartlett: Yes

Charles Humble: Can you describe the structure? So how are the various engineers divided into different teams and what does it look like?

Alice Bartlett: So there are ten teams which are split into three groups - lifecycle, which is about acquiring and retaining customers. The app - apps, the Edit and the main app, then the experience team, which is looking at the home page, the article page, search, all of the things that people come to the site to do. And then we have the reliability and platforms and ads teams who are basically working on ft.com the platform, and it's all of the front end bits. So we back onto a load of APIs from another team in Sofia. And yeah, but all of the content and ads is what is in my group.

Charles Humble: As I understand it, your principal engineers also do management or some management. Is that right?

Alice Bartlett: We've just changed that. So I now have one principal engineer who is an individual contributor. And I've got four others who do management They do help with delivery and team health. They do help with technical stuff too. They're all very technical managers. But the IC one doesn't and won't have any managerial responsibility. He is a leader in other respects, but not through managing managers.

Charles Humble: How many tech directors are there overall?

Alice Bartlett: Six.

Charles Humble: And you all report into a CTO role?

Alice Bartlett: Yes. We are reporting to Rebecca Salisbury, who is the CTO.

Recommended talk: How To Lead Through Transformation in Tech • Hannah Foxwell & Charles Humble • GOTO 2025

The Reality of Tech Director Responsibilities

Charles Humble:  I think we see what the structure looks like. I think most people have quite naive ideas about what a tech director actually does. So can you maybe describe the role for us? What's actually involved?

Alice Bartlett: Firstly, all of the hardest problems within the 70 people that work in customer products end up with me. You never get the easy problems because the easy problems are solved already, so they don't - you might get notified about, oh, we solved this easy problem, but you never actually - it's never worth your time to really hear about it. Yeah. So all of the hardest problems and you can imagine with that many people, there's a lot of problems - there's a lot of just life happening that often requires - I need to know just because that's the responsible thing to happen is for me to know things. Or I need to give advice to my managers about how to have difficult conversations, what the outcome is. I need to make sure that they're following the HR practices we have, but also interpreting the HR guidance correctly.

There's often in those respects, I'm always trying to coach the people who report into me in those conversations rather than have them myself. But sometimes when it's a particularly difficult situation, then I will be involved. So those things happen. That's just the scale of the number of people you have. The more people you oversee, the more you have to spend some time on those problems.

Then there's thinking a couple of years out, about where we're trying to take - the problems we're looking at today. Problems are going to happen, we think, in the future and making sure that someone is looking at where customer products, but also the FT as a whole is going to go in the next 2 to 3 years. And there's some stuff that's very speculative about that. And then there's some stuff that I might - there are some aspects of the work that I can see where we're trying to get to, but also what the current next step is, and then you're always adjusting and helping people to adjust their work and the processes to get to some vision. So that's another big bit of the work.

Then the third thing is it's not so much dealing with problems of staff, but it's problems of just the work. Something's gone slightly wrong. I spend a lot of time listening and thinking and maybe doing some stakeholder management and maybe communicating upwards to our CTO so that she has — she never wants to be surprised. And so making sure that the right information is in the right places and that my peers, the tech directors either side of me, they have the right information as well, so that if we're all trying to manage either a technical incident or a stakeholder relationship that's gone a bit funky, we all have the same information and we all understand what we want to get out of it, and we're able to manage a situation, so that the people who are doing the work can just get on with it without being pushed around by the winds within the organization.

Charles Humble: That's got a lot to unpack there, actually. I'm curious about - so if you're being brought into one of those difficult problems, maybe you have to intervene at some level. How do you go about building out enough context to intervene in an appropriate way?

Alice Bartlett: So I rely on my principal engineers too - so like my boss doesn't like being surprised. Neither do I. I often expect them to have a good briefing for me. And if they don't, then we'll explore it together. And they will often go away with some things to find out. And so that first thing is essential. I need to know what is happening from the principal engineer who's closer to the thing, and then I can go into a meeting with a stakeholder and get their perspective, or I can go into a meeting with my product director counterpart or whoever, have a conversation about what's happening there.

And that involves being very curious and non-judgmental, because particularly for me, I have a real bias for action, which sometimes does get me into trouble. And so I'm always trying to not say the first thing, but listen to what's going on around and what people are telling me. And so then generally the way for me to not act is to keep asking more questions. And then I have to go away and think about it. Because I'll usually have to - if it's really messy, I'll have to turn over the information I have outside of work time in my head to pick the next action. This again isn't about me jumping into something provided the situation allows that time for reflection. Sometimes they don’t.

Charles Humble: Absolutely. How do you balance - this is something that I've personally struggled with. So this is a bit of a selfish question now I'm thinking about it. But how do you balance your timetabled time— the time you've got in meetings or whatever— with the things that come in that I imagine is quite a large part of your daily work, but you can't really plan for them by their nature. So how do you balance those?

Alice Bartlett: It is really hard, actually. What's hard is that when I - I'm usually so busy that when I have a gap, I'm like, oh my God, what do I do now? Oh I've got this hour. I mustn't waste it. Oh my God, I'm so busy. Oh and then I end up not doing anything. And it's just - that feels worse than being really busy.

In terms of balancing - my team is just really great. I have these five principal engineers. They each know what they're doing. Every week I have an hour with each of them, and I have an hour with all of them at the same time. And so, a lot of these live things that are happening, one of them will be my point person on that. And so part of balancing my time is knowing, well, do I need to have a conversation about this right now, or can it actually wait till I have a 1 to 1 with Tatiana tomorrow and we can talk about it then.

Also all of them know enough that if I spend the next six months having one on ones with them about just work and they want to, they will be able to interject and be like, could we talk about me for a second? And that is an acceptable and important thing for them to say, so like just having a really strong team of people who I've worked with for a long time, who I know really well, we were peers and then I became the tech director. There's just a lot of respect there. But also they are really on it for their own domains. They know what they need to be doing, which means that I can leave things that are on fire - on fire enough that they can be left to a couple of days when I have a 1 to 1, instead of spending all my time trying to get up to speed on something that I know is being handled by a principal engineer. I just need to trust that if something really needs to be escalated or I really need to be brought into something right now, then they will, but otherwise they will tell me, they will give me an update in a 1 to 1 and that will actually be fine.

Handling Stress and Dark Side Behaviours as a Leader

Charles Humble: I think that's such great insight. Actually. I think that trusting the people around you to bubble up when things are really important and crack on with another, is, I think, a really key part of it. Actually, I have a sort of vaguely related question, which is, do you have any advice for when you yourself are not at your best? So I think I mean, certainly for me sometimes that might be outside stuff, like things that are going on with my children or something like that, which is making it difficult to maybe be as focused as I would like at work or maybe I'm a bit stressed and I can be a bit less empathetic or a bit more flippant when I'm under stress. I'm just curious if that's something that you experience and if you have any thoughts on it.

Alice Bartlett: Yes. I'll tell you what I do when I'm stressed. I am bad at keeping secrets and I - we all have these things that we do when - natural impulses that feel just like who we are, that we can't - that when we're in a professional context, we can keep on top of provided we're not tired, we're not overwhelmed by something else. And then when you've got less weight to keep on top of - to remain professional and to remain present and keep on top of these bad habits or bad impulses, they come out.

And so the first thing is to know what your bad impulses are. For me, I know it's gossiping and telling people things like thinking out loud too much, saying too much stuff, all of that. So know what your bad habits are and then when you can feel the bad habits coming, just make - for me, it makes yourself unavailable to talk to only the people you need to talk to. And especially if you've got people that you know are going to bring out these bad habits more - just find ways to limit the interactions to what is essential while you get back on top of whatever it is that's creating this hole in your reserves.

How to Give Difficult Feedback

Charles Humble: That's really, really good advice. I just thought of an article that I edited actually years ago for someone called Helen Bartimote, which is about dark impulses that come out when we're under stress. So I will get that link in the show notes as well, because it overlaps and it's kind of interesting. Do you have any advice on where you've got to give difficult feedback? So how you approach, I don't know, telling someone that they may be underperforming or something like that.

Alice Bartlett: Yes. So the first thing is to prepare for the conversation. Don't just wing it. That's advice for me because I'm a real winger of things, but it's not appropriate to wing those. The next thing is to just remain curious about why - you're not telling someone that they're underperforming. Ideally they shouldn't be hearing that - that shouldn't be what they - they need to know that. But also it's not a conversation in which you go in and say you're underperforming. Here is the information. Why are they underperforming? What have I observed? What have they observed? It should be an agreement between me and the person that they are not meeting the current expectations. But there should also be some curiosity as to why that might be - not so that they can make excuses, but because people don't just underperform. They don't understand what's expected of them. Maybe something's going on that means that their performance has changed. What is that? Can we support that? Do they need something? Do they have an unmet need that we can help with?

Basically, I think that the most important thing is just to be really curious. And the second most important thing is understand what the difference between nice and kind is, because nice says, no, you're not underperforming. Don't worry, it's nothing, it's nothing. Whereas kind is telling someone that they're underperforming, making sure that they know, even though that makes you feel bad, even though you don't enjoy doing that and you feel like a bad person, because to let someone underperform and not realize it is going to be worse for that person in the long run, because they will eventually be moved along.

I think what I see in a lot of quite junior managers is just hesitancy — so one of two things — either you over index  you're underperforming. I'm a good manager, I have to tell you. Or you're too nice but not kind. I don't want to upset this person. So I - you get to the point where you have to say your performance is not meeting our expectations, but you can't because it doesn't feel kind. It doesn't feel nice. So you sidestep the issue.

Recommended talk: Early Days of Agile Development & Is Design Dead? • Martin Fowler & James Lewis • GOTO 2024

Architecture Change: From Spaghetti Code to Systemic Clarity

Charles Humble: Absolutely. You gave a very interesting talk at StaffPlus 2023 called The Journey of a Byline. And we'll link to it in the show notes, because I do really encourage people to go and watch. It's a great talk. If I try - and there's no point in trying to rehash the talk because people can go and watch the video. If I try and boil it down, it was basically you had a situation where you had a fairly, I'm going to say, spaghetti-ish system that was the results of lots of building and maintaining a system over a long period of time. And you had rendering bugs in this case in the mobile app. And it was really hard to tell where it came from because you had basically content transformation happening in lots of different places and a certain amount of duplication and so on. Is that a fair high level summary?

Alice Bartlett: Yes.

Charles Humble: Excellent. Okay. It sounds like one of those projects that I personally would have run a mile to avoid. It just sounds like, oh gosh, no. Once you ended up working on it, what was it that drew you to it? Why was it the right thing?

Alice Bartlett: Well, I was actually told to work on it by my then boss, who was a tech director, and she said - and I was really surprised because this is not really technically my bag. These architectural challenges, among my peers, the other principal engineers, I just felt there were some other principal engineers who are much more in tune with how our content rendering stack worked than me. I'd never actually overseen any of the editorial team's work. So the article - the team that works on the article page, none of that. So I really didn't know a lot.

And so I said why do you want me to work on it? And she said, because it's really important. We've got loads of stakeholder buying and you're the best at communicating things, and I need someone who is going to not go away and do all the work, but it's going to just look like a bunch of engineers have just run off over here. But someone that is going to keep the work in the light. People are going to be able to understand it, see what the value is and not feel like it's just happening and we're not - nobody's allowed to talk about it because ot's too complicated andtoo technical. And I was like, well, I agree, I am the best communicator. So fine.

I did that and it was just amazing. One of the things I did was make sure that all of my - I don't call them weaknesses exactly, but un-strengths —were counterbalanced by the team. Again, I got to pick the team and it wasn't like I forced anyone to do it. But when I was putting the team together, I could see really clearly who was really interested in solving this problem. And so I was able to go and ask them, hey, do you want to come and be the tech lead of this team? And it was great because there were a bunch of engineers who have just been cross with how spaghetti the rendering code was who were excellent engineers and exactly who you want to be solving that problem because they really care about it. And so I put together this team of highly motivated, very smart people. And we had a great time.

Charles Humble: It's interesting that you got the role because of your communication skills. Is that something you actively worked on, or is that something you're just naturally good at?

Alice Bartlett: No, it's a natural strength. I mean, that's not a very humble thing to say, but yes. Well, it's important that people know that because people come and ask me, how did you get so good at either being assertive and saying what I think or being a good communicator. And I'm like, I didn't have to work at them. So it's hard for me to give advice on how other people can be good at these things because I didn't have to work at them.

Charles Humble: Maybe another way to think about that was whether there were particular additional outcomes or other positive outcomes that came about as a result of you being, as you put it, good at keeping the working in the light and communicating with stakeholders and doing that sort of thing. Did you find other things that came out of the work as a result of that?

Alice Bartlett: I think it went further than it might have done. Because the team were already quite — I didn't have to do a lot of work with them to get them to proactively communicate about what they were doing. They were really keen to do that and keen to share it. I just gave them some pointers and shaped the output a bit. But it meant that other engineers in the business were interested and it meant that one of our - our initial goal was just to deal with the rendering in customer products. My team. But then one of the team that manages the CMS was like, oh, we render all of the content in our article preview in an entirely different codebase. We have just duplicated the code for article rendering on the site. And so every time we release a new article feature, we have to build it twice. Could we maybe use this rendering pipeline here too? And I think if we hadn't been communicating so actively, it wouldn't have been as easy to do that.

Charles Humble: Having worked on a lot of CMS’ as well, that sort of thing is gold, because it’s like “I can’t fix this problem because it doesn’t look like that in the damn CMS!” 

Alice Bartlett: That accuracy is really important for our editorial colleagues. So then they were suddenly like, oh, this is - you're able to explain to them what the benefit of this piece of work was, because we couldn't have done this with the previous pipeline. But now, because we have this single thing where all the transforms happen in one place, and we've made a systematized how an article can be, we can put that in different places. And it's easy. So that was really cool.

Charles Humble: Oh, that's really cool. So it was a fairly complete rewrite. In the end, it wasn't just changing a bit of rendering code somewhere. It sounds like you were basically rewriting the whole rendering system.

Alice Bartlett: Yeah, it was pretty big, but we broke it down into smaller pieces. It's still - it's finished now, but the initial pitch was six months of work, which we did. And then we got to the end of the six months and were like, well, we should - here's some more stuff we definitely need to do. And we kept it going like that. And I don't think if I had said, can you fund two and a half years of work please, anyone who would have been like, sure, absolutely sounds great. So you need to — this is getting stakeholder buy-in. But basically, if you're asking for more than six months of anybody's time at the FT, it's going to be a no unless it's a really big, obvious commercial upswing, which never is with an engineering-type problem. That's really hard to prove. Especially again, especially as not only do you have to evidence it, you have to make it more convincing than all of the other stuff.

Charles Humble: Because at the end of the day, business stakeholders are basically trying to assess that priority against a whole bunch of other things. 

Alice Bartlett: And we do get some leeway. People understand that software needs to be maintained. We don't have to convince anyone of that. It can be hard to convince people of sometimes the extent to which it needs to be maintained.

Charles Humble: It's an interesting point, though, because if you're doing what effectively ends up being a major reimplementation and you've brought engineers and put a team together to do that, and then presumably at some point that project is done and the engineers go off to do other things, and then you've got basically another system which now needs maintaining. So who does that transition to? Who maintains it afterwards?

Alice Bartlett: So that's the platforms team in customer products who are maintaining all of the shared code, basically.The article - the storytelling team, I think, also have a bit of this pipeline as well. So that does already exist as a shared - it's a reliability team and a platforms team that are both — their stakeholders are the other engineers in the FT rather than people in editorial.

Charles Humble: Right. So is there a process to handover from development to platform, or what does that handoff look like?

Alice Bartlett: Well, I took - some of the people who - this was deliberate, but some of the people who worked on the rebuild were from the platforms team, meaning that - I mean, that is a way of shortcutting the not invented here. Why do you get to do all the fun work and then you hand it over to us to maintain it forever? That attitude, which I completely - I hate it when people try and get some funding for a fun piece of work and then go, oh, we've done this now, and you have to maintain this thing forever.

Charles Humble: Yes.

Alice Bartlett: It's always a downer.

Thinking 2-3 Years Ahead

Charles Humble: So you said again in your tech director job that one of the bits of that role is thinking about 2 or 3 years ahead. Talk to me a bit about what - how do you do that? What are you doing? How do you keep up to date? What's the process for thinking ahead?

Alice Bartlett: It's fairly unstructured, but I'm generally looking at the FTEs... I don't think it's giving away any commercially sensitive information to say that we're looking at our quite wide product base. There's the Financial Times, but then we have 15 publications, trade specific publications like The Banker, the Investors Chronicle. We also have an events business. There's lots of different stuff we can sell.

But at the moment we don't have a single customer view or the ability to cross-sell or the possibility of asking anything about our events and people's data. Who went to an event? Do they also have FT subscriptions? Should we be trying to do much more smart things if you joined up all this customer view together? But technical architecture currently in no way supports that. It's really complicated.

So thinking about that problem and how we approach it is what we should be doing. That's not my job because that's a commercial strategy. But I know that's the commercial view. So I'm thinking about the engineering effort. What are the technical limitations to us being able to fulfill those things? How can I prioritize those now? Because when people start asking for this, I won't be able to say, "Well, we are in no position to fulfill any of the things you just asked for, but I'll start working on that. And in two years time, maybe."

That extends to the whole of technology. I can't really do much about the single customer view because customer data is not in my area, but we all need to be thinking about that kind of problem.

Recommended talk: How to Bake a Change • Daniel Terhorst-North • GOTO 2023

The Impact of AI on Software Development

Charles Humble: It feels like a really interesting time in technology at the moment. Both the job market, but also what's happening more broadly with AI. There are differences of opinion about how much impact that is having on or will have on programming, but it's there and it's a topic of conversation. I was just curious to get your perspective on the overall situation.

Alice Bartlett: The main thing that I worry about with AI is how... when you are in a transitory phase like this, I've got a lot of senior engineers who were trained the old fashioned way, without AI copilot type things and are really able to see what is good about the AI created code that they're looking at and what isn't. They're able to really be very good judges of that.

Then I'm also seeing more junior people who are less able to distinguish between good code and bad code. This is the same in any job — anybody whose profession involves some aspect of creating text. Writers can see what good GPT output and what bad GPT output is.

So what currently I'm worried about is the more senior people's job becomes... because the volume of code you can write with GPT or copilot or whatever is so much higher, your senior engineer's job becomes a lot more about reviewing these large volumes of not necessarily great code, especially as more junior people aren't really able to see what's good and what isn't.

But that's a temporary phase, because eventually your more senior people will age out and you'll just end up with a different way of writing code. I kind of can't really tell whether that different way is better or not. Because maybe if the code basically works and you never really have to reason about what it's doing, and no one cares about the code being not very elegant, for example... elegance is important when a human has to read it and debug it. But if no human ever has to go near it because it's all AI around everything, then maybe that doesn't matter. But I don't know what the actual outcome of that would be in terms of software quality. It seems bad, but also that's because maybe I'm old fashioned.

Charles Humble: That's really interesting. I've been in IT for 30 years at this point. Over that time there have been these moments where we've moved up a level of abstraction essentially. Not as many people writing code in relatively low-level language like C or C++, to something like Java or maybe C#. As you go up that abstraction ladder you lose more of an understanding of what the machine is doing. Most of the time that's okay. Sometimes it's not — if you're working on very high performing code, maybe then that abstraction can be a problem. But for most systems it doesn't really matter.

But I can remember old C++ greybeards getting very annoyed about the fact that nobody knew what was going on under the bonnet anymore. I wonder if it's a bit the same thing, but I also worry because I'm also a writer. I've seen a lot of very badly written stuff that's been sent to me, that's obviously been written by an AI and editing it is joyless. I worry about what that does to a field. Whether you lose expertise along the way. You lose the ability to appreciate  is code good or is it not good? And when that matters, that feeling or judgment maybe gets eroded.

Alice Bartlett: I think there are more acceptable applications of it that I'd be less worried about - like generating test data. Creating tests for software you've already written, or if you're doing test-driven development, then generating the code, and as long as the code always passes the tests and your tests that you wrote fully meet the acceptance criteria, then that could be fine.

But it's a really different way of working. Your expectations of your peers for peer review have to be quite different because you would say, "Don't read any of this AI generated code. It's just a waste of your time. Spend all your time on the tests. And if this code passes those tests, we all agree it doesn't matter what the code is doing or how it was written."

But that's so different to how the teams that are writing software currently work. I find it hard to imagine that's where I will get to without some deliberate decision to do that, instead of writing a load of code in GPT or copilot, writing tests in copilot - everything is just AI’d.

Charles Humble: There are all sorts of challenges that come up with AI as well, because if you have a hybrid situation, AI will tend to lag behind what is currently idiomatic in a given language, for example, because it's trained on what's effectively legacy code. So if a new version of a framework or a language comes out, the code it's writing is going to be behind the curve. If you're not reading that code, it doesn't really matter. But if you are, that starts to be quite difficult - you end up with a sort of mismatch of code within a codebase, which is not great.

Alice Bartlett: Exactly. So I'm trying not to be too much of a doomer about AI because I think you can just regard it as a tool. It's how skilled the hands that wield it are. But I'm nervous.

Charles Humble: Me too. Thank you very much indeed. It was really great to chat to you. I really appreciate your time.

Alice Bartlett: Great. Thank you very much for having me. It was lovely to chat.