An over-the-wall process is a sequential workflow where each department completes its work in isolation, then passes it to the next department with little or no collaboration. The name comes from the metaphor of literally throwing a finished design “over a wall” to the next team, who then has to figure out what to do with it. This approach was the standard in manufacturing and engineering for decades, and it still shows up in software development and other industries today.
How the Process Works
In a traditional over-the-wall workflow, product development moves through departments one at a time. An engineer or customer creates and designs a product, then sends it to purchasing and manufacturing. Each group works within its own boundaries, finishes its piece, and hands off the result. The next department picks it up cold, often without context about the decisions that were made upstream or the constraints that lie downstream.
The defining features of this model are straightforward. Cross-department communication is minimal, and that’s by design, not accident. Departments develop their portion of the work without meaningful input from other stakeholders. Problems aren’t identified early, so teams either have to loop back for costly redesigns or accept that waste and inefficiency get baked into the final product. The overall time to produce a quality result increases significantly.
Coordination between departments relies on formal handoffs: detailed specifications, standardized procedures, and established traditions. There’s a clear start and stop for each team’s involvement. Design finishes before manufacturing begins. Manufacturing finishes before quality assurance reviews. Each wall between departments represents a point where knowledge, context, and nuance get lost.
Why It Creates Problems
The core failure of the over-the-wall process is the absence of feedback loops. When departments only communicate through narrow, predefined channels, issues that could be caught in five minutes of conversation instead surface weeks or months later. A design that looks elegant on paper might be nearly impossible to manufacture at scale, but the manufacturing team never had a chance to flag that before the design was finalized.
This isolation often extends to the organizational chart itself. In many companies, the first person who has visibility into the needs of both departments is a senior executive, sometimes as high as the CIO or VP of Engineering. Communication outside the formal handoff process has to follow the chain of command: up through one department’s leadership, across to the other department’s leadership, and back down. That path is so cumbersome that informal collaboration between teams is discouraged or, in some organizations, actively suppressed.
The practical consequences compound over time. A product that needs redesign late in the process costs far more to fix than one where the issue was caught during early design. Teams downstream feel frustrated because they inherit problems they had no role in creating. Teams upstream feel frustrated because their “finished” work keeps coming back. Morale drops, timelines stretch, and quality suffers.
Over the Wall in Software Development
The over-the-wall pattern isn’t limited to physical manufacturing. It’s one of the most recognized anti-patterns in modern software development, particularly in the relationship between development teams and operations teams. In this version, developers write code until a feature is technically complete, then throw it over the wall to operations to deploy and maintain in production.
This split creates a specific set of problems. Developers can claim their work is “done” because the feature functions in a test environment, but the software may not run well in production. Developers lack context about operational needs like monitoring, scaling, and reliability. Operations teams, meanwhile, don’t have time or incentive to engage developers in fixing problems before the software goes live. The result is software that works on a developer’s machine but causes headaches everywhere else.
Even when organizations try to modernize, the wall can persist in disguise. Some companies create a dedicated tools team and call it “DevOps,” but if operations staff still work in isolation and developers still hand off applications without collaboration, the fundamental problem remains unchanged. The tools might improve, but the lack of early involvement from operations in the development lifecycle limits any real progress. Some organizations have even relabeled their operations teams as “Site Reliability Engineers” while maintaining the exact same wall between departments, essentially recreating the original silo with updated job titles.
The Alternative: Concurrent Engineering
The direct response to over-the-wall development is concurrent engineering, sometimes called simultaneous engineering. Instead of moving through departments one at a time, multiple teams work in parallel from the earliest stages of a project. A manufacturing engineer reviews designs while they’re still being drafted. A purchasing specialist flags supply chain constraints before materials are specified. Quality assurance raises testing concerns before the prototype is built.
This approach directly addresses the weaknesses of sequential handoffs. Problems get identified early, when changes are cheap and fast. Stakeholders from every phase contribute their expertise during design, so the final product reflects real-world constraints from the start. The overall development timeline typically shrinks because teams aren’t waiting in line for their turn, and expensive late-stage redesigns become far less common.
In software, the equivalent shift is the DevOps movement, which breaks down the wall between development and operations by embedding collaboration, shared responsibility, and continuous feedback into the entire lifecycle. Developers take ownership of how their code runs in production. Operations teams participate in design decisions. The formal wall is replaced by open communication channels and shared goals.
Why the Pattern Persists
Despite its well-known drawbacks, the over-the-wall process remains common because it’s organizationally simple. Each department has clear boundaries, clear deliverables, and clear accountability. Managers know exactly what their team is responsible for. Handoffs create natural checkpoints. For organizations that value control and predictability over speed and adaptability, the sequential model feels safe.
It also persists because changing it requires more than a process update. Breaking down walls between departments means restructuring teams, redefining roles, and shifting a culture that may have operated in silos for years. People have to learn new communication habits, share ownership of outcomes they previously didn’t touch, and accept that “done” doesn’t mean “handed off.” That kind of organizational change is slow, uncomfortable, and easy to abandon halfway through, which is why many companies end up with hybrid approaches that still carry traces of the original wall.