Governance and Standardisation

If there is one thing that Corporates are masters of, is Governance. I mean, most corporates have forgotten their technical roots, and have mostly outsourced, making them over-reliant on vendors. But with Governance - thats something they take very seriously. They have BRM, PMO, RA and Security departments - all fighting to have their part of the Governance pie.

By Governance, they really mean control. How to control something - a new technology, project or process - so that it's utterly ineffective in its objective. Corporates get a thrill out of saying "NO" to people and projects - because thats where they get their power from. Corporate culture revolves around approval - and people get power trips by declining to approve. Lets take for example Security: they may be part of the approval process for your project. You go to them (either to present to their forum or approval board, or directly to them to get sign-off) to show them what you doing, and what the objective is. Now instead of them understanding the business objectives, and that its all of our responsibility to see how we can meet the business objective, and specifically for them to guide us in making the solution secure, then just reject the proposal. And its not really that the solution was insecure, but its a power play. If you involve them too early, they say its not their job to develop the solution. If you come to them at the end, they reject it for not involving them earlier.

Contrast this to Amazon's Leadership Principles - specifically how they value Bias for action:

Tell me about a time when you worked against tight deadlines and didn’t have time to consider all options before making a decision” or “Describe a situation where you made an important business decision without consulting your manager.”

But corporates are all talk and buzz words. They have strategies and HR principles of "being Agile". It reminds me of a Dilbert I seen the other day:

Pointy haired boss says “Our strategy is to be agile and nimble”,

and Dilbert replies

"Do other companies have strategies of being clumsy and slow?"

There is nothing like big Gated processes that screams out “Waterfall”, like Councils and Approval Boards, which require a project to present to multiple of these shows to progress, which probably only meet once a month, forcing you to schedule long in advance. The funny, yet morbid part, is that most of these councils are the same people, but still pretend that each new forum adds value.

There are better alternatives. Google Apigee talk about governance with a small g – just enough governance to make it work.  This is what the leading DevOps researches, from the book Accelerate, The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations say about CAB:

“teams that required external approval for deployment showed the lowest performance”

and

“it’s a form of risk management theatre: we check boxes so that when something goes wrong, we can say that at least we followed the process. At best, it introduces time delays and handoffs between teams”

These are all behaviours of Pathological organisations that we discussed regarding culture - ways to escape scapegoating from failure, and shirking responsibilities. A recent discussion I had with an Infrastructure team on their cloud implementation and why they over 18 months late, was that they first need a strategy to define the Governance, so that they don’t have too many Cloud providers. Really??? They impacting the whole business, making them unable to deliver effectively,  don’t have any cloud presence yet, but they worried about "too much Cloud". Perhaps they should actually start using Cloud, then use those lessons to implement Governance. Why are they solving a problem they don’t have yet? Cloud is over 17 years old (AWS launched in 2002, developed in Cape Town) - they don’t need a strategy, its too late for that.

Another form of Governance is Standardisation.

Corporates want teams to use the "approved" solution. They don't want diversity in platforms or technology. Its a one-size-fits-all mentality, even if you projects requirements are different. The authors of Accelerate say it much better:

In many organisations, engineers must tools and frameworks from an approved list. This approach typically serves one or more of the following purposes:

• Reducing the complexity of the environment
• Ensuring the necessary skills are in place to manage the technology through its lifecycle
• Increasing purchasing power with vendors
• Ensuring all technologies are correctly licensed

However, there is a downside to this lack of flexibility: it prevents teams from choosing technologies that will be most suitable for their particular needs, and from experimenting with new approaches and paradigms to solve their problems. Our analysis shows that tool choice is an important piece of technical work. When teams can decide which tools they use, it contributes to software delivery performance and, in turn, to organizational performance. This isn’t surprising. The technical professionals who develop and deliver software and run complex infrastructures make these tool choices based on what is best for completing their work and supporting their users. Similar results have been found in other studies of technical professionals (e.g., Forsgren et al. 2016), suggesting that the upsides of delegating tool choice to teams may outweigh the disadvantages.  

When the tools provided actually make life easier for the engineers who use them, they will adopt them of their own free will. This is a much better approach than forcing them to use tools that have been chosen for the convenience of other stakeholders. A focus on usability and customer satisfaction is as important when choosing or building tools for internal customers as it is when building products for external customers, and allowing your engineers to choose whether or not to use them ensures that we keep ourselves honest in this respect.

The spotify model allows teams to choose their own tools. But nobody was to re-invent the wheel, so if a team notices another team using a tool or platform and it works for them, they more than happy to just use it as well. Natural selection wins.