Draft amnesty week, woo. Shoutout to the CB team for saying they wanted someone to write this post! I haven’t run this past anyone who helped organise the group with me, and they might disagree completely. Also, I don't know how relevant my experience will be. Also, Claude helped me write lots of this. Here goes!

I ran Oxford's AI safety student group for a year, and I made a bunch of mistakes. Here I'll try to recount some of the ones it might be helpful to hear about. Also, maybe none of this advice is right for you (c.f). An alternative title for this post could be “advice on running AI safety student groups for people who are exactly like me”.

TL;DR: Running groups is hard. Try to work from what you’re excited about, plan for succession early (and take action on those plans!), don’t just defer, aim for success spirals, accept management will be weird, and treat your motivation/energy descriptively.

Group context

Some brief context on the group first:

• We operated as a sub-team within Oxford's pre-existing AI student society
• Our structure was pretty standard:
  • Weekly talks from speakers in the AI safety space
  • Socials with free food after the talks
  • Reading groups (AI Safety Fundamentals curriculum)
  • Research "labs" - light-touch mentorship projects where people spent ~5 hours/week over 8 weeks working on small research projects

Our theory of change was roughly: get people in the door with cool talks and socials → interested people self-select into reading groups and labs → we accelerate their careers via speeding them up (in terms of their awareness of AI safety, or their research skills).

Mistakes I made

In roughly descending order of importance.

1. Structure your group activities around what you’re good at/excited about, not what your imaginary ideal group organiser would do

When planning the group activities, I did a lot of backchaining from what I thought a great outcome would be and how to get there, and not a lot of forward chaining from “who am I, what am I like, what is my team like, what can we do and how do we do the best version of that”. This, in combination with having wildly optimistic time estimates, meant I always felt overstretched and incompetent, the group was always doing many things to an okay standard (rather than few to a high standard), and I don’t think we got the most out of our time and resources.

In hindsight, I wish I’d spent more time figuring out what I and the team were good at and excited to do, and playing to our strengths. I found group logistics, running talks, and hosting very general introductory social events stressful and unpleasant: hosting reading groups, co-working and informal discussions, and research sprints, in contrast, were all fun. I don’t think I took this seriously enough. I wish that I had (on the margin) been thinking more about my skills/energy/enthusiasm as a constraint, just like time or money, and figured out how to get the most out of what I had. Just Trying Harder to do what I thought the imaginary ideal group organiser (who’s arbitrarily good at everything) would do didn’t work that well, and made running the group feel much worse than it had to.

2. Plan for succession early, and watch out for acting merely out of duty

I was pretty busy/stressed already that year, didn’t feel very well-suited or excited about the group, and ended up running the group because (it felt like) no one else would do it. I think this probably made organising the group less fun for my other team members (sorry guys <3), and was a bad foundation to begin on. But most importantly for this post, it was totally predictable.

We had aimed to build a community of smart technical students interested in AI safety research, not people who enjoyed organizing or community building. This meant that when it was time to find new leadership, we had a group of very smart but mostly organisationally, uh, challenged people, who all found research cooler and higher-status than “community building”. I’m personally not very good at being organised, management, or community building, and I still ended up being amongst the best candidates.

I think I should have:

• Been much more aggressive in narrowly scoping the group (explicitly declaring which activities were out of scope, based on what people were actually excited to lead; setting a low bar for success; starting from a point of “how to I minimise the feeling of effort to run these things, and get the best outcomes given this”)
• Been more experimental with group structures, e.g. by running semi-autonomous cells where everyone owned a piece they cared about, rather than having a traditional leadership structure (the group ended up looking close to this, but I think it would’ve been better to go even further in this direction, and be more transparent and proactive about it)
• Started succession planning from day one by building a community for people who genuinely enjoyed organizing and community building
• Been more willing to do things that felt embarrassing or costly for other people, and trusting those people to say no and not think I was a massive loser, e.g. asking the Oxford EA group for help

I think the group handover from me to my successor went very well, but that this was very lucky. I wish our group had been doing this a year before I took over, so that we had a better replacement for me.

3. Don’t just defer (even if you think the received wisdom is basically right)

I basically continued the same high level plan from the previous year without much critical examination. This was partly because it felt easier to execute an existing plan than to design a new one, and partly because I had this sense that "smarter people than me have figured this out, who am I to try to solve this from first principles?"

I think this was wrong. Not that many different approaches had been tried in AI safety community building, especially in the specific context I was working in. It was totally possible that a completely different approach would have worked better. Plus, even when you basically agree with the previous plan, there's value in thinking through your own approach –  it creates a sense of ownership, excitement, and motivation that's hard to get when you're just executing someone else's vision. I think I would have felt more invested and energized if I'd built something that felt like "mine" rather than maintaining someone else's system.

Some approaches that could have helped here:

• Getting feedback from other group organizers at different universities who felt comfortable criticising us
• Running pre-mortems ("Imagine it's the end of the year, and despite executing all our planned activities, our group was mediocre – what happened?")
• Trying to forward chain from the constraints we were facing, rather than back-chaining from desired end states
• In general, having a lower bar for plans and more flexibility to pivot
  • I think it felt hard/scary to think about strategy because it felt really high stakes, but that was a mistake! We could’ve set up things so we had much more flexibility (e.g. by not committing to running longer projects, or by having looser role descriptions, or pre-committing to re-evaluating our overall strategy periodically: I think this would’ve been worth the costs)

4. Do one thing well, not many things to an “okay” standard (or figure out how to be happy with doing things to an “okay” standard)

I really wanted our group to be broad, welcoming, and ecumenical, appealing to philosophers, social scientists, economists, engineers, and theoretical computer scientists all at once. I tried to make a space that was welcoming, ambitious, intellectually exciting, and open to everyone.

Unfortunately this was way too ambitious given our resources. In practice, it meant we did a mediocre job serving many audiences, rather than an excellent job serving a specific one.

One example is our talks. They took a lot of (felt) effort to organize and run, but in retrospect, I don't think they delivered proportionate value. Most of our highly engaged participants were very excited about socials without the preceding talks. I was slow to change my mind about this, partly due to the sunk cost fallacy ("we've already put so much effort into the talk series"), and partly because I never made it explicit what would cause us to change strategy.

We probably needed >1 talks as entry points, especially in our context (packed first term, students frequently miss week 1 and week 2 events). But we could have done just 2-3 talks and then more socials, saving lots of organizational effort while still serving our community-building goals.

5. Managing peers is weird, and unglamorous work needs systems

Trying to manage fellow students who are your peers rather than your reports is inherently awkward. You're all at the same level, you're all busy with your own academic commitments, and nobody signed up to have you as their boss. It's just going to be weird no matter what approach you take.

I found some aspects of delegation surprisingly easy – people were generally happy to own projects they were excited about, and did really excellent jobs. (I think the biggest wins of the Oxford AI safety group are from people other than me who owned one thing they loved, and did it extremely well). But there was always unglamorous work (putting up posters, setting up rooms, managing attendance lists, tracking correspondence with the university, sending emails) that no one was enthusiastic about, and I was hesitant to assign unpleasant tasks, which meant they often fell to me by default.

I should have either created systems to track all recurring tasks and distribute them fairly, or made the boring work more explicitly a shared group responsibility from the start.

6. Be transparent about your capacity and motivation; try to treat them purely descriptively (rather than normatively)

Throughout the year, I had some constant low-level stress about the group. After the first month or so, I didn't feel especially excited about what we were doing, but I pushed through out of a sense of obligation. I was always playing catch-up and felt like I was constantly underperforming. I found this very hard to talk about to the other group members: it felt like a personal failure, and I didn’t want to let down people who (I believed) were relying on me.

This is a difficult topic to write about – it can be hard to avoid feeling shame or guilt over this. I wish I had a smart answer here. Instead I’ll give the (pretty unhelpful) high level recommendation of “try to treat these things descriptively, as fixed constraints you face or resources you have, and then work from there”.

In retrospect, I think it would have been better for everyone if I had been more transparent about my capacity and motivation, and adapted our plans/my implicit expectations accordingly. If I had narrowed our focus, I might have created a healthier success spiral where I felt like I was winning, and so got more excited, and so did even more, and so on.

7. A grab bag of small, concrete tips

• Triple your time estimates: I was consistently too optimistic about how long things would take, especially organising or admin – even after tracking my time (wilful delusion is real). A reasonable heuristic for people exactly like me-back-then is “make a reasonable estimate and then 2-3x it”.
• Set concrete thresholds for when you’d change priorities/drop projects: We collected metrics and feedback, but I never established clear thresholds for when to abandon an approach. This led to a situation where I felt vaguely dissatisfied with our model but never decisively changed course. I wish I had set concrete success metrics at the beginning, so I would have known when to pivot. (It also would’ve been computationally much cheaper! You don’t have to think about things every week, you can just execute until your pre-chosen reflection point, then check your metrics and act on them. C.f. Alex on steering vs rowing.)
• Choose your organizational model explicitly: I wish I had either committed to very clearly specified roles with accountability, or embraced a fully autonomous cell structure where people own entire areas. The middle ground (vague responsibilities with sporadic check-ins) created confusion and dropped balls.
• Create systems for task management: I wish I had implemented some kind of shared task tracking system from the beginning. This could be as simple as a shared Trello board or Airtable with recurring tasks. It sounds very obvious, but hey, I told you upfront I was bad at organising.
• Tracking “felt sense of energy costs” can be as useful as tracking “clock time costs”