A Founder's Guide: The Importance of Organizational Structure

Why corporate bureaucracy is good, actually

Legibility in Code

Our monkey brains are uniquely well suited to pattern recognition. We’re really really good at it. Patterns stick in our brains long after they are useful — anyone who’s ever had an ear-worm stuck in their head knows that. So if you want to really get something through to someone, you have to make it a pattern.

In my post on the importance of writing patterns in programming, I said:

The best way to get someone to understand something is through repetition.

This is hopefully uncontroversial. Instrumentalists will repeat scales over and over until the scales are 'in their fingers'. Children will practice writing the same letters repeatedly, tracing out letters in size 50 font in little handbooks. Slightly older children practice multiplication tables until they are second nature. Every language in the world has some version of the phrase 'practice makes perfect'. Speechwriters and self-help leadership books both proclaim that you must over repeat yourself to get an idea across. And adults in our particular field like to cite the 10000 hour rule.

Repetition is an easy way to make something a pattern. If you do something consistently, every day, you’ll become an expert. Why? Because your brain starts to do the heavy lifting for you.

It’s a bit like working with LLMs. The first time you try to do something new with an LLM, you have to really iterate to get it to work right. Tweak the prompt, provide the context, use RAG, etc. etc. But if you fine tune the LLM instead, all of that extra information is now just in the weights of the model. We incur an upfront training cost to lower our inference cost.

I think humans work similarly, at least if you squint a bit. The first time you do something new, it’s hard. You have to reason from first principles, there’s nothing stored in the ‘weights’ of your brain. But the thousandth time you do something? Well, all the synapses are there to make things fast and easy.

It makes sense to write code in patterns. In the same post, I wrote:

[Patterns in code] are all meta -- they aren't about what the code does, but rather how the code should be written. You could solve any programming problem without these constraints. However, code that follows the above constraints is better because it reduces the cognitive load of the future reader/maintainer by using pattern matching and repetition as an efficiency hack.

That bit about cognitive load is pretty key. Patterns are easier to remember, to work with, and therefore to follow. And that makes tons of sense in a coding environment. Programming legibility is critical for the lifespan and functionality of a particular piece of code. If patterns improve legibility, write in patterns.

I can’t believe it took me so long to realize that all of the above applies to corporate structure too.

Legibility in Corporate Structure

One of the hardest parts of running a company is alignment. Quoting Dan Luu here:

One thing it took me quite a while to understand is how few bits of information it's possible to reliably convey to a large number of people. I've seen quite a few people in upper management attempt to convey a mixed/nuanced message since my time at MS and I have yet to observe a case of this working
...
If I write a blog post and 5% of HN readers get it and 95% miss the point, I view that as a good outcome since was useful for 5% of people. It's different if you run a large org. If you send out a nuanced message and 5% of people get it and 95% of people do contradictory things because they understood different parts of the message, that's a disaster.

Turns out, this isn’t just a problem at big companies like MS. In a world with remote teams and people in different time zones, in a company working on an off-the-wall, never done before product, communicating intent and aligning the team to a single direction is easily the hardest part of day-to-day existence.

Especially as a manager.

Especially especially as a founder.

My team is incredibly talented (really if any of them are reading this, I feel so lucky to work with them) so a little bit of alignment from me goes miles and miles. Which in turn means I spend a lot of time thinking about how to get folks on the same page. This may be obvious to everyone else already, but as a first-time manager I only just realized: patterns need to be laid into corporate structure for all the same reasons they exist in code.

Or, put another way, if you can reduce the cognitive load of a message, you can convey more bits in the message. By structuring our communication, we leave ourselves more room to have nuanced, detailed takes. That, in turn, empowers our team to be more autonomous and make more intelligent decisions which, in turn, directly results in velocity in the right direction.

What do corporate patterns look like in practice?

• Structured meetings with clear purpose that reoccur on consistent time intervals. Daily standup, weekly sprint planning, quarterly strategy all-hands, bi-annual performance review. The formality and cadence of these meetings can be stifling in a large company, but the repetition serves a greater purpose. The guaranteed existence of these meetings allows the rest of the team to plan around them, while also serving to streamline the cognitive load these meetings might otherwise take.

• Standardized practice for documentation, including where documentation is stored and how a document gets shared and read. Templating can be highly constraining, but it can serve to ensure that everyone is on the same page about how to read a document. Meanwhile, making sure that all relevant data can be found with the same patterns means more of the team is starting with the same shared context. I always hated ‘design doc review’ — getting signatures from stakeholders who would inevitably nitpick about some small thing they had ownership over. Now I get it. The sign off means they get it too.

• Consistent HR policies for everything. Vacation days, sick days, what can and can’t be expensed, promotion cycles, travel. Every second the team spends thinking about how to plan a trip or whether they can expense something is time that’s wasted.

But doesn’t this all suck? Isn’t this why we wanted to leave corporate in the first place? — Amol, 2020

Well, yes, it can suck. To a first approximation, this is why a lot of people leave big companies. The structure can be incredibly restrictive, preventing real genius and creativity from shining through while politically optimized muck gets passed around wasting everyone’s time. So whenever my cofounder and I considered adding anything that was too ‘structured’ to our organizational flow, we both internally gagged and agreed not to do it.

But — and it should be obvious by now, but repetition is key to making things land — reducing structure comes with significantly increased cognitive load. And our communication suffered for it. It’s great to have a team that is super competent and autonomous, but that can be dangerous if you don’t have the rigor to provide alignment and direction. And that, in turn, leads to a ton of wasted time as your team goes in a bunch of different directions or, worse, remains paralyzed by indecision.

In retrospect, the beauty of a startup environment is NOT a lack of structure. Rather, it’s the ability to use structure effectively. In a flat team with 10 people, it’s really hard to have corrupt incentives, or overly political processes, or useless sync meetings that exist as some VPs vanity project. Startups are lean enough that they can quickly identify and avoid most of the common failure modes of corporate structure.

And that, in turn, means that startups uniquely can reap the benefits.