Software engineering governance helps teams make decisions, Sarah Wells said at Goto Copenhagen. She argued it should support value delivery, not hinder it. Poor governance slows progress and can increase costs. A technical strategy with a radar can help teams to make better decisions, and aligning with DORA capabilities can boost their performance.
Wells defined software engineering governance as the set of principles, practices, and tools that help teams make consistent, informed, and safe technical decisions:
Often, governance didn’t include tools; it was more about setting expectations. But tools offer an opportunity to help people do the right thing by making that an easy option.
Governance should be about helping teams to deliver value, not telling them off, Wells said. And it should keep the company safe, secure, cost-effective, and moving in a consistent direction.
Governance that requires coordination with external teams or waiting for approval can have a big impact on productivity and effectiveness, Wells said. But often people swing away from these processes and don’t think about what they might lose as a result:
Without governance, what will prevent you from releasing code with security vulnerabilities? Will you be able to quickly and easily patch code when you need to?
If you move to the cloud and let developers spin up resources when they need them (which Wells mentioned you should), then without governance, there will be servers running that should have been shut down or downsized weeks or months ago, costing you money.
Wells mentioned that, without governance to give you oversight of your software estate, engineers may have to manually deal with issues, preventing them from spending time on feature development. Without governance to keep technology groups aligned, you can end up building the same things twice or see teams using a platform that is on its way out of the organisation, because they don’t know that.
The DORA capabilities are practices, processes, and tools that are linked to high performance on the DORA metrics, and enhanced business outcomes for a technology organisation. The capabilities are linked to three areas: a climate for learning; fast flow; and fast feedback. We can learn from the DORA core capabilities when it comes to software engineering governance, Wells explained:
Any governance process that requires waiting for another team or person to do something is going to impact both fast flow and fast feedback.
For example, you might find that any project that introduces a new technology is slowed down because the architecture review process is unwieldy and takes weeks.
Some of the capabilities do relate directly to governance concerns, for example, streamlining change approval, and version control, Wells mentioned.
Wells argued that we need a technical strategy to align technology decisions and make better decisions. This is something a surprising number of organisations don’t get round to, Wells said, but when you have it, you need to communicate it frequently in lots of ways, so people get to know it well enough to use it when making decisions.
An organisational tech radar can also help, because it shows what is already being successfully used, or has failed, within the organisation – so teams can pick something from the first set, Wells mentioned.
People want to do the right thing, including people writing multiple policies that everyone needs to read or holding CAB meetings, Wells said. If you can get those people to work with platform or security engineering teams, you can use their knowledge to build a better solution, she added.
Wells mentioned that we need to bear in mind that if someone thinks their job is to run a CAB, it will be hard to cancel it. However, if they can reframe their job as keeping the organisation safe, it’s possible to find better ways to do that, Wells concluded.
InfoQ interviewed Sarah Wells about applying governance practices.
InfoQ: What are the drawbacks of change advisory boards?
Sarah Wells: Change Advisory Boards are groups of people from different parts of the business who meet to review and accept or reject software changes going to production.
They give the illusion of safety, but research shows that most changes get approved, and problems still make it through, so they don’t reduce the number of failed changes. They do however slow teams down, and we know that being able to release code when it’s ready is important for software engineering productivity.
InfoQ: How can we build guardrails and policies that work?
Wells: Start by thinking about how you can build them into tools and processes so it’s easy to do the right thing.
For example, we wanted people to add every new service into our service catalogue. Making that the place where you got a unique system code that had to be used to tag all AWS resources nudged engineers to do that at the right time: when they were about to go live.
