A familiar DevOps capacity conversation
A client recently brought me a question that tends to surface once a platform team is no longer “just setting up CI/CD,” but is now responsible for the delivery system everyone depends on: pipelines, cloud environments, deployment standards, incident support, security guardrails, and developer enablement.
“Michael, our CFO asked why we need three DevOps engineers instead of one. What should I tell him?”
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 DevOps capacity formulas are meant to close. They turn scattered symptoms — slow deployments, growing incident load, a platform backlog that never gets smaller, fragile environments, security and compliance requests, cloud cost surprises, and constant support interruptions — into a staffing conversation that engineering, product, and finance can evaluate together instead of debating from anecdotes.
🛠️ Practical enough for planning, honest about uncertainty
The formulas I use are intentionally practical. They will not produce a perfect model of human work, and they should not be treated as a universal benchmark for every engineering organization. A five-team SaaS company, a regulated enterprise, and a small product group running mostly managed cloud services will make different assumptions about ownership, risk, automation, on-call coverage, compliance burden, and acceptable lead time.
The point is not to calculate a magical headcount number. The point is to make constraints visible: where the pressure is coming from, which teams are absorbing it, what work is being deferred, and which tradeoff the business is accepting if it chooses not to add people, reduce scope, standardize tooling, improve self-service, retire complexity, or simplify the platform.
I call these formulas because they provide a repeatable way to reason about capacity, not because they capture every variable with mathematical precision.
DevOps work includes interruptions, context switching, ownership gaps, production risk, and organizational friction. Any useful model has to stay simple enough for engineering managers, platform leads, and executives to use in the same conversation.
Goals for this article
- 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.
- Getting useful numbers requires fitting the formulas to your company
- The formulas rely mostly on quantity variables, not quality variables. The main exceptions are coverage and score metrics, which are included to reflect whether work is actually owned, supported, and maintained at an acceptable level.
- DevOps Capacity ≠ Full-Time DevOps Engineer: DevOps work can be done by developers or DevOps agencies as well
📜 How to use this article
- Start by identifying what your current DevOps capacity can reliably support, then treat that as your 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 exact variables will differ by company. The point is to stop treating “one DevOps engineer” as a generic unit and instead measure the real operating load that 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:
- More time spent on support, less on everything else.
It could be OK that your DevOps capacity goes more towards support IF the growth rate is slow.
Why only if it's slow? Because spending time on support teaches the DevOps Engineer what use cases should be supported, and s/he gets the time to build, document, and automate them.
This increases your DevOps-to-Developers efficiency.
(I’m inventing terms right and left over here) - 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 a DevOps group of about 40 engineers covering stateless infrastructure, data infrastructure, monitoring, CI/CD, and data streaming. Each DevOps team owned a Slack support channel, and developers used those channels for pipeline failures, infrastructure questions, access requests, environment issues, and production follow-ups.
Extra Capacity Required Indicator: Each DevOps team had to keep 1–3 engineers available mainly for support rotation. That is a clear sign that the team is doing more than operating platforms; it has become the default intake desk for work that should be automated, documented, delegated, or designed into a self-service flow.
Solutions: The teams reviewed recurring requests every week, automated repeatable tasks, and exposed self-service paths for standard needs so developers did not have to wait in Slack. They also worked with key developers to improve platform knowledge inside product teams. The capacity gain came less from pushing people harder and more from removing avoidable handoffs. - Company #2 Example:
- 30 developers, a DevOps team of 1 DevOps Engineer
Extra Capacity Required Indicator: The DevOps Engineer worked mostly on support tickets opened by developers, and the developers started deviating from the standard deployment process to bypass common errors
Solution: Increased monthly capacity using a part-time DevOps Consultant from our team, and trained key-developers in the organization to provide support within their teams.
I think you’re ready to jump into the big formula for DevOps capacity!
🧮 The Big Formula - Calculating DevOps Capacity
The formula for finding the ‘Required DevOps Capacity’ in your company is:
Why is this the formula?
- 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 time & effort saving things you have - the less working hands you have
Let’s dive into the ingredients of scale, complexity, and leverage.
🔑 The Basic Formula - What is ‘DevOps Capacity’?
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
The formula for understanding the ‘Scale’ in your company is:
“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 your systems create with the DevOps capacity your organization actually has:
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 volume of work your system processes over time, such as user-initiated requests, scheduled jobs, batch data processing, queue events, or streaming workloads.
- 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 environment, 6-40 container instances per environment
- Approach: Both infrastructure and deployments are managed using Infrastructure-as-Code, Hired a part-time DevOps consultant to implement an initial system and train the development team to take ownership over it
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, No standardized process for all developers
- Approach: Both infrastructure and deployments are managed using Infrastructure-as-Code to achieve "One-Click Environments", Hired a part-time DevOps consultant to implement an initial system and train the development team to take ownership over 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.
For the sake of this article, complexity means More options and less certainty about which option to choose, resulting in more time to choose, and a lower likelihood to make the right choice.
You know you are in a complex environment when you want to do something, but you are not sure if THAT’S the way to “do things around 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 staffing exercise. It is a way to find where delivery is slowed by 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?” but “which constraints should additional capacity remove?” In many organizations, the highest-leverage move is not adding another person to absorb more tickets. It is removing the right work from the queue: self-service environment creation, paved-road CI/CD templates, standardized cloud and Kubernetes defaults, documented escalation paths, sensible access workflows, and ownership boundaries that make it clear when a product team can act independently and when platform help is required. If the debate is stuck on opinion, a DevOps maturity assessment can help translate symptoms into operating-model decisions: what to automate, what to standardize, what to delegate, and where specialist DevOps or platform engineering capacity still matters. The goal is for the same capacity to support more teams, safer releases, and faster incident recovery without becoming the permanent bottleneck 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 evaluated as a capacity and capability decision, not as a magic shortcut. A good partner should help you remove bottlenecks, build reusable platform patterns, document the operating model, and transfer knowledge back to your teams. If the engagement only adds more hands to the ticket queue, you may get short-term relief without changing the underlying capacity problem. Use outside support when it accelerates a clear outcome: stabilizing delivery, building self-service infrastructure, improving cloud or Kubernetes operations, reducing incident load, or covering a specialist gap while you hire 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
