Context: Memo #2 in my sequence of publishing Lightcone Infrastructure internal team memos about our organizational principles

Delegation is good! Delegation is the foundation of civilization! But in the depths of delegation madness breeds and evil rises. 

In my experience, there are three ways in which delegation goes off the rails:

1. You delegate without knowing what good performance on a task looks like

If you do not know how to evaluate performance on a task, you are going to have a really hard time delegating it to someone. Most likely, you will choose someone incompetent for the task at hand. 

But even if you manage to avoid that specific error mode, it is most likely that your delegee will notice that you do not have a standard, and so will use this opportunity to be lazy and do bad work, which they know you won't be able to notice. 

Or even worse, in an attempt to make sure your delegee puts in proper effort, you set an impossibly high standard, to which the delegee can only respond by quitting, or lying about their performance. This can tank a whole project if you discover it too late.

2. You assigned responsibility for a crucial task to an external party

Frequently some task will become the central bottleneck for the success of a project. A key priority of everyone working at Lightcone should be to keep up constant pressure on identifying what our current task bottlenecks are, and to relieve them. 

If you delegate a task which later turns out to be a bottleneck for your project to someone who does not understand the project constraints as much as you do, you are in a much worse position to accelerate progress when the value of doing so becomes much higher.

And sometimes something even worse happens. The party you delegated the task to notices that having become the central bottleneck for your project is a position of leverage over you and the rest of the organization. Due to the scarcity of the labor the delegee provides, they end up rewarded for being the bottleneck, and they will actively fight information and skills from diffusing throughout the organization, as that threatens their high-demand and privileged position.

3. The delegee builds systems or processes that take on a life on their own. 

Even if you overcome these first two problems, and find a delegee competent at a task, manage to set realistic standards that motivate them to do perform high-quality work, and only delegate tasks that are unlikely to become the central bottleneck, your delegee might still end up messing up, by themselves trying to sub out the task or to set up a bad system trying to automate it.

Automation is a core principle of Lightcone (as will be covered in a future memo), so everyone across the organization should be trying to systematize tasks and automate themselves. 

But it turns out that building automations for a task, or hiring for a task, is often a very different skill than performing the task yourself. You, as someone in a quasi-executive position at Lightcone, are trusted to know how to automate and simplify things by Lightcone standards, but the people you hire will likely not have those skills. 

In the worst case, whole mini-departments and teams, with their own interests, actively working on ensuring their continued existence are created, against the interest of the organization at large.^[1]

To address all three of these failure modes, Lightcone has a general rule:

Unless you really have to, or the task is highly specialized, do not delegate a task you do not know how to perform yourself.

This rule aims to address all three of the above. By knowing how to perform the task yourself...

• You (usually) learn what good and realistic performance on a task looks like
• You maintain the ability to increase capacity if the task becomes a bottleneck
• You can audit systems and processes created in the pursuit of the task you delegated

If you ever end up in a spot where you do not have the time, or the aptitude, to learn how to perform a task you are delegating yourself, it is your job to otherwise ensure the scenarios above do not occur.

This is a very intense rule. It rules out a large fraction of  behavior at almost every other organization in the world. 

"Oh man, the bathroom right next to the common area is clogged. I should call a plumber to fix it while I keep hacking away at these event invoices". WRONG. Go and call the plumber (or ideally, ask the person on our staff who already knows). Then ask the plumber to explain to you what they are going to do to fix the problem. Then fix the problem yourself. Then, next time you can call a plumber to just solve the problem, and you will know how long this task is supposed to take, and whether the next plumber is doing a fine job.

"Oh man, we are being sued by FTX. I should hire a bankruptcy lawyer to prepare our defense." WRONG. I mean yes, of course go ahead and hire a bankruptcy lawyer to prepare the defense. But in-parallel use language models to prepare a defense yourself, then run the defense by the lawyer you hired until you think you understand reasonably well what the core constraints are. Then work together with the bankruptcy lawyer on the defense.

"I've never done much database query optimization, I should hire someone to optimize our Postgres indexes as we keep having slow queries". WRONG. Go and read about Postgres indexes yourself. It's not that hard. Feel free to call up someone with more expertise to teach you. Yes, this will set back the feature you wanted to push by a week. It's worth the tradeoff. 

Knowing how to perform a task yourself at all is not the same as knowing how to perform it as well as the person you are delegating the task to. The goal is not to ensure that competence across every work-relevant dimension strictly declines as you go down the organizational hierarchy. You frequently will, and should, delegate to people who are 10x faster, or 10x better at a task than you are yourself. 

But by knowing how to perform a task yourself, if slowly or more jankily than your delegees, you will maintain the ability to set realistic performance standards, jump in and keep pushing on the task if it becomes an organizational bottleneck, and audit systems and automations that are produced as part of working on the task. This will take you a bunch of time, and often feel like it detracts from more urgent priorities, but is worth the high cost.

1. ^{^}

   One might think that surely this can't happen at an organization as small as Lightcone, which would be mistaken! I really have seen organizations of merely 10 people end up with 3 of those being part of a department that should not exist but is kept alive by holding some crucial resource hostage. Even within Lightcone I have seen cases where someone takes joy and pride in being the bottleneck on certain technical information, when in-fact them doing so is causing great harm to the organization.