Pretty interesting, but I have a bunch of warning flags around the phrase “hire an ops person”, here’s a few thoughts:
Everyone on our team is a “generalist”, not an “ops person”. Anyone can do any task. When we run an event or space, responsibilities involve “venue setup” and also “preparing opening session”, and anyone should be able to be assigned to any task, or help with any task. (Of course, there’s explicitly one person owning each task, it’s fully clear who has final decision-making power, and who gets credit for failure/success.)
For new organizations I would bet on them much harder if all the cofounders could do all the work, than if the cofounders could each only do some of the work. And I’d bet against more strongly still if no single cofounder could do all of the work. I do think research orgs tend to have more of a split here, I’m not sure how good I think that is (I know multiple cases where it’s led to major dysfunction), I still think it’s best if there’s a person at the top who can do everything.
Historically when I’ve been told by a team-lead that “ops is not my responsibility, I’m not tightly in the loop on that” this has been closely correlated with there being an ops catastrophe somewhere that the team-lead is unable to fix, that’s been quite costly for the project.
Your point about giving space for newcomers to fail a while is a good one, and I agree. But I’m not of the same mind that “get better ops hires” is the method, as opposed to “relentlessly work until you yourself have the skill to ensure your project’s success”.
Especially if your ops hire doesn’t understand your work or your mission, and you aren’t likely to produce very legible signs of success (e.g. big funding, big publications, impressive product sales, etc), then it’s hard for that person to be motivated by the mission, and they may leave to do something for which they do have the generators. And then you’ll be left with a shell of an org built around them that nobody, not even you, really knows how it functions.
That said, I think if you’re weak in an area (e.g. in coding, or management, or other things), having a cofounder who is strong in that area is really excellent, and my best project collaborators have been people who, while in key ways are extremely similar to me, do have strengths where I have weaknesses and can pick up the slack there.
As a second example of Lightcone being generalists, when we’re evaluating how LessWrong/AF is doing, everyone should have an inside view and have engaged with the content, not only some of us e.g. at a recent team retreat, we spent an hour or two as a team debating whether the simulators post was right about the myopia of language models, and nobody wasn’t basically following the discussion.
Pardon the long scattershot of thoughts. I have a sense that people often try to ‘hire for ops roles’ poorly, and are confused about how to allocate work within a small team, so I wanted to say something about how it can go wrong and how else one can think about it.
Edit: I don’t think this applies for short-term contractors, it primarily applies to cofounders and other permanent hires.
Pretty interesting, but I have a bunch of warning flags around the phrase “hire an ops person”, here’s a few thoughts:
Everyone on our team is a “generalist”, not an “ops person”. Anyone can do any task. When we run an event or space, responsibilities involve “venue setup” and also “preparing opening session”, and anyone should be able to be assigned to any task, or help with any task. (Of course, there’s explicitly one person owning each task, it’s fully clear who has final decision-making power, and who gets credit for failure/success.)
For new organizations I would bet on them much harder if all the cofounders could do all the work, than if the cofounders could each only do some of the work. And I’d bet against more strongly still if no single cofounder could do all of the work. I do think research orgs tend to have more of a split here, I’m not sure how good I think that is (I know multiple cases where it’s led to major dysfunction), I still think it’s best if there’s a person at the top who can do everything.
Historically when I’ve been told by a team-lead that “ops is not my responsibility, I’m not tightly in the loop on that” this has been closely correlated with there being an ops catastrophe somewhere that the team-lead is unable to fix, that’s been quite costly for the project.
Your point about giving space for newcomers to fail a while is a good one, and I agree. But I’m not of the same mind that “get better ops hires” is the method, as opposed to “relentlessly work until you yourself have the skill to ensure your project’s success”.
Especially if your ops hire doesn’t understand your work or your mission, and you aren’t likely to produce very legible signs of success (e.g. big funding, big publications, impressive product sales, etc), then it’s hard for that person to be motivated by the mission, and they may leave to do something for which they do have the generators. And then you’ll be left with a shell of an org built around them that nobody, not even you, really knows how it functions.
That said, I think if you’re weak in an area (e.g. in coding, or management, or other things), having a cofounder who is strong in that area is really excellent, and my best project collaborators have been people who, while in key ways are extremely similar to me, do have strengths where I have weaknesses and can pick up the slack there.
As a second example of Lightcone being generalists, when we’re evaluating how LessWrong/AF is doing, everyone should have an inside view and have engaged with the content, not only some of us e.g. at a recent team retreat, we spent an hour or two as a team debating whether the simulators post was right about the myopia of language models, and nobody wasn’t basically following the discussion.
Pardon the long scattershot of thoughts. I have a sense that people often try to ‘hire for ops roles’ poorly, and are confused about how to allocate work within a small team, so I wanted to say something about how it can go wrong and how else one can think about it.
Edit: I don’t think this applies for short-term contractors, it primarily applies to cofounders and other permanent hires.