Building Infrastructure Platforms

Why “Build It & Run It” Breaks at Scale

Software delivery has accelerated dramatically in the last two decades, and so has the architectural complexity of the systems being built. The old model — begging an infrastructure team for rack space, wrestling with load balancers for days, and hoping your go-live script survives contact with production — is fading. Teams increasingly own their services end to end, configuring infrastructure with the same discipline they apply to application code.

That works well for a while. But once an organisation reaches a certain size, letting every team invent its own approach to the same hosting problems becomes wasteful. You end up solving the same networking, backup and compute challenges over and over, in slightly different and often incompatible ways. That is the signal that it may be time to invest in an Infrastructure Platform: a set of common cloud components product teams consume instead of building their own.

A well-run platform saves product teams time, reduces cloud spend, and tightens security and operational rigour. As a result, execs are increasingly willing to fund dedicated platform teams. This is where things often start to go wrong. A platform team without a clear mandate can spend months building things nobody uses, or delivering capabilities that duplicate what product teams already have. The following principles are drawn from direct experience building these platforms — and from watching them fail.

Start With Strategy and a Measurable Goal

The worst outcome is spending months on a platform only to hear stakeholders say it didn’t achieve its goal. For infrastructure platforms, that disappointment is often fatal — it leads execs to scrap the effort entirely and spend the budget on more product teams, which generally makes the underlying problem worse. The prevention is not rocket science: define a goal and a strategy that every stakeholder is bought into before you write a line of infrastructure code.

The first step is gathering the right people to define the problem. That means product and technical executives who hold the budget, aided by subject matter experts who can provide context about what is actually happening on the ground. Useful problem statements are honest and measurable. For example:

We don’t have enough people with infrastructure capability in our top 15 product teams, and we don’t have the resources to hire the amount we need, delaying time to market for our products by an average of 6 months

We have had outages of our products totalling 160 hours and over $2 million lost revenue in the past 18 months

If you cannot articulate a problem statement like these, you may not need a platform at all. If you have many problems you want the platform to solve, list them all, but select one as the primary driver. Multiple competing goals lead to overpromising and underdelivering, with effort scattered across outcomes that never quite land.

Translate the problem into a measurable goal. The examples above become:

Provide the top 15 product teams with the infrastructure they can easily consume to reduce the time to market by an average of 6 months

Have less than 3 hours of outages in the next 18 months

Run a Post Mortem

You have identified a problem, so it is worth understanding why it exists. Bring together everyone with context — ideally people with different perspectives and visibility — for a post mortem session focused on the problem you identified.

Set expectations upfront that the session is a safe space: honesty is celebrated and blame is absent. The goal is root cause analysis. Draw a timeline of contributing events and help each other build a complete picture. Use the 5 whys technique, but do not fixate on a single root cause — most organisational problems stem from a combination of factors.

Once root causes are identified, ask what needs to change to prevent recurrence. The answers might be new security guidelines, organisation-wide CI/CD practices, or embedded QAs on every team. Capture all of it.

Run a Future Backwards Session

This session starts from the goal and works backward. Map what would need to be true to meet it: “all products have multiple Availability Zones,” “all services must have a five-nines SLA,” and so on. Then figure out how to make those things true. The answer may be a new infrastructure platform team, more hiring, different governance, or embedding infosec experts earlier in development.

Run both sessions if you can — the post mortem first, since it is easier for most people to reason about the past before the future. A past-facing analysis grounds your future planning in hard-won reality. If you only have time for one, do the future backwards session: its scope is wider, since the future has not happened yet, and it tends to foster broader ideation.

The output should be a practical, prioritised list of actions. That list — not a vision statement — is your strategy. Note that vision and goals are not strategy; if you are new to the distinction, Good Strategy Bad Strategy by Richard P. Rumelt is a worthwhile reference.

It is entirely possible that your strategy concludes an infrastructure platform is not the answer. That is fine — platforms are not for every organisation. If that is your conclusion, stop here. If the strategy does call for building a platform, proceed with the rest of what follows.

Discovery isn’t just for customer products

It’s easy to assume that user research doesn’t apply to internal platforms. But the pattern is all too familiar: an infrastructure team builds something impressive, and then no product team adopts it. The reason is usually the same as for any unused product — it was built without understanding what the users actually needed. Maybe the need wasn’t there to begin with. Maybe the platform arrived too late, after teams had already rolled their own solutions. Or maybe it landed too early, when potential users were too busy with their own backlogs to pay attention.

Before committing to a build, run a proper discovery phase just as you would for a customer-facing product. A discovery is a timeboxed effort where the team that will build the solution investigates the problem space. By the end, the team should know who the platform's users are — there may be several types — what problems they face, what they’re already doing well, and have a rough idea of what infrastructure product would help. Discovery is also the time to explore useful context: current technologies in use, past failed attempts, and any governance constraints that will matter.

Your strategy work defines the organisational need, but discovery translates that into user needs — where "users" means product teams, mostly developers. Keep your strategy front and centre to focus the work. If your strategy is security-oriented, for instance, you might spend discovery time on security breach post-mortems, interview a spread of people from Head of Security down to developers and QAs, and map existing security lifecycles across teams.

If discovery time is limited, the one activity worth prioritising is Event Storming. Gather one team or several who will be your platform's customers, in person with a physical wall or virtually with a whiteboard. Draw a timeline with a clear start and end — for infrastructure platforms, mapping from project kickoff through to live in production is usually the right span. Have everyone add steps as sticky notes in one colour, then overlay frustrations, pain points, and things that often go wrong in another colour. If time allows, add useful extra information: technologies or systems in play, time spent at each stage, or which teams are involved where. The facilitators should probe each sticky for context during the session and follow up on interesting areas afterwards. Once discovery is complete, prioritise the work that delivers the most value fastest.

Get users in before it’s polished

"That won’t work for us" is the worst possible verdict on an infrastructure platform — especially when it comes after genuine efforts to understand user needs. It’s a risk that grows as you break your platform down into stories and begin making small implementation decisions without validating each one. That speed is natural and healthy, but without regular feedback, months can pass and those small decisions accumulate into a product that misses the mark.

Conventional product guidance says to find the minimum viable product (MVP) and iterate. But for infrastructure platforms, "viable" is ambiguous — if your goal is reduced security risk or faster time to market, that definition can push your first release so far out that it’s too late. A better lens is the Shortest Path to Value (SPV): the soonest point at which any value can be realised — for your team, your users, or your organisation. SPV pushes you to keep the slice thin and get an early learning opportunity in front of real users. Onboard users as early as you can, and use what you learn to direct where the platform goes next.

Share your technical direction early and often

Articulating your technical vision early has two benefits: it stops other teams from unwittingly building the same thing, and it keeps stakeholders confident in what you're doing. Crucially, it’s another chance to get input before too much is decided.

The vision doesn’t need to be formal. Skip heavyweight modelling tools — grab a whiteboard and a marker, and let the ideas be messy. The point is clarity and iteration, and it’s easier to start over with a wipe than a file. When the moment calls for something a little more structured, though, two lightweight techniques are worth knowing.

C4 diagrams

C4 diagrams, introduced by Simon Brown, build on UML concepts to decompose a system into four levels of abstraction — each useful for talking to a different audience about different questions:

• Level 1: Context — the most zoomed-out view. It shows the system in question, its neighbouring systems, and its users. Use it to frame conversation about how teams might interact with and onboard onto your platform.
• Level 2: Container — expands the context into applications and data stores. This level supports discussions with your own team about architectural choices, and with SREs about monitoring and alerting considerations.
• Level 3: Component — pick a container and drill down further to show how its modules interact with each other and with components elsewhere. This is where responsibilities within the system become clear.
• Level 4: Code — an optional level that describes class-level interactions. Given the overhead, generated diagrams are usually the sensible route here, and they pay off when describing unusual or legacy design decisions. Guard against producing diagrams purely for their own sake.

Once you have a vision, keep it with you: bring it to sprint demos, reference it in design conversations, and take it into threat modelling sessions.

Architectural Decision Records

C4 diagrams describe the present or future shape of your platform. Architectural Decision Records (ADRs) are the complementary technique for capturing the past — the what and the why behind the decisions that produced the system. Placing ADRs in your platform’s repositories leaves future teams a trail of well-constructed clues about why the architecture is the way it is.

The record format is lightweight, and tooling such as Nat Pryce’s adr-tools can help keep them consistent. A typical template records the date, the decision in question, and the context that prompted it:

Ever hit some oddity in your architecture and wished you could ask its author what they were thinking? That’s exactly the gap ADRs fill — capturing not just what was built but the reasoning that shaped it, so the next person looking at the system gets an answer without needing a time machine.

Treat the Platform Like a Product

Mandating platform usage rarely works. If you want teams to adopt your infrastructure voluntarily, you need to build something they actually enjoy using. That means applying the same disciplines used in consumer product development: user research, service design, and content strategy. These roles often get overlooked in platform teams, but they matter just as much here as they do in any other product org.

Start by mapping the user journey for a key interaction like onboarding. A typical, less-than-ideal flow might include handoffs between the developer and your platform team, loops that send users backward, manual steps performed by your team, and a long list of discrete tasks with waiting periods in between. The goal is to compress that into a fully self-service flow that takes a handful of steps and requires no platform team intervention.

Getting there requires stripping away complexity rather than adding it. You will face a tradeoff between a simple user journey and a simple codebase; both are valuable, but the right balance depends on why the platform exists. If the point is faster delivery to market, a frictionless onboarding experience should win.

Complexity Is a Liability

Every line of code, every config flag, and every design pattern is a potential failure point. Platform software is no exception — even if it lacks a fancy UI or a highly available API, it will accumulate bugs. The stakes are higher than for ordinary internal tools: your production environment is every dependent team’s development environment. A platform outage can take down other teams’ workflows, eroding trust and damaging the relationships you need for adoption.

Complexity creeps in through Conway’s Law: systems tend to mirror the communication structures of the organizations that build them. That means platform designs frequently embed workarounds that cater to a specific snapshot of your org’s history. This becomes especially problematic when a platform must integrate with many teams, each with their own nuances — every integration becomes a tightly coupled component that reflects a business process rather than a reusable capability.

Before adding another component, ask whether it is truly necessary. Each new moving part is an investment in maintenance, a source of potential support burden, and another failure mode. Sometimes you are constrained by architectural debt, compliance, or security — but in the absence of such constraints, prefer fewer, more general components.

Measure What Matters

If you defined a measurable goal in your platform strategy, you need a way to track it. Turn that success metric into a lightweight dashboard — a way to celebrate wins and build confidence in the platform across the organization. Choose metrics that are relevant and actionable; a metric that does not change anyone’s behavior is just extra work.

The four key metrics from the 2018 book Accelerate are a good starting point for any platform team. They are simple indicators of software delivery performance:

• Delivery lead time — the time from code commit to running successfully in production. Shorter and more predictable lead times correlate with higher-performing teams.
• Deployment frequency — more frequent deployments are typically smaller and safer, easier to test and roll back.
• Change failure rate — the share of deployments that impair production and require a rollback or fix-forward. This is distinct from red CI/CD pipelines, which only indicate general build health.
• Mean time to recovery — how quickly you can recover from a failed deployment. For a platform, your recovery time multiplies across every dependent team; you are a critical dependency for your organization’s delivery capability.

These four metrics are trailing indicators — they tell you how well you have performed, but only once you have users. If adoption is still the challenge, focus there first. And do not try to measure every facet of platform design; some things do not succumb to metrics. Pick the important signals, track them, and ignore the rest.