The five abilities
Most of my philosophy, when I talk about building teams, is about building engineering teams for product. Infrastructure sits a little outside that, so let me lean in on how I think about it.
When it comes to infrastructure, I build teams that align to three cornerstones: developer productivity, cost effectiveness, and what I call the five abilities. Together they keep platform engineering pragmatic and execution-focused, rather than a pursuit of technical ambition for its own sake.
Three cornerstones
Developer productivity
Faster iteration, less friction. Invest in tooling and automation that reduce cognitive load, make releases effortless, and remove the roadblocks that slow engineers down.
Cost effectiveness
Infrastructure should scale with business needs, not just technical ambition. Right-size cloud spend, avoid waste without sacrificing reliability, and make ROI-driven decisions.
The five abilities
The foundations that decide whether a platform can be trusted and can grow. Five of them, and they’re the rest of this piece.
The five abilities
Each one is distinct. They overlap in places, but conflating them is how teams end up with systems that are technically “up” but miserable to run, or observable but impossible to change. The value is in treating each as its own first-class concern.
Availability
The uptime metric. The percentage of time your systems are operational and serving requests as expected, usually expressed as a target: 99.9%, 99.95%, 99.99%. Availability is the number most stakeholders care about, and the one most teams over-optimise for in isolation.
Not the same as reliability. Availability is the outcome: was it up? Reliability is the behaviour under pressure: did it hold together? A system can hit its uptime target while still failing users repeatedly if it struggles under load and recovers just fast enough to keep the SLA green.
A quick note on language: an SLA (Service Level Agreement) is a commitment to a customer, usually with consequences if you miss it. An SLO (Service Level Objective) is an internal target you set for yourself, the goal you aim for to stay well inside the SLA. Most teams should be managing to SLOs; the SLA is the floor, not the aim.
Reliability
How the system behaves when things go wrong. Does it degrade gracefully or fail catastrophically? Can it handle partial outages, unexpected traffic spikes, or dependency failures without cascading? Reliability is about predictable, correct behaviour across all conditions.
Not the same as availability. A system can be “up” but unreliable, returning errors, timing out, or producing inconsistent results. The distinction matters because fixing availability (uptime) and fixing reliability (behaviour under stress) require completely different interventions.
Maintainability
How easy the system is to operate, debug, and extend over time. Can a new engineer get up to speed on it in a day? Can you deploy a fix at 2am without dread? Maintainability is the ability most often sacrificed in the name of speed, and the one that compounds most painfully when neglected.
Not the same as observability. Maintainability is a property of how the system is built: its design, documentation, and operational procedures. Observability is about what you can see while it’s running. A well-observed system that is poorly designed is still a nightmare to maintain.
Observability
The ability to understand what is happening inside a system from the outside, using logs, metrics, and distributed traces. Not just “is the alert firing?” but “why is latency spiking on this specific endpoint for this specific user cohort?” Without it, incidents take longer to diagnose, post-mortems are guesswork, and on-call is miserable.
Not the same as monitoring. Monitoring tells you something is wrong. Observability tells you why. Monitoring is a subset of observability, a necessary one, but not sufficient. The difference shows up most clearly at 3am, mid-incident.
Scalability
The system’s ability to handle growth (more users, more data, more traffic) without requiring constant manual intervention or architectural rewrites. Scalability is about building headroom into the design, so growth is planned for rather than stumbled into.
Not the same as availability. Availability is about uptime today; scalability is about whether today’s design can handle tomorrow’s load. A system can be highly available at current scale and collapse completely at 2x traffic. Both matter, but they need different work to address.
Define success across all five and engineering stops being a cost centre. The principles hold whether you’re a startup or an enterprise, and they give you a rubric you can actually use: in goal-setting, project gates, and performance conversations.
Beyond Google’s SRE
The Google SRE book is a landmark. If you haven’t read it, you should. It codified a discipline and gave the industry a shared language for reliability engineering. I draw on it regularly.
Where my approach differs isn’t because the model is wrong. It was written at Google scale, for Google’s context. Most companies I work with aren’t Google. Smaller teams, tighter budgets, engineers wearing several hats.
A few places where my thinking shifts. It’s broader than reliability and availability: I treat maintainability, observability, and scalability as first-class concerns alongside reliability, not afterthoughts. That’s why the five abilities look the way they do.
It’s vendor-pragmatic. I’m not tied to any toolchain or cloud provider. The right infrastructure is the one that fits your team’s skills, your budget, and your trajectory.
And it’s business-calibrated. I weigh cost, team bandwidth, and long-term sustainability in every call: managed services versus self-hosted, automating the toil that actually hurts versus chasing a theoretical automation ceiling. In most companies, infrastructure exists to serve the business, not the other way around.
I was running platforms before “SRE” was a job title, often in organisations that never had a dedicated SRE team. That shaped how I think: pragmatic first, principled always.