The ABCDE of Tech Governance

When your org is small, shaping your technology stack comes naturally, but maintaining that as you scale becomes challenging. You risk sprawl, with so many technologies being introduced that your devs can’t keep it all in their heads. This wastes time. You also risk ensnaring your devs in rigid tech decisions that prevent them from using the best tool for the job - or perhaps forces them to use tools that were the once right but are now outdated. Read on to learn the ABCDE technique - which will help you establish tech governance while avoiding the pitfalls.

It’s helpful to understand that there are two common failure modes for technology governance in organisations; they can be thought of as polar extremes, and you want to avoid both:

Sprawl is the first failure mode

Sprawl is when there are many different ways to solve the same problem, and different devs choose different ones.

If you are not careful, solving day-to-day problems across your software footprint can require devs to hold a lot in their heads - more than one person can. So they go slow and spend all day reading docs.

Cognitive load theory helps you to understand why this is. It tells us that people can keep a limited amount of new context in their head at once - think of it like a fixed budget. You want to spend as much of that mind space budget as possible on achieving business goals, and not squander it on an unnecessarily complex blend of tech. Requiring devs to hold less tech context in their heads will literally make them smarter when it comes to solving business problems.

Sprawl results from a lack of coordination across different people, and your business being unwilling or unable to go back and simplify.

Entanglement is the second failure mode

Entanglement is when developers feel so constrained by governance that they can’t use the best tool for the job, and instead slowly make do with the wrong tool. Entanglement can result from ivory tower architecture, where architects make decisions in isolation, away from the teams living with the consequences of the decision, but also from things going stale - tech governance staying still while the rest of the world moves on.

ABCDE guides you on a safe path forward

Since sprawl and entanglement are opposites, it might seem as if organisations are doomed to slow down as they scale. However, there is a way forward that lets you minimise the impact of scale on velocity. Lets step through the five ABCDE principles…

Architect for your scale

Putting in place the right high-level architecture, aligned to the right organisational structure, will go a long way to letting your technology function scale.

Your goal should be to ensure that every component has a team that owns and operates it, and teams spend at least 80% of their development effort on components they own. If you can pull this off, teams do not suffer much cognitive load from different technologies being used in other teams. It allows experiments to run in one team, without impacting others.

One of the best ways to achieve such a clean division is to use Strategic Domain Driven Design. This involves breaking up your domain - the totality of what your business achieves - into smaller subdomains. The aim is to set things up so that each subdomain is implemented by a bounded context. Each subdomain has a cross-functional team assigned to it. That team should be equipped to independently evolve that domain (with all the product / tech / delivery support needed for that mission). On the flip side, teams shouldn’t be too big - Amazon’s Two-Pizza Team concept of limiting teams to about 10 is a good guideline. Ideally, each bounded context is its own microservice, so the owning team can evolve it independently.

There is an art to breaking a domain down into smaller subdomains and bounded contexts. Bounded contexts are generally either business-facing (directly delivering value for the business or the market it serves), or are platforms / subsystems (which indirectly deliver value by reducing duplication or taking a complex problem out of other teams’ hands). I recommend thinking about the business needs first, and only when you start to notice waste from duplication, consider adding platforms; this is the architectural version of the Extreme Programming YAGNI principle. When deciding how granular to go, consider the scale of your business - bounded contexts introduce overhead, so don’t go too crazy.

Further reading: I recommend Team Topologies for helpful guidance on structuring and classifying teams.

Balance your governance

We talked earlier about how Sprawl and Entanglement are the two failure modes to avoid, and how they are two opposite extremes. Your aim should be to chart a course between those two extremes; you want to balance between the chaos of no governance and the stiffling nature of too much.

A good principle to apply is that you should use the least governance possible. For example, not everything needs to be a hard mandate or prohibition. Instead, consider the impact a technology has on developers, and the amount of certainty you have in it. Things like programming languages have a high impact - it is relatively hard to switch between languages, and you could be stuck with one for a long time - so they warrant more governance. A tiny library that is only likely to be used in a few places and could be trivially swapped out does not justify heavyweight processes. Consider when a recommendation or information paper might be more appropriate.

Keep changing your governance

Technology evolves all the time, and if your governance doesn’t keep up, you could be holding your organisation back. You don’t want to be mandating COBOL when all your competitors are using Rust, for example!

You should also be mindful of creating a rachet effect where governance only ever gets stricter, and restrictions build up over time to an unsustainable level.

The solution is to regularly review existing governance artefacts, and assess if they are still appropriate. In this process, prune your guidance and standards to keep them fresh and lean.

I recommend making this process always-on for anything that comes to your attention as being broken, but also having a regular cadence (e.g. annually) where you review everything. Having the additional regular cadence ensures that always-on doesn’t become never-on.

Have a clear decision maker

Decisions about what tech governance to put in place impact many people in your organisation, and can be very impactful (either positively or negatively). The wrong tech could slow you down. At the same time, if the discussion goes around in circles, you may never reach a conclusion.

The solution is to have a clear decision-maker, who is responsible for consulting widely, listening to what people have to say and considering their points, but is then empowered to make a decision. When assigning decision rights, consider where a decision can be made locally to a team, and where it affects the whole organisation and needs to be centralised. Unnecessary centralisation is bad because the teams themselves often have the most context.

You should aim for a culture of “Disagree and Commit”, where people will vigorously state what they think and why during the consultation phase, but once a decision is made, everyone will back the decision even if it differs from their original position. This is a lot easier if people are encouraged to focus more on outcomes (what they need from a technology choice), and not positions (which technology).

Further reading: Decision Rights: Who Gives the Green Light?

Do controlled experiments

Finally, a key aspect of effective tech governance is not to blindly make standards on technologies the business has no experience with. Leading with a standard before you have the experience means you are making decisions with limited information, and the risk of a mistake is amplified as multiple teams adopt the standard.

Instead, regularly look for opportunities to introduce new technologies, and do experiments with that technology - i.e. trial it for one service in one team first. This requires a degree of coordination - which can be as simple as a registry of experiments going on. If the trial goes well, then you can start thinking about updating guidance or standards. Equally importantly, teams should be prepared to exit the trial and eventually replace the technology if the trial goes poorly; you don’t want a trail of failed experiments littered everywhere.

Recap

When scaling an organisation, remember your ABCDE:

• Architect for your scale
• Balance your governance
• Keep changing your governance
• Have a clear decision maker
• Do controlled experiments

If you can keep on top of the ABCDE, your velocity per developer will only dip slightly compared to a tiny organisation, allowing you to scale your amazing business up effectively.