Do your job unreasonably well

By MaxDalton @ 2026-01-27T16:53 (+83)

I've just started a blog about EA-org-style management, together with Brenton of 80k. You can subscribe on Substack if you like.

Here's the most recent post!

I think often people treat “development” as an add-on that’s quite different from their work.

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.

JP Addison🔸 @ 2026-01-28T20:10 (+6)

I like this a lot.

[Musing] I suppose that I would expect that it's sometimes correct to have personal dev goals look like spending work time learning AI safety. It's a question of whether you're hill climbing to a better version of yourself or attempting to jump to a different peak.

Like a junior ops person could spend 10% of her time on learning to code, to use a potentially antiquated example.

MaxDalton @ 2026-01-29T13:26 (+4)

Yep, I agree with this! (Perhaps I should have included this caveat.)

Though I think often the junior ops person might be better off trying to take a month or two off to skill up more seriously, then begin applying for engineer jobs, or something? (Though obviously this is hard to do.)

Thomas Kwa🔹 @ 2026-01-30T01:33 (+2)

Being really good at your job is a good way to achieve impact in general, because your "impact above replacement" is what counts. If a replacement level employee who is barely worth hiring has productivity 100, and the average productivity is 150, the average employee will get 50 impact above replacement. If you do your job 1.67x better than average (250 productivity), you earn 150 impact above replacement, which is triple the average.