When you join a company, or start closely working with one, what’s one of the first things you want to understand?
Maybe it’s the product roadmap, tech stack, metrics, or the strategy. For many of us in technology, it’s the architecture documents. We want to see the system, the platforms, the dependencies, run the tests, and see what’s already been deployed to production. But there is another artifact I’ve learned to pay attention to very early on and that’s the Org Chart.
I am not particularly interested in the hierarchy itself, or to find out who has the biggest title. I am looking to understand how information travels through the company. Who is close to the customer? Who is close to the technology? Who owns the business outcomes> Who has the authority to make decisions (even in flat or teal organizations), and how far are they from the people on ground zero.
Once you start looking at an org chart this way, it stops being a diagram of people and who reports to whom, and will look surprisingly like a data model.
The Org Chart Is Modeling Your Information
Data models define what exists, how things relate to each other, where information belongs, and what constraints govern the movement of information. Organizations have many of those similar characteristics. Reporting lines create relationships; roles create ownership; and management layers transform detailed information into increasingly abstract representations of what is happening.
Here is the catch: if you ever played Telephone Game or Telestrations (our family’s favorite game) you see where I am going with this. The org chart gives you a map of how information is transformed along the way and what eventually comes out the other side.
Note that I am not at all arguing against organizational structure. Hierarchy exists for good reasons, and filtering information is a necessary part of leadership. An executive should not be consumed by understanding every detail of technical tasks and similarly the engineering team doesn’t need to participate in every strategy meeting. Good leaders often separate signals from noise so that people can focus and make decisions without drowning in context.
So the important distinction is not that the information gets filtered, it’s when relevant information is mistaken for noise (and vice versa) because it doesn’t fit naturally into the structure carrying the decision.
Consider a situation that’s familiar to those who worked in large technology companies (and I have seen this many times).
The company announces a strategic partnership with a major cloud provider. From an executive perspective, the decision may be entirely rational. Maybe the company negotiated better pricing, secured favorable long-term plans, etc. There may have been months of thoughtful analysis behind the decision. It’s a clean story, and all in good faith.
Meanwhile, somewhere else in the organizations, engineering teams have spent years accumulating operational knowledge around the existing platform. They know its failure modes, deployment pipelines, security, tooling, cost optimization, and the architecture. However, they were never consulted for the decision making. All of this engineering and information should matter in technology decision making. So what happened?
The question isn’t whether executives should make strategic decisions or whether engineers should have veto power over them. Neither is particularly helpful. The more interesting question is: When did that engineering knowledge enter the decision?
If the decision originated through strategy, finance, procurement, or an executive partnership, there may have been no natural place for that operational context to travel. Eventually engineering will be brought into the conversation, of course. But timing changes the nature of the conversation. Early enough, the question might have been, Should we do this, and under what conditions? Later, after contracts have been negotiated and commitments communicated the question becomes, How do we make this work? (and I have been there through consulting or fulltime employment gigs).
The information wasn’t necessarily ignored; it simply arrived too late to influence the decision.
Information Changes as It Travels
Now back to my family’s favorite game (telestration). Most people are familiar with the telephone game, you know that information changes as it moves. In organizations, however, that transformation isn’t usually caused by carelessness; much of it is intentional and necessary. Every time information jumps from one team to the next, someone is putting their own spin on it - even when they are trying not to..
A detailed technical problem becomes a summary for a director. The director combines it with five other concerns for a VP. The VP translates those into business impacts. By the time the information reaches the executive discussion, ten pages of messy reality may have become one sentence on a slideshow. That level of abstractions is indeed what enables large organizations to function; but it could also lose lots of detailed information that would otherwise make a difference.
Similarly, in a ‘top-down’ matter, a leader might say, “I think we should explore whether AI could help us here.” The leader intends to introduce an idea; a few organizations later, a team hears, “Leadership wants AI in this product.” Exploration has quietly become commitment.
This is where power becomes part of the data model. Authority changes how information is interpreted and travels through the system. Oftentimes, the people close to work have the richest context while the people further away have greater decision authority.
Neither side has the full picture on their own. A healthy organization needs a way for the two to meet before context is compressed beyond usefulness.
When Alignment Hides Missing Information
To get around these communication issues, many companies have company-wide meetings. These meetings go by different names: alignment meetings, all-hands, you name it! The strategy makes sense. The company direction is communicated in these meetings, there are usually green, yellow, red next to each KPI, and often there is time for Q\&A at the end and often these meetings wrap up with a bunch of nodding heads and high-fives.
I wrote about this in When Silence Pretends to Be Alignment: agreement and alignment are not the same thing. Real alignment requires a shared understanding of reality, including the tradeoffs, risks, and uncertainty that comes with a decision. Silence (or Q\&A at the end of the meeting when everything is already decided upon) can just easily mean that people have learned when raising a concern is unlikely to change the outcome.
Seen through the lens of the organization chart, there is another possibility worth considering: perhaps the disagreement never reached the room in the first place. The people sitting around the table may genuinely be aligned based on the information available to them. The missing context was strategically, and in good faith, abstracted away.
That distinction matters. Sometimes what looks like an alignment problem is actually an information flow problem.
Read the Org Chart Differently
So, what can we do about it? Not everyone can attend every meeting all the time, that’s just a waste of everyone’s time. Too much noise hides away the signal, what is the right level of abstraction and how to ensure the important information travels up and down the org chart properly.
Next time you look at the org chart, instead of looking for titles and reporting systems, treat it as a map of information flow. Take one important decision your company has made recently and trace the information that shaped it. Where did the original signal come from: paid customers, execs behind closed doors, engineering team, salesteam, HiPPO (Highest Paid Person Opinion), etc? Then follow the map to see which roles did it travel through before reaching someone who could act on it. Find out where it was summarized or reframed, where was the judgement applied, which people had useful context but no natural path into the decision. Or maybe vice versa, a decision that was great and benefitted all, trace those as well, what details were added, which roles were included in the discussion, when did each piece of information shared.
Then look at the distance - where are the people with the greatest authority structurally farthest from the people with the richest context. The answer to these communication issues is not a flat organization. I have seen many organizations, claiming to be flat and yet they are the hilliest ones, when things go wrong no one wants to take responsibility for it! Teams need boundaries to be effective; organizations need people who can turn complex issues into direction and be able to abstract details for different teams. The point is to simply become more aware of what structure is in place and could affect information.
Once you flip how you look at the org chart - less people diagram, more network map - a lot of those chronic “communication issues” start making a lot more sense. “Communication problems” become routing problems, “data problems” become ownership issues, etc. You will notice that a team who appears to resist change actually has useful context that may have not been communicated properly. Or a company that appears beautifully aligned may simply have become very good at compressing uncertainty.
Next time you hear something like “Why didn’t we know this sooner?”, the correct response might be hiding inside the org chart - Did our organization give that information a path to reach us with enough details within a proper timing?
Long before that dashboard, slideshow, metrics, or AI model, something was already deciding how information would move, where it would be transformed, and who would ultimately see it.
We just called it The Org Chart.