The capacity conversation usually starts after the workaround breaks
A client recently asked the platform-engineering question that shows up when a company has grown past the “one senior engineer keeps delivery moving through heroics” stage. A handful of deployment scripts had turned into the operating layer for engineering: CI/CD workflows, cloud account and project structure, Kubernetes and serverless deployment paths, infrastructure-as-code modules, runtime standards, incident support, security guardrails, cost controls, secrets and access patterns, and the enablement work that stops teams from losing days to broken environments, unclear ownership, or knowledge trapped in chat threads.
The budget question was direct: why does this environment need three DevOps engineers instead of one? The useful answer is not “because DevOps is important.” It is capacity math. Start with committed roadmap work, then add the operational load that rarely fits neatly into sprint planning: production escalations, pull request reviews, Terraform drift, failed pipelines, certificate and dependency updates, audit evidence, cost investigations, access requests, policy exceptions, flaky test infrastructure, base image patching, and the steady stream of “quick” developer support. In 2026, that background load is often heavier than the original platform plan assumed: more AI-assisted code reaching review, more short-lived environments, more compliance evidence, more cloud spend scrutiny, and more security checks pushed into the delivery path. If one engineer is expected to review infrastructure changes, unblock releases, tune cluster policies, handle on-call escalations, prepare audit artifacts, investigate cloud spend, and coach product teams through platform changes, staffing is no longer a preference debate. It is a business decision about how much delivery delay, burnout, single-point-of-failure risk, and platform instability the company is willing to carry in the system that ships and runs its software.
Until that moment, the budget conversation had been relatively easy.
If storage utilization is climbing, you can show the graph and justify another few hundred dollars a month for disks.
If CI queues are delaying merges, deployments still require hand-holding, cloud accounts have weak guardrails, incidents are pulling senior engineers out of roadmap work, and product teams are waiting days for platform fixes, the case is harder to express. You are not buying “1.5 DevOps engineers”; you are buying release throughput, operational safety, faster recovery, cost control, compliance readiness, and fewer blocked engineers across the company.
That is the gap these capacity formulas are meant to close. They take symptoms that usually arrive as scattered complaints — slow deployments, rising incident load, a platform backlog that never shrinks, fragile environments, security and compliance requests, cloud cost surprises, and constant support interruptions — and turn them into planning inputs that engineering, product, and finance can discuss without relying on the loudest anecdote in the room.
🛠️ Practical enough for planning, honest about uncertainty
Use the formulas below as planning heuristics, not as a precise model of human work and not as a staffing ratio to copy from another company. A five-team SaaS business, a regulated enterprise, and a small product group built mostly on managed cloud services will make different assumptions about ownership, risk, automation, on-call coverage, compliance effort, lead time, and how much platform complexity they are willing to operate themselves.
The point is not to produce a magic number. The point is to make the constraints visible: where operational pressure is coming from, which teams are absorbing it, which roadmap work is being delayed, and what tradeoff the business is making if it chooses not to hire, reduce scope, standardize tooling, improve self-service, retire complexity, or simplify the platform. A useful capacity model should make the next decision clearer, even if the number is still an estimate.
I call these formulas because they create a repeatable way to reason about capacity, not because engineering work can be measured with mathematical precision.
DevOps and platform work is shaped by interruptions, context switching, unclear ownership, production risk, and organizational friction. A useful model has to be simple enough for engineering managers, platform leads, and executives to use together, while still being honest enough to show where the pressure is really coming from.
Decisions this capacity model should help you make
- Help you understand how many DevOps Engineers you need
- Provide you with tools to reason with your CFO
- Encourage you to learn martial arts to successfully defeat your CFO in combat if all else fails
🤷 Caveats
- This model is not written in stone; I’m open to learning from your experience and improving it based on what you see in real engineering organizations.
- Calibrate the formulas before using the result
- Most of the formulas use inputs you can count: developers, services, environments, pipelines, incidents, and support channels. Those numbers are useful, but they do not explain the whole capacity picture. Qualitative factors such as ownership clarity, automation coverage, documentation quality, supportability, and maintenance debt can change the real capacity requirement as much as raw volume does. Ten services with consistent deployment patterns may be easier to support than three services with bespoke pipelines, unclear runbooks, and no obvious owner.
- DevOps capacity is not the same as one full-time DevOps engineer
Use the formulas without fooling yourself
- Start by identifying what your current DevOps capacity can reliably support, then treat that as the baseline unit. For example:
160 hours of DevOps engineering per month = 20 microservices, 3 development teams, a defined release cadence, a known incident load, and a specific amount of platform support.
The variables will differ by company, and the numbers only matter if they reflect real work. The point is to stop treating “one DevOps engineer” as a generic planning unit and instead measure the operating load that a given amount of capacity is carrying. - As the company grows, look for indicators the existing capacity isn’t able to handle more than it does and hire more DevOps capacity
🚨 The indicators that more DevOps capacity is required
There are 2 main indicators that more DevOps capacity is required:
- Support work is useful until it becomes the platform interface.
Some support load is healthy. When the company is growing, the queue often shows where developers are getting stuck: unclear deployment paths, missing documentation, brittle environments, confusing access flows, or platform defaults that do not match real use.
The failure mode is different. If the same questions, access requests, deployment failures, and environment fixes keep coming back, support has stopped being discovery. It has become capacity leakage. At that point, DevOps-to-developer efficiency improves only when recurring support is converted into self-service, safer defaults, clearer ownership, or automation that removes the ticket altogether. - Different engineers and teams are solving the same problems in different ways for themselves.
This often starts when DevOps or platform hiring lags behind demand and developers cannot wait for every environment, pipeline, permission, or deployment issue to be handled centrally. Some local problem-solving is healthy, but it becomes expensive when every team builds its own scripts, Terraform patterns, CI templates, dashboards, or access workflows in isolation.
It is acceptable for product teams to solve DevOps use cases when those solutions become contributions to a shared platform or a documented standard. It is a warning sign when the same problem is being solved five different ways and none of those solutions are reusable, supportable, or owned.
Example client indicators:
- Company #1 example:
A company with roughly 300 developers had about 40 DevOps engineers spread across stateless infrastructure, data infrastructure, monitoring, CI/CD, and data streaming. Each group owned a Slack support channel. Over time, those channels became the default front door for pipeline failures, infrastructure questions, access requests, environment issues, and production follow-ups.
Capacity signal: Several DevOps teams needed 1–3 engineers available mainly for support rotation. That was not just an on-call coverage issue. It showed that platform engineers had become a manual intake layer for work that should have been automated, documented, delegated, or exposed through self-service. The visible symptom was “too many questions in Slack”; the underlying capacity problem was that routine delivery work still required a specialist to interpret, approve, or execute it.
What changed: The teams reviewed recurring requests every week, grouped the highest-volume patterns, automated repeatable tasks, and created self-service paths for common developer needs. They also paired with key developers to move platform knowledge into product teams. The capacity gain did not come from asking DevOps engineers to work faster. It came from removing avoidable handoffs and making routine work executable without waiting for an answer in Slack. - Company #2 example:
A company with 30 developers had one DevOps engineer supporting delivery, infrastructure, and developer requests.
Capacity signal: The DevOps engineer spent most of their time on support tickets opened by developers. As common deployment errors kept recurring, some developers began bypassing the standard deployment process to keep work moving.
What changed: The company added monthly capacity through a part-time DevOps consultant and trained key developers to provide first-line support inside their teams. That combination reduced the single-person bottleneck without immediately turning every platform problem into a full-time hiring decision.
With those caveats in place, here is the planning model for estimating DevOps capacity.
A practical way to estimate DevOps capacity
A useful way to estimate required DevOps capacity is to start with the work the platform team must absorb, then adjust for risk, complexity, and the level of self-service already in place:
Why this works as a planning model
- The bigger the stuff to build and maintain - the more working hands you need
- The more variations you need to support - the more working hands you need
- The more self-service you have, the fewer hands-on interruptions you should need
Let’s dive into the ingredients of scale, complexity, and leverage.
The baseline: what “DevOps capacity” actually includes
The guiding principle here is simple: a DevOps engineer should enable delivery, not become a permanent checkpoint for every delivery task.
That means enabling teams to provision infrastructure, deploy workloads, store and process data, observe services, and recover from incidents with as little unnecessary handoff as possible. When every change still requires a DevOps engineer to approve, debug, click, or explain the same thing again, capacity is being consumed by friction rather than leverage.
DevOps = Enable ownership of the relevant stakeholders over the infrastructure, monitoring, security, architecture, data, configuration, deployment, orchestration, testing, and development.
‘DevOps Capacity’ is the time & effort invested in achieving “DevOps” as defined above.
⛰️ Scale - Size Matters
Start by defining the scale you are asking the platform to support. In capacity planning, “scale” is not only traffic volume. It also includes the number of services, environments, deployment paths, cloud accounts or projects, runtime patterns, data systems, compliance boundaries, and teams that depend on the platform.
“Michael, did you just create a recursive definition?”
Why yes of course! this is the rationale:
- Larger systems require more time and effort to understand, build, secure, operate, and maintain.
- Larger teams and client bases create more internal and external use cases to support, which increases the load on platform, infrastructure, and release processes.
To make the two types of scale above easier to discuss, I use two simple capacity models.
They are not scientific laws. They are structured ways to compare the demand created by your systems, teams, and operating model with the DevOps capacity your organization actually has:
Map the system scale and operational surface area
- Resources Used could mean many things, some of them are: Storage volume, Number of CPU cores, Number of nodes, Memory used, etc.
- System throughput is the work your systems process over time: user requests, scheduled jobs, batch runs, queue events, streaming workloads, and any other flow that creates operational load. Throughput matters because each flow tends to bring its own deployment risk, scaling pattern, observability requirement, failure mode, ownership boundary, and support expectation. A quiet batch job that fails every morning can consume more DevOps attention than a high-traffic service with mature dashboards, alerts, and rollback paths.
- Instances per Service refers to the number of replicas of the services developed within your company, for example: Kubernetes Pods, serverless functions executions, etc.
A client's system scale example: 1-year-old startup
Scale: 3 AWS ECS clusters, 6 microservices, 3 main environments, 3–150 ephemeral development environments, and 6–40 container instances per environment
Approach: Infrastructure and deployments are managed with infrastructure as code. The company hired a part-time DevOps consultant to implement the initial system and train the development team to own routine changes, instead of creating a permanent dependency on the consultant for every deployment or environment issue.
Organization Scale
- Number of Developers refers to the number of developers, and shame on you for bothering yourself with reading this line
- Total Users refers to the number of active clients
Noteworthy:
B2C will usually have more clients, with more standardized interfaces - DevOps Engineers most likely will be less involved in direct ways with client facing features.
B2B on the other hand will usually have less clients, with more customized interfaces per client - DevOps Engineers are more involved with client-facing features through the developers.
A Client's Organization Scale Example - Healthcare Company:
Scale: 200 developers divided into teams of 4–12 people, 10 DevOps engineers and SREs, high autonomy per team, and no single standardized process for all developers
Approach: Infrastructure and deployments are managed with infrastructure as code to support “one-click environments.” The company also used a part-time DevOps consultant to implement an initial system and train the development team to take ownership of it.
Bonus:
Check our availability for a call about scaling DevOps in your organization in a more gradual way using MeteorOps
🥴 Complexity - More Options, Less Clarity
I know, I know… It looks similar to the chapter about Scale.
In this context, complexity is not only the number of systems you run. It is the number of choices engineers must make without strong defaults, and the uncertainty around which path is considered safe, supported, and maintainable. That uncertainty creates decision latency and makes it more likely that two teams solve the same problem in different, incompatible ways.
You are operating in a complex environment when an engineer knows what outcome they want, but still has to ask, “Is this how we do it here?”
So, what does complexity have to do with both the system and the organization?
- More complex system - More time and effort are required to map the available options, and customize (copy, paste, modify) or generalize (refactor, parameterize) solutions
- More complex organization - More time and effort are required to communicate, provide support, cascade initiatives through the company, and lower likelihood of initiatives getting accepted
This time I’ll present you with the formulas for complexity without drumrolls:
System Complexity
- Number of Tools refers to any tool, either existing or custom-built, that helps build and maintain the system. More tools mean more capabilities, more potential integrations between tools, and more potential ways to achieve the same goals. (Tools have an upside as well!)
- Number of Platforms means any platform on which you run workloads or consume resources (e.g. - AWS, Kubernetes, Linux, Jenkins). Using more platforms requires supporting more ways of running each workload or consuming each resource.
- Number of Codebases refers to the repositories where your systems are developed and maintained. The more separate codebases you operate, the harder it becomes to keep development workflows consistent: build conventions drift, CI/CD pipelines fork, dependency upgrades happen unevenly, and release practices become harder to support at scale. A larger number of repositories does not automatically mean you need more DevOps capacity, but it does increase the value of shared templates, standards, and automation that prevent every team from reinventing the same delivery path.
- Number of Services is the number of services developed by the developers: more services, more different units with different logic to them, which in turn creates more unique operational requirements.
To sum up, ‘System Complexity’ increases when there are more services, running on more platforms, managed by more tools, across more codebases.
A Client's System Complexity Example - Low Scale, High Complexity:
- Complexity: The entire system was 1 service deployed on just 1 server, but was deployed using multiple deployment tools (chef, ansible, bash scripts), from multiple different repositories (about 10), with a specific set of steps required to fully set it up
- Approach: Containerize everything, Consolidate the deployment to one docker-compose file, Consolidate the configuration and automation to one tool (ansible), Consolidate the repositories into one
Organization Complexity
- Number of Teams - More teams mean supporting and maintaining more ways of work
- Number of Hierarchy Levels - More middle-management layers in the organization make it more likely decisions and communication will cascade through it, and so increasing the time & effort for decision-making and communication
- Level of Hierarchy-Reliance for Communication - Exactly the same effect, but focused on the culture of the company
🪄 Is there anything that makes DevOps capacity more efficient?
Calculating DevOps capacity is not just a headcount exercise. Done well, it exposes where delivery is actually getting stuck: repeated support requests, fragile release paths, manual environment provisioning, unclear ownership, noisy incident handoffs, and the morale cost of constant interruption.
The better planning question is not “how many DevOps engineers do we need?” It is “which constraint should the next unit of capacity remove?” In many organizations, adding another person to absorb tickets only makes the bottleneck quieter for a while. The higher-leverage move may be self-service environment creation, paved-road CI/CD templates, standardized cloud and Kubernetes defaults, documented escalation paths, workable access flows, or clearer ownership boundaries that show when a product team can act independently and when platform help is required. If the discussion is stuck in anecdotes, a structured DevOps maturity assessment can give teams a shared language for deciding what to automate, what to standardize, what to delegate, and where specialist DevOps or platform engineering capacity still matters. The goal is not to keep the platform team busy. It is to make the same capacity support more teams, safer releases, and faster recovery without turning that team into the permanent approval queue for every deployment, pipeline change, cloud request, access issue, or post-incident follow-up.
Valid question! And this is the formula for DevOps ‘Leverage’:
- Documentation Coverage - Out of the internal company’s tools and processes, what percentage has documentation?
- Automated Processes Coverage - Out of the manual processes used by the developers, what percentage was automated?
- Engineering Talent Concentration Score - The seniority (relevant experience) of your engineering team, divided by the acceptance rate of engineers to your company.
More experience and lower acceptance rates improve the score. - Tools Community Size - How widely adopted are the tools being used by the company? And how active is the open community working on and with it?
Example:
Another client of ours had all of its infrastructure managed manually.
To increase the documentation-coverage and the automated-processes-coverage, it decided to adopt an infrastructure-as-code tool.
They considered Terraform and Pulumi, and ended up choosing Pulumi, in order to avoid hiring more full-time DevOps Engineers, and delegate responsibilities for infrastructure management to the developers.
It increased the documentation-coverage by the sheer fact that all of the infrastructure is now described in a Git repository.
It increased the automated-processes-coverage because every piece of new infrastructure was introduced into Git, would exist in every new environment, and would get automatically reconciled if its state drifts.
And the formula for the score (One last formula, I promise):
Note that this variable does NOT say “DevOps Engineering Talent Concentration Score”, because the assumptions are that:
- Every engineer on the team can take part in filling the DevOps capacity - it doesn’t have to be a specific team or person
- More experienced engineers require less training and support, and so consume less time for the DevOps Capacity
Example:
MeteorOps hires 7 engineers out of every 1,000 vetted.
We only vet DevOps Engineers with extensive production experience in at least two previous companies.
Our median seniority is 8 years of experience.
It means the ETCS (Engineering Talent Concentration Score) is 114.
🧠 Engineering Talent Concentration Score - The biggest leverage you can get
If you can take only one thing from this article, make it the engineering talent score.
Having a DevOps candidates pool of engineers with relevant experience, and hiring only the top percentile of that pool, is an insanely high-leverage action.
You get engineers with perspective on how to do things right, and perhaps more importantly, how to do things wrong.
Enjoying someone’s learning from successes, and learning from failures, saves your company lots of time learning the hard way.
External DevOps help can be useful, but it should be framed as a capacity and capability decision, not a way to postpone operating-model choices. A good partner reduces bottlenecks by building reusable platform patterns, documenting how the system is supposed to run, tightening delivery and runtime practices, and transferring knowledge back to the teams that will own the work later. If the engagement simply adds more hands to the same ticket queue, you may buy short-term relief while the underlying capacity problem keeps compounding. Use outside support when it is tied to a concrete outcome: stabilizing delivery, creating self-service infrastructure, improving cloud or Kubernetes operations, lowering incident load, or covering a specialist gap while you hire, train, or reorganize internally.
I’m not going to do that.
(P.S. - I’m the Marketing Director)
To Summarize
Instead of writing more words, here are all of the formulas:
I hope you find it useful!
I’m also interested in learning about how you used he formulas, and what insights you had as a result.
If you came up with new useful variables and formulas, please send it to me so I can take credit over inventing them.
If your CFO isn’t convinced
