Orthogonal Cadences

“Conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.” — Fred Brooks, The Mythical Man-Month

When we say Form Follows Function in software, we rarely stop to ask what dictates the shape of the engineering team itself. If our architectural patterns decompose into Data, Algorithms, and Boundaries, the human system that constructs them must possess an equally deliberate anatomy. Yet, modern software organizations routinely overlook these human boundaries, blending distinct operational roles under the guise of organizational flexibility.

Conway’s Law and the Spreading of Structural Debt

Before we can dissect individual roles, we must observe the silent gravity of organizational structures. In 1967, Melvin Conway formulated what we now know as Conway’s Law: Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

The implications for role blending are foundational. When an organization erases the lines between specialized positions—demanding that a single individual absorb orthogonal operational cadences—the communication pathways within the system inevitably blur. Conway’s Law dictates that this organizational ambiguity is non-negotiable; it will eventually mirror itself into the architecture of the product.

A fragmented human architecture creates a fragmented product. If the internal boundaries of responsibility are tangled, the software architecture will gradually lose its cohesion, becoming heavily coupled. The structural form of software cannot long survive the structural deformity of the team that writes it.

The PM/BA Hybrid: The Clash of Scope and Constraints

Collapsing the roles of Project Manager (PM) and Business Analyst (BA) into a single position creates an immediate systemic crisis. While they might appear adjacent on an organizational chart, their core operational directives are fundamentally adversarial. They represent two entirely different vectors of product creation.

The Business Analyst operates in the dimension of depth and discovery. The BA’s primary function is to uncover the intrinsic value of the business domain, map out user journeys, and ensure the product actually solves the core problem. The PM, conversely, operates in the dimension of boundaries and constraints. The PM’s survival metrics are strictly structural: keeping the project within the iron triangle of time, budget, and scope.

When these roles are forced into a single individual, the system breaks under the weight of an unresolvable conflict of interest. Under the inevitable pressure of tightening deadlines, the hybrid specialist faces an untenable choice. The PM’s survival instinct—the mandate to deliver on time—will almost always override the BA’s functional precision.

To protect the schedule, the deep discovery required for a fluid, tailored solution is often bypassed. Edge cases are left unexamined, and critical business logic is flattened into superficial specifications. The organization forces the engineering team to build a rigid, compromised square simply because the constraint has swallowed the function.

The Developer-Analyst: Violating Inversion of Control

The most insidious role collapse occurs when an engineer—often due to an analytical background—is tasked with writing the technical specifications for their own upcoming development work. On paper, management sees this as a masterclass in efficiency: a single resource who can gather requirements and instantly translate them into code. In reality, it is a failure of system design that violates the core principle of Inversion of Control.

In a healthy engineering ecosystem, requirements must flow from the outside in. The Problem Space—populated by actual stakeholders, users, and business intents—dictates the functional boundaries. The implementation space must then adapt to these needs. When a developer is forced to step into the analyst’s shoes to unblock their own task, this entire lifecycle collapses. The Problem Space is effectively erased.

Without an independent analytical layer to advocate for the user, the project is stripped of its intent, actors, and real-world friction. The developer is trapped in an echo chamber, forced to play both the architect and the builder.

This is where the organizational delusion exposes itself. The international architecture standard ISO/IEC/IEEE 42010 explicitly mandates that any viable system design must address the distinct, often conflicting concerns of separate stakeholders.

So, when management dumps a raw task onto a developer and asks them to “just figure out the requirements,” where exactly is the engineer supposed to find these people?

Are they expected to magically hallucinate the operational fears of the Maintainers, the budget anxieties of the Acquirers, the workflows of the Users, the regulatory nightmares of the Regulators, or the infrastructure limitations of the Operators—all while sitting alone with an open IDE?

Forced role blending demands that a single human mind simulate an entire committee of conflicting actors simultaneously. The result is never true efficiency. It is a compromised mental model where the long-term needs of system users are quietly sacrificed just to reduce complexity and minimize execution risk within the codebase.

When an engineer with a rigorous analytical eye demands completeness, edge-case handling, and clear functional intent from incoming tasks, their standards are often mischaracterized as pedantry or friction. In a broken system where superficial specifications are the norm, demanding high-quality requirements looks like an attack on the team’s velocity. In truth, it is the only logical defense mechanism against architectural rot. You cannot implement clean algorithms if the functional intent behind them is non-existent.

Other Ubiquitous Collapses: The DevOps Misconception

The disease of role-blending is not confined to the intersection of product and engineering; it bleeds deeply into operations. The most pervasive modern manifestation of this is the systemic distortion of the DevOps movement. Originally conceived as a cultural philosophy to bridge the communication chasm between Development and Operations, it has widely devolved into an exhausting job title: a single individual who is expected to write core product features and manage cloud infrastructure simultaneously.

This specific collapse directly opposes Eliyahu Goldratt’s Theory of Constraints, a foundational principle popularized in IT literature by Gene Kim, Kevin Behr, and George Spafford in The Phoenix Project.

In any software delivery pipeline, the primary constraint—the bottleneck where value is actively transformed into reality—is almost always engineering cognitive capacity. According to the Theory of Constraints, any minute a bottleneck spends on a non-bottleneck activity is an absolute loss to the entire system.

When management expects a developer to balance feature delivery with infrastructure provisioning, pipeline maintenance, and production on-call rotations, they introduce systematic noise into the delivery chain.

The operational nature of operations is reactive, interrupt-driven, and volatile. The operational nature of engineering is proactive, focus-driven, and deeply contextual. Forcing a single mind to constantly jump between the quiet isolation required to write pure algorithms and the chaotic, high-alert state required to debug a cloud node destroys the lifecycle cadence of both. The engineer is left in a state of permanent cognitive fragmentation, producing compromised code and fragile infrastructure.

Conclusion: Teams Should Be Cross-Functional, Not Individuals

The industry’s obsession with hybrid roles stems from a fundamental misunderstanding of what cross-functional engineering actually means. Management often conflates a cross-functional team with cross-functional individuals. They assume that if a team needs to be agile, every single member must morph into a Swiss Army knife, blurring the boundaries of their core competence until the operational focus evaporates.

The SWEBOK (Software Engineering Body of Knowledge) does not treat Software Requirements, Software Design, and Software Construction as interchangeable tasks for a single generalist. It categorizes them as distinct, specialized disciplines with their own chapters, methodologies, and mindsets.

When an organization respects these boundaries, it is not creating rigid silos; it is protecting the functional purity of the product. True cross-functional agility is achieved when distinct specialists—each mastering their own layer of Data, Algorithms, or Boundaries—collaborate seamlessly along clean, well-defined interfaces.

We do not build software to showcase our ability to multi-task or to minimize headcount at the expense of sustainable design. We build it to execute a business function. If you want a system that possesses conceptual integrity, respect the ancient archaeology of your human patterns. Build your engineering teams the way you build your cleanest codebases: with highly cohesive components, loosely coupled roles, and strictly isolated responsibilities. Build your rectangles with pragmatic, distinct intent.

If you wish to submerge yourself deeper into the underlying patterns of systems, teams, and constraints, consider pulling these works from your shelf: