What are the next steps?

Of course, if you’re already running a hiring round, then you’ll want to ask them to drop an application into that. You’ve already designed a round with processes which sit precisely on the frontier somewhere in the N-dimensional tradeoff space of the relevant desiderata, right?1

But if you’re not running a hiring round for a pre-defined role, you’ll want to start off with something easier than fully assessing them for every plausible role.

I’ll frame the situation to the candidate something like this:

I don’t currently have any open hiring rounds that would clearly be a good fit for your profile, but it does seem plausible that we might be able to find a role that is a great fit.

Obviously, the bar for me running an off-cycle hiring round for a single candidate is quite high and the most likely outcome is that I don’t generate a role that makes sense for me to go further on exploring with you.

But I would be interested in each of us getting a chunk of information on one another’s situation now, checking in on whether a fit seems plausible, and if so proceeding with work tests, perhaps a trial, and so on.

How does that sound?

Here are some of the steps I might take at that point:

During the initial conversation

1. My quick potential deal breakers. I have three very quick ones: salary, location, and 80k’s current strategy.

2. Their quick potential deal breakers. “Can you think of anything which we could find out about easily which, if we knew about it now, would let us know that working together isn’t a good idea?”

3. Understanding their background and strengths. (Obvious.)

4. Asking them to react to my 1–2 minute description of the plausible roles. (Obvious.)

Follow ups

1. Asking them to send me work. Sometimes I can see hours or maybe even hundreds of hours of someone’s output without asking them to spend any time on my specific work tests. Neat huh!? What I ask for depends on the profile and my uncertainties. If they’re a researcher I want to see their research and if they’re an engineer I want to see their code. You can see a template I use to ask operations generalists for work samples in the footnote.2 (Note the approach and tone in my ask — I’m trying to lay out my aims, giving some sense of what meeting those aims might look like, and then letting them make a judgement call on what to send given whatever constraints they might face.)

2. Sending them information on working at my org, on my team, and with me. Over time, I’ve built a repeatable package here.3

3. Talking to someone who’s worked with them. EA references are different to typical references — they often get me information which is meaningful enough to change my next steps. I do them earlier than is typical outside the EA ecosystem.4

4. Asking them to send me a resume. Though I tell them to skip it if they’d have to redesign or if it doesn’t add anything to their LinkedIn.

5. Asking them what they’ve already got. “Do you have anything that might let me quickly get information on you generally — for example, a blog, some writing on how you think about work, a working-with-me document, or anything like that?”

6. Is there anything in particular I’m interested in finding out about this candidate? I’ll often do a brief brainstorm, and add that into my follow up email.

Making a judgement call on which one to run

It’s very valuable to be able to do hiring off-cycle. Being able to consider candidates whenever they come across my radar enables me to hire more people, and potentially some of the most outstanding. It’s a major reason that bar hiring is so useful.

I do find it bloody distracting though.

I find making individual judgement calls on what the next step should be (rather than progress vs. don’t progress), needing to evaluate candidates against my remembered version of the bar, and dealing with the added uncertainty of what people’s fit might be for the roles which I could design is very cognitively demanding.

But getting a large chunk of initial information from a candidate as I describe here often helps. It’s often enough to move ‘whether to investigate’ from a difficult borderline decision to an obvious one, and when it does I can narrow the set of plausible roles by a lot.

Most of the time, I’ll bring in 70% or more of the information here during our discussion and single email follow up. Only then will I sit down and determine whether and what next steps we should take.

In slot hiring, an organisation decides it has a particular position to fill (or maybe two positions, or more). It runs a hiring round, picks the best candidate it finds, and makes an offer. If that person declines, it makes the offer to the next-best, and so on.

Most of the world operates in slot hiring, so it’s the model most people have internalised for how organisations work.

In bar hiring, an organisation defines a threshold of fit and hires anyone above it. The strength of the candidate pool determines how many offers are made.

Determining whether slot or bar hiring mode is the best approach

An organisation wants to hire up to the point where further recruitment stops being the most valuable use of its resources.

The choice between bar and slot hiring mostly comes down to whether we land on that point more reliably by (a) specifying how many hires to make ahead of time, or (b) asking hiring managers to make a judgement call on whether candidates meet a bar.

Here are some key factors which drive that decision:1

1 – Is there a steep drop-off in how much value a hire can add?

If there’s some very valuable work which ‘must’ be done, but additional work is lower in value, then we’ll get a steeply diminishing returns curve.

For example, in a town of 1000 people, it’s very important to have at least one doctor so that we have someone who can treat the very highest ‘value per doctor time’ conditions (for example, heart attacks and appendicitis). It’s really important to have a second doctor, it’s ideal to have a third doctor, but the tenth doctor isn’t adding much and the 100th doctor adds a trivial amount.

This means that we should try extremely hard to have at least one doctor — and whether to hire is dominated by the number of existing doctors (rather than by their quality). Whereas in a city of a million, the difference in value added by the 1000th doctor is only very slightly less than the 1001st doctor.

When you’re building an organisation and looking to create roles which you can ‘bar hire’ for, you want to look for places where you expect the curve to be gradual rather than steep.

(I’ll link to a future post on this — “proven talent profiles”.)

2. How quickly does candidate quality drop off?

A gradual drop-off favours slot hiring. You can figure out the ideal number of hires to make before you start hiring, because the decision about whether to make 1 or 3 hires isn’t very dependent on the specifics of who turns up.

I expect the best way to know the shape of your curve is with experience, or asking others who have experience.2

3. How effectively can your organisation execute on hiring staff at the bar?

Specifying a number of hires to meet is very legible. In contrast, specifying a bar is complicated and difficult for leadership to verify.

By using slot hiring, organisations are often guarding against principal-agent problems where staff take actions which benefit them rather than the organisation — for example if a manager wanted to hire a large team because it’d look good on their resume. Giving a manager a set number of slots rather than asking them to make a judgement call on the bar is one way to reduce these.3

But as leadership and hiring managers are more synced up, bar hiring becomes more possible. And, if you can make it easier to determine whether a staff member meets the bar (for example, by building a process around a set of proven talent profiles — I’ll link to a future post on this), you can increase how legible the bar is. That will make bar hiring more attractive.

Navigating the bar shifting up and down

Where the bar should sit moves up and down over time.

This might happen due to general strategic changes, or because of a change in the relative importance of bottlenecks.

For example, if a huge number of applicants suddenly turned up who all cleared the current bar, management capacity would get overwhelmed, onboarding systems would get overwhelmed, you’d run into a funding bottleneck, and so on.

Or consider an advocacy nonprofit, one which wants a fundraising function, a research function, and a content or marketing function. Its impact is roughly the product of their strength across these three areas.

If the marketing function is already strong and already covering the most valuable work, adding additional marketers will add much less value than improving either of the other two programmes.

But it can get worse than that. If we model a marginal marketer as drawing on some org resources which might otherwise be used to improve the other two programmes (for example, CEO attention, funding, recruiting team support), the cost of a marketer could reach or exceed the benefits.

In this case, marketing has moved into a steep drop-off scenario, and you should raise the bar until you’re only hiring marketers who are so strong that they add enough value to compensate for the opportunity costs.

(I think that the right way to think about this technically is as a production function. I’ve mused on that topic in contexts like 80k’s here.)

Always be hiring

A major advantage of being in bar mode is that it enables you to hire all the time. You can apply that bar to anyone who shows up and evaluate them against it — whether it’s through referrals, networks, side conversations between open rounds, or random messages.

This is very useful, but there’s a cost: it leaves you with a decision point that’s often quite tricky to make — when should you investigate a given person? That’s essentially a value-of-information question, and it’s quite tricky. I describe a few moves which help me make progress rapidly here.

The referees usually want to help the candidate get a nice job, they might worry about legal risk, and they just don’t have much reason to help the organisation make the best decision.

EA references aren’t like this.

EAs care about the mission of one another’s orgs and tend towards literal communication over false social niceties.

If you’re a hiring manager, you need to be aware of these cultural differences to avoid miscommunication.

If you’re used to the EA world and you’re getting a reference from a non-EA referee, you might over-update on effusively positive feedback.

If you’re used to the non-EA world and you’re getting a reference from an EA referee, you might update too negatively on concerns.

In one hiring round I was involved in, we spoke to a referee who said that they wouldn’t hire the candidate again. In another, a referee told us about a case where the candidate had treated others poorly.

Those references would have been strong red flags outside EA. But in the context of an EA reference, they might just be yellow flags. The right approach was for me to understand what happened, look into the concerns myself during the trial, and ultimately to make up my own mind about whether to make the offer.

Ideas for getting a useful reference

• Confirm sharing permissions. Offer options: a) just you, b) anyone involved in the hiring process, or c) a short pre-approved list of names.

• Act early. Ask for references before the final stage, not after. You want to find out about uncertainties early enough to test them. You also need to avoid putting the referee in a position where their reference will seem like the only reason an offer didn’t come through. Never say ‘offer made, pending references’.

• Ask the unknown-unknowns question. “What would you want to know, if you were me, thinking about hiring this person?”

• Ensure you’re calibrated on the level of performance being discussed during the conversation. Are there people who you both know who you can compare the candidate to? When they say that the candidate’s project management skills are strong, does that mean relative to a 30th percentile or 70th percentile seniority role at your org? If they drop balls, how large and how often?

Outside the EA movement, employment references are often performative: getting anything you can really update on can feel like drawing blood from a stone. Inside, they often exemplify an attitude of collaborative truth-seeking which I deeply appreciate. I can speak to someone who genuinely wants my organisation to make the right call, and who works with me to give the most useful, well-calibrated information that they can.

In the references I mentioned above, we looked into the concerns and discussed them with the candidate. In one case, we tweaked their initial responsibilities a little, setting them up in a role we were more confident they'd succeed in.

In both cases we made the hire, and I’m very glad that we did.

Oh, whoops. That’s actually the data on where the 2024 EA survey respondents live.

The highest cost of living cities is actually this one:

One could be forgiven for mixing these up — the overlap is pretty intense.

The only top EA hub locations that aren’t in the top 50 most expensive cities in the world are Cambridge (#52), Melbourne (#79), and Berlin (#101).

If your intuitions aren’t built for the absolutely insane prices of these cities, you might want to change your orientation to spending.

In central London, a square metre of floor space costs around £500 a year — about £40 a month. In Berkeley it’s about $580/m² (~$54 per square foot).

This means the space cost of a chest freezer is ~£40/month, and an exercise bike setup is ~£80/month.

I suggest the following heuristic:

Spend liberally to buy comfort per unit area.

Here’s some of how I follow through on that heuristic:

1. Buy storage. Including setups that are pleasant to interact with.

2. Use vertical space. Our IKEA BESTÅ system stacks to the ceiling.

3. Avoid bulk buying. Buying extra for convenience is fine. Buying extra for lower cost is false economy. Chest freezers rarely make sense.

4. Reduce clutter. Clutter gives me a sense of low space, or claustrophobia or something like that. I like having strong cable management, and I avoid storage I can see directly into.

5. Multipurpose furniture. Beds with storage space underneath. Storage ottomans. Extendable tables. Sofa beds.

6. Generally resist owning things, and make peace with getting rid of them. Amazon delivers quickly in these cities.

7. Exercise machines are very ‘expensive’. For me, that makes it a no brainer to go to a gym instead.

8. Space efficient appliances. My colleagues like these fans, which are expensive but much smaller.

9. Remind myself how ‘expensive’ space-intense setups are. I like having my electric piano out, but most of the time it’s not worth ‘paying’ £30 of space cost per month for it.

Taking this seriously helped me live comfortably in an 80 sq ft room for ~6 years. That probably saved me around £400 a month relative to the place I was likely to move into next.

Footnote: it feels a bit bananas to start with a joke surfacing a real issue (EA’s concentration in expensive cities) and then talk only about how to individually cope. The obvious systemic fix would be for funders to encourage orgs towards lower-CoL hubs — coworking spaces in Houston, Prague, Thailand, Indian cities, or building places to live like CEEALAR in Blackpool. They could discourage location-based salary policies: instead, pay a single global rate and allow remote employees to live wherever is best for them (within org constraints). But I think that push would actually be a mistake. It matters a great deal that bio people can be in Boston, policy people can be in DC and London, and that people working on AI can be in San Francisco. At the moment, the right approach is to subsidise the cost of living in those places, not relocate the people doing the work.

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.

Too many people in our audience feel uncomfortable with selling themselves.

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.

Accounting for my value of time, the transaction costs I have to ‘pay’ can easily be the majority of the true cost of working together.

So 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 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. (Incidentally, 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.)

Most of our encounters with advertising and salespeople in everyday life are bad. They don't seriously try to account for the negative effects they have on others.

But if you're trying to make the world better and operating in an environment where you care about the effects you're having on others, you could decide for your advertising and sales not to suck.

You could make your marketing helpful rather than spammy. You can endeavour to give people an accurate picture of what you can do, rather than overselling.

I suggest doing that.

(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, finding mentors, research collaborations, and 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.)