When infrastructure pressure starts building, one conclusion tends to arrive quickly. It is also a perfectly reasonable one:
“We need another DevOps engineer.”
There are more deployments. More infrastructure. More alerts. More incidents. More requests from developers.
And the person carrying Cloud, DevOps or Platform work can no longer keep up.
Hiring may be exactly the right decision.
But not always.
Sometimes the team is short of a person. Sometimes the infrastructure is simply creating more work than it should. Adding capacity to a system that produces too much work may relieve pressure without removing its cause.
The distinction matters: hire when the need is structural, but do not hire permanently around problems that should disappear.
Headcount is not the only question
Consider a product organisation with roughly twenty developers and one person carrying most of its Cloud, DevOps and Platform responsibilities.
Their scope includes AWS or Azure, Terraform, Kubernetes, CI/CD, observability, secrets, backups, incidents, access and support for development teams. From a distance, the answer looks obvious: add another engineer.
There is a better question to ask first:
What is actually consuming that person’s time?
Time spent building new capabilities, making architecture decisions and owning a growing platform is different from time lost babysitting releases, interpreting noisy alerts or unblocking routine work that should be self-service.
Situation A: the team genuinely needs more capacity
The infrastructure is reasonably automated. Common paths are repeatable. Teams can deploy safely, incidents result in learning, and operations do not depend on one person’s memory.
At the same time, the company is adding products, teams, regions or requirements. New responsibilities will remain: platform security, reliability, developer experience, cloud governance or an internal Platform Engineering function.
Hiring probably makes sense here. Growth has created durable work and continuous ownership. The new person will not be compensating for a broken system; they will own a lasting responsibility.
Situation B: the system creates too much avoidable work
Deployments contain manual steps. Terraform is risky to touch. Alerts interrupt people without guiding action. New environments take days. The same tasks return every week, and every incident ends up with the same person. Runbooks are missing or cannot be followed without an oral explanation.
Hiring can increase throughput, but it does not remove this work. It may simply spread the load widely enough to make it look sustainable for a while.
A focused infrastructure and CI/CD assessment can separate a lasting backlog from operational debt before the team decides which role it actually needs.
1. Deployments need babysitting
Having a pipeline does not make delivery reliable. CI/CD may exist on paper while still depending on tribal knowledge, privileged access or manual intervention.
Look at the entire path to production:
- Does somebody have to watch every deployment?
- Are there manual steps outside the pipeline?
- Is rollback simple, tested and predictable?
- Can developers deploy autonomously within clear boundaries?
- Do pipelines frequently fail for reasons unrelated to the code?
- Does one person have to intervene over and over again?
A fragile pipeline turns every release into operational work. It delays small changes, concentrates permissions and encourages larger batches, even though larger batches usually make failures harder to isolate.
Improvement does not necessarily require rebuilding the delivery platform. It may start with immutable artefacts, meaningful checks, consistent configuration, a verified rollback and a route to production the whole team understands. That is the purpose of healthy DevOps automation, not accumulating YAML.
If every deployment needs supervision, there is probably a problem worth fixing before assuming the team lacks headcount.
2. Too much depends on one person
The bus factor is a simple way to describe how many people can become unavailable before work stops.
The practical question is uncomfortable but useful:
What happens if the person who knows the infrastructure best is unavailable tomorrow?
They may be the only one who can recover a system, locate credentials, understand Kubernetes networking, change particular Terraform modules, lead an incident or explain why the architecture looks the way it does.
Specialisation is not the problem. Senior teams will always have people with deeper knowledge in particular areas. Risk appears when operational knowledge and authority to act are concentrated without another viable path.
Reducing that dependency involves:
- documentation kept close to the real system;
- executable, tested runbooks;
- automation for frequent operations;
- standards for common paths;
- access and recovery procedures;
- primary and backup ownership;
- hands-on knowledge transfer, not only recorded sessions.
The goal is not for everyone to know everything. It is for an absence not to stop production and for the team to act from evidence. A dedicated review of the DevOps bus factor provides a useful way to map that risk.
3. Manual, repetitive work fills the week
SRE uses the term toil for manual, repetitive, operational work that could be automated and consumes time without creating proportional new value.
Not every operational task is toil. Investigating a new failure or designing a recovery strategy can generate valuable learning. Creating the same user for the fifth time, copying configuration between environments or renewing certificates through a delicate manual sequence usually does not.
Toil often hides in small jobs:
- creating and removing users;
- provisioning environments;
- changing DNS;
- renewing certificates;
- applying configuration changes;
- running deployments;
- checking backups;
- rotating secrets;
- repeating nearly identical changes across accounts.
No single task appears large enough to justify a project. Together they fragment the day, interrupt higher-value work and turn the infrastructure engineer into a human ticket queue.
Automation does not mean turning every exception into a platform. Measure frequency, risk, time and variability first. Then automate stable paths with proportionate controls. Infrastructure as code with Terraform can help, but a repository nobody can safely review is just technical debt in a different form.
A team may be saturated because its internal operating system creates too much work. Before adding capacity, decide which part of that work should cease to exist.
4. Alerts exist, but they do not help
Prometheus, Grafana, centralised logs or an APM product do not automatically create observability.
Tools collect signals. The operating practice has to turn those signals into answers:
- Are alerts actionable?
- Are there so many that people ignore them?
- Can the team see what changed before an incident?
- Can it identify the degraded service quickly?
- Can it distinguish a technical anomaly from actual user impact?
- Does every alert have a severity, an owner and an expected action?
When alerts lack filtering and context, they create more work. The on-call engineer reconstructs the story by hand, moves between dashboards and asks what was deployed. Another engineer can share that investigation, but the signal remains poor.
An SRE and observability practice should connect symptoms, changes, dependencies and reliability objectives. It does not need to become an endless tooling programme.
Good observability does not mean more dashboards. It means answering the important questions sooner.
5. Kubernetes constantly needs specialist attention
Kubernetes can be a sound technical choice. It also introduces a broad operational surface: upgrades, security, networking, storage, ingress, observability, resource management, autoscaling, GitOps, policies, backups and disaster recovery.
Specialist knowledge is expected. The problem starts when every change, diagnosis or upgrade always lands with the same senior engineer.
At that point, review three things:
- whether Kubernetes remains the right abstraction for the product;
- which complexity can move into managed services or standard paths;
- which operations should become repeatable procedures the team can execute.
Sometimes a central platform genuinely needs more permanent operators. In other cases, the immediate need is to stabilise it, reduce exceptions, define boundaries and transfer operations. Focused Kubernetes consulting and support can have a clear end without challenging the entire technology choice.
If every change depends on the same specialist, the answer may not be one more specialist. It may be less operational complexity for specialists to absorb.
6. The cloud bill grows, but nobody can explain why
Rising Cloud spend is not automatically a problem. More users, traffic, data, availability or regions may justify it.
The risk is being unable to answer:
What is driving the increase?
That answer requires more than the monthly total. It involves rightsizing, orphaned resources, storage, traffic, snapshots, databases, Kubernetes workloads, commitments, architecture choices, tagging and ownership.
Without allocation, the team receives a bill and opens an investigation. With ownership and context, it can distinguish productive growth, deliberate headroom, waste and conscious design choices.
FinOps is not only about spending less. It is about understanding cost and connecting it to the value it produces.
A useful FinOps practice creates a decision loop between engineering, product and finance. It does not pursue the lowest possible bill or trade resilience for an isolated saving.
If every change in spend requires days of manual investigation, some of the team’s pressure comes not from growth but from insufficient financial and technical visibility.
7. The same incidents keep returning
The cycle is familiar: an incident occurs, somebody applies a fix, production recovers and the team returns to urgent work. Weeks later, the same failure comes back in a slightly different form.
Nobody is deliberately ignoring root cause. There is simply no space left. The next deployment, alert or request consumes the window in which the team could have added hardening, automation, better signals or a recovery test.
Breaking the cycle means reserving capacity for:
- root cause analysis proportionate to impact;
- corrective actions with an owner and date;
- automated checks and recovery;
- observability improvements;
- documented decisions and procedures;
- resilience work where the risk justifies it.
The team needs time to improve the system, but the system consumes all of its time.
This is one of the clearest signs of operational debt. Hiring may create the space to address it, but only when that is an explicit goal. If the new engineer immediately joins the same reactive rotation, the cycle continues with a slightly larger queue.
So, when should you hire?
Hire when the need is structural and permanent.
That may mean sustained growth across products and teams; enough volume for continuous ownership; a new internal Platform Engineering or SRE function; increasing regulatory or availability requirements; or responsibilities that will remain after today’s bottlenecks have been removed.
In those cases, define the role around outcomes and ownership, not a shopping list of tools. Will this person own the platform? Build paved roads for development teams? Lead reliability? Run production continuously? Which decisions will they be empowered to make?
DevOps consulting and an internal hire are not universally competing options. They can be separate stages: understand and stabilise first, then add durable ownership with cleaner context.
The goal should not be to avoid hiring. It should be to hire when there is a genuinely permanent need.
When does a focused external project make more sense?
Some important problems do not justify a permanent position by themselves:
- repairing CI/CD;
- stabilising Kubernetes;
- carrying out a migration;
- reviewing cloud costs;
- removing a critical dependency;
- automating infrastructure;
- preparing a platform for an audit;
- improving observability.
These situations may benefit from senior capacity for a limited period with four clear responsibilities: solve, document, transfer and leave.
The scope should include acceptance criteria, access to the relevant accounts and repositories, recorded decisions and a handover the team can verify. If the external provider becomes the new indispensable person, the project has not removed dependency. It has moved it.
You’re not filling a seat. You’re solving a problem.
That does not make the problem small. A migration or Kubernetes stabilisation may be business-critical. It only means that its intensity and specialist demands do not necessarily last forever.
10 questions before opening another DevOps role
The decision becomes clearer when it starts with specific questions:
- What is actually consuming the team’s time?
- How much of that work is repetitive?
- Which tasks can be automated?
- What currently depends on one person?
- Which projects are blocked by infrastructure?
- Are deployments genuinely autonomous?
- Do the same incidents keep returning?
- Does observability support fast diagnosis?
- Is there enough permanent work to justify another FTE?
- If we removed the main bottlenecks, would we still need another person?
You do not need false precision to answer them. Review tickets, interruptions, incidents, waiting time and planned work over several weeks. The evidence usually shows whether the team needs more capacity or needs its infrastructure to create less work.
Those are different statements:
- “We need more capacity.”
- “We need our infrastructure to generate less work.”
Both can be true. The important thing is not to treat them as the same decision.
Not every infrastructure problem needs another hire
Sometimes the team should grow. If there is lasting ownership and a durable backlog, delaying the hire only transfers pressure to the people already there.
At other times, the team needs senior capacity for a few weeks to remove a bottleneck, stabilise a platform, automate work, address operational debt, document decisions and transfer knowledge.
Then the internal team continues with infrastructure that demands less intervention and a clearer view of the work that remains.
That distinction can prevent a company from hiring permanently around problems that should disappear.
