Management The Basics Don't Scale

The Org Chart Test

If you’ve had a 1:1 with me in the last decade you know that once we’re done with our planned agenda that there is good chance that I’ll stand up, walk to the whiteboard, and start drawing some version of the organization chart (“org chart”).

I believe the org chart is one of the three critical artifacts that must be easily discovered and well-maintained. Why? First, let’s start with a definition. In my favorite part of Managing Humans, the glossary, I define an org chart as:

A visual representation of who reports to whom. Org charts are handy in large organizations for figuring out who you’re dealing with.

That’s one good use case, but one is missing. An org chart should also effectively describe, at a high level, how the product is organized and also who is responsible for what. An org chart should be legible.

The Legibility Test

Grab a co-worker (doesn’t matter who), head to your nearest empty conference room with a whiteboard, grab a colored pen and make sure it’s not a Sharpie™, and starting scribbling. We’re looking for an org chart.

Rands, how should I draw it? Boxes and arrows? Architecture? People structure? Technical structure? Which boxes go where? I need guidance.

For this exercise, the only guidance I’ll provide is no names of human beings.1 Please draw what you consider to be the most commonly understood version of the org chart.

Done? Ok.

Here are a series of increasingly complex questions your drawing should answer:

Did you draw something? Seems like a simple part of the task, right? I do candidate interviews all the time, so I’ve got this drawing down, but I wonder about you. How quickly can you step up, draw some boxes, and give them names? Are you happy with the result?

At any point during the drawing process, did you stop to explain yourself? Are there parts where you are making excuses for the way it’s being drawn? As you were drawing the boxes, did you need to stop and say “Yeah, this is weird, but…” or “You probably think this box means THIS, but it means THAT.” If you’re like me and you’ve drawn this picture a lot, you probably don’t even hear these excuses because that’s just the way we’ve always described it.

When you’re a small team, say less than 100, the org chart isn’t that important because the humans can keep the state of the team in their head. Nothing needs to be written down because communication is freely flowing. The communication tax of large organizations has not yet been applied. The humans know who is responsible for what. They know who owns different parts of the stack. They must. It’s a small company, and the ownership of things is changing all the time because… it’s a start-up. Chaos is the defining characteristic.

At some point, someone on the team is talking to an interview candidate, and they realize they need to draw a visual representation of the team. It’s crude. It’s fast. And it’s the very first org chart. More on this moment, but back the test.

Final question. If you left the org chart on the white board2 and a random tenured human on the team walked by the conference room and saw the org chart, would they or would they nod and say, “Yup, that’s about right.” The tax on communication increases as a function of the size of the team. The reason you need agreed upon and well-understood artifacts like an org chart is because critical aspects of the organisms are clear. Everyone understands critical truths.

This final question is impossible to answer effectively. You need to answer the question subjectively, “Is my org chart legible?” Is it clear enough to read? Could your average employee without any outside help read your org chart and answer the following questions:

  1. What are the constituent parts of the team?
  2. It is clear from the names of the different teams who are likely responsible for what within the team?
  3. Does how the org chart is drawn give the reader a high-level idea of how the product or business is architected?

Management types take this artifact for granted because we live it. Our day is full of travels across the org chart. It’s our mental map for the humans the and technology within our teams which means we both understand it and take it for granted. The vast majority of the humans in the organization do not have a daily need for org chart understanding, but when they do, your goal is instant maximum legibility.

The Basics at Scale

How much time is your team thinking about obvious things? Tricky question for a manager to answer because the job gives you extraordinary access to information. There are daily reminders of the obvious.

The communication tax applied to large teams assures that the basic information doesn’t scale without structured assistance. The org chart, the company values, and the current business goals: this critical set of information must become a set of easily discoverable and well-maintained artifacts. When the humans have a question, your goal is they habitually return to these artifacts to answer their obvious questions because they are full of critical truth.


  1. When proper names show up on an org chart, it transforms into a different beast. It’s an equally important artifact, but when names land on the org chart, it becomes less organizational and more political.

    Back to our rapidly growing start-up. There’s a critical inflection point when someone somewhere in the building thinks, “We need managers” and twelve point three seconds later they draw a people-based org chart on the nearest piece of paper. Jules can work with this folks. Kate can manage these humans. Ok. Whew. Next crisis.

    This is backwards. Jules and Kate are lovely humans and perfectly capable of being managers, but an org chart built around the humans is backwards. What are you building? An e-commerce site? Rad. You likely have a front end team and a back-end team. Build your first org chart around your product or the technology; not the people.

    A people-based org chart describes power structures. Who is responsible for whom? What do they own? How big is their area of influence? Who do they report to? You can not avoid these questions being asked, but you can set the tone for how you view your organization structures. Product first? Technology first? Or people first?

    I share this advice with you because it’s a mistake I’ve made for years. Initial conditions set a tone that is nigh impossible to change. 

  2. Don’t do this. It freaks people out. See above.