The modern world moves fast. To keep up you need to be able to respond and adapt to changes and new ideas quickly. To support that goal, most modern tech companies have adopted organisational structures made up of small autonomous teams, microservices, and domains. Those teams have all the people and skills they need to deliver and operate their product, possibly even to market and sell it. Compared to larger, monolithic teams built around capability or function the intent is to be faster and better with fewer bottlenecks or dependencies between teams. However, to do this, you have to give up some control...
Herding Cats
Imagine for a moment that you’ve created a hot new tech company. You’ve got a bunch of talented people and you’ve empowered them to do whatever they need to make their product successful. Each team has built amazing things from scratch using the tools they know and love. They’ve done their best to be responsible about things like security and data protection. They’ve moved quickly. Your company has done well. They’ve succeeded.
But now the connections between those teams and products are many and varied and things aren’t quite as easy as they used to be. In fact, you’ve slowed down. Every team is maintaining custom connections to every other team and some of the different tech choices are making this really hard. You’re spending a lot of money on infrastructure. Changes in one place routinely cause unforeseen problems elsewhere. Teams have interpreted policies differently and nobody is quite sure what the current state of things is. It’s surprisingly hard to find information. New teams starting up have a lot to do to get integrated into the system. And worst of all, your people are getting frustrated at just how much they’re having to do that isn’t focused on building their product.
At this stage, you’ll have several people playing the role of “cat herders”. These people are trying their best to coordinate things, to improve common problems, to share wisdom. These people are heroes. But they can’t solve it all. You need something better.
Governance and citizenship
"The need for governance exists anytime a group of people come together to accomplish an end" (iog.ca)
Governance is about how you get independent actors to co-exist as a coherent whole. In the context of a tech company, those actors are the teams, the systems, and the people. They’re your citizens. As in the real world, there are lots of ways to govern citizens. You could stick with the “no rules” way of doing things but as we’ve seen above, it doesn’t work so well. You could start writing rules for everything and then trying to get all your teams to follow them. That way lies pain for all.
But remember: you want autonomous, empowered teams because they’ll ultimately deliver better results. So you need to find a balance. You need a framework that supports your goals and your people.
Tools, rules, people and support
The first thing to accept as you approach the opportunity is that there is no quick fix, no silver bullet, and no single solution. The second thing to note is that this isn’t a new problem. In tech there has been lots of great thinking about this, for example the concept of the data mesh proposes a set of principles to support a distributed data organisation.
You can and will need multiple approaches to establish good governance, most likely including a mix of the following
Policies and standards - These describe (mostly) non-negotiables. These are the rules you have to follow. The laws you comply with, the protocols your systems use to communicate with each other, the way you log events for system observability. These policies and standards need to be created in collaboration with teams to make sure they work for the people who have to adopt them. They need to be widely and regularly communicated.
Shared infrastructure, tooling and templates - If you want teams to keep moving fast, in accordance with your policies and standards, these things will help. If all your teams are setting up the same tech stack and you know how you want it to be done securely, give teams a template for it that they can build on. This has the added benefit that you can include logging, monitoring and metadata from the start. These tools are usually built by platform teams but could be created more organically as well. Be careful about mandating the use of these things unnecessarily. If they don’t quite work for teams you’ll introduce different problems.
Experts and Specialists - It’s unlikely that you’d want to have a data protection specialist or niche technology expert in all teams. But you need these experts to be available to your teams. They’ll most likely own some of the policies or create some of the tools described above. They’ll also help engineers and others work through their specific use cases. They should be visible and seen as supporters of the teams rather than police or document writers. Note that some teams may require particular expertise, for example payments regulation could be embedded in a team building a payments processing system.
Processes - It isn’t glamorous but you will need some standard processes. Exactly which ones will depend on your company and what you value but they will often focus on the areas that involve multiple teams. You will likely want some around how you release to different environments or how you manage incidents. You may also have to participate in external processes such as audits. Take processes seriously and make sure each has an owner. Good processes make things easier for everyone. Bad ones slow things down and weaken your culture of empowered teams.
Knowledge and learning - Documentation, tutorials, guides, training. Although every company needs to do this, it’s especially important when you have teams spread out. The information needs to be easy to find and use. If your teams can self-serve the information they need then, that’s right, they are empowered! This needs to be considered part of your culture. Teams need to contribute as well as consume and while it has to be open, knowledge rarely organises itself neatly by chance. Good tools, ownership, and promotion matter here.
Community - Not everything will be quickly solved by tools, rules or specialists. And if your aim is to have empowered, autonomous teams (it is!) then you want them to be able to solve their own problems, share and celebrate their hard-fought wins for others to benefit from, and for your collective intelligence to increase as this happens. This is community. This is where your people are participating citizens and not isolated individuals. Create forums, give people the right collaboration tools, and help them to use them well. Treat this as a core competency.
Anything that requires all people to participate or act on is expensive both in terms of financial cost and as a distraction from your core mission. Think carefully about what you introduce and regularly review whether anything existing should be removed.
Summary
Empowered and autonomous teams can do incredible things. Time after time we see them go faster and achieve better results than projects with cross-team dependencies. When those teams are supported with the right governance framework they can move quickly, maintain high standards in areas like security, reliability and interoperability, and focus on their mission: delivering value to your customers.