Move one box on an org chart and the company hears a speech.
Put Customer Success under Sales and renewals start sharing oxygen with new revenue. Give Security a direct line to the CEO and risk has a shorter route into the room. Bury a strategic initiative 5 layers down, across 3 functions, and every decision about it now has a commute.
None of those choices proves what leaders believe. Organizations are too complicated for structural fortune-telling. A direct report may be ignored; a deeply nested team may be unusually influential. But an org chart still records a set of practical decisions about attention, authority, communication, and whose trade-offs get settled together.
That makes structure more revealing than the values page. The values page describes what the organization hopes to be. The chart shows some of what it has made easy, hard, central, and remote.
The useful question is not, "What secret motive does this box expose?" It is simpler: if this priority really matters, does the structure help people act like it?
What the evidence says
- An org chart does not measure culture or prove intent. It does show formal reporting relationships, layers, grouping, and where authority is meant to sit.
- Melvin Conway argued in 1968 that systems tend to reflect the communication structures of the organizations that design them.
- A 2016 review of 142 empirical studies found mirroring between technical and organizational structures was common in firms and industries, but not universal.
- Direct reports, team boundaries, and layers shape access and coordination. They are constraints, not destiny.
- Read the chart as a hypothesis about priorities, then test it against budgets, calendars, decisions, and the informal network where work actually happens.
An org chart is a set of management decisions
An org chart looks passive after it has been drawn. The boxes sit still. The lines behave. Nothing on the page admits how many arguments were required to put them there.
Yet each structural choice answers a management question.
Grouping people into one function says some work benefits from shared standards, skills, or leadership. Splitting them into separate business units says proximity to a market, product, or customer matters more. Adding a management layer creates another place to coordinate and another boundary information must cross. Removing one gives senior leaders more direct contact and more people competing for the same attention.
Reporting lines also allocate formal authority. They influence who approves hiring, evaluates performance, controls a budget, resolves a conflict, and hears bad news first. The line may be badly used, but it is not decorative.
This is why reporting lines and ownership are different, but related. The chart does not tell you who owns every customer outcome or cross-functional decision. It does tell you where the organization expects formal management to happen. That expectation shapes the operating environment around the work.
When leaders say a subject is strategic, the chart offers a useful follow-up. Who has the authority to make the subject real? Who settles its conflicts with other priorities? How far does a warning travel before it reaches someone who can act?
If the answer is "it depends," that may be honest. If the answer is "nobody knows," the mission statement is doing unpaid structural work.
Conway's law made communication part of the design
In 1968, computer scientist Melvin Conway published an article with the modest title "How Do Committees Invent?". Near the end, he stated the observation that would outlive the rest of the paper: organizations that design systems are constrained to produce designs that resemble their communication structures.
The mechanism is less mystical than the name Conway's law suggests. When 2 parts of a system depend on each other, the people designing those parts need to coordinate. Team boundaries, communication channels, and the division of work influence which dependencies are noticed, negotiated, or avoided. Over time, the product can begin to carry the shape of the organization that made it.
A payment team and an account team that rarely coordinate may create an equally awkward seam in the customer experience. Three teams with separate roadmaps may produce 3 versions of the same underlying capability. A company organized around channels may find the mobile and desktop experiences developing separate ideas about what the product is.
This does not mean every awkward product seam can be diagnosed by staring at the chart. It means organizational boundaries create coordination conditions, and those conditions can appear in the work.
The later evidence is interesting precisely because it is mixed. Alan MacCormack, Carliss Baldwin, and John Rusnak compared software systems produced by organizations with different structures and found support for the idea that product and organizational architectures mirror each other.
But a broader 2016 review of 142 empirical studies found boundaries. Mirroring was prevalent in firm and industry studies, not universal. Evidence from open collaborative projects was much less supportive, and digital coordination sometimes allowed groups to break the expected pattern.
That is a better result than a law that claims to explain everything. Structure exerts pressure. People, tools, modular designs, and strong cross-boundary relationships can resist it.
What reporting lines reveal, and what they do not
The most conspicuous signal on a chart is proximity to the top. A CEO's direct reports usually have faster access to the person who resolves organization-wide trade-offs. Their subjects are more likely to appear in senior meetings because the people responsible for them are already there.
That access can reflect a priority. It can also reflect company history, executive preference, a temporary crisis, or a role that simply needs enterprise-wide scope. One box does not constitute a diagnosis.
Patterns are more useful.
Look at what has a seat together. If Product, Engineering, and Design report through one executive, the organization has created a place to settle their trade-offs. If they meet only at the CEO, ordinary disagreements may travel higher than anyone intended.
Look at what is centralized. Centralizing Legal, Finance, People, Data, or Operations can create consistency and economies of skill. It can also increase distance from the teams that need decisions. Decentralizing them can improve local response while producing duplicated work and incompatible standards. The right choice depends on the work. The cost exists either way.
Look at the layers. Layers are not automatically bureaucracy. A good manager can translate strategy, develop people, and coordinate work that would otherwise land on one overloaded leader. A bad layer forwards information in both directions and calls the delay alignment.
Look at the boundaries. If a customer journey crosses 6 teams, the customer will experience all 6 handoffs even if the chart presents them beautifully. If one product depends on teams with unrelated priorities, those dependencies require an explicit coordination mechanism. Hope is not one.
Look at the exceptions. Temporary teams, dotted lines, chiefs of staff, and special project offices often appear where the normal structure cannot handle an important piece of work. Exceptions may be sensible. A large collection of them is the organization writing margin notes on its own design.
These signals tell you what the formal system is set up to do. They do not tell you whether leaders behave accordingly, whether employees trust one another, or whether an unofficial expert is quietly keeping 4 departments functional. For that, you need to understand the informal organization behind the chart.
Structure follows priorities, then starts shaping them
Leaders often discuss structure as if it obediently follows strategy. Decide what matters, arrange the organization to deliver it, and carry on.
The first half is sensible. The second misses what happens next.
Once installed, a structure develops momentum. People build expertise inside its boundaries. Budgets follow its units. Performance goals reward local outcomes. Meetings, dashboards, and career paths grow around it. Yesterday's strategy becomes today's operating environment.
That environment then shapes what the company notices and can do easily. A centralized function sees patterns across the whole company but may respond slowly to local variation. A product-aligned team can move quickly for its customers but may solve a shared problem in splendid isolation from 4 other product teams.
This feedback loop is why an old chart can quietly preserve an old strategy. Nobody has to oppose the new priority. The existing system can simply make the old behavior cheaper.
It is also why reorganizations are tempting. The mismatch is visible, so redrawing the structure feels like direct action. Sometimes it is. Sometimes the chart changes while goals, incentives, decision rights, and habits remain untouched. That is why reorgs so often fix less than their diagrams promise.
The chart matters. It just cannot carry the change alone.
The inverse Conway maneuver is a design bet, not a spell
Software organizations sometimes use an inverse Conway maneuver: arrange teams around the architecture they want, so communication patterns support that design rather than reproducing an inconvenient legacy structure.
The idea is powerful. If a company wants independent product modules, giving stable teams clear ownership of those modules can reduce constant negotiation. If it wants one coherent customer journey, grouping the necessary skills around that journey may be more effective than asking separate functions to coordinate through tickets.
But the phrase can acquire more confidence than the evidence deserves. Changing team boundaries does not automatically create a good technical architecture. It can move dependencies out of sight, overload specialists, or produce clean boxes around work that remains tightly coupled.
Use the maneuver as a hypothesis:
- What customer or operational outcome should become easier?
- Which technical and work dependencies does that outcome contain?
- Which people need frequent, high-quality communication to manage those dependencies?
- What authority must sit inside the team, and what expertise can remain shared?
- Which new boundary will the design create, and how will work cross it?
That last question prevents the familiar organizational magic trick in which a problem disappears from one side of a line and reappears on the other with a new meeting series.
How to read your org chart without pretending it is a personality test
Start with a priority leaders have repeated often enough that everyone can recite it. Customer retention. Product quality. International growth. Cost discipline. Faster decisions.
Then trace it through the formal structure.
- Which role is answerable for the outcome?
- Does that person have the authority to resolve its most common trade-offs?
- Which teams must cooperate, and where do their goals conflict?
- How many layers separate frontline information from a consequential decision?
- Where does scarce expertise sit?
- What gets measured and rewarded inside each unit?
- Which informal relationships compensate for the chart?
Do not score the answers. Discuss the mismatches.
Some will be deliberate. A compliance function may need independence more than speed. A scarce technical specialty may be centralized even when product teams would prefer dedicated support. A temporary business priority may not justify a permanent reporting change.
Other mismatches will expose a priority that exists mostly in presentation software. That is useful information. It lets leaders choose among 3 honest responses: change the structure, add a real operating mechanism across it, or stop claiming the priority outranks everything the system currently rewards.
An org chart is not a confession under oath. It cannot tell you what leaders privately care about, and it cannot capture the trust, influence, or habits that make the formal organization work.
It is still evidence.
The chart shows where the organization has placed people, authority, and distance. Those choices create a practical theory of how work should happen. If the theory contradicts the strategy, employees will eventually learn which document to believe.