Disclaimer: I originally wrote this as a private doc for the Lightcone team. I then showed it to John and he said he would pay me to post it here. That sounded awfully compelling. However, I wanted to note that I’m an early founder who hasn't built anything truly great yet. I’m writing this doc because as Lightcone is growing, I have to take a stance on these questions. I need to design our org to handle more people. Still, I haven’t seen the results long-term, and who knows if this is good advice. Don’t overinterpret this. 

Suppose you went up on stage in front of a company you founded, that now had grown to 100, or 1000, 10 000+ people. You were going to give a talk about your company values. You can say things like “We care about moving fast, taking responsibility, and being creative” -- but I expect these words would mostly fall flat. At the end of the day, the path the water takes down the hill is determined by the shape of the territory, not the sound the water makes as it swooshes by. To manage that many people, it seems to me you need clear, concrete instructions. What are those? What are things you could write down on a piece of paper and pass along your chain of command, such that if at the end people go ahead and just implement them, without asking what you meant, they would still preserve some chunk of what makes your org work? 

Here’s my current best guess at how I would do this for Lightcone Infrastructure, the organisation where I spend the majority of my waking hours. I wrote it by thinking about how the team I'm on has actually operated during periods of high output, and then trying to turn that into a set of rules. Others on the team might disagree about which rules matter and where the magic sauce is, but I think this is at least empirically descriptive of how my team spends much of our time. 

0. Blockers are death. Above all else, your job is to unblock anything that prevents you from moving as fast as you can toward your top priority.

1. The team has one team lead who’s the final decision-maker on all decisions, unless they explicitly delegate a decision. Consensus is slow and blocking. Having a tie-breaker means you can move faster. 
2. Start each Monday with an all-hands meeting where the team lead sets or clarifies the top priority of the team. 
3. After the Monday meeting, there’s a block of time on everyone’s calendar during which no one is allowed to schedule any meetings in advance. This is the “top priority block”, where everyone’s sole goal is to work on whatever the top priority is, as identified in the all-hands meeting. The point of not scheduling meetings is so that no one ends up blocked and waiting for someone else to come out of a call or meeting (that’s not itself about the top priority). Any person on the team who could unblock someone else’s pursuit of the top priority, is available to do so during this block. 
4. Have a single day, e.g. Tuesday, that’s the “meeting day”, where people are expected to schedule any miscellaneous, external meetings (e.g. giving someone career advice, or grabbing coffee with a contact). The reason I find this important is that, if you don’t have it, people end up scheduling their meetings at random, uncoordinated times during the week. And this means that there ends up being very few slots where the people who might unblock each other are both free at the same time. 
5. No remote work. Everyone is in the office. If you need to be unblocked by someone, the fastest way is to just go to their desk and ask them in person. 
6. People on the same team work in the same room. Sudden questions, comments, or info sharing out loud is encouraged. If people want to focus deeply for a while, they can put on headphones.
7. For many tasks, pairing (or occasionally, where it makes sense, trio-ing), is encouraged.
   1. This is often a big boost to people’s ability to stay focused on the goal and avoid making stupid mistakes that another person would catch. 
   2. It also has the side-effect that there are two people with context who understand this task, as opposed to a single point of failure. This again derives from Postulate 0: blockers are death. Having multiple people with context is an excellent way to avoid single people becoming blocking elements for the org
   3. Sometimes people have an intuition that “it’s more efficient for two people to split and do different things as opposed to collaborating on the same task”. I think this intuition is most often wrong for Lightcone (and orgs with similar goals), because the important thing is not how many tasks you can do at once, but how quickly you can pursue your top priority. 
8. Use a real-time chat platform like Slack to communicate (except for in-person communication). For god’s sake, never use email within the team.
9. On Slack, add all team members to all channels relevant to the team. Splitting people up across channels is not efficient, even though it might appear that way -- because it increases confusion in the organisation (people don’t know what’s going on elsewhere), which causes you to be less efficient at the long-run goal of moving as fast as possible toward your top priority. 
10. Do not use private, direct messages, except in rare cases. Instead create a set of public 1-1 channels between pairs of people, but where each channel has the whole team in them. Like this:
     
11. I think the simple rules in 9 and 10 have surprisingly large implications. 
     
    1. I think that the natural way information travels between people is usually in the form of nuggets of chit chat, clarifying questions, gossip, or 1-1 conversation. By default information does not travel via long written documents. Writing and sending those documents around will slow your team down a lot. 
    2. Chit chat, 1-1 or in small groups, is also the default way humans coordinate and sync up on things. They don’t use big meetings with processes. Meetings are death. They slow everyone down. If you have public 1-1 channels you remove the need for a ton of meetings -- because people see what’s happening and sync up by default. 
    3. Moreover, when people have managers they only meet with occasionally (e.g. once per week), there’s a tendency to need to “have something to show your manager”. You want to impress your manager, and you have 1 hour a week in which to do so. “Look, I made a massive list in this spreadsheet of all the 300 hotels in Berkeley, along with rankings of all of them along 9 key dimensions, so that we can now sit down together and pick the best one for our next retreat!” The spreadsheet looks like a unit of progress. It is a legible artefact. The problem with such artefacts is that they’re very often bloated and totally unnecessary. Most progress is not shaped like an artefact, and trying to turn it into one is a tax on speed. The fastest way of finding the right retreat location might be to throw out 3 links to different airbnbs, have your team offer a few comments, realise a key consideration, and then go ahead and book the right one. This doesn’t produce any impressive artefact you can show a manager. But a good retreat centre got booked, real fast, and the manager could see that. 
    4. (Separately, I hypothesise that it makes people more agentic, via the following mechanism. Sometimes when people join teams, their manager onboards them, gives them a clear task, sends them off to their desk, and tells them they’ll check in again in a week. As the time a week later arrives, unsurprisingly, the new recruit has not accomplished much, or, insofar as they have, it was in totally the wrong direction. I think this is often because the new recruit lacks something I’d call “context”. There’s a nebulous sense of “who understands process X, who is in charge of thing Y, who should I ask about thing Z, who is already working on task W and where are they at” and so on, and new recruits lack most of this info, which tends to add up to a state of confusion and paralysis, that cause them to have a hard time doing anything. When we have public 1-1 channels, we automatically imbue most context on most people. It’s much less common to be left wondering what on earth is going on, and as a result people will be more empowered to just do what they think needs doing (and their hypotheses as to the-right-thing-to-do will be much more on track, given the context they have).)
    5. Finally, some people are good coders, some are good designers, others know a lot about geography, others know obscure wikipedia facts, and so on. Even if two people nominally collaborate on a task, there’s often a third person who has a take or some other resource that would be very useful to them. By having public channels, you enable that person to appear and share that info. 
    6. (The exception to public DM channels is cases where you want to signal that you’re not trying to embarrass or attack someone in front of the whole team, you’re just trying to give them direct feedback or something like that. As a heuristic, if you are DM-ing your colleagues once a week, then you’re using it too much.) 
12. When working with outside teams, try to replicate some of the above dynamics by e.g.
    1. Using “connected channels” in Slack, and adding the whole team to those channels, or
    2. Have a “team_transparency@companyname” email address, which is such that when someone CC’s it on an email, the email gets forwarded to a designated slack channel
13. If one of your teammates messages you directly, or if someone @ tags you, you want to respond basically immediately. In other cases (e.g. discussion in main team channels), it is common for people to often respond immediately, but it’s often fine not to. I think this is important for a few reasons: 
    1. Sometimes, for me to book a company flight, I need to get the site password from Alice, get the company card details from Bob (who in turn needs to verify with Carol that she can actually give them out), and for Dave to tell me that “pro tip: you actually can save a lot of time by using this other site me and Alice just found”. If people don’t reply immediately, this whole process can take a week: there’s a chain of 3 people passing information to each other, each of whom takes a day to reply (and you first go down the chain, and the replies have to travel all the way back up!) If you respond immediately, resolving this takes 1 minute. Blockers are death, and you want to be the kind of org where if someone is blocked on you responding to their message, you want to respond and unblock them immediately. 
14. Everyone on your team should be full-time. A person who is only around part time will end up losing context when they’re gone, and even worse, for whatever parts of your org only they understand, other people will end up being blocked on them when they are not around. A person who works 40h a week is much more than 2x as valuable as someone who works 20h. These phenomena continue to scale as people work even longer weeks, but eventually drastically decline as people become overworked.
15. If you have a blocker that could be resolved in a minute, you are encouraged to immediately interrupt the person who could resolve it for you. If they’re not in a meeting, just go ahead. If they are in a meeting, you might want to check that it’s not with the literal President of the United States or something, but in most cases it is absolutely fine to walk into and briefly interrupt people in meetings when they are blocking elements, that could be easily resolved. 
16. If you want to take up everyone’s time with a big meeting, prepare a memo. 
17. Have regular 1-1s with the people you work with. Some considerations only get verbalised via meandering, verbal conversation. Don’t kill it with process or time-bounds. Some crucial considerations, and some of the best ideas, are had by people just messing around late into the evening, talking because it’s interesting and seemingly without aim. Don’t let this kind of conversation drown out your other work -- but make space for it. 

That's it for now. 

I have more to say, but for now I will ship early.