I have an organization of a few hundred people reporting to me. These people are intelligent, knowledgeable, and sophisticated. They’re motivated to do their jobs well and accomplish our mission. We’re trying to do difficult and complicated things, but I have to explain everything like they’re five because nuance does not scale.

Think about how you handle problems with a small team. You talk a lot. You listen a lot. You propose ideas, pick holes in them, patch them up, shoot them down. It takes a lot of time. Now embed that team into a larger organization supporting a multi-billion dollar business. This team has to make sure that what they build fits into the strategy. They have to collaborate with a half a dozen other teams.

Building a software product is hard. It’s not one decisions but hundreds of thousands of decisions, maybe even millions. Building dozens of software products is proportionally harder, especially with your teams distributed around the world. Even if I had the knowledge to make all of those decisions well, I certainly don’t have the time or bandwidth. Instead, the decisions are distributed all throughout the team. Some of the decisions are things that can be computed from available information to derive the “right” answer. Where that isn’t possible, or it isn’t possible with the information available to the individuals on the teams, is where I need to fill a void.

Somehow I have to fill that void with useful guidance and information at scale. That means I have to keep the messages simple. I can’t meet with everyone on each team to explain what I meant when I chose my words clumsily. I can’t explain how abstractly-expressed guidelines apply to each individual situation. I can’t describe a complicated method for identifying situations where the guidance applies and where it doesn’t. I can’t leave out important decisions as exercises for the reader, assuming everyone will know exactly how to fill in the blank. I have to give guidance that is unambiguous, readily applied, complete, and with clear guidelines of when to apply it. If not, the best case scenario is that I’m inundated with questions. Worse is the possibility they think they understand, but what they understood and what I meant are different.

It would be nice if this was just about how the guidance was phrased, but it often means that the underlying ideas need to be simplified as well. That means that our API first strategy applies to every externally-facing product, not just the ones where we expect to have a customer. It means our accessibility audit deadline is the same for every team, no matter how important their product or which countries they serve. It means that we focus the complex and sprawling idea of “application fidelity” on the idea of showing the job seeker the exact application the employer will see for them to confirm and submit. It means that I list exactly which time zones are part of Asia/Pacific and which are part of the Americas, and I deny that Europe exists.

These are not definitely the best decisions to make for each situation facing each team. But they are the best decisions to make when I’m deciding for every team at once. The bigger the organization, the simpler and clearer your ideas have to be. There may be better ideas, but you won’t be able to get them implemented because doing so means you have to anticipate or react to a blizzard of questions and clarifications that you either will handle imperfectly or burn enormous amounts of time trying to handle perfectly (and probably still fail).