Stop Shifting Left: Infrastructure, Security, and Network Teams Are Support Functions—Nothing More
For the past several years, the software industry has been consumed by a mantra: shift left. Testing shifted left. Security shifted left. Infrastructure shifted left. Compliance shifted left. The idea was noble at first—catch problems earlier, reduce bottlenecks, empower developers. But in practice, “shift left” has become a quiet abdication of responsibility by infrastructure, security, and operations teams.
Instead of building systems and services that enable engineers to focus on delivering software, they’ve pushed their own complexity onto developers, burying us under responsibilities far outside our expertise. The result? Software engineers are spending less time writing code, less time testing features, and less time delivering what customers actually care about: working software and great user experiences.
This shift has reached a breaking point. It’s time to say what few want to admit: infrastructure, security, and network architecture are support functions. They exist solely because of what software engineers produce. Without software, there would be nothing for them to support. Their mission is to enable software engineering—not to compete with it.
The Problem with the “Shift Left” Mentality
On paper, the case for shift left sounds sensible. Move tasks earlier in the development cycle, empower developers to fix problems before they metastasize, reduce rework. In quality testing, this made sense—catching bugs sooner saves everyone time.
But the industry didn’t stop at testing. Entire disciplines—security, infrastructure, networking, compliance—decided they too should “shift left.” Instead of building self-service, hardened platforms and enabling tooling, they pushed their work directly onto developers.
That has created three major problems:
-
Dilution of Expertise
Software engineers are trained to build applications. Security engineers are trained to harden systems. Network architects are trained to design scalable, resilient topologies. Expecting one group to moonlight as another inevitably means none of the jobs get done well. -
Productivity Loss
Every hour an engineer spends writing IAM policies, configuring firewall rules, or fighting through infrastructure-as-code scripts is an hour not spent on product innovation. That’s not efficiency—it’s waste. -
Superficial Coverage
Complex disciplines require deep expertise. When developers are forced to take on these tasks, they address them only at the surface level. The result is more risk, not less.
Why Support Functions Exist
Let’s be clear: customers do not pay for infrastructure. They do not pay for network design. They do not pay for security policies.
Customers pay for software that works. They pay for user experiences that solve problems, delight them, and add value to their lives.
Infrastructure, security, and networking exist only because software exists. If there were no applications to deploy, no users to protect, no traffic to route, these functions would have no reason to exist. Their entire mission is to support the production and delivery of software.
That means their job is not to shove complexity onto developers. Their job is to remove friction. To build reliable platforms. To provide secure, paved paths. To anticipate problems and design systems that protect developers from them.
They are not the main act. They are the backstage crew. Vital, yes—but vital because of the performance on stage.
The False Economy of Shifting Left
The industry often justifies this push by claiming it’s cheaper to “catch problems early.” That might work for catching bugs in unit tests, but it falls apart when applied to entire support disciplines.
- Context Switching Overload: Developers now juggle a dozen responsibilities at once, leaving them spread thin.
- Burnout: Engineers hired to build features find themselves doing three jobs poorly instead of one job well. Attrition follows.
- Slower Delivery: Ironically, pushing responsibilities left has slowed down the very thing we were trying to accelerate—shipping valuable software.
The supposed savings are a mirage. Every hour “saved” by security or infrastructure teams is borrowed at interest from the engineering teams actually producing customer value.
What Needs to Change
It’s time for support disciplines to rediscover their purpose: enabling software engineers. That requires a fundamental shift in mindset.
-
See Yourselves as Support, Not Peers
Infrastructure, networking, and security are not parallel to software engineering. They are subordinate to it. Their success is measured by how much more effective they make software engineers. -
Automate, Don’t Delegate
Stop handing developers 300-page manuals or fragile YAML scripts. Build hardened, self-service platforms with guardrails. Provide tools, not chores. -
Protect Core Engineering Time
Every meeting, every policy, every new burden placed on developers should be weighed against one question: does this help them write more and better software? If the answer is no, it belongs somewhere else. -
Recenter on the Customer
Remember that the customer does not see your network diagrams. They don’t click through your IAM policies. They don’t interact with your infrastructure code. They experience the product. If what you’re doing doesn’t directly make that product better, faster, or safer, it’s not the right priority.
Conclusion: Let Engineers Engineer
The shift-left movement has gone too far. What began as an efficiency play has become a quiet abdication of responsibility by the very teams meant to support software engineers.
It’s time for a course correction. Infrastructure, security, and networking are support functions. Their mission is not to burden developers, but to empower them. Not to offload responsibility, but to absorb it. Not to compete for mindshare, but to clear the path so engineers can do what they do best: write code, test it, and deliver the experiences customers actually pay for.
Let engineers engineer. Let support teams support. And let customers enjoy the software they came for in the first place.