Platform engineering means creating user-centric capabilities that enable teams to achieve their business outcomes faster than ever before. At Equal Experts, we’ve been doing platform engineering for over a decade, and we know it can be an effective solution to many scaling problems.

Unfortunately, it’s easy to get platform engineering wrong. In this series, I’m covering some of its pitfalls. Last time it was the power tools problem, and today it’s the technology anarchy problem. 

Alignment and autonomy are needed

Teams need alignment and autonomy in product and technology to succeed at scale. Alignment connects vision, strategy, and execution, while autonomy empowers teams to act independently. Increasing alignment means better decisions, and increasing autonomy means faster decisions. Here’s a 2×2 from our alignment and autonomy 101. 

Platform capabilities are a great way to share technical alignment with your teams. Baking alignment into capabilities such as deployment pipelines and observability dashboards makes engineering tasks much easier for teams. You might know this as an opinionated platform, paved roads, or golden paths. But when alignment is absent the magic doesn’t happen and your teams are in anarchy.

The long-term costs of technology anarchy 

When your platform capabilities offer autonomy without alignment, your teams can  quickly make technology decisions, but without guidance. In the short term, this allows teams to use familiar tech stacks to rapidly build services and deliver them to customers. However, in the long-term, it creates a fragmented ecosystem full of inefficiencies, staffing challenges, and a maintenance mountain. 

I’ve previously described how to measure capabilities in internal customer value, internal customer costs, and platform costs. Here’s a v1 platform that lacks technical alignment with three teams building their own pipelines in different tech stacks. There’s some internal customer value, and low platform costs as the platform team doesn’t have to build much. But internal customer costs will skyrocket over time.

This pitfall occurs when these interconnected, incorrect beliefs exist in your organization:

• Command and control is the only method of alignment
• Alignment and autonomy are opposites
• Teams must be in autocracy or anarchy
• A platform team must impose strict rules, or have no rules at all

When your platform team chooses to build capabilities without technical alignment, it’s anarchy. Every team builds custom solutions, instead of leveraging shared capabilities. When a pipeline breaks, only one team can fix it. When a pipeline is enhanced, only one team benefits. When a team needs changing, people won’t want to move. When a team needs downsizing for maintenance mode, other teams won’t want to manage their services. There are no economies of scale. 

For example, an American telco invited me to visit their 20 teams, who had adopted You Build It You Run It for all their digital services on Google Cloud Platform (GCP). Team boards didn’t show much progress, and there were blank looks when I asked about their platform team. It didn’t exist, so 20 teams were using GCP in 20 different ways. When we measured the teams on unplanned tech work, we learned 40-60% of team time was GCP work. 

Similarly, a British retailer had 10 teams with 10 different RabbitMQ messaging solutions, until a single Pub/Sub solution was mandated for consistency. This meant 10 subtly different migrations, and there was a big dent in productivity and morale. More upfront technical alignment could have prevented all that unplanned tech work.

Achieving aligned autonomy

You escape the technology anarchy pitfall by replacing low alignment capabilities with aligned autonomy capabilities. This produces paved roads, which supply the friction-free guidance that teams need to make independent technology decisions in the same organizational direction.  

In the above 2×2 grid, you’ll see aligned autonomy is in the top right. It’s possible to have high alignment and high autonomy when you implement technical alignment as contextual guidelines, not top-down rules. Here’s how your platform team can make it happen:

• Declare low alignment capabilities as v1, and restrict them to old services.
• Capture guidelines on tech stack, architecture, etc. from engineering leadership in Architectural Decision Records (ADRs).
• Ask teams to build services with the decision records built in.
• Rebuild v1 capabilities with decision records built in, and declare them as v2.
• Host new services on v2.
• Migrate old services to v2.
• Delete v1.

Your platform team needs to stay user-centered, and focus on a great platform experience. It might mean a customizable pipeline template for a single tech stack, a four golden signals observability dashboard, or an automated ServiceNow workflow. There’s a higher platform cost, but you minimize internal customer costs and boost internal customer value. That’s a good trade-off. Here’s v2 of that imaginary platform, showing the same three teams with one pipeline template for their common Python tech stack.

Conclusion

Technology anarchy is a dangerous pitfall with painful, long-term consequences for your organization. If you reject the false dichotomy of alignment and autonomy as opposites, your platform team can create aligned autonomy in platform capabilities and help your teams to achieve engineering excellence.

I’ll share more platform engineering insights in my talk “Three ways you’re screwing up platform engineering and how to fix it” at the Enterprise Technology Leadership Summit Las Vegas on 20 August 2024. If you’re attending, I’d love to connect and hear about your platform engineering challenges and solutions.