Specifically, companies with a flat structure (no managers at all) are weird. Decades of management tradition tell us that Someone must be in charge and make sure everyone’s doing their work. Otherwise, everyone will goof off, right? And yet, somehow these companies manage to work out. I’m not even talking about the big ones that hog all the attention (looking at you, GitHub). Big, flat companies are wonderful case studies on their own but, much like quantum physics, it’s when things reach the tiny startup scale that they start to get weird. A team of five won’t have a full-time manager (unless something goes drastically wrong). How do things get done? Who decides what to do next? What happens when (gasp) people disagree?

I am by no means an expert in this topic. Rather, this essay has been written as a letter to my college self, containing what I wish I had known back then about flat management. I hope you learn something!

Management does not get the attention it deserves in a small startup fighting for its life (much like everything else). I’ve seen startups tear themselves apart like an off-center centrifuge thanks to a lack of focus or unwillingness to Make Tough Decisions. Managing people will be the hardest thing you do as a founder.

This is why we see the default for companies at this stage to be declaring themselves “flat”. At the surface, it seems like a good idea. “I’ve hired smart people” you, the founder, might think. “They can take care of themselves while I focus on the many other things that are currently on fire.”

To a certain extent, you’re absolutely right. If you haven’t hired smart people, stop reading this and go fix that situation by any means necessary. If you have hired smart people, congrats! Step one completed. On to steps two through eight bazillion! For argument’s sake, let’s define flat as “Delegation of 100% of management tasks” (excluding administrative things like paperwork and talking to lawyers). This is in contrast to a hybrid model where long-term decisions are passed down but employees are largely free to implement as they see fit.

Let’s try and answer the three questions from the opening paragraph with the “100% delegation” model:

How do things get done?

You’ve hired smart, motivated people who enjoy what they do. Getting good programmers to program is not a hard task (in fact, stopping them from programming might be harder). No problems here.

Who decides what to do next?

Ah, here’s where things start getting tricky. One of the main troubles with hackers is that we tend to dive into a rabbit hole and keep exploring. Getting to 100% coverage or utilizing that nifty new tool might feel awesome but it’s not propelling the product forward. We’re delegating all the things, so we can’t create a TODO list and tell everyone to follow that. What do we do?

Remember the dozens of articles talking about the importance of “culture” and “mission” that hit HN every week? You can’t throw a rock in San Francisco without hitting someone talking about how important mission and culture are (speaking of, try and create a culture of not throwing rocks at people - it does wonders for recruiting). If you create a setting where things get done in a given style, others will follow. Your team members can weigh their next action on “Does it follow the mission?” without any additional input from you. 100% delegation achieved. Well, 99.9% delegation; you’ll still need to decide on a mission, but it scales after that.

A practical example of this is how an employee deals with a problem they can’t overcome. They could continue attacking the problem, take a short break, or interrupt a coworker and ask for help. All of these are reasonable options but the one that’s selected depends on the priorities of the company. Is uninterrupted work time more valuable than a fast answer? Is it acceptable to browse Facebook while you shunt the problem to a mental background process?

Other critical questions in day-to-day work include:

  • How are teams formed?
  • How important are tests?
  • What frameworks/plugins/etc should we use?

Creating a culture that answers these problems is outside the scope of this essay. If you’re interested, check out the two culture talks from Sam Altman’s Startup Class: part 1 part 2

What happens when people disagree?

Most of the time, disagreements are amicable and resolve themselves without external intervention. I’ve had cases where, after 15 minutes of fruitless discussion on what pattern was best, we put it to the gods of Math.random() to decide for us. These are cases where 100% delegation works out fine.

We are still human, despite Kurzweil’s best efforts, and there will still be times when we just don’t get along. The worst thing you can do here is to remain vigilantly neutral. When conflict flares up, you can’t delegate the task of making sure everyone gets along. Sometimes things get so bad you have to step in. It’s important to remember that those involved in the scuffle honestly do believe they’re in the right - coming down with the hammer of “You were in the wrong, so stop it” will not encourage a healthy workplace. Building rapport through empathy (https://getlighthouse.com/blog/building-rapport/) will be an incredibly powerful tool in the rare situations when you have to drop out of 100% mode. I promise - it’ll make everyone’s lives easier.

Hiring

Deciding which potential employees to bring on is bit trickier. I believe that the only rational hiring process is a centralized one. Without a centralized, objective process, the selection criteria chosen by the typical engineer is too variable for hiring to be performed in an objective manner. This centralization breaks the 100% model.

As a field, we’re absolutely rubbish at interviewing. Most of the things we use to evaluate candidates (tricky logic puzzles, reciting algorithms from memory, ambiguous “fit”) either do not judge the candidate on work skills, or worse, depend entirely on the interviewer’s mood. With 100% delegation, each employee selects their own interviewing style, making it difficult to evaluate and compare candidates.

You’ll need to set a standard for candidate evaluation by ensuring your employees know how to run an objective interview and modeling it yourself. Once things are set in place, it is much easier to maintain momentum. An excellent treatise on the subject can be found here: http://sockpuppet.org/blog/2015/03/06/the-hiring-post/

You may think otherwise about any of the concepts presented here - if you do, please write about it! I’d love to hear your thoughts.