# Sarah Wells: Governance, Platform Engineering, and AI Strategy

**Podcast:** The InfoQ Podcast
**Published:** 2026-07-13

## Transcript

The decisions you're making right now about AI adoption, architecture trade-offs, and how your team works together will shape your systems for years.
Getting those calls right when the landscape is shifting this fast is hard.
QCon San Francisco has spent 20 years connecting senior engineers with practitioners who are a few steps ahead on the same problems.
This November 16th through the 20th, 60-plus speakers across 12 tracks will share what's actually working in production and what isn't.
No hidden product pitches, just senior practitioners helping senior practitioners.
Learn more at QConSF.com.
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.
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, you're 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.
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.
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?
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 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.
So what I hear you're saying is this is a little bit about avoiding certain risks.
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 that'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.
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.
Something done to you.
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 all experience 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...
positive contribution to the process in the eyes of the people who you are hopefully helping?
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 and 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 CICD 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.
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 a.m.
in the morning.
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.
They could still have...
problems with GDPR if they screw up with personal information.
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.
But if you get it wrong, it could be financial panic.
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.
I think what I'm referring to is reputational risk.
Yes.
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?
Yeah, I mean, I'm in no way saying that the FD didn't take things seriously about that.
But for example, if you are 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 ones that will get a call at three 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 you thought that 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, 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.
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.
I had a guest, Matthew List, 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 the architects are responsible for anything that can't be written in a use case.
Yes.
So how does that fit with platform engineering?
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 is the natural place where architecture sits in the product team, as opposed to a platform team where you're making decisions that apply more broadly.
It sounds like you were doing architecture without calling yourself an architect.
How does it look from that point of view?
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 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 was, 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.
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.
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.
Could you give me an example of that?
to make it real concrete for our listeners.
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.
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.
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.
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.
Well, pilots have checklists.
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 travelling by plane much safer, and they were specifically looking at how do you make surgery.
and being in hospital much safer.
And I think we can learn from it definitely in software engineering.
And one thing I love 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.
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.
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 in an incident where something big has happened and you're thinking, I've no idea what's gone wrong here.
How do you incorporate all these ideas of checklists, of leveraging friction for 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?
Well, what are the precedents that we can take from the past and adapt to the future?
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.
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, we're 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 passed, you're in a good position.
I don't think we know exactly how all of this is going to work, but I'm really enjoying finding skills that people have published that really helped 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.
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 agent's 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 we've had a little five-year period where we said, oh yeah, 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.
When you say that, two things come to mind.
One is if the AI is writing a test, one has to be very careful with the instructions you give the AI.
Because if you tell the AI the test has to pass, the test can simply be assert true and the test passed.
So you have to be very careful of how the AI writes the tests and the instructions and maybe a separate agent is writing a test 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 an assembly language.
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 none of them 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.
Yeah.
Because how do you understand something?
If AI 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?
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 then 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 speccing 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 edges, 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.
But you have to worry about that with humans too.
Yeah, and 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.
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.
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.
Yes.
I was like, oh, we'll ask that at the end of every sentence now.
Vibe coding to me is sort of going to be like people who wrote Excel macros back in the day are.
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 asked it to critique itself, but it didn't naturally critique itself.
You had to ask it to critique itself.
I'd already asked it, have a look carefully at this code, because 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, oh, 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, or will we stop having software developers doing software development?
But I think even some of the people who are 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?
What 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 tests 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?
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.
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, I don't know how much 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 where 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 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.
We've clearly seen in many technological changes, people over-promise, 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 is going to do.
And there was 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.
It's like doing open heart surgery in front of an audience, figuring out how to do open heart surgery at the same time.
Yeah.
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 things going wrong.
But I think there are also plenty of places where LLMs in particular, and 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 lots 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 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.
There are lots of different format documents, but I want to try and find this cool 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.
You know, you made an important point.
I mean, most of us who are involved in this understand this, but LMs are not the only form of AI.
There's machine learning.
There's now...
talking 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 material 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 it's sort of AI good, AI bad, and the context gets lost.
Yes.
And also the AI confessed, the AI apologized.
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 just a fantastically good thing to be able to do.
The most amazing thing to me is it's awesome in what it knows.
It's awesome 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 dredge work.
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 sides 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 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 five minutes, 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.
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?
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, You know, I could never make anyone write documentation for other developers, but they'll write it for an agent.
So this has been a very interesting conversation.
I'd like now to sort of go and ask the question or version of the question that I ask all my participants, because I find the answers interesting and it lends a sort of a human aspect.
Yes.
What is your favorite part of being involved with architecture?
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's something that good architecture is about, solving problems.
What is your least favourite part of that involvement?
Sometimes you'll be in an organisation 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.
Do you feel anything creatively, spiritually or emotionally about that process?
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 solving a problem that's been solved before.
And we might be using components that we've done a hundred times because every site needs something to 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, yeah, 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.
What turns you off about that process?
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 like 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.
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.
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.
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?
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 Dan McKinney 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 like 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's basically Shazam for birds.
So you can basically record a bird song and it will say, that was a robin.
Yes, I know people love that.
Yes.
It is such a nice thing.
I just use it all the time because I just am curious.
What is that sound?
And I've learned so much about different birds just from using that.
So that's the technology that I love because it's free and it's really straightforward.
What about the process of architecture creation do you love?
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 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 approaches.
Let's just do one of them and being willing to go back and make changes if you have to.
So 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.
What about that process do you hate?
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.
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.
What profession other than the one you have now would you like to attempt?
So obviously in the last sort of...
five years I've written a book so you know for the I became a writer and 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 sat in a room thinking which is 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 it was in software engineering so I don't know.
I don't have anything that really stands out as this is what I would move into.
Do you ever see yourself not doing what you're doing now anymore?
Well, so I've been in the industry a long time.
I'm old enough to be looking to the point 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.
When a project is done, what do you like to hear from the clients or your team?
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 and actually going back and saying, did this solve your problem?
And maybe iterating and doing the next phase of work.
And I think the best thing that you can have is the sense that this has solved a problem for someone.
Well, thank you very much for being on the podcast.
This was a fascinating conversation.
Hopefully we can do it again sometime.
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.