The Seven Powers of Platform Teams

I work on Workiva’s cloud platform engineering team, where we design and operate Kubernetes and AWS infrastructure supporting more than 300 microservices across multiple AWS regions. The platform spans networking, observability, CI/CD, compliance, and internal developer tooling. Lately, our team has been busy developing and codifying our strategy. I’m not a big fan of reinventing the wheel, and neither is the rest of our team, so we welcomed the opportunity to use existing business strategy frameworks and methodologies as a way to get started quickly. We used the Playing to Win Framework, and were able to flesh out a meaningful strategy focusing on things such as reducing cognitive load for development teams and streamlining how we report the customer impact of incidents.

I’m also a big fan of the Acquired podcast, which frequently references Hamilton Helmer’s 7 Powers framework. I thought it would be interesting to use the framework to stress test our platform strategy — even if the framework was originally intended for businesses competing in markets rather than internal platform organizations.

One challenge is that platform engineering teams occupy a strange middle ground. We are neither a product company nor a traditional shared-services organization. Most strategy frameworks assume a business competing for external customers, while platform teams exist to improve the effectiveness of internal engineering organizations.

Still, the exercise turned out to be useful. While some of the 7 Powers map awkwardly to platform engineering, others — especially counter-positioning and process power — describe platform teams surprisingly well.

Let’s see what we get.

What are the 7 Powers?

The 7 Powers come from Hamilton Helmer’s book 7 Powers: The Foundations of Business Strategy. The framework describes durable competitive advantages that allow organizations to outperform competitors over long periods of time.

Each power provides two things: a benefit to the organization that possesses it, and a barrier competitors must overcome to compete against the power holder.

The seven powers themselves are:

• Scale Economies — Per-unit costs decrease as scale increases.
• Network Economies — A product becomes more valuable as more users adopt it.
• Counter-Positioning — A superior model incumbents struggle to copy without harming themselves.
• Switching Costs — Customers incur meaningful costs when changing providers.
• Branding — Historical reputation creates perceived value beyond objective differences.
• Cornered Resource — Exclusive access to a valuable resource or capability.
• Process Power — Embedded organizational processes create sustained operational advantage.

The framework is normally applied to companies competing in markets. Platform teams obviously are not that. But many of the same strategic dynamics still exist inside large engineering organizations.

Applying the 7 Powers to Platform Teams

Our platform team is responsible for shared cloud infrastructure, CI/CD, observability systems, and internal platform services. Since the 7 Powers apply more directly to entire businesses or business units, they don’t translate exactly to shared service or platform teams, but we can still use them to learn what levers are important to a platform team.

Power 1: Scale Economies

• What is it?
  • Per-unit costs decrease as production volume increases.
• Does a platform team have it?
  • Yes. But sometimes indirectly.
• Does a platform team need this power to succeed?
  • Yes. Shared services should provide scale economy benefits to the rest of the organization.

Scale economies are tricky to apply to a platform team.

For example, consider compute nodes. We run Kubernetes and can leverage that platform to pack multiple workloads on to shared nodes to increase overall efficiency and utilization of each node. This improves utilization, but it does not necessarily change the underlying unit economics of the infrastructure itself. Instead, the cost decreases we see typically come through volume purchasing agreements with suppliers like AWS. In this scenario AWS holds the scale economy power and can leverage that power to keep us in their ecosystem.

We do see some scale economy power in the shared services that we run. For example, our team is responsible for running the messaging infrastructure used by all applications at Workiva. By centralizing this infrastructure component into a shared team and shared service, the per-unit cost of sending a message is decreased for the organization as a whole — this is a thinly disguised example of “production volume” that Hamilton Helmer describes in the book, but is likely the closest we can achieve as a platform team.

Another way to think about scale economies for shared services is that the platform team should be able to offer shared services at a lower cost to the overall organization than having teams individually implement those services. If we can’t acheive that lowered overall cost, we shouldn’t provide that particular shared service.

Power 2: Network Economies

• What is it?
  • Value for each user increases as the user base grows.
• Does a platform team have it?
  • Yes.
• Does a platform team need this power to succeed?
  • Yes. But maybe weakly.

Network economies exist any time that value increases as more people use an application or system.

Within a platform team, network economies exist within any observability tooling. If you run an application as part of an ecosystem within your organization, the value of observability increases the more applications use it: there is one place to view application telemetry across the entire organization, and one place to correlate logs, tracing, and metrics across multiple applications.

A similar economy exists within the shared network itself. Most applications will run on the same VPC or networking infrastructure, which enables applications to communicate with one another without unnecessary overhead incurred by crossing network boundaries.

Platform teams do have network economies, but they are likely not the key to platform success, and are more a side effect of having software developers as a cornered resource.

Power 3: Counter-Positioning

• What is it?
  • A superior model that incumbents can’t copy without harming their own business.
• Does a platform team have it?
  • Yes.
• Does a platform team need this power to succeed?
  • Absolutely.

Counter-positioning is arguably the most important power that platform teams have.

Modern cloud providers already offer infrastructure primitives, deployment tooling, managed services, and automation capabilities directly to engineering teams. At the same time, application teams can increasingly assemble their own infrastructure stacks using open source tooling and SaaS products with very little centralized coordination. So why do most large organizations still have platform teams?

In most cases, the broader organization has made a concrete choice to invest in platform teams to optimize for the needs that cloud providers aren’t well positioned to meet. Cloud providers optimize for flexibility and breadth. Ad-hoc engineering solves for team autonomy, but often at the cost of operational consistency, reliability, compliance, and long-term maintainability. A strong platform team occupies a deliberate counter-position between those two extremes.

Another way to think about counter-positioning is that if the platform cannot provide a meaningfully better experience than directly using AWS or assembling tooling independently, it probably should not exist at all.

Power 4: Switching Costs

• What is it?
  • High costs for customers to switch to a competitor.
• Does a platform team have it?
  • Yes.
• Does a platform team need this power to succeed?
  • Please no.

There can be, and usually are, high costs to switching between a platform team’s offerings and other offerings. For example, if your team builds out a custom CI/CD tool to meet your own internal SOC controls or compliance, legal or regulatory requirements, it is difficult for engineering teams to just switch to a competitor.

Knowing that a platform team can leverage the power of high switching costs, it can be tempting to introduce these costs throughout the organization as a means of making your services essential to the business.

This is a slippery slope and not something you should lean into. Instead, a platform team aligned with the needs of the organization should try to remove as many unnecessary switching costs as possible so that engineers are free to choose solutions that best meet their needs, and allows the platform to easily adapt to industry trends as products and services mature throughout the ecosystem. This means standard things like prefering open standards, avoiding deep coupling to internal tooling, and making deployment workflows portable.

Healthy platform adoption should come primarily from usefulness, not captivity, and platform teams should reduce migration friction as much as possible.

Power 5: Branding

• What is it?
  • A unique brand identity that attracts and retains customers.
• Does a platform team have it?
  • No.
• Does a platform team need this power to succeed?
  • No.

Platform teams can and should build trust within engineering organizations, but that trust is usually earned through operational excellence and developer experience rather than branding itself.

Unlike consumer companies, platform teams rarely benefit from brand mystique or emotional attachment. Engineers will tolerate weak branding if the platform is reliable and useful, but they will not tolerate strong branding attached to poor developer experience.

In practice, platform reputation tends to emerge as a side effect of process power and successful counter-positioning rather than functioning as an independent strategic advantage.

Power 6: Cornered Resource

• What is it?
  • Exclusive access to a vital resource, like a patent or location.
• Does a platform team have it?
  • Sort of.
• Does a platform team need this power to succeed?
  • No. At least they shouldn’t.

Platform teams do not usually possess true cornered resources in the traditional business sense. However, they often acquire something close to soft monopoly power inside organizations.

Engineering teams may be required or mandated to use centralized CI/CD systems, networking models, observability platforms, security controls, or deployment pipelines due to operational, compliance, or governance requirements. Over time, this can create a captive internal user base.

The danger with this captive base is complacency. Once platform adoption becomes mandatory, it becomes easy to optimize for platform convenience rather than developer experience. Services only need to become “good enough” rather than genuinely excellent. When that happens, engineering organizations begin viewing the platform as bureaucracy rather than leverage.

The strongest platform teams resist this trap by continuously treating internal engineers like customers, even when they might not have an alternative.

Power 7: Process Power

• What is it?
  • A unique, hard-to-copy process that creates a cost or quality advantage.
• Does a platform team have it?
  • Yes.
• Does a platform team need this power to succeed?
  • No.

Platform teams often derive enormous leverage from operational process itself. “Golden Paths,” incident response practices, deployment safety mechanisms, compliance workflows, and production engineering standards all encode organizational knowledge into repeatable systems that the broader engineering organization can adopt consistently.

Unlike many of the other powers, process power compounds over time. Operational maturity, incident management, compliance workflows, deployment safety mechanisms, and production engineering practices become embedded organizational knowledge that is difficult to replicate quickly. A significant portion of the value a mature platform team can be encoded into operational experience and practices that the rest of the organization is hooked into.

What I Learned from This Exercise

Going through this exercise convinced me that successful platform teams derive most of their durable value from reducing organizational complexity rather than owning infrastructure. Counter-positioning and process power are the biggest levers that platform teams have at their disposal to provide value to the organization.

Counter-positioning explains why platform teams continue to exist despite increasingly capable cloud providers and open source ecosystems. Process power explains why mature platform organizations become more valuable over time as operational knowledge accumulates and becomes embedded into tooling, workflows, and organizational practices.

It is also instructive to look at how many of the powers that create durable businesses can become dangerous inside platform organizations. Switching costs, mandatory adoption, and soft monopoly power can all push platforms toward complacency and bureaucracy if they are used as a means of creating leverage within the organization.

Ultimately, platform teams succeed when engineers choose to use the platform because it genuinely improves their ability to build and operate software in ways that aren’t possible with cloud providers and open source ecosystems — not because they are forced to.