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.
Thanks for the nice point, Thomas. Generalising, if the impact is 0 for productivity P_0, and P_av is the productivity of random employees, an employee N times as productive as random employees would be (N*P_av - P_0)/(P_av - P_0) as impactful as random employees. Assuming the cost of employing someone is proportional to their productivity, the cost-effectiveness as a fraction of that of random employees would be (P_av - P_0/N)/(P_av - P_0). So the cost-effectiveness of an infinitely productive employee as a fraction of that of random employees would be P_av/(P_av - P_0) = 1/(1 - P_0/P_av). In this model, super productive employees becoming more proctive would not increase their cost-effectiveness. It would just make them more impactful. For your parameters, employing an infinitely productive employee would be 3 (= 1/(1 - 100/150)) times as cost-effective as employing random employees.
I find this convincing and a nice idea. Thanks!
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.
This is how I used to approach dev goals:
Luckily, I think there’s a better way.
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?
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.
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:
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. )
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 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.
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.)