Your team is not an infrastructure team

This is for engineering leads and CTOs at product companies who are running self-managed AWS infrastructure and have started to notice a pattern: the work the engineering team is actually doing, day to day, does not fully match the work the engineering team was hired to do. Not for teams evaluating their first infrastructure setup. For teams that are past that stage, operating a production system, and carrying an operational overhead that nobody explicitly signed up for.

At some point between the first deployment and today, your product team became a product team that also operates infrastructure. That transition was never announced. It happened through a series of individually reasonable decisions that accumulated into a permanent operational responsibility. Most teams are still carrying it without having asked whether they should.

What the team was actually hired to do#

When you hired your engineers, the implicit contract was specific. Build the product. Ship features. Maintain quality. Grow the codebase in a direction that keeps the team fast as the product matures. For engineering leads, the contract included growing developers, raising the technical bar, and making architectural decisions that the team would not regret in two years.

Nobody described the job as managing IAM policies, debugging ECS task definition failures, or auditing security group rules before the quarterly review. Those responsibilities were not in any job description. They arrived through the side door, attached to a platform choice that seemed unremarkable at the time.

The engineers on your team are capable of doing infrastructure work. That is not the point. The point is that infrastructure work is not what they are optimised for, not what they were hired for, and not what creates value for your product or your users. Every hour spent on it is an hour spent doing a job that is not the job.

The transformation nobody declared#

The path from product team to product team that also operates infrastructure follows a recognisable pattern, and it is worth tracing precisely because it was never a single decision.

It started with a server. That was fine. Then high availability required a second server behind a load balancer. Then a managed database because running MySQL on EC2 was an unacceptable risk. Then Redis for caching and sessions. Then a queue for background jobs. Then a CI/CD pipeline because manual deploys do not scale. Then IAM roles for the pipeline to authenticate with AWS. Then CloudWatch alarms because something went wrong in production and the team found out from a user.

Each step made sense. The sum of those steps is an engineering team that is now responsible for operating a non-trivial distributed system alongside the product it was supposed to be building. The operational surface did not arrive all at once. It accumulated, one sensible decision at a time, until it was large enough to require dedicated attention on a weekly basis.

The team did not choose this. The team chose to ship a product. The infrastructure complexity was a consequence they did not fully account for, and by the time it was visible, it had already become normal.

What normal is costing#

The dangerous thing about normal is that it stops feeling like a cost. The deployment pipeline failing on a Friday afternoon is normal. Debugging a CloudWatch alarm that fired at 11pm is normal. Spending the first hour of Monday triaging an infrastructure issue that surfaced over the weekend is normal. Allocating part of every sprint to infrastructure maintenance is normal.

Normal does not mean justified. It means the cost has been absorbed into the background of how the team operates, which makes it invisible in the same way that a chronic low-grade pain stops registering as pain once the body adapts to it.

The cost is still there. Two to four hours per week of engineering time on routine infrastructure maintenance. Four to eight hours per month on unplanned incident response. A fraction of every senior engineer's attention held in reserve for the infrastructure problems that will inevitably surface. The architectural and product decisions that do not get made because the engineers who should be making them are occupied with operational work instead.

What makes this particularly expensive is that the engineers absorbing the infrastructure cost are disproportionately the most experienced ones. Junior engineers cannot safely operate the infrastructure without significant support. The operational burden falls on the senior engineers, the engineering leads, the CTOs who should be spending their time on the hardest product and architectural problems. They are doing infrastructure work instead, not because they want to, but because the platform requires it and they are the ones qualified to do it.

With Sevalla, that allocation does not exist. Your team deploys from Git. Sevalla handles runtime orchestration, networking, scaling, failover, observability, and deployment workflows behind the platform boundary. The operational surface your senior engineers are currently absorbing is simply not there. They do the job they were hired to do, from the first day to the last.

The justifications that do not hold#

Teams that have internalised infrastructure ownership as normal have usually also constructed justifications for why it is the right approach. Those justifications are worth examining directly.

The first is control. Running your own infrastructure means you control it. You can tune it, optimise it, change it when you need to. This is true in principle. In practice, the control being exercised is control over infrastructure decisions, not product decisions. The things the team is controlling are not sources of competitive differentiation. They are the operational substrate beneath the product. The control argument would be compelling if the thing being controlled mattered to the product's success. For most product teams, it does not.

The second is cost. Managed platforms are more expensive than raw AWS. This is sometimes true in narrow accounting terms. It is almost never true in full-cost accounting that includes engineering time, on-call burden, and opportunity cost. The true cost calculation has been done in detail elsewhere in this series. The conclusion is consistent: the total cost of self-managed infrastructure, including the engineering time required to operate it, is three to five times the AWS invoice alone.

The third is that serious teams run their own infrastructure. This is a cultural assumption that AWS has benefited from enormously and that does not survive scrutiny. Seriousness is measured by product quality, team execution, and engineering standards. None of those require self-managed cloud infrastructure. Many of the most effective product engineering teams in the industry run on managed platforms because they have recognised that the infrastructure is not the interesting part of what they are building. The teams that confuse infrastructure complexity with engineering rigour are not more serious. They are more burdened.

The job description audit#

There is a straightforward exercise that makes the mismatch visible. Write down what the engineering team is actually doing, where the hours are actually going, across a typical two-week sprint. Not the planned work. The actual allocation including the unplanned infrastructure tasks, the deployment debugging, the operational maintenance, the incident response.

Then write down what the engineering team was hired to do. The job descriptions, the original mission, the reason these specific engineers were recruited.

The gap between those two lists is the cost of treating infrastructure ownership as a fixed condition rather than an active choice. It represents engineering capacity being consumed by a function the team was not designed to perform.

Sevalla exists for the 90% of teams who should not be running AWS at all. It is a production-grade platform that handles the infrastructure layer so that product engineering teams can do the job they were built to do. The question is not whether your team is capable of running infrastructure. It is whether that is what you want your team spending its time on.

The decision that was never made#

Your team became an infrastructure operations team without anyone deciding that was the right outcome. The question now is not how it happened. It is whether you want to keep choosing it.

Staying on self-managed AWS is not a neutral default. It is a decision made every sprint, in the allocation of engineering time, in the work that gets done and the work that gets deferred. The engineers on your team are making that decision with you every week, even if nobody has named it that way.

The product team you actually want is the one that ships with full attention on the product. The infrastructure layer should be quiet, handled, and invisible to the team's daily work. For most teams on self-managed AWS, it is none of those things. It is the thing that surfaces in standups, generates the most stressful incidents, and consumes the senior engineering time that should be going to the hardest product problems.

Sevalla is what it looks like when the infrastructure is handled and your team gets to be a product team again. That was the original arrangement. It is still available.