Reading the Org Chart Like an Architect: What Reporting Lines Reveal About Your Systems
Photo: James Bray Griffith, Public domain, via Wikimedia Commons
Ask a chief architect why the customer data platform requires three manual reconciliation steps every quarter-close, and you will likely hear a technical explanation: legacy schemas, an ill-timed vendor sunset, an integration that never got rebuilt. Ask a sharper question — what happened in the organization in 2019? — and the answer often changes entirely.
Conway's Law, the 1967 observation that organizations design systems mirroring their own communication structures, has hardened into a cliché in engineering circles. What receives far less attention is the corollary that matters most in practice: when the organization changes and the systems do not, yesterday's org chart becomes tomorrow's technical debt.
The Fossil Record of Reorganizations
Consider a pattern that plays out repeatedly across American enterprises. A regional insurance carrier splits its claims operation into two divisions — one handling personal lines, the other commercial — in a 2019 restructuring driven by a new COO. The split made sense commercially. Nobody ordered a corresponding change to the claims management platform, which had been built as a single workflow engine.
Five years later, the platform carries two parallel status models, two sets of business rules embedded in duplicated service layers, and a handoff queue between the divisions that exists only because two vice presidents needed separate reporting lines. Engineers who joined after 2021 describe the duplication as a baffling architectural decision. It was never an architectural decision at all. It was an organizational decision that hardened into architecture because nobody with the authority to change the system was in the room when the reorg was approved.
This is the fossil record effect: reorganizations leave strata in the codebase, and architects who excavate carefully can date a system's strangest features to the moment the reporting lines moved beneath them.
Mergers Write the Ugliest Code
Acquisitions produce the most vivid examples. When a Midwest healthcare services firm acquired a smaller competitor in 2020, the integration playbook called for consolidating onto the acquirer's billing system within eighteen months. The deadline slipped, then slipped again. What remains today is a dual-billing environment where the choice of which system processes a given account depends on which sales region originally signed the customer — a boundary that maps precisely, account by account, onto a sales territory realignment that happened during the deal.
The lesson is uncomfortable: integration roadmaps are political documents. The system that survives is frequently the one whose owner had the stronger seat at the table, not the one that was technically superior. Post-merger architectures are, in effect, a written record of who won the argument — and losing factions tend to keep their systems alive out of inertia, budget protection, or simple spite.
Why Architects Should Read the HR File
If organizational structure shapes system structure, then architectural review boards are working with half the evidence. A few practices can close the gap:
Maintain a reorg-to-architecture ledger. Every significant organizational change — a new business unit, a leadership change, a consolidation — should trigger a documented assessment of which systems are affected. Most enterprises track application inventory meticulously and organizational change not at all.
Interview the survivors. The engineers who can explain why a service boundary exists where it does are often the same people who lived through the original reorganization. Their departure, as VZDR has noted before, is one of the most expensive events an enterprise can fail to plan for.
Treat duplicated capability as an org chart symptom first. Before commissioning a costly consolidation project, ask whether the duplication reflects a genuine business need or merely two teams that stopped talking. The remediation plan differs enormously depending on the answer.
Simulate the target organization before the target architecture. When designing a future-state platform, pressure-test it against the org chart as it will exist after announced changes, not merely as it stands today. A design that assumes seamless collaboration between two departments scheduled for separation is a design already failing.
The Inverse Lever: Designing the Organization on Purpose
The most mature organizations run Conway's Law in reverse. Rather than accepting that architecture will mirror the org chart, they deliberately shape teams to produce the architecture they want — an approach popularized as team topologies. A company that wants a unified customer profile does not merely fund a data platform; it restructures ownership so that a single accountable team controls the customer identity domain end to end.
This requires executives to accept something they often resist: system design and organizational design are the same discipline practiced at different altitudes. A CIO who approves a reorganization without consulting the architecture function is making an architecture decision with an HR document. The reverse is equally true.
Conclusion: The Map Is Hidden in the Org
The clunky designs that frustrate engineering teams are rarely products of bad engineering. More often, they are faithful — even elegant — renderings of an organization as it existed at some past moment, preserved in code long after the humans moved on. Enterprises that want honest architectures need honest records of their own history: who reported to whom, when, and why. Architects who can read those documents as fluently as they read a dependency graph will find that the most confusing systems in the portfolio suddenly make perfect sense. Making sense of them is the first step toward changing them.
