The idea that SREs, DevOps engineers, or Application Engineers should not design your SDLC may sound absurd at first. After all, if not them, then who? It’s a tough proposition to accept—but stay with me. Most SDLC dysfunctions—your productivity bottlenecks, quality issues, and engineering inefficiencies—stem from one fact: your SDLC likely evolved organically under the influence of operators, not designers.
To understand this counterintuitive claim, let’s use an analogy from transportation systems.
Imagine you’re the newly elected mayor of a wealthy island nation. Your first task: build world-class ground and air transportation systems. Would you hire Uber drivers to design the island’s roads or pilots to design its airports?
Obviously not. Uber drivers and pilots know how to operate within those systems, not design them.
So why bring this up? Because the same logic applies when DevOps engineers, SREs, or application developers are asked to design an organization’s Software Development Lifecycle (SDLC).
The Operator–Designer Fallacy
We instinctively understand that operators and designers require very different skills in transportation systems. Yet when it comes to SDLC systems, we forget this entirely.
An Uber driver or pilot may know all the operational aspects of their system—tools, signals, and procedures—but system design requires deeper knowledge: queuing theory, network theory, flow management, systems engineering, and economics. Designing a transportation system is about integrating mechanical, technological, and social components into one coherent whole. Operators are not trained for that.
The same applies to SDLCs.
Startups often let application engineers pick tools—GitHub, Jenkins, Asana, Datadog—and loosely string them together. Many engineers assume that since they can make these tools work, they can design a good SDLC. In larger organizations, Agile coaches or Scrum Masters—often skilled in story management but not system architecture—are tasked with “fixing” the SDLC.
The result? A fragmented, inefficient system—just as chaotic as if every Uber driver redesigned the road network to suit their own preferences.
Why We Fail to Recognize This Fallacy
1. Invisibility
Transportation systems are techno-mechano-social systems. Their problems are visible—traffic jams, accidents, delays. Everyone can see when the system fails. In such systems, it’s obvious that driver suggestions alone can’t fix design-level issues.
But SDLCs are techno-social systems—mostly invisible. Each participant only sees a part of the whole. The Agile coach focuses on story points; the incident manager focuses on postmortems. Each operates in isolation. Because the social and technical aspects of SDLCs are intangible, people assume failures are individual, not systemic.
Designing a great SDLC requires not only technological skills but also understanding of social systems—queuing theory, flow, task synchronization, and organizational cadence. None of these are taught in engineering schools.
2. No Schools for SDLC Design
To design transportation systems, universities offer specialized programs:
- MIT – Civil & Environmental Engineering
- UC Berkeley – Transportation Engineering & Planning
- Delft University of Technology – Urban & Transport Planning
- Embry-Riddle Aeronautical University – Airport Management
- Technical University of Munich – Air Transport Systems
In contrast, there are no schools for SDLC design. We learn by tinkering and using buzzword methodologies like Agile or DevOps, which address only parts of SDLC—not the system as a whole.
3. Lack of Systems Thinking
Systems Thinking is essential for designing any social system, whether it’s transportation or SDLC. As systems grow more social, this skill becomes even more critical.
In the SDLC world, people divide systems by service or function, only to later struggle integrating them. Designing for effective integration demands Systems Thinking—a way of seeing relationships, flows, and interactions instead of isolated parts.
Technologists often confuse Systems Thinking with Systems Engineering. They’re complementary. Systems Thinking builds the mental model to understand complexity; Systems Engineering turns that understanding into practical design.
So What Can You Do?
Only technologists can design SDLC systems well—but not by relying solely on analytical thinking. SDLCs are techno-social systems. To design them, technologists must complement analytical skills with Systems Thinking, learning how social and organizational dynamics interact with technology.
Consider this thought experiment:
If someone claims to be an SDLC designer, ask them—“If I gave you a billion dollars and three months to design an SDLC that could onboard 100 developers a month while maintaining high productivity and quality—what would you do?”
If they struggle to give a coherent blueprint, they don’t actually understand SDLC design.
How We Can Help
For Startups: SDLC as Code
We help startups implement SDLC as Code (SDLCaaC)—a systematic approach inspired by Infrastructure as Code and Pipeline as Code. Most companies build SDLCs organically under time pressure; we’ve designed one that scales sustainably.
Your engineers, SREs, and DevOps staff will operate the system, not design it—just like pilots and drivers operate vehicles designed by transportation engineers. With our SDLC in place, teams become up to three times more productive, and organizations often see 10–20x overall improvement in throughput, quality, and cost efficiency.
For Existing Organizations: Transformation
If you already have an SDLC, we can assess and transform it. Using our models, we benchmark your current system, identify dysfunctions, and design a blueprint to evolve it. Transformation happens in steps that continuously deliver value—and the benefits compound.
At SystemsWay, we focus on Systems Transformation, not cultural transformation. Well-designed systems make average people great and great people exceptional.
Our transformation program includes Systems Thinking training for executives and engineers alike—because transformation only succeeds when those who execute it also understand and co-create its design.
A Note on “Design Thinking”
Be wary of confusing Design Thinking with Systems Thinking. Design Thinking is useful for creating human-centered interactions but isn’t sufficient for designing complex techno-social systems like SDLCs. Systems Thinking encompasses a broader, deeper framework—one that integrates technological, organizational, and human elements into a unified design.
