Most engineering leaders think velocity problems are technology problems. They see slow deployments and assume the solution involves better CI/CD pipelines, more developers, or migrating to microservices. But as Sarah Wells discovered as she experienced the digital transformation of the Financial Times, the biggest constraints aren’t in your codebase; they’re in your org chart.

The FT’s journey from 12 releases per year to more than 20,000 wasn’t primarily a technical achievement. It was an organizational one. Their infrequent deployments weren’t happening just because of architectural limitations; they were happening because of change advisory boards, separate QA teams, and decision-making processes that treated every release like a potential catastrophe.

“If you don’t get those things right, you can’t move fast,” Sarah explains. The shift to microservices enabled zero-downtime deployments, but the real breakthrough came from dismantling gatekeepers, empowering cross-functional teams, and recognizing a fundamental truth: velocity is a cultural and business issue, not a technical one.

In this episode of Velocity’s Edge, Sarah and host Nicko Goncharoff explore why successful digital transformation requires organizational change alongside technical evolution. They tackle essential questions: How do you assess whether a company can make the cultural shifts required for velocity? What communication channels and forums do engineering teams actually need? How do you measure progress on transformation that goes beyond technology?

The conversation reveals why the fastest-moving organizations aren’t necessarily those with the best technology stack—they’re the ones that understand how to eliminate decision-making dependencies and build cultures that allow teams to move with autonomy.

Sarah Wells is a recognized leader in software engineering, with a focus on microservices, DevOps, and engineering enablement. A frequent speaker and the author of Enabling Microservices Success, Sarah brings extensive industry knowledge and hands-on experience in building high-performing engineering teams.

As in all our episodes, we speak in plain, executive-summary business terms, framing complex business and technology strategic challenges in context, using language that makes them more accessible and actionable.

Listen here, download it from Apple Podcasts, Spotify, or find it wherever you get your podcasts.

Episode Information
Season 1, Episode 5
Length: 20 minutes, 08 seconds
Host: Nicko Goncharoff
Guest: Sarah Wells
Recorded: VOXPOD Podcast Studios, Parsons Green, London
Engineer: Dayna Ruka
Editor: Dayna Ruka, Jeet Vasani

Episode Transcript

Nicko Goncharoff: Hi. This is Velocity’s Edge podcast. I’m Nicko Goncharoff, and with me today is Sarah Wells. She is lead consultant for engineering effectiveness at EPSD.

Today we’re going to talk about why velocity is a cultural and a business issue rather than a technical one. It’s a topic that is definitely fascinating to me, so I look forward to hearing you expound upon it at length.

Sarah Wells: It’s interesting. I started to write a book about microservices as an architectural choice, and I realized that being successful, adopting that– and successful means being able to deliver value fast for your business– was more dependent on the organizational structure and culture than the technology choices. Because if you don’t get those things right, you can’t move fast. My experience is that I worked for the Financial Times for over a decade, and during that time we went from 12 releases a year to over 20,000.

NG: Okay, hold on just one moment. Did you say 12 releases? Not 1200?

SW: No. We used to release, for the website, once a month on a Saturday, because we couldn’t do zero-downtime releases. So we had to freeze the website, because the FT is business and financial news, there’s not as much news happening, for example, on a Saturday as there is during the week. So we would just be not publishing new news, and we would freeze it, and we would do a release. And that obviously constrains how often you can do a release.

We changed the way that we built stuff. So we moved away from a monolithic architecture to microservices so that individual releases could be done with zero downtime. That let us move to releasing hundreds of times a day, because you’re doing lots of small releases. But we couldn’t have done that without some pretty significant changes to both the organizational structure and the culture that we had in the organization.

I think often, particularly now, microservices have become a kind of “late majority” thing. People want to build a system using microservices, but they’re not necessarily thinking about what the organizational structure and cultural implications of that are. So if you can’t give autonomy to your teams, then you’re not going to be successful with that as a choice. In fact, you have to be able to empower and let your teams make choices, whatever your architectural choice, if you want to be able to move fast.

NG: Right. And if you’ve been working with a monolithic approach, obviously there’s no structure that is going to enable people to do that.

SW: Well, you can actually be very successful with a monolith if you build it so that it’s modular, so that you have boundaries, and so that people can be very much working within a particular part of the system. The trade-off for microservices versus monolith is really about whether your complexity is in the build-and-deploy process or in your operational side of things. But for either of those to be successful, you really need to be able to have very coherent parts of the code that you can change, knowing you’re not going to impact something somewhere else. And you also just need that ability that individual teams can make a change and deploy it without having to wait for other people to do stuff, because that just delays business value from being released.

NG: Is there a template for the type of organizational structure that you need? Or is it more about just how people are making decisions? It sounds daunting to me. I’ve worked at both what, back in the day, they called “agile organizations,” where we could just make continuous releases. But I’ve worked at a number of companies with monoliths.

I have to digress a little bit. I think it’s fascinating that you said something positive about monoliths. I absolutely detest them, just because I worked more on the business side, and I wanted things for our customers or for our roadmap, and I was repeatedly told, “well, that’s six months off… that’s 12 months off… that’s a year off,” because everything had to be fixed for a single deployment. So maybe that’s just an old monolith, a creaky monolith.

SW: I think it depends. For example, Shopify have a modular monolith, and they make a lot of releases, and they’re able to release value fast, but it takes a lot more work. One of the reasons I like microservices is that the boundaries are actually very hard to go across.

In a monolith, you’re relying on people not reaching across the code into another part of the system. It’s harder to put any constraints in place. But in the microservices it’s much easier, because you can see when someone’s making a call to another part of the system.

You were saying, so what is it about the culture that allows you to start moving fast? There’s some really interesting stuff that’s mentioned in the Accelerate book that was published in 2018, based on the research from DevOps Research Association. It talks about what Ron Westrum talks about as business cultures, different cultures. Whether you have something that is a very bureaucratic culture where you have to get permission, you have to go up the chain and down the chain to do something, versus something that he calls “the generative culture,” where it’s really about information flow.

One of the things I think is essential is that you have a culture that allows teams to have the autonomy to make decisions. And so you want to set up a team so that they are cross-functional, they have all the skills in the team to build and deploy and operate their software, and that they’re allowed to do it.

The kinds of changes that we went through at the Financial Times, and generally speaking a lot of these things start with technology changes… The first thing that happened was that we had an investment in automation so that we could build a new server in 15 minutes. When I first joined the FT to start work on the content API at the FT, it took six months to build a server, rack it up, install everything, and have it ready to deploy code to. By the time I’d been at the FT three years, it was 15 minutes, and we were complaining about how long that took. We also invested in automated build and deployment pipelines so you could start to do a release with automated tests much, much more quickly than we had when I first joined. And all of these things are great, but unless you’re also prepared to let people do it, it doesn’t work.

So alongside that, we had some pretty big changes. We removed our change advisory board. When I was first working at the FT, I would go to a meeting on a Tuesday to get permission to release, to test on a Thursday, and then the following Saturday, perhaps we’d release the production. We moved away from that. And those kinds of changes are quite big, and they also impact people. There are people who have a job doing that, so you have to find a way to have the conversation with those people to say, “The job that you do has value, you just need to do it in a different way.”

It’s not a meeting where we all sit there and talk about what change we’re going to make, because you don’t have as much context on the change as I do. So really, you should be trying to make the change happen as close to the knowledge of the code as possible.

NG: Right. So, by introducing automation, maybe technical controls, you are eliminating some technical dependencies. But, crucially, you have to then reorganize the organization so that you don’t have decision making dependencies.

SW: Yeah. And actually that can be really difficult, because there will be people who have roles that are really about making decisions. So in a traditional environment, you may have an architecture group that make decisions about technology. You might have a QA team that do performance testing. Well, what we found was that you couldn’t have a separate team doing performance testing and still be able to do hundreds of releases a day. It has to be automated. It has to be part of every release that you do. So you want to still do it. You want people who have expertise in QA, but you want them to be embodying that in the standard build pipeline that you have. So you have these automated tests that run, rather than someone running through a script separately.

NG: Right. So in other words, you can shift them from, instead of running tests, to designing them.

SW: Yeah. There’s a lot of stuff about “shift left” with testing, with a lot of other things as well, with security. The earlier you can start thinking about these things, the better. And when you have a team that has a lot of the necessary skills in place, you can move much more quickly.

NG: On a related note, engineering effectiveness clearly impacts the bottom line. And I’ve seen this… well, it’s funny, I don’t notice it when everything is going well. But I definitely have noticed it when it’s not. But you still see boards or executive leadership teams looking at it as, “oh, this is a technology problem… we don’t have the right tools, maybe we don’t have enough people in IT, etc.” How do you go about showing them? And I know you can. How do you go about showing them that this is actually an organizational issue or a cultural issue?

SW: I think you start by looking at how long does it take from having an idea to having that idea live, because that’s normally something you can start to measure and say to people, “well, look, you’ve got a problem here.”

If it takes three months from you having this idea to having any part of it available in production, that’s a long time where you’re not testing it, where you’re maybe investing quite a lot of work without knowing if this is really valuable. So you want to try and make that a quicker process.

There are these DORA metrics that were identified by the people that wrote Accelerate: how long does it take from when you commit code to it going live, and how many releases do you do a day? You can start to look at those figures and say, “Well, look, we’re not performing at the high level. There are lots of people who are far better at this than we are. So maybe we need to look at that.”

The related thing is to start saying, well, there’s got to be an investment in the things that make developers productive. And I think this is something that took us a while to appreciate at the FT. If you’re letting all of these teams be fairly independent, autonomous, you can end up in a position where you’re asking every team to solve the same problems for very boring things. You do not want every team to have to design a CI/CD pipeline, and to have to choose their own hosting provider, and to work out DNS. You want to have a platform engineering team that’s building some of these common capabilities, but they also need to have a different focus.

I ran platform engineering at the FT for a while. Their focus needs to be, “what are we doing that speeds up everybody else?” Not, “I am building a platform that you must use,” but “what is holding everyone up? What can I do that’s going to speed them up?” And sometimes it’s not about building a platform, it’s about documenting how to do something on the hosting provider you already have.

NG: From an outside perspective, because you were talking about the FT, but if you’re coming to a new organization, how do you assess their ability to make a cultural shift? Just a little bit of background to what my thinking is: each department thinks, “I don’t have enough people. I don’t have enough resource.” I mean, you hear that all the time, right? But they’re not able to step back and say, “well, if you redeploy people in the way that you’re talking about, maybe you do have enough resources, it’s just that they’re not doing the right things.” Do you find that’s often the case?

SW: Yes. When I’m working with a new organization, I generally say, “Who should I talk to in the engineering group?” And that will normally be principal engineers, senior engineers, engineering directors… and you will find in that group that some people already know what the problems are. They’re just not sure how to make the right proposal that’s going to land, or how to explain it in a way that will make sense to their C-suite. You’ll talk to people, you’ll realize where there are particular bottlenecks, and you can start trying to tackle some of those.

And often it can be about communication. It can be as simple as, there are these two groups and they don’t actually talk very often, but if they talked a bit more often, that would break down some of those barriers, and you’d be able to make better progress. An example I had was an organization where the infrastructure and platform engineering and the product engineering teams didn’t have any kind of regular forum to talk. There’s a lot of space there for there to be a gap where you don’t understand the intentions of the other group. And as soon as you have that regular conversation, you realize you’re actually all trying to solve the same problems. You are trying to help the business move forward.

NG: One of the themes in this season of Velocity’s Edge is trying to give people who are listening a couple of immediate and cost-free steps that they can take to fix problems. So one of these, and I mean, it almost sounds too obvious, one is: if you’re having problems, maybe your first stop should be the engineering team. But also, analyzing whether they have the space or the forums to communicate with each other. Is that correct, or would you rephrase that?

SW: No, I think definitely looking for “are there the right communication channels?” And some of that is about things that are above a team level. You really want there to be people that are interested in operational matters. And maybe they have a meeting once a week where they talk about “what are the things that we’re really struggling with?”

At the Financial Times, there was a monitoring guild for a while, because we effectively realized that our monitoring was not very good, and driven by the infrastructure team. I joined this as an engineer. I was a principal engineer at the time, but I was really interested in understanding what was going on in the systems I was having to support in production. And we would meet weekly, and we’d talk about how we were going to improve this, and really we were looking at how do we introduce observability into our systems. So not just “we’re monitoring,” but “how do we know what’s going on?”

And we met for about maybe six months to a year. And then we said, “actually, we’re pretty happy that this is now on a really good footing. We don’t need to keep doing this.” So setting up those very specific, or encouraging people to set up these very specific, groups of people that have a common interest to solve a problem can really work brilliantly.

NG: I have to say, I love the fact that you set up a technology oversight group and called it a “guild.”

SW: The idea comes from, there was a very influential blog post about the Spotify model, which it turns out Spotify never actually followed. It was an aspirational thing. But they talked about guilds and chapters, and the idea of the guild was all the people who are in a particular role or have a particular interest get together and are trying to improve that. It is that idea of “we are the experts in this area, and we’re going to make the best stained glass windows,” that kind of thing. It’s very influenced, I think, by that idea of guilds of craftsmen.

NG: Fair enough. Having lived in the UK for 15 years, I also just thought it it sounds like a uniquely British take on organizing high tech.

In terms of these types of transformations, have you witnessed any or been aware of any that haven’t succeeded? And if so, why?

SW: I have to say I spent a long time at the FT, and that was a successful transformation, even though it took us maybe five years. Because from start to end, you’re getting value along the way. Since then, I’ve generally been working as a consultant, so you don’t get to see the whole of that. You get to be there long enough to see whether it’s heading in the right direction.

I’ve definitely seen, or had conversations with people, where there is a general feel that, “this is just a technical problem… this is just a problem with our engineering team.” And for me, that’s a sign that this is not going to work. Because if you don’t actually have people in the leadership roles understanding that there is broader change that needs to happen, it’s very unlikely that you’re going to be able to do it.

If you’re in those kinds of organizations, you might be able to make improvements in terms of automation or the engineering tools that you have, but eventually you’re going to hit the point where culturally, people can’t imagine working differently.

I’ve had a discussion with people in an organization where they’re basically convinced that, “we can test to the point where we know that anything we release is going to be fine.” And for me, that’s fundamentally impossible. It’s a very different mind shift. And the idea that that’s why we have our change advisory board, so that we can have this conversation to make sure that when we release something, it’s going to be fine.

I am familiar because I ran operations at the FT for four years. You can’t expect everything to work in production. Even if your code is perfect, something else will go wrong.

Some of the biggest outages we had at the FT were third-party providers, like our DNS provider or our CDN. It’s still, for anyone that uses the FT, it’s indistinguishable from there being a problem with our website. You still have to be able to deal with that and have workarounds and have a plan for it.

I think your transformation will fail if the engineering leadership can’t see the value in why you would want to do this. That sense of “the engineers just want to do fun stuff.” Actually, most engineers want to solve problems. I’ve done some consultancy where everyone felt, “well, the engineers never know things go wrong, and no one seems to care.” And it just turned out to be because when things go wrong, you open a ticket in a JIRA board, and actually the engineers don’t find out about it for a couple of days.

As soon as we introduced a Slack channel where people could say, “hey, I think there’s something wrong with the website,” the engineers will be straight on it. And the CEO said, “This is amazing. The engineers really care.” And it’s like, yes, they’ve always cared. You just didn’t set it up so they could do that support.

NG: Right. We’re talking about a cultural and business mindset, and cultural and business transformation needed to maintain or accelerate velocity. But there are objective ways of measuring that progress. That’s the thing. It’s not abstract, actually. The DORA metrics are, for example, one way of objectively measuring the improvements or quality. Is that correct?

SW: Yes. And they are good when you start from a position where you don’t release things very often. What we found at the FT is actually quite quickly we were doing regular releases of small changes, but we still had a lot of work that we needed to do. So DORA wasn’t the best way for us to track from that point. I’m interested in SPACE, which is another set of metrics which considers more how people feel in their role as well. Nicole Forsgren, who was involved with the original DORA metrics and Accelerator, has worked on SPACE as well.

I think you need to look at developer productivity across a lot of dimensions to get something that tells you how you’re doing, and you need to actually consider that this is something you care about. Because I think there’s still a subtle thing at the back of “why should I care if my developers are enjoying themselves?” Well, what you should care about is that they’re able to do their work. And also it’s really expensive to hire and train new people. So like, maybe make it so that they want to stay.

NG: Yeah. And also reassure them that all the effort that they’re putting in every day is going toward, one: something they care about; two, something they signed up for. That’s another topic around consistency and strategy, and balancing strategy versus feature development, etc., but we’ll save that for another time. Thanks very much for joining us today.

SW: You’re welcome. I really enjoyed it.

NG: I’m Nicko Goncharoff. Thanks very much.