Blog

iSAQB Software Architecture Gathering

Independent Consultant and Author
Published on August 19, 2026

Beyond Red Tape: Sarah Wells on Governance That Helps Teams Move Faster

1. Do you have a theory why "governance" and "policy" tend to associate with negative sentiment?

I think it’s because historically, organisations did not make it easy for people to do the right thing. They implemented governance as gates, and policies as documents to read, rather than guiding teams and providing automated checks early on.

There are two aspects to this. Firstly, when you have people whose job is to ensure compliance, they will do that. It feels like the Dev vs Ops split we had before the DevOps cultural change. You really want compliance teams who see their role as being part of a team trying to produce good quality software running in production!

And then, you want to catch things early: preferably, you want people to build things that are secure and compliant from the start. And that’s because stopping people at a later stage is friction, and means they have to redo stuff, and that is not interesting or enjoyable.

So, I think it’s completely understandable that there is negative sentiment around governance, and some obvious changes to make that will change that around!

2. Why can we not be totally unconstrained in software developing organisations? What are the worst outcomes of not having any governance?

Complete and rigid standardisation can slow people down because they are fighting against the tools they are using, and it takes too long to agree on solutions for novel challenges. For example, I have worked on metadata stored in a relational database because that’s what was approved, and it took us much longer to make progress than when we started to store metadata in a graph database (which suits that domain far better).

However complete autonomy can mean multiple teams solving the same problems, and problems that aren’t important to the business, such as hosting platforms, observability, CI/CD pipelines. I also believe there are some areas where you simply can’t allow everyone to make their own decisions, for speed, cost or security reasons.

For example, when you are investigating an issue in production, it’s going to be much more difficult if it turns out most of your logs are in one log aggregation platform, but one team has decided to use another. You can’t easily link everything together.

And there are things I’d expect every team to comply with. For example, the way that they handle PII data, or a requirement to patch vulnerabilities within a set timeframe. Getting these things wrong can be costly - GDPR breaches can lead to fines up to €20 million or 4% of annual turnover! And security incidents can be very expensive.

3. What if people argue about a policy repeatedly? What is the right framework for changing constraints?

There are two reasons people will end up arguing about a policy. One is about genuine differences of opinion about whether it’s a good policy. I’m thinking about the example of password rotations for standard user accounts. Often a policy, no longer supported by the National Cyber Security Centre or NIST because it makes people less safe.

The second reason is because it adds friction and makes it harder to achieve their goals. And there, the question is whether you can remove some of that friction.

In an organisation with the right kind of culture, you learn from your own experience and from other people’s, and so I’d hope that you end up with a small set of really important policies in place.

4. How democratic should governance be in companies? Should we have representation rules and majority votes?

I think people responsible for governance should welcome feedback, and provide ways for that to happen. Representation is a good way to do that - create a forum for people with an interest in getting governance right, because that builds up trust.

However, I don’t think voting is the way to decide on governance. Ultimately, some group has this responsibility for keeping the organisation secure, keeping costs down, and allowing teams to deliver business value. They should have autonomy too in how they do that.

5. What is the ratio of developing good policy versus communicating/explaining it when working in architecture governance?

In my experience, people do not communicate enough about the things they define or build, whether that’s teams building tools, or those defining policy. You work on a project, get it “finished”, send one email, and then that’s very likely it. But so many people will miss that single communication. You need to repeat the message, and also send it in different ways. At the Financial Times we used email, slack, All Hands meetings, posters in the kitchen, example code, internal conferences. Every opportunity to pass on the message. It’s still not as much of a time commitment as working on the governance, but it’s an essential step to making that work valuable.

6. How do you follow-through on enforcing non-automated guardrails (e.g. documentation)? Is there a nicer framing than audit (or review)?

I think so! A good start is making the current state visible to people. We did this at the FT for our runbooks (information used during production incidents). We worked out which information was the most critical, and scored each field and created a sum across that service, for the team, and for the group within the FT.

When people can see how to improve a score, and which information is the most impactful, it makes it more likely that they will fill that information in. And the slight gamification of being able to see how you compared with other teams also helped nudge people to provide more information.

You can start with that, and then iterate - for example, to say that the most critical systems have to get to a score above 85%, or have particular fields completed.

I like this kind of approach because there is never really an audit “activity”, there’s just a gradual expectation of things getting better and the ability to see where people aren’t making improvements.

Of course, sometimes, you still need a big red flashing light: “this needs fixing now”!