Governance is a critical aspect of any organisation, ensuring that we operate safely and effectively. However, I’ve observed that excessive governance can often hinder our ability to seize opportunities and respond to unexpected challenges. When surprises arise—be it a market shift, a product issue, or an internal complication—the time and cost to rectify these problems can escalate dramatically.
The Pitfalls of Over-Governance
From my experience, I’ve seen that much of the governance we encounter is self-imposed. This is particularly true in organisations that operate in silos or have a dedicated governance department. Here’s the crux of the issue: when governance becomes a separate entity, it often leads to local optimisation rather than system optimisation.
- Local Optimisation: This occurs when we focus on improving one aspect of the organisation without considering the broader implications. For instance, imagine a cog in a machine that’s struggling to turn because it’s jammed against other cogs. If we decide to remove the teeth from this cog to make it spin freely, we’ve achieved a local optimisation. However, this cog is now ineffective in driving the entire system.
This scenario is all too common when governance is treated as an isolated function. Decisions made in an ivory tower can lead to regulations that, while well-intentioned, fail to add value to the organisation as a whole.
Compliance vs. Overzealous Governance
Take the example of compliance regulations, such as the Sarbanes-Oxley Act (SOX). The intent behind SOX is to ensure transparency and accountability, but many organisations misinterpret this as a need to exceed the minimum requirements.
- Minimum Compliance: The SOX audit requires organisations to trace actions within their systems, but it doesn’t mandate that this process be user-friendly. A simple log file suffices. Yet, I’ve seen organisations burdened with excessive documentation and processes, all in the name of compliance.
In one instance, I worked with a US-based organisation that had a stringent compliance framework. Every meeting required notes to be sent to compliance for review. During a discussion about transitioning to Team Foundation Server, compliance personnel insisted on maintaining change request logs.
I invited them to observe how Azure DevOps functions, which maintains a complete history of every work item. When I asked if this was sufficient for compliance, they confirmed it was. We eliminated the need for change request work items entirely, streamlining the process and reducing unnecessary overhead.
Lean Governance: A Path Forward
This experience highlights the importance of lean governance. We must regularly assess our processes to identify and eliminate waste. Here are some strategies I recommend:
Organisational Hygiene: Regularly review policies and procedures to ensure they still serve a purpose. Often, we create policies out of fear, only to find they’re no longer relevant.
Compliance as Code: Where possible, integrate compliance requirements directly into your product. This approach minimises the effort needed to meet regulations while ensuring that compliance is maintained.
Focus on Value: Always ask whether a process adds value to the overall system. If it doesn’t, it’s time to reconsider its necessity.
Conclusion
In conclusion, while governance is essential for organisational safety, it’s crucial to strike a balance. We must avoid the trap of overzealous compliance that stifles innovation and agility. By embracing lean governance principles, we can create a more efficient, responsive organisation that is well-equipped to navigate the complexities of today’s business landscape. Remember, the goal is to meet compliance with the minimum amount of work required—no more, no less.
Governance is important for organizations to function safely. Too many organizations, if you’ve got extremely high levels of governance within your organization, you’re probably going to have a great deal of difficulty taking advantage of opportunities and dealing with surprises. A surprise, something that goes wrong in the market or your organization or your product or whatever it is, is going to take a long time and be much more expensive to fix than it needs to be.
Now, that doesn’t mean that you can’t do something because most governance is self-imposed. I’m going to explain that because it’s something that I’ve seen time and time again. In most organizations, especially if you’re siloed, if you have a governance department, this is even more true. Just like if you have a security department, you’ve weird security decisions. There’s this idea of local optimization rather than system optimization.
Sometimes when you look at just one thing and you make a change or make a fix for that one thing, you’re actually making a change that’s better for this one thing, but it breaks something overall in the organization. I really say an example is, let’s say you have a cog in a machine and you’re looking just at this cog and it’s slow to turn because it’s pushing against all these other cogs in the system. What would make this the most efficient cog possible? Well, if we delete all the teeth from the cog, then it can just spin freely, but now it no longer drives the rest of the system. It’s no longer part of the rest of the system. We’ve made a local optimization that makes this better, but it doesn’t help us overall.
That’s what often happens when governance is a separate department. When governance is a group of people in an ivory tower and they’re making decisions about governance for the sake of governance, they’re not making decisions about governance to provide value, safety, and security to the organization. They’re doing it for the sake of governance. What you find often happens is they take the externally imposed regulatory governance that you might be required to meet. There might be government regulations, there might be industry regulations, there could be HIPAA, there could be FDA, there could be whatever the things, FAA, whatever regulations you come under. SOX audit, right, being one. SOX audit is a great example.
What you’re supposed to do to meet a SOX audit is you’re supposed to do the absolute minimum that it says in order to meet a SOX audit. For example, you have to be able to trace who did what in the system, but it doesn’t have to be easy to trace who does what. It just has to be traced. Writing a log file, for example, is adequate. If you have to go look it up because you’re being audited or because something’s gone wrong, you can look it up. It might cost you a little bit more for that one time, but overall it costs you a lot less because you don’t have to build any systems around maintaining the audit logs, being able to query the audit logs. All of that stuff is time and expense you don’t need.
SOX audit, the people who created the SOX audit expect you to do the absolute minimum you need to meet that minimum bar, which is the SOX audit. But that’s not what happens in organizations. What happens is overzealous compliance folks think about, well, if this is the minimum bar, then we should be here. We should be much higher than the minimum bar to protect ourselves. But that’s not true. You only need to meet the minimum bar to protect yourselves. That’s it. You’ve met the compliance.
That means that there’s lots of things that you do in organizations that don’t have to be there or don’t have to be like that. A fantastic example is I worked with an organization, I try to remember where it was, somewhere in the US, and they had a huge compliance need, so much so that every meeting that we had, the notes all get sent off to compliance and then feedback came back and that kind of thing. We were talking about my level five, we were talking about all those things, and the compliance folks were getting a bit antsy because we were moving from their old system to Team Foundation Server, and they wanted to have change request logs. They wanted to have all of those things.
So I invited compliance to the event where I was talking about how the system worked. In Azure DevOps, it maintains every value of every variable that ever was on a work item. Every field, the full history of that field is maintained. It’s never lost, it’s never overwritten, it’s just always available. I talked about that, and the team was saying, “Yeah, but we have to have this change request work item.” The compliance person was at the back of the room, sitting, working away, just listening. I just asked them directly, “Is this good enough to meet the compliance?” and they were like, “Yeah, no problem, that’s great, that works.”
So we just removed the whole need for change request work items. They had other documents and assets that were around that story of change requests that we no longer needed because we met the compliance without them. This company had been doing them for years. So there’s all sorts of organizational craft that builds up. You want to think about lean governance, lean procurement, lean processes. Is there any waste in the system? You want to think about organizational hygiene. What do you need to do on a regular cadence to minimize? Because sometimes we create, we think something looks a bit scary, so we create a policy for it, and then it’s not actually that scary, but the policy still exists. Then another policy gets bolted on, and another policy gets bolted on.
So we need to go through organizational hygiene where we divest ourselves of waste, of the things that don’t work for us, of anything that is getting in our way that doesn’t add value to the overall system. That’s one thing for sure. We want to have as much compliance as code as possible. So if you can have it built into your product that it just complies, this is for times where you do need to have, you know, just write that log and meet that compliance, then have it in there.
These types of governance should be met in the absolute minimum required, minimum amount of work, minimum amount of effort, minimum amount of code, minimum amount of everything required to meet the compliance and no more.
