The Org Chart Is a Lie. Here's How IT Actually Works.
Every organization has two structures. The first is the one on the org chart, a tidy hierarchy of boxes and lines that suggests a clean, logical flow of authority, communication, and decision-making from the top of the chart to the bottom. The second is the one that actually exists, a complex, informal, relationship-driven network that bears a family resemblance to the org chart in the way that a map of a city resembles the city itself: technically accurate in broad strokes, silent on all the things that actually determine whether you get where you are trying to go. IT professionals learn to read both maps, because navigating only the official one is a reliable way to get very little done.
The informal network is where IT work actually happens in most organizations. It is the reason why a project that has been stuck in formal approval for six weeks gets unstuck in forty-eight hours after the right conversation at the right coffee machine. It is the reason why the most effective IT professionals are not always the most technically brilliant ones but the ones who know which business stakeholder actually controls the budget despite what the reporting structure suggests, which department head's endorsement makes a new initiative viable, and which executive assistant manages the calendar of the person whose signature is needed. These are not political skills in the pejorative sense. They are organizational literacy skills, and they are as learnable and as valuable as any technical certification.
The organizational literacy gap creates real problems for IT teams that are technically excellent but structurally naive. The perfectly designed solution that dies in committee because the right people were not brought into the conversation early enough. The implementation that launches successfully but gets quietly undermined because a key stakeholder felt bypassed in the scoping process. The security policy that gets written correctly but never enforced because the person responsible for enforcement reports to someone who finds it inconvenient. Every one of those outcomes is a failure of organizational navigation rather than technical capability, and every one of them is preventable with a better understanding of how decisions actually get made in the specific organization you are working in.
Mapping the informal network is not complicated but it requires deliberate attention. Who do people actually call when they have a problem, regardless of who they are supposed to call? Whose opinion carries weight in meetings that exceeds what their title would predict? Which relationships across department lines are strong enough to accelerate cross-functional work when the formal process is too slow? Who knows where the bodies are buried regarding legacy systems, historical decisions, and why the environment looks the way it does? These people are often not the most senior people in the room. They are frequently the people who have been in the organization long enough to have seen multiple reorganizations, survived multiple leadership changes, and accumulated the institutional knowledge that makes everything else function.
The org chart matters. Formal structures exist for good reasons and operating entirely outside them is its own kind of organizational malpractice. But IT leaders who treat the org chart as the complete and accurate representation of how their organization works will consistently be puzzled by why good technical work fails to produce the organizational outcomes it should. The map and the territory are different things. Learn both.
