This post is about what to do when you realise you’re not going to get through everything you’ve committed to.

Of course, in the long run, you can build your organisational and personal capacity to get more done. You can improve your ability to forecast workloads and reduce how regularly you end up with too much on.

That sounds great. You should totally do that.

But in the moment, you’ve really only got these five options. Pick one intentionally and then do the best job of it you know how, perhaps incorporating some of my ideas below.

I think that’ll turn out better than grinding through your original plan with more stress and longer hours than you intended.

1. Drop

Dropping means deciding that something probably won’t get done — by you or anyone else.

It’s often the right call, but it can feel hard to actually make the decision.

One trick: talk to someone else about it. Your manager is the ideal person. They’re less emotionally tangled up in whether you complete your plan this week and more in touch with the bigger picture — including your long-run sustainability. They can help you feel like it’s ok to let something go and, if needed, give you the push to do so.

Getting Things Done has a useful reframe here: instead of deleting the task, move it to your ‘Someday Maybe’ list. Putting something on that list doesn’t mean you’ve decided never to do it. It means you’ve decided that future you will decide. (Future you seems like a capable person who has lots of time. I’m sure they’ll get right on it.)

Note that if you’re dropping something you’ll probably also have to let others know that you’re not going to do something they expected you to do.

2. Delay

Delaying is different from dropping: you’re still committed to the task, but you’re renegotiating the timeline. The advice is otherwise ~identical to the advice above.

3. Delegate

Delegation usually means giving a task to someone you manage. But if that were possible, you should have spotted it when you made your plan — so if you’re only thinking about it now, there was probably a reason you didn’t do it then, and that reason is likely still in play.

But when you’re overwhelmed, you might have options you wouldn’t normally consider:

• You could hand it to a peer — someone senior enough and high-context enough to run with it. In normal times you wouldn’t ask, but a crunch isn’t normal times.

• You could delegate it to your manager. Managers are often empowered to do a much worse job than the people reporting to them, and sometimes that’s the right call.

4. Do a dogshit job

Like, really dogshit.

Your instinct might be to try doing your original plan but faster. Sometimes that works, but it has downsides.

I often nudge people into going one step more dogshit: substantially descoping the project. Instead of doing the old project badly, do a qualitatively different project — one that captures a fraction of the value for a fraction of the effort.

For example, rather than a strategy document, put a paragraph in a #half-baked-ideas channel. Rather than producing a proposal of strong reasoning transparency, message someone your bottom line on what you think (with a flag that you’re low on capacity and an offer to do a stronger writeup if they really need you to).

5. Do it anyway

Sometimes, after considering all the above, you decide that the best option is to do it anyway.

If you’re going to take this option, set it up so it’s not a grim slog. Work on Sunday, but be out by 11am. Set up Pomodoros with friends. I like to time-box my sprints and put something I’m looking forward to at the end — usually a party or a weekend away.

You keep getting offered insurance — for laptops, flights, events, equipment. Each time, you’re aware that declining could cost the organisation thousands of dollars if something goes wrong. So it feels uncomfortable to say no.

I think you should almost always say no. I hope this post helps you feel comfortable with that decision.

How to think about insurance

Insurance sells you protection against risks at a markup. That markup is your donors’ money.

The markup covers insurers’ admin costs, profit margins, moral hazard, and adverse selection.

On top of that, insurance costs staff time — buying it, tracking it, and chasing claims.

What this means for add-on insurance

For laptops, flights, events, and equipment, the case is straightforward. The alternative to insurance is self-insuring — just paying out of pocket when things go wrong. Over time, this costs less than the premiums .

(An exception is when adverse selection works in your favour: for example, buying a flexible airfare for another 10% when you think there’s a 50% chance that you’ll change the flight.)

When other factors change the insurance calculus

I think you can decide on add-on insurance using the reasoning above. But that doesn’t apply for all decisions about insurance.

Protecting individuals from catastrophic risk. For example, we buy directors’ insurance and medical travel insurance for staff. These are worth the premium because the downside for the individual is severe. (Note: medical travel insurance and trip-disruption insurance are different products. The first protects an individual from a medical emergency abroad. The second covers missed flights and lost luggage — skip that one.)

Catastrophic financial risks to the organisation. Insure against risks that could threaten the org’s existence. Working out what counts as catastrophic for your specific organisation is genuinely complicated and context-dependent, so I’m going to skip trying to give general advice on this one.

Legal or contractual requirements. If the law says you need insurance, you get it. If your landlord requires office insurance to rent to you, you get it.

Insurance bundled with other benefits. Sometimes insurance comes packaged with useful services — for example, AppleCare bundles insurance with better repair service. These might sometimes be worthwhile — but I can’t recall any cases where it’s seemed worth it for us.

Fortunately, our audience are also people who might change their orientation in response to an economic concept. Especially if it’s one which reframes selling themselves as a way of helping others.

That concept could be ‘transaction costs’.

Let’s say you’re a freelancer and you’d like to support me in my work at 80,000 Hours.

I’ll need to pay your fee. But I also need to ‘pay’ the transaction costs of acquiring your service.

These transaction costs are:

1. Discovery — I need to notice I have a need and learn that you can meet it.

2. Trust — I need to be confident you can actually deliver, and that working with you will be a good experience.

3. Transfer — I need to actually acquire your service: contracts, onboarding, project management.

The transaction costs I have to ‘pay’ can easily be the majority of the true cost of working together.

Anything you can do to reduce these transaction costs is very helpful to me.

You’ll reduce my discovery costs if you market yourself enough that I can actually find you and learn what you have to offer.

You’ll reduce my trust development costs if your writing speaks directly to any concerns I might have. Similarly, my trust development costs will be low if previous clients of yours say ‘hell yeah’ when I ask if I should work with you. (Having a trusted brand like this is a route to reducing transaction costs, and it provides a reason to do a better job than would otherwise be optimal.)

Finally, you reduce my transfer costs by making yourself easy to onboard and manage.

(For practical advice on all of this, read Sammy Cottrell’s What They Don’t Teach You in Freelancing School.)

Unfortunately, most of our encounters with advertising and salespeople in everyday life aren’t pleasant. I think it’s because the organisations selling to us are primarily trying to get our money. They don’t care much if their marketing wastes your time or attention.

But if you’re trying to make the world better, and you’re selling to others who are too, then you actually care whether your outreach helps or annoys them. So your marketing should aim to be genuinely helpful, not spammy. And it should give people an accurate picture of what you can do — not oversell.

(Note that the effects here travel beyond a single interaction, as described in Communities of do-gooders should be exceptionally considerate.)

This basic structure — discovery, trust, transfer — applies to most of the ways you might want to work with others.

Hiring an employee. Getting yourself hired. Research collaborations. Finding mentors. Customer acquisition.

In any of these cases, you can enable more productive exchange through work that makes it easier for the other side to find you, evaluate you, and work with you.

Think of it as one of the ways you can help others.

But before doing the full review, I think it’s good to spend 2-5 minutes giving high-level comments, as soon as possible.

1. Sometimes this will immediately catch some high-level mistake or miscommunication: you can give them feedback on this mistake and they can immediately begin working on an improved version. (Whereas if you’d waited longer to give the feedback, you’d delay them.)

2. Sometimes you can quickly ascertain that it’s good enough, and they can progress with the project.

3. Sometimes you will realize that you need to review it in more depth. Maybe you have time to do the full review now. If not, spend <5 minutes giving initial feedback, focused on:

   1. Any high-level comments that they could be working on between now and when you get a chance to properly review. This allows them to begin the fix sooner, and it will mean that the thing you review later is closer to what you want (thus saving you time on the final review).

   2. Asking any clarifying questions that will inform your review: this could be missing information that affects your views, or it could be clarifying what sort of comments are most needed.

Often a small amount of time from you can allow your direct to move onto the next stage of their project. So make it one of your top priorities to unblock people quickly.

OK, but is this advice helpful?

Am I just saying “do this thing sooner”? Obviously it would be great to do everything sooner, but there are many priorities...

The thing I’m trying to say is: rather than waiting and eventually spending 30 minutes on the review, try to do a really quick version sooner. I think this is a more feasible thing for most people to do, even given other priorities.

Additionally: Ask your directs to tell you what sort of comments are needed (high-level comments, critiquing key claims, tweaking wording). That will allow you to spend less time on comments, and it will also mean that your direct gets the feedback that they most need (and aren’t annoyed by feedback that isn’t appropriate to the stage of the project).

I think that you should at least consider focusing on strengths instead.

Why focus on strengths?

Increasing returns. You can often create a lot of value by becoming excellent at a few important things, and then finding roles that use those strengths. So going from good to great can be worth investing in. This is particularly true if you’re operating in domains with fairly heavy-tailed returns, like research.

Success spirals: It can be more fun and exciting (h/t Daniel Kestenholz) – it’s a more positive endeavour than trying to address your weaknesses: you can lean into your passions, and build a sense that you’re doing a good job overall.

Some weaknesses can be fixed with an exoskeleton (rather than just by building muscle). Even when it seems like a weakness is really holding you back, that doesn’t necessarily mean you should work on improving it. Maybe instead you should try to fill those gaps by shifting responsibilities around. For instance, if you struggle with setting an inspiring vision, maybe you need a co-founder who complements you (obviously not speaking from personal experience here). Or if you are great at writing and a colleague is stronger at product work, can you shift work around appropriately?

(Also, sometimes your weaknesses support your strengths: for instance, I have a theory that some thinkers I respect come up with good ideas in part because they’re not trying to reply to my emails on time (and therefore not very reliable). They take a lot of time going on walks, sketching ideas out on whiteboards, and totally failing to be organized. And I wouldn’t have it any other way.)

Why focus on weaknesses?

Plugging weaknesses could be the right call if:

• It’s hard to disentangle pieces of work that rely on your strengths from tasks that expose your weaknesses. For instance, management often requires both good social skills and decent organization.

• You haven’t tried that hard to develop your weaknesses: sometimes weaknesses are just things you haven’t trained much, and they can become strengths with a small amount of investment. Conversely, be skeptical of trying to improve at something if you’ve tried to improve it in the past and failed to make much progress.

• You’re a generalist: in this case, your strength may be your ability to be flexible and handle almost any task that’s needed. (This is commonly the case for chiefs of staff, entrepreneurs, etc.) If you’re good at 95% of what life throws at you but screw up the remaining 5%, it might be worth addressing that 5% even if it’s fairly-intractable, so that you can jump into any situation and handle it decently.

  

Aim — What are we trying to achieve, and why?

Project — Describe the major steps of the project and roughly what each looks like.

How hard to try — Are we maximising or satisficing? Roughly how much time do you expect it to take? (One useful manoeuvre is: “If you notice you’re on track to spend more than X hours, check in with me.”)

Information — The catch-all for helpful context you haven’t already provided. This might include people they could ask for help, non-obvious constraints they might face, passwords or access they’ll need, or previous examples to compare to.

Deadline — When the project is due, including any sub-deadlines along the way.

Stakeholders — This includes you as their manager, and sometimes others.

Memory aids are great

Checklists are helpful, and a good memory aid (a ‘mnemonic’) increases how often you actually use one.

I created APHIDS after struggling to find a good mnemonic for delegation. A good mnemonic is a memorable concept rather than an arbitrary string of letters, proceeds in an order that makes sense for tackling the problem, uses words that intuitively prompt each step, and balances brevity with comprehensiveness.

Doctors use mnemonics constantly — SOCRATES for pain assessment, ABCDE for emergency response, SPIKES for delivering bad news, etc. My background is in medicine, and when I was first taught how to delegate it felt almost odd that I wasn’t given a mnemonic to help remember how to do it well.

How do you remember the memory aid in the first place?

Aphids are small sap sucking insects. When there’s a lot of sap to be sucked, they clone themselves.

Cloning allows aphids to rapidly scale up their sap-sucking activities and ensures perfectly duplicated genetic instructions are passed on.

If you too would like to rapidly scale up your activities with high-fidelity instructions, I suggest that you emulate aphids through using APHIDS.

Fig 1: An aphid giving birth to its clone. Inspiring.

(Or, if you’d prefer to skip the convoluted metaphor, you could write the mnemonic on a sticky note and put it on your monitor for a few months.)

A template for your text expander

Aim -

Project (i.e. description of what to do) -

How hard to try (hours, vibe, a check-in threshold, etc.) -

Information (examples, people to ask, non-obvious constraints, etc.) -

Deadline -

Stakeholders -

I think it’s better to have the development and the work deeply integrated.

The failure mode

This is how I used to approach dev goals:

• Pick a goal that’s kinda related to your job, but not very. A common one when I worked at CEA was “learn more about AI safety”.

• Have a fairly ambitious plan for how you’re going to do this, e.g. read a set of blog posts and produce notes.

• One third of the way into the quarter, realize that a lot of other things are genuinely more important than your dev goal, and focus on those instead.

• Feel kind of sheepish at the end of the quarter.

Luckily, I think there’s a better way.

Pick dev goals that are part of your job

If you’re setting a development goal for the next quarter, you should pick some skill or task that you’re anyway going to be using a lot in the quarter. So, you should avoid setting a development goal that’s like “improve negotiation skills” if you don’t expect that by default you’ll be doing a lot of negotiation in the quarter.

Why focus on things you’d do anyway?

• It makes it much easier to find the time to improve: In my experience, the main way that development goals fail is that they get dropped when the “real” deadlines come flying towards you. If it’s tied in to your core work, you’re more likely to feel permission to work on it. And your manager and other team-mates are also more likely to invest in giving you feedback on an important work project than just on your development goal.

• It’s a good check that you’re learning skills that are actually useful: If you’re not going to use a skill (much) soon, it’s a sign that the skill is not very useful.

This extends to sequencing as well: For instance, suppose that you want to improve at onboarding new people and also at giving feedback, and you’ve got 2 new hires starting in Q3 and then a performance review round in Q4. Then your Q3 dev goal should be about onboarding, and your Q4 goal should be focused on giving feedback.

… then do your job unreasonably well

Once you’ve picked a focus, just do this aspect of your job unreasonably well, by putting locally-unreasonable amounts of energy into it.

Suppose you want to get better at giving feedback, and you think that in general you should spend 10 minutes/week writing feedback for everyone you manage.

When “get better at giving feedback” is your dev goal, you should:

• Spend 2x as long on the feedback part (so maybe 20 mins/person/week rather than 10 mins). This might look like spending more time reviewing work, brainstorming things to say. And then more time honing the phrasing.

• Ask your manager / mentors / peers for feedback on your feedback (and for general tips on how they give good feedback).

• Track how your feedback is / isn’t changing people’s behaviour, come up with hypotheses for what’s going on there, tweak your approach.

• Maybe spend some time writing and reflecting on what good feedback looks like

• Etc.

Now a lot of this is pretty closely tied in with what you’d do anyway: you’re not taking a course on feedback or reading a book. You’re just taking a much more intense approach to this part of your job.

(Note: it might not always be about slower-but-better: maybe you want to be better at producing quick 80/20 drafts of documents: in that case, you might want to set a timer, gather your focus, and try to draft something in half the time you normally would. Or to reflect after writing and think through where you wasted motion. )

After the dev goal

Then once you’re finished with this dev goal, you can go back to spending 10 minutes / week on feedback.

But I bet that those same 10 minutes will now yield a better result: you’ll have a better sense of what really good feedback looks like, how to handle tricky edge cases, what the key pitfalls are, etc.

This is a bit like practicing your cycling pedal stroke in slow motion, then speeding it up.

I think this is wrong.

I don’t think it’s uncooperative to pitch people to work at your org:

1. In general I think that you end up with better allocation of talent if everyone pitches and individuals decide, rather than if people are timid to pitch

   1. If you don’t pitch them, you deprive them of the information that you’d like to work with them (which might not be obvious to them), and lose any possibility of them joining (even when it might be optimal).

      1. Obviously, sometimes individuals will decide to accept the offer that is lower impact.

      2. But overall I expect individuals to make good decisions about this individuals have info about their private preferences and circumstances, as well as more detailed info about both options, whereas the pitching orgs mostly have info on only how good their option is.

   2. It’s often hard to tell when people might want to join: maybe people have a personal reason to move cities, maybe they’re not enjoying their current role, etc. Asking them lets the system incorporate this non-public info.

2. More deontologically, I think it’s good to empower people over their career decisions and not make choices for them.

3. Not doing this is arguably illegal (collusion between employers)

In my experience the above is a somewhat established norm in EA orgs (e.g. I think 80k strongly thinks this, this was our policy at CEA when I ran it — and that’s a reciprocal norm, e.g. 80k would be fine with CEA pitching its staff, and vice versa). But I still hear people occasionally arguing against pitching.

Things that I think would be bad, but which I’m not suggesting here:

• Doing a disingenuous pitch

• Giving misleading views about whether you think someone should join your org (e.g. sometimes I pitch people, but tell them that I think they probably shouldn’t join us because their current role seems stronger in terms of fit / impact)

• (less sure) Being (excessively) negative about their current / other options.

• Local feedback (”That email was really well clear, it would have been great if there were a summary too.”) and

• Global feedback (”I’m glad you work here. You’re especially strong at written communications, but it would be great if you could improve your attention to detail”).

You could be synced up with your direct report locally but not globally, or vice versa.

You could be giving too much negative local feedback and too much positive global feedback, or vice versa.

The weekly mini performance review

I’ve found it useful to write a short (3-4 sentence) piece of global feedback, like a mini performance review, for each person I manage. I copy this across in our meeting notes from week to week, occasionally tweaking things if my overall assessment has changed.

This means that we’re always synced up on their overall performance, so there won’t be any surprises come the annual performance review.

It also helps to put specific feedback in context: if they made a big mistake one week, then I’ll share that, but right next to that they’ll see my overall assessment (which is usually positive!).

It doesn’t take long - maybe less than a minute on average - to copy this mini performance review across from last week’s agenda to this week’s, and check that it’s still accurate. If I need to tweak it, that might take a bit longer, but in that case it’s worth it to stay synced up on their overall performance.

(Some people imagine that it’s terrifying to get a weekly performance review, but because we do this every week and it rarely changes, it makes performance management almost boring.)

What might these look like?

Here’s a rough template:

• Start with a sentence that says how they’re performing overall (below expectations / performing well / exceeding expectations)

• One sentence summarizing their strengths

• One sentence summarizing what you’d like them to improve (maybe framed in terms of what they’d need to achieve the next promotion)

• Maybe one final summary sentence

Example (for a hypothetical product manager)

You’re performing well, and I’m excited to keep working with you. Because of your regular, perceptive user interviews, you have a really great understanding of our users; you iterate quickly; and you come up with creative product ideas. To become a senior product manager, I want to see you improve on your planning and delivery: particularly in making sure that the team always knows what the top priority is and anticipating roadblocks. Overall I’m really excited that the team hit our goals for the year, and I’m excited to see even more progress this year.

(Normally these claims would be things you’d already synced up on, for instance through a performance review or weekly feedback, so this would just be a summary.)