# Close open loops

*Context: Post #7 in* [*my sequence*](https://www.lesswrong.com/s/cegJvyiP2dBkhDh2K) *of private Lightcone Infrastructure memos edited for public consumption.*

* * *

David Allen, of [Getting Things Done](https://www.amazon.com/Getting-Things-Done-Stress-Free-Productivity/dp/0142000280) fame says:

> Every commitment unfinished is an “open loop”; and when it is tracked in your psyche, instead of your system, it will require energy and attention to track and maintain. Once the open loops are captured, you can manage completion by using an external system that takes much less energy than keeping it in your head. Every commitment unfinished requires management in a trusted system until it is done or discontinued. 

What goes for personal productivity system, in this case goes even stronger for organizational attention. In my experience, Lightcone is capable of maintaining something like 8-10 open streams of work at any given point in time[^y6j7u0jw8x8], and at that point we are definitely already starting to buckle and occasionally drop things.

This means as an organization, it's really quite important that when you open up some kind of organizational loop, that one variable you optimize for heavily is "total calendar time for which the loop is open". Closing an open loop at an organizational level means that either an issue is fully resolved, or work on a project fully completed, or the organization has some clearly defined external trigger that allows the organization to fully stop paying attention to a stream of work until the trigger fires.

Here are some examples of open loops that people have taken on, that look at the "work hour" level like they wouldn't involve that much effort, but end up quite costly for the sake of maintaining an open loop:

*   "Exploring" some external collaboration with another organization
*   Telling someone that they can run an event at Lighthaven many months in the future, without locking down the exact date, and with unclear commitment
*   Starting a refactor and partially committing it to the codebase, and then asking other people to avoid using the old way of doing things until the new way is ready
*   Hiring someone in a part-time role, or otherwise promising someone that they will "stay in the loop" on some Lightcone project in some way

If you find yourself in the position of holding such an open loop, apply roughly the following rules in order: 

**If the open loop takes less than 5-10 minutes to close**, just do it at your earliest available time, unless you are really in a very bad deadline crunch (in which case add it to some system you have for tracking open tasks to think about soon).

**Decide whether the reward at the end of this project is worth it at all.** Be ruthless.

**If it isn't worth it**, add a task that closes the project to your task list, or close it out right there and then if it takes less than 5-10 minutes.

**If it is worth it**, work on the task until the vagueness of the situation is defined enough to be systematized, and then build the system that provides a clear trigger for the organization whenever further action is required.

* * *

While "systematizing work" is a bigger issue than today's memo covers, here is some existing infrastructure we have for capturing and systematizing open loops: 

**Slack is your friend.** Slack is the central "wait until" system. If a project is blocked for a week (and you've already tried to unblock it and the blocker really seems not worth pushing on further), set a reminder in a related project channel or your wall to ping the channel in a week. If you haven't created at least one public Slack channel reminder in a week, you are probably making a mistake.

**Airtable is where simple automations live.** Use Airtable automations to trigger Slack messages when a project requires further action, possibly directly connected to a table that captures project details. When something requires repeated attention from the organization, set up the automation to ping people on a repeating schedule.[^o7qmtp866r] A future memo will cover in more detail about good principles for automations.

**Responsibilities bubble up.** If you find yourself with too many things to keep track off, hand them off to me (or your direct manager if that is for some reason not me). Make sure you are very clear that you are doing this, and not just expressing overwhelm. I will figure out some way to rebalance load in the organization, half-ass the task, or decide to cut it. It is much better to bubble up a responsibility than to drop it.

**Create Slack channels with external organizations or stakeholders**. If you have a project that is often blocked on input from an external party, add them to a Slack channel (with everyone on the Lightcone team in it). Tell the external stakeholder to post in that channel as soon as their part of the work is done and your work can proceed.

[^y6j7u0jw8x8]: An open stream of work here is roughly something on the scale of "our relationship with the AI Futures team for AI 2027" or "an ongoing marketing push". In general Lightcone tries to keep the number of diffuse responsibilities per employee low, per Amazon's "Single Threaded Leadership" model, on which I'll probably write a memo at some point. 

[^o7qmtp866r]: Beware, people tend to set the schedule of these reminders usually far too frequently. If you want to make sure we from time to time check in with our Lighthaven neighbors, think about what the lowest tolerable frequency for doing so is (hint, it's not once a month, it's probably more like once a quarter or semester). A reminder that pings frequently quickly does the opposite of what you are planning to achieve and creates active ugh fields around tasks.