This makes me wonder if operations really is the big bottleneck with EA/AIS/MIRI in particular. Anyone good at operations, would not have let this situation happen. Either it would’ve ended quicker (“Sorry, we’re not hiring right now, try again later.”) or ended differently (“You’re hired”).
FWIW I think that accepting/rejection emails are unusually hard to write, because it’s such a big event for someone else’s life, that I always spend a lot of cognitive cycles trying to do a good job, and it’s a massive cost when you have to process like 30 of them. Quite stressful. Even for people who are strong operationally, I think this is a quite different and unique task.
Large companies that do send rejection emails (e.g. Google) keep them short and blunt. Y Combinator iirc had a message (or link?) basically saying “our rejection likely doesn’t mean anything wrong with you or your idea, there’s just a ton of applicants”. If rejection emails are being personalized and it’s taking a while, then whatever process is used for them sounds like a bad process (even if the process is “just” somebody spending lots of mental cycles doing it). Unfortunately, this moves my mental model of MIRI another micron towards “an organization of procrastination / prioritization issues / ???”.
For me, the difficulty was basically never “saying no” to someone, or figuring out how to politely say “no” to people, and was almost always deciding whether or not to say no to someone. Lots of people were borderline in various ways, or it wasn’t clear which category of people should get the next unit of attention (and so if their category isn’t going to get any units of attention in the next month I should just say no to them, but if they are going to get attention then maybe I’ll look at them more closely later, etc.).
I think now I would respond with an email that’s much more like “you’re waitlisted; going off of past numbers, that means this is ~90% a no and ~10% that I’ll get back to you in more detail in 1-3 months” or Buck’s “by default you’re rejected, but if you want more consideration do XYZ” or w/e.
[EDIT]: Like, for workshop attendance, you know you have 24 slots (or w/e), and you can just score people, and have a bunch of definite invites, a long maybe list, and the rest definite rejects, you can tell everyone their status. [Ideally you have the meeting to resolve the maybe list quickly and so you can wait until you have a yes/no/”if someone else drops out” waitlist decision for everyone and don’t need to email anyone twice.] But if someone is like “hey I’m interested in helping, here are some facts about me” they either fit into one of your buckets and you can send them the material for that bucket, or not, in which case it’s unclear. [I had less context for the engineering roles, but my sense is that there were the standard small team problems of “hmm, does this person fit the place where we most want to grow next?” vs. “would we want this person a year from now?” and so on, whereas MANGA is much more “oh yeah, we need a hundred more Xs across the whole org, we’ll hire them and let them find a team and if they don’t find a team, then we’ll let them go.”
This makes me wonder if operations really is the big bottleneck with EA/AIS/MIRI in particular. Anyone good at operations, would not have let this situation happen. Either it would’ve ended quicker (“Sorry, we’re not hiring right now, try again later.”) or ended differently (“You’re hired”).
FWIW I think that accepting/rejection emails are unusually hard to write, because it’s such a big event for someone else’s life, that I always spend a lot of cognitive cycles trying to do a good job, and it’s a massive cost when you have to process like 30 of them. Quite stressful. Even for people who are strong operationally, I think this is a quite different and unique task.
Large companies that do send rejection emails (e.g. Google) keep them short and blunt. Y Combinator iirc had a message (or link?) basically saying “our rejection likely doesn’t mean anything wrong with you or your idea, there’s just a ton of applicants”. If rejection emails are being personalized and it’s taking a while, then whatever process is used for them sounds like a bad process (even if the process is “just” somebody spending lots of mental cycles doing it). Unfortunately, this moves my mental model of MIRI another micron towards “an organization of procrastination / prioritization issues / ???”.
For me, the difficulty was basically never “saying no” to someone, or figuring out how to politely say “no” to people, and was almost always deciding whether or not to say no to someone. Lots of people were borderline in various ways, or it wasn’t clear which category of people should get the next unit of attention (and so if their category isn’t going to get any units of attention in the next month I should just say no to them, but if they are going to get attention then maybe I’ll look at them more closely later, etc.).
I think now I would respond with an email that’s much more like “you’re waitlisted; going off of past numbers, that means this is ~90% a no and ~10% that I’ll get back to you in more detail in 1-3 months” or Buck’s “by default you’re rejected, but if you want more consideration do XYZ” or w/e.
[EDIT]: Like, for workshop attendance, you know you have 24 slots (or w/e), and you can just score people, and have a bunch of definite invites, a long maybe list, and the rest definite rejects, you can tell everyone their status. [Ideally you have the meeting to resolve the maybe list quickly and so you can wait until you have a yes/no/”if someone else drops out” waitlist decision for everyone and don’t need to email anyone twice.] But if someone is like “hey I’m interested in helping, here are some facts about me” they either fit into one of your buckets and you can send them the material for that bucket, or not, in which case it’s unclear. [I had less context for the engineering roles, but my sense is that there were the standard small team problems of “hmm, does this person fit the place where we most want to grow next?” vs. “would we want this person a year from now?” and so on, whereas MANGA is much more “oh yeah, we need a hundred more Xs across the whole org, we’ll hire them and let them find a team and if they don’t find a team, then we’ll let them go.”
FWIW, I think MIRI’s operations team is unusually good compared to peer EA orgs, but mostly weren’t in charge of recruiting.