Governance in the Age of AI: A Conversation with Sarah Wells

Transcript

Michael Stiefel: Welcome to the Architects Podcast, where we discuss what it means to be an architect and how architects actually do their job. Today's guest is Sarah Wells, who is a technology leader, consultant, and conference speaker, with a focus on engineering effectiveness, microservices, incident management, platform engineering, optimizing for flow, and technical strategy. She has over 20 years experience as a developer, principal engineer, and tech director across product, platform, SRE, and DevOps teams.

She spent over a decade working at the Financial Times as it transformed from 12 releases a year to more than 20,000, embracing autonomous, empowered teams and adopting microservices, DevOps, containers, and platform engineering.

She's the author of the O'Reilly book Enabling Microservice Success: Managing Technical, Organizational, and Cultural Challenges. It's great to have you here on the podcast, and I'd like to start out by asking you, were you trained in any area of architecture? It's not something you decided one morning, you woke up and said, "Today I'm going to get involved with architecture".

Getting Interested in Architecture [01:54]

Sarah Wells: I think it happens the same way for a lot of software engineers is you start off and you're just doing a small part of a system, and you get a very tight spec, you know, at junior, and then as you get more senior, you start to think more widely. And then at some point, you basically go, why are we doing this this way? This doesn't seem sensible. And that's the point where you start to be thinking architecturally. You've had enough experience to recognize things that seem to be good choices and things that were bad choices and to basically feel the frustrations of decisions that were painful and hard to undo. So, I think that's how I've seen people move into architecture. It's certainly the way it worked for me. Although I never officially had an architect title, I definitely started to care about those decisions and to really want them to be made well.

The Intersection of Governance and Architecture [02:42]

Michael Stiefel: But then you sort of transitioned or took the perspective of governance looking at this? How did those two things mesh together? Was it a fight or was it a cooperative endeavor?

Sarah Wells: So, what happened was I was a principal engineer leading the team that built the content API at the Financial Times, and we were adopting microservices. There were several parts of the FT that were adopting them at the same time and and actually, there was just a big contrast between the teams that were trying to build microservices and our centralized teams like our architects, some of whom weren't embedded in the teams, and so they were making decisions that didn't necessarily fit. But there was a lot of governance, like here are your choices of database that you can use, here are your choices of architectures.

I then ended up moving into a role as a director of engineering in charge of operations reliability and ultimately platform engineering, and actually part of that has got to be looking at how you govern things. By which I mean, how do you decide how much standardization to have? How do you avoid some parts of the system doing things completely differently or building things three times in completely different ways because there's no common view of it? So, naturally, governance for me came out of, I can't do a good job in my platform engineering group unless we have some way to try and be more consistent.

Adapting Governance to Organizational Needs and Risks [04:06]

Michael Stiefel: So, what I hear you saying is this is a little bit about avoiding certain risks.

Sarah Wells: Yes, I always think there are a couple of risks. There's the security risks, there's the cost. You know, you can end up spending a lot more because you're doing things three different ways. And then there's just the complexity. The complexity of doing things differently makes it very hard for people to move between teams. It makes it very hard to build common tools or frameworks that could help people. So, it was really about, well, this is slowing us down, it's friction. I really would like us to be able to build new features and products without having to invent everything or having to work around the differences between the way different groups do things.

Michael Stiefel: Because when I hear governance, the word red tape, the word bureaucracy appears, or sometimes it comes in the terms of enterprise architecture, where we view things from the trenches, and even the architects in the trenches view this as something that's getting in our way.

Sarah Wells: Something done to you.

Michael Stiefel: Because what you're saying makes a lot of sense. If every team is using a different approach, a different language, a different database, it becomes very difficult to move people around and have cross-functional teams and have backup roles. And certainly we've all experienced governance as red tape, this is not something that's just a made-up fear. So, how do you deal with that? How do you become a positive contribution to the process in the eyes of the people who you are hopefully helping?

Non-Functional Requirements in Platform Engineering [05:46]

Sarah Wells: I feel like we moved from infrastructure and operations teams to platform engineering, and it was very much like the move towards DevOps. You start to see yourself as one group, and you're there to enable, you're there to make things easy for people. So once you start to think in terms of being the platform engineering team, you're looking at governance as well, there are things we need to do because it's for the good of the company. You do not want to be having to pay a large amount of money for GDPR violations. You don't want to be spending a fortune on cloud because everybody's just spinning things up and no one's ever shutting them down again.

So there are things the company cares about. You just want to think about the guardrails you put in place because actually a lot of the time, developers in different teams are repeating work because they don't know that there's something that they can already use, or it doesn't quite work for what they need and they don't have the ability to feed that back. So, I want engineering teams to be building their own solutions for things that are exciting and interesting and novel and that really help the business. I do not want every development team to have to build a CI/CD pipeline. That's really not the most exciting thing and it just isn't valuable for the company. So you start to think in terms of a platform and guardrails. They bake that stuff in, and they should bake it in, in a way that actually for most developers, you don't even notice that there's governance there. You just are guided to do the right thing at the right time without even understanding that you're following some rules.

Governance as Enablement [07:18]

Michael Stiefel: Viewing governance as enablement, as helping people, that's obviously different for different organizations because there are organizations like Netflix where my understanding is that each group can do whatever they want. They're just responsible. If it breaks, you get the call at 2:00 AM in the morning.

Sarah Wells: Yes.

Michael Stiefel: And there is the other type of governance that tries to have rules, have things that enable people. Does this depend on the type of projects you're doing? For example, at Netflix, they're not going to be fined by the government for some financial transaction violation.

Sarah Wells: They could still have problems with GDPR if they screw up with personal information. So I don't think any company can be entirely ungoverned, "you can do whatever you like". I think you absolutely have different levels of what matters to you depending on your company. One of the things we used to talk about at the FT was, we're not a hospital, we're not a power station, people don't die if we get this wrong.

Michael Stiefel: But if you get it wrong, there could be financial panic.

Sarah Wells: I'm not saying that we in any way didn't take things seriously, but I just think you have to sort of think about how rigorous you are about some aspects of what you're doing.

Michael Stiefel: I think what I was referring to is reputational risk.

Sarah Wells: Yes.

Michael Stiefel: Because the Financial Times does have a very good reputation for reliability and reporting, and people very often, "Well, they messed up here, how are they messing up in other areas?"

Sarah Wells: Yes, I mean, I'm in no way saying that the FT didn't take things seriously about that. But for example, if you were making a change to the layout of a page on the website, you probably are not thinking about that in as rigorous a way as we're changing the way that we do editing for articles. One of the things I loved about DevOps was, "oh, you build it, you run it". So, the idea is that you as developers should be responsible for the things that you build. And I think you build things entirely differently if you're the one that will get a call at 3:00 in the morning because it's broken. And what I've seen is that you are much more likely to pick a well-established technology that everyone understands, and only go for something novel if it really gives you something, because basically the really novel stuff is very hard to fix when something goes wrong because there's just no track record of people having used it in the same way.

So I do think that, like, "you build it, you run it" worked. But what's been interesting about that is you don't actually have development teams who all want to understand everything top to bottom. And this is where I think platform teams really help, because you start to divide that responsibility between we build a platform and we make sure the platform is running, you deploy your applications to it and you are the ones that make sure they are running, and I think that split actually works really nicely. But if you're building a platform and running it for teams, you have to say, well, there are things that your applications need to do.

We need you to write your logs to the common log store. We need you to make sure that you've got security scanning in place on the way to production, because otherwise you're asking the platform team to take risks. What I like about this stuff is you can say, okay, we'll do a lot of work for you, like we'll make it easier for you to build a new product and launch it, build a new feature, but there are some things we expect you to do. There's like a checklist of stuff you ought to have in place before you go live.

Michael Stiefel: I had as guest Matthew Liste a couple of weeks ago, who does the platform engineering for IBM, and one of the things I ask people who are involved in platform engineering, actually two things. One is how do the things that don't fit in a use case: security, scalability, all these things, if you have a DevOps mindset? Because for me, my back of the envelope definition of an architect is that the architects are responsible for anything that can't be written in a use case.

Sarah Wells: Yes.

Michael Stiefel: So, how does that fit with platform engineering?

Sarah Wells: So, I think platform engineering also sits within a lot of those areas. And so you expect to be thinking architecturally at the level of how do you host stuff, how do you set up DNS, how do you build monitoring? I think there's definitely an overlap. You expect to have architectural thinking in teams that are doing platform engineering. I think it's a natural place to do a lot of actual architectural planning, especially if you're working in an organization where you're building microservices.

A lot of the decisions you're making are about this deployment platform that you're going to put stuff on. And so within the product teams, there may be some decisions about are any of the data stores that we currently have available to us right for our use case? So, for example, there was a point at the FT where my team introduced a graph database. It really worked for what we were doing, we were doing metadata. Metadata is a graph. There are companies, there are people, articles, it's all part of a graph. We didn't have that as a central thing available to us at the FT, so we basically installed it ourselves. And I think that that is the natural place where architecture sits in a product team as opposed to a platform team where you're making decisions that apply more broadly.

Performing Architectural Duties Without the Title [12:38]

Michael Stiefel: It sounds like you were doing architecture without calling yourself an architect. How does it look from that point of view?

Sarah Wells: So, I think my experience of architects, say, 10 years ago, obviously things have changed since then, but there were very few architects who were working hands-on in a team that was delivering stuff. So, my experience of architects then was they would be thinking about architecture and writing documents to say this is the way we should approach something, but they weren't really feeling the pain that teams were feeling.

So, for example, the architects group recommended a particular messaging software like if you need to send out messages, use Kafka. And I think Kafka is a really great bit of software for particular use cases. It wasn't the right bit actually for the use case that my team had. There would have been better choices, but because you're trying to say here is the one approved software that we use, it just felt very frustrating. But the architects we had that were working in teams, they're helping you to make the right decisions, that was fantastic. But actually what happened at the Financial Times around that time was we moved away from having architecture as a role. We moved towards principal engineers and more than architects, and the difference was really that principal engineers are also expected to be hands-on in the team. They were individual contributors, they were leading technical efforts, they were thinking about architecture, which is I think an interesting move, a lot of architects became principal engineers. I became a principal engineer around this time, having not been an architect.

And that was great, and we expected people to do architecture within the teams they were in. It's interesting since I've left the FT, I know that they've recruited in at least a few architects, but to look at that overall thing, and I think that's something that you miss if you're only looking at architects in a team, you need to be thinking about the decisions that will cause a little bit of pain to every team, so no one's going to choose to do it, but actually they're good for the company. And when I was at the FT, I tried to do some of that because with my colleague, Rob Godfrey, we took over the tech governance group, which was effectively our architecture decision forum, and we defined a new process for it, and that was the forum for bringing forward architectural decisions that were going to impact teams more widely. I think that was a recognition that you do need to talk widely about the things that are going to impact people.

Governance as the Enabling Arm of Architecture [15:16]

Michael Stiefel: That sort of brings us back around to governance. So, I hear you saying, and tell me if I'm putting words in your mouth, that governance is actually an architectural function. It's the enabling arm of architecture. In other words, you need to have policies, you need to understand risk, you need to have steps on the way to production. There are certain boring things that are necessary that have to get done, and that is what governance is all about.

Sarah Wells: I don't think it's just architects, but I do think architects should care about it. I think there are other aspects, security, engineering, finance might be interested in some of the governance things that you do. I would like to focus on governance as something that enables people to move fast without worrying that they're going to do something wrong. I just want to make it really easy to do the right thing quickly.

Michael Stiefel: Could you give me an example of that to make it more concrete for our listeners?

Sarah Wells: So, we had an engineering checklist at the FT, we would have a set of steps that you should do while taking something to production, and we would try and provide tools that would just help you to do the right thing without even having to read those checklists or think about it. So, for example, we really wanted to have a record of every service that got created and who owned it, which team owned it, and we had a sort of registry for that. But the easiest way to make that happen is you make it so that you can't actually deploy an AWS resource that isn't tagged with a system code that exists in the registry.

And the nice way to do it is to allow people to create a very very small record for a new system because they don't know everything about it, but at least you know that the system exists, it's got this system code, it's owned by this team, and for me as an operations person as well, you know that if something goes wrong, you can go, okay, I can find the responsible people. So, you're making it quite easy to do the right thing, there are ways for people to spin up new resources and they automatically add that system code to it. It's a very small bit of friction that gives a good value to the organization.

Michael Stiefel: So, in other words, it's sort of, you leverage a small amount of friction to avoid a larger amount of friction down the line.

Checklists [17:40]

Sarah Wells: Yes, and also, you know, I had another principal engineer say to me when I was director of engineering that she loved the checklist because she knew that if she went through it and had done all these things, that she was good to go.

Michael Stiefel: Well, pilots have checklists.

Sarah Wells: The Checklist Manifesto is a brilliant book, and it's basically looking at what can we learn from the way that air travel has used checklists to make traveling by plane much safer, and they were specifically looking at how do you make surgery and and being in hospital much safer, and I think we can learn from it definitely in software engineering. And one thing I loved from the book was the idea that you don't write a checklist of all the stuff that everybody already knows to do. So our checklist wasn't, here's how you write code or write tests. It was, you maybe haven't thought about security scanning, maybe you've not thought about accessibility. Here's the checklist that tells you how to make sure you've done an acceptable job of this. A weird one for procurement, which most developers are like, I don't know when to get procurement involved, but if we have a checklist that says here's where you should involve them, here's how you involve them, and, more crucially, if procurement are demonstrably helpful, which they were, then it's a great checklist item.

Michael Stiefel: And obviously, the degree to which you have the details in the checklist depends on the risk involved. Software does not operate under pressure the same way a doctor in surgery or an airplane pilot in an emergency. You know, there you want the checklist to actually reduce the mental overload so they can react to what's important.

Sarah Wells: Well, and in software engineering, we have it in incidents. You know, it's a really helpful thing to have that framework of here is what I do when someone reports that the Financial Times website is down. And that is somewhere where there is that real pressure and it's terrifying as a software engineer to get involved on an incident where something big has happened and you're thinking, 'oh, I've no idea what's gone wrong here.

Governance with Non-Deterministic Learning Agents [19:39]

Michael Stiefel: How do you incorporate all these ideas of checklists, of leveraging friction to avoid greater friction, when you're dealing with learning agents that are not deterministic, don't have feelings of pride or wanting to necessarily do the right thing, whatever that would mean for an agent, and no one is with experience? So how do we get into this world? Are we just jumping off the edge of the cliff without thinking, or what are the precedents that we can take from the past and adapt to the future?

Sarah Wells: I'm going to focus on using agents in the software development process just because that's what I'm more familiar with. So, first of all, I just think we are eventually going to move away from looking at code and doing PRs and actually really understanding the code. I feel that's the way it's going because we've gone from writing the code to now teams that are getting inundated with PRs. So I feel we will eventually move away from that, but the things that are going to protect us are all of the things that were good software engineering practice anyway. So, what are the checks that we do before we push code to production? Do we have good tests? Do we have good integration tests? Are we scanning? Are we linting? All of these things together are going to be focused on how do we know that this is still working? Now, you do have the position where people are writing the tests with AI and they're writing the code with AI, and you have to think about how you capture that.

I feel that if you get to the point where you're comfortable that you have a set of tests that define how something works, you should be fairly comfortable to let the agent make changes, and if the test passes, you're in a good position. I don't think we know exactly how all of this is going to work, but I'm enjoying finding skills that people have published that really help me to go through the code that I've been working on with an agent and pick up bugs and pick up the wrong ways of doing things and look at security, and I feel that is going to be quite good.

The fact that you have AI in products where you can't predict what's going to happen with that, I find much more terrifying, to be honest, because I feel like once the agents have written the code, I'm now looking at a thing that's not going to change if I validate that and it goes to production, I'm happy with it. I do feel it's the same quality things that maybe maybe we've had a little five-year period where we said, oh, yes, you know what, developers can be responsible for quality and they can be responsible for performance testing and they can be responsible for everything and architecture. Well, maybe we'll just go back to having far more role-based assessments of whether something is good to go.

The Challenges of Understanding AI-Generated Code and Tests [22:22]

Michael Stiefel: When you say that, two things come to mind. One is if the AI is writing the test, one has to be very careful with the instructions you give the AI, because if you tell the AI a test has to pass, the test can simply be “assert true” and the test passes. So you have to be very careful of how the AI writes the tests and the instructions, and maybe a separate agent is writing the tests from the agent that's doing the coding. But the other thing that comes to mind is that I'm old enough to remember when people programmed in assembly language.

Critiquing AI Outputs [23:01]

And what happened was, as compilers got better and better, the assembly language became less human readable, because they were writing assembly language for the compiler and not for humans. Now, my point is, I don't know how many people out there who are listening to this understand virtual memory, understand page faults, understand assembly language, or know what I'm even talking about. But in some sense, that makes the point. Because how do you understand something? If AIs start writing code and they're only writing it for other AIs, how are humans going to understand this and figure out the problems that are in this code?

Sarah Wells: Well, and I wonder if it will get to the point where we are asking the AI to tell us how the functionality works and then we're saying this is the change that we want to make to the functionality, and we are understanding what the tests look like, and we have this test coverage, and not worrying too much. So, I'm currently doing some coding in Python. I've never written Python. I mean, when I say I'm doing the coding, the agent is doing the coding. But I feel quite comfortable that I'm specing it, and actually my software engineering skills, I know the sort of edge cases that I want it to look at. That's been very interesting. It's not vibe coding. I do look at the code when I need to, but I'm also mostly relying on the AI to write a lot of parts of this. I think it will be very interesting to see where we're at in a year's time because I would say that three or four months ago, before Christmas, people were using agents but they weren't totally all in, and I feel like there was a step up in quality where you can really do very good coding with agents. You still have to worry about whether something is doing what you thought it was going to do,

Michael Stiefel: But you have to worry about that with humans, too.

Sarah Wells: Yes. And I, I am actually finding that by picking skills that have particular personas and saying look at the security of this, look at the quality of it, look at the front-end aspects of this, is it well-designed? 'Grill me' is one of the agent skills that I've heard a few people talking about, which is basically, I'm going to do this thing, ask me all the questions that you need to know the answer for to understand exactly what I want to build. I've seen people talking on LinkedIn about we're using agents to do a lot of coding, but we're really concentrating on our rules for good architecture and making sure that we can explain what does a good architecture look like. I feel there's a whole range of things that in a year's time, we're going to go, well, of course I do these five things and it helps me to feel confident. It's fascinating, it's such a big change and it's still early days.

Michael Stiefel: I mean, you have to be very careful about the persona you give to the AI. Ask for critique, and what you're doing is very different from vibe coding.

Sarah Wells: I just wanted to jump in there and say I literally said to an agent recently, 'have a look at this, be hypercritical', and it found two bugs.

Michael Stiefel: Yes.

Sarah Wells: That was I was like, oh, I'll ask that at the end of every sentence now.

Michael Stefel: Vibe coding to me is sort of going to be like people who wrote Excel macros back in the day were. They're good up to a certain level of competence, but you have to distinguish between that and doing the type of programming or the coding that we think about.

And it's interesting from two points of view that you ask it to critique itself, but it didn't naturally critique itself. You had to ask it to critique itself.

Sarah Wells: I'd already asked it, 'have a look carefully at this code' but it's when I said, 'be hypercritical', it found something that it had not found before and I just thought, well, this is interesting. And I do think there's definitely a case where I am looking at what's being suggested and saying, 'ah, no, I don't like that, I don't like the table structure that you're suggesting there, it doesn't look right for me from my years of experience'. Like everyone was worried, you know, and I think still is worried, about, well, will we stop having software developers doing software development? But I think even some of the people who've gone very much into AI are starting to realize that what they need is a software developer using these tools to do stuff really quickly, rather than vibe coding it themselves, because at some point it has to go live. Without that experience, you can't make the judgment of is this a sensible plan?

The Impact of AI on Developing New Engineers [27:17]

Michael Stiefel: But you raise now the interesting question is, if all this coding is going to be done by the AI, guided by the experienced professional, those are the tasks that were traditionally given to junior engineers as their apprenticeship. So, where are all the future software engineers going to come from? And what is software engineering education going to look like in the universities or in businesses or elsewhere?

Sarah Wells: Well, so I think we have to also be really aware that at the moment, there are a lot of people who want to sell us on AI. And they also want to convince us that all of the lack of recruitment and all of the job reductions are about AI, when the end of zero interest rates has a lot to say with it, and also if you look at the number of people employed in tech, there were suddenly a lot of people recruited. And many of the jobs that are going are taking companies down to where they were at maybe three or four years ago. I will be interested to see in a couple of years' time whether it's the case that we're not recruiting junior engineers because ultimately, there are already people saying, don't know how much of this is a joke was, oh, we've recruited a junior engineer because actually it's cheaper than spending the tokens to do this the old way.

So, I think there's going to be a year or so when no one really knows, and maybe there won't be a lot of people working in junior roles for a bit, but then we'll see what happens there. I do think that AI for coding and for a lot of this sort of stuff is really good. Will it be economical? Because we know that it's costing a lot more to run than we're paying. Would I pay $200 a month rather than $20 a month? I definitely know of a few places that are starting to look at running open source models on their own hardware, and maybe you'll get good enough performance from some of those to still find it a beneficial thing.

Finding Out What AI is Good For [29:07]

Michael Stiefel: We've clearly seen in many technological changes people overpromise, there's a retraction, but in that process, we figure out actually what the technology is good for. Let's pick the most recent example. It's not like the internet, where people overbuilt the networks and they overpromised what this was going to do and there were a lot of failures. But it didn't necessarily impact the day-to-day business in the same way. Here, you're talking about people who have an existing product, who have existing customers, who have existing reputations and trying to switch out their processes, you know, it's like doing open-heart surgery in front of an audience, figuring out how to do open-heart surgery at the same time.

Sarah Wells: Yes. There have been a few people who've tried to bring in AI for their customer service and they've found people don't like it and it doesn't work that well. I think there are going to be lots of cases where people are currently using AI that ultimately there won't be that much benefit because it isn't reliable enough, it's got too much of a downside on the risk of it going wrong. But I think there are also plenty of places where LLMs in particular—I think we're really talking about LLMs because there's lots of other AI that's much more predictable. I think there are places where it's extremely useful. There are a lot of problems that you would never bother solving that if you have enough skill, you can solve.

So, lots of internal tools, particularly tools in development teams, people can just go, well, I've always wanted to fix this, but it was always a pain, but I'm going to do it. I've seen people doing AI with hack days where they have built stuff that will help them generate postmortems after incidents. That saves a lot of time. Gather together all of the conversations, create the document, suggest some actions. You're going to look at it. I think that you can generally use things internally where people will understand whether it looks good or not. It's a brilliant use case for looking at unpredictable documents, you know, there are lots of different format documents, but I want to try and find this core bit of information. That's better than regular expressions by far. So, I do think there's tons of things where it's not that risky to have it involved in your product. The bit where I would be worried is it's publicly available and people outside my company are interacting with it.

The Various Flavors of AI [31:29]

Michael Stiefel: You know, you made an important point. I mean, most of us who are involved in this understand this, but LLMs are not the only form of AI. There's machine learning. There is now talk about people developing quantitative models that are not based on the transformer model that LLMs are, but they're based on let's say fundamental physics or data, you know, in biomedical research or materials science where they're using very, very different AI models. You know, they're not probabilistic in the way the transformer technology is, because they're going to be put in situations where you can't be. So, yes, this is important for people because you know, you read the popular press and sort of AI good, AI bad, and the context gets lost.

Sarah Wells: Yes, and also, the AI confessed, the AI apologized, and it's like, the predictive text engine came up with the next words that it would say. It's amazing the way that you can have the conversation, but I'm just bearing in mind this is amazing stuff, I'm not sure about how the economics are going to work, and people are trying to explain to me that this AI has a soul, and I'm concerned about it. I'm still taking it with a pinch of salt, but I'm also thinking there's some very impressive things that you can do now quite quickly that are amazing. So I'm not a front-end developer, I've never—well, not since my very first years as a software developer, and that was so long ago that it was very much HTML tables.

I'm not a front-end developer, but I wanted to take a spreadsheet that had a bunch of proposals for a conference that I was reviewing, and I wanted to just be able to go through them one by one in a way that made it easy for me to read and where I could tick the ones that I liked. And I could generate that with an agent in 10 minutes, because I didn't care what color it was, I didn't really care the width of it, I could just get something that was usable for me to view things in a different way, and I really found that as just a fantastically good thing to be able to do.

Michael Stiefel: The most amazing thing to me is it's awesome in what it knows. It's awesome in what it doesn't know. And it's awesome in what it thinks it knows, but it doesn't really know. And you can't very often distinguish between all those three. But for the case that you just mentioned about reviewing those proposals and I've done similar things, it's a fantastic time saver. Even in putting together these podcasts, I obviously have to check the transcript manually, but then I have to find out what technologies were mentioned, where do I want to put the headings, where do I want to summarize. Actually, I have to review and rewrite what the AI that I use does, but it saves me an enormous amount of drudge work.

Sarah Wells: So I feel very strongly that I do not want to use AI to write. I don't want the creativity to be done by an AI, but I wrote this talk that I gave at QCon, and I asked the AI to look at the slide deck and say, "Is it flowing? Is there any bit where I'm moving between two slides and it doesn't make sense?" Also, have a look at the slide deck and get me a list of all of the things I've referred to, all of the links, and why I referred to them, so I can put it on my website. And those sorts of—I just wouldn't have bothered creating a bibliography of my slides because you always—I'm always running out of time at the end when I'm still trying to practice it. But being able to do that in 5 minutes meant that I just put it up on my website and said to people who came to the talk, "Hey, if you want to immediately click through to all the links, here they are". I just love the little bits of friction that get removed. It's going to be really interesting to see what people use it for in a year's time when people have had AI long enough, assuming that the economics haven't fallen apart, because I still am very much of the opinion that there isn't a plan for how you make money out of this.

Specifying Requirements for AI Coding [35:27]

Michael Stiefel: Yes, yes, yes. But you also raise an interesting question which, you know, when you use it for coding, how do you specify the requirements in an unambiguous way to the coder? And I think this is another unsolved problem, because especially when you find bugs in the field and what the AI has done...How does the AI modify its code or do we rewrite it from scratch?

Sarah Wells: It's true, but there are things that we know like saying, okay, we've got this bug, can you write me a failing test? And then fix the bug. And you can watch that the test fails and that the test passes once you've fixed it. You do want to look at what's going on so that it's not just an imaginary… I think there's a lot of improvement put around AI coding agents to make it so that there's a validation that there's something there. It all comes down for me to the things we already know are good about the software engineering process that good companies already do. If you've got a big ball of mud and you've got no tests and you've got no kinds of guardrails and you don't have any documentation, you're going to find it really difficult to do well with using these tools. But if you've got exceptionally good documentation, really good tests, you've got a very modular architecture, I think that that makes it easier for both humans and agents to do stuff.

It's really funny, someone said, "do you know, I could never make anyone write documentation for other developers, but they'll write it for an agent".

The Architects’s Questionnaire [37:05]

Michael Stiefel: This has been a very interesting conversation. I'd like now to sort of go and ask the questionnaire version of the questions I ask all my participants because I find the answers interesting and it lends a sort of a human aspect. What is your favorite part of being involved with architecture?

Sarah Wells: I love solving problems, especially creatively. As in, being creative in thinking about the problem and trying to work out how to solve it. I think that that is something that good architecture is about, solving problems.

Michael Stiefel: What is your least favorite part of that involvement?

Sarah Wells: Sometimes you'll be in an organization where the same discussions just happen repeatedly. You think you've agreed on something, but it turns out that it's slippery, you know, there wasn't anything written down and the person that never actually really agreed and then you just end up having the same fight. And I just that can be a very draining part of doing architecture in my experience.

Michael Stiefel: Do you feel anything creatively, spiritually, or emotionally about that process?

Sarah Wells: I want to broaden it to being the whole software engineering process to be honest. I feel like it took me way too long to realize that actually this totally is a creative outlet for me. You are doing things where you're creating something new. We very rarely solve a problem that's been solved before. I mean we might be using components that we've done a hundred times because, you know, every site needs something where you log in, every site needs you to display a list of things, but you are solving some problem and you're listening to people and doing that.

And so I think that, yes, there's absolutely creativity in the job. And I moved into software engineering as a second career. I'd been working in scientific and medical publishing before that and I did journal and book production. So this is like you get a manuscript, and you do all of the steps to take this through to being a book. And I enjoyed it a lot. But after six years, it's actually the same list of things that you do for every book. There's not often a problem that you need to solve in that. One of the things I loved when I got into software engineering was this is new and it's novel, or else we wouldn't be doing it.

Michael Stiefel: What turns you off about that process?

Sarah Wells: Oh, I'm going to go slightly sideways on this and say, I think that for a long period of time, I've worked in places where there was a very common pattern of what an architect looked like. And so I never considered that I was going to be an architect. No one ever suggested to me that I become an architect. And I think that there is a gender thing here, like you're a woman in software engineering, people are going to expect that you become an engineering manager. But I really liked solving problems and I think that I should have been encouraged to be an architect. But I think back and go, who were the architects in my organization? There were like 12 men and they all dressed identically. So I feel like there needs to be that sense of people recognizing that there are different aspects of being an architect and that architects may look different.

Michael Stiefel: And it also speaks to the fact that you have to start recruiting these people earlier in the process because if they're unaware of the possibilities, they're going to channel themselves in a direction that maybe they should have done something differently.

Sarah Wells: I would just like to encourage, if you're an architect, particularly if you're a man, particularly if you're a white man, to be thinking, how do I recognize people who have the ability to think architecturally and is my pattern going to find everybody that might be good at that because the thing that really works is sponsorship. And there's a really interesting thought about the difference between mentoring and sponsoring, and so mentoring, you're giving people advice, but sponsoring people means that you're in a room saying give this person this opportunity. Actually, you know what, we should encourage Sarah to apply for this architecture role because she's clearly doing that in her current position. That's what makes a massive difference.

Michael Stiefel: And this is important, too. When you're trying to nurture those architects, you also have to realize that not everybody is meant to be an architect.

Do you have any favorite technologies?

Sarah Wells: So I think in the technologies I would reach for by default in my working life, I'm going to go for the stuff that like Dan McKinley would call the boring technologies, wherever I can because they're well-understood, everyone knows how to use them, you can get going solving your problem more quickly because you install Postgres and you get going. You do the stuff that is straightforward, well-documented also really helps. I want it to be just—like if I go and look something up and it totally explains to me how I can call the API and it's accurate, oh my god, I'm going to use that again. But outside of work, I like the technologies that just have that sense of magic about them. I've got an iPhone and I've got a Mac, and I love that I can basically copy something on my phone and paste it on my Mac. That is just brilliant. I also love Merlin ID, so this is from Cornell, it's an app that is basically a Shazam for birds. So you can basically record a bird song and it will say that that was a robin.

Michael Stiefel: I know people who love that, yes.

Sarah Wells: It is such a nice thing. I just use it all the time because I am just curious. What is that sound? And I've learned so much about different birds just from using that. So that's a technology that I love because it's free and it's really straightforward.

Michael Stiefel: What about the process of architecture creation do you love?

Sarah Wells: I think it's that sense of I have made a decision here that is a good decision for the context that we're in and it's not overly complicated. So the simplicity, as simple as you can reasonably be while still solving the problem and not restricting things before you need to. I do think you can—that it's very easy as an architect to overcomplicate things and to build for the future, but it's that sense of recognizing the one-way decisions versus the two-way decisions and really focusing your efforts on the decisions that are hard to undo. And for the rest of them, I really love just going, you know what, these two things both look like reasonable reasonable approaches, let's just do one of them and being willing to go back and make changes if you have to. So I like, I actually really like the decision-making, and I do think actually that's one of the things that you can spot people who are going to be architects or are going to be directors and leaders in technology is a willingness to say, "I don't know everything about this, but I can tell you that of the five options, three of them are bad, two of them are okay. I'm going to choose this one, but I'm willing to go back". I think that willingness is a good marker.

Michael Stiefel: What about that process do you hate?

Sarah Wells: I was trying to think about this and I just don't think I really hate anything in particular. It's normally about how things exist in a particular organization. You know, I like to work in an organization that has an open learning culture. That is something where you are given the ability to suggest and make decisions and make change happen. I think that's really lovely. So I can't imagine going voluntarily to work in somewhere that's really bureaucratic because I just would find it frustrating. So I think it's about the organization, the culture that sits around your work that lets you do good work.

Michael Stiefel: What profession other than the one you have now would you like to attempt?

Sarah Wells: So, I think in the last sort of five years I've written a book, so you know, for the first I became a writer and that was something new and interesting to do. It's very different from being a director of engineering. There's a lot less meetings, for a start. You go from I'm in a meeting for six hours a day to I'm sitting in a room thinking. Thinking and trying to work out how to phrase something. So I guess I've done a little bit of that. And obviously I had a profession before I was in software engineering, so I don't know, I don't have anything that that really stands out as this is what I would move into.

Michael Stiefel: Do you ever see yourself not doing what you're doing now anymore?

Sarah Wells: Well, so I think... I've been in the industry a long time, I'm old enough to be looking to the point of that at some point, I won't be working anymore, and that's an interesting thing because you start to think, well, what does that look like? I think I'll still be doing stuff because I have a career that's a real portfolio career, I'm involved with conferences, I talk at conferences, I work with different clients, I think that's really reassuring actually to feel like I don't have to be working five days a week and then bang, I stop, I can just gradually fade out of working every day and I think that would be quite enjoyable. I find it interesting to do different things. Sometimes I'm working on projects that are really process oriented, they're really about the kind of management of engineering, so you're looking at how does this work in this organization, how can I help work out where the bottlenecks are and where we could try and push forward a particular solution, a particular way of working that might solve that. And sometimes I'm doing things that are much more architectural and I really like that switch.

Michael Stiefel: When a project is done, what do you like to hear from the clients or your team?

Sarah Wells: I want people to be like, "oh, you know, this is great, so much better than what we had before, it's a pleasure to use. I've got this idea of how we can improve it", you know, just engagement. I want the things that I've built to be something that people use, and that you get that feedback of actually you did solve the problem. Because I think there's so many things I've worked on in my career where we built something and it didn't go live, or it went live and no one actually used it, and I think that we've got much better actually in the time that I've been working in software at checking, at actually going back and saying did this solve your problem, and maybe iterating and doing the next phase of work. And I think that the best thing that you can have is the sense that this was a problem solved for someone.

Michael Stiefel: Well, thank you very much for being on the podcast. This was a fascinating conversation, and hopefully we can do it again sometime.

Sarah Wells: Yes, I've really enjoyed this. Well, we should maybe do it in a year's time and go, what were we wrong about AI? Thank you so much for inviting me, I've really enjoyed it.

Mentioned:

• Sarah Wells Enabling Microservice Success: Managing Technical, Organizational, and Cultural Challenges
• Atul Gawande - The Checklist Manifesto
• Dan McKinley - Choose Boring Technology
• Mathew Liste Podcast - Engineering Stable, Secure and Scalable Platforms
• Merlin ID (Merlin Bird ID App)
• GDPR (General Data Protection Regulation)