Thanks for mentioning all of these! Bluedot has put out so much awesome stuff for the broader fieldbuilding community!
We tried this before with a few groups, and found that adding a third party to organizing a course (especially for smaller courses) can actually add more work than it saves.
Could you expand on this a bit more? This is basically the main crux for us to be running this kind of program, or at least for including groups who would otherwise be able to put up their own courses. Can you think of some specific failure modes that we should be mindful of?
Customisation is hard and (groups think it is) necessary: Groups want something weird or custom about their courses (their own facilitators for just their group, in-person groups, different readings, translated content etc.). This is always true, because if they were okay with something standard their members could just take our standard courses.
(FWIW I think most customisations that groups want are probably not necessary, but people behave like they are critical blockers. Most group leaders should probably think more carefully about the time trade-offs of getting more things 80% right rather than few things 99% right. Quality is not the goal. I don’t think this philosophy works everywhere, but for (especially informal) group organization where stuff is bound to get dropped anyway it seems fair to accept.)
This customisation usually meant having to communicate and manage this. And there would be ongoing coordination overhead—inevitably a facilitator gets ill occasionally, or a room isn’t available, or people haven’t done the readings and want to reschedule. And then for each of these events there’s some extra coordination layer added for the group. We automated more of this over time, but it’s still always clunky if say a facilitator is ill at short notice and we need to find a substitute.
Integrated automated systems not set up for customisation: This was exacerbated because our systems are primarily designed for us to run our courses, rather than other people. They were fairly tightly coupled, meaning it was hard to just take one piece (we’ve improved this now, although it isn’t perfect). This meant we had to do a lot of hand holding to explain how they worked, fix things when people used them in ways we didn’t, etc. If we had built it more like a self-serve SaaS product this would have reduced our support burden / the amount of back-and-forth, but this is very hard to do with such a small team.
I’m not quite sure what the lessons are here. I think if I was to try to support as many groups with ops support now I might try (moderate confidence, please don’t take this as perfectly accurate—I also suspect speaking to many diverse group leads would lead to better insights here):
Build technical tools (e.g. for scheduling, admissions, hosting readings) that:
can be used entirely self-service by group leads
are modular so people can put together their own custom course from building blocks, but with an obvious default that plays well together
are very easy to get started with (e.g. free hosted versions, intuitive interface/video tutorials)
Build resources such as:
curricula and session document templates, with instructions on how to use them inline
marketing templates
template Airtable bases / Google Sheets for common course functions
evaluation rubrics, to check courses are going well / what responsibilities of course leads should be (but not actually tell them what to do, just what to achieve)
AVOID trying to write a ‘guide’ to running a course. Despite how useful these could be, people usually don’t read them. They also are a pain to maintain as other things evolve.
AVOID trying to outsource more ‘human’ operations
AVOID catering for all custom set-ups—draw a boundary at what is delivering the most value for groups
Groups want something weird or custom about their courses [...] if they were okay with something standard their members could just take our standard courses.
I’m not sure I agree with this, as AIS collab has done this kind of coordination before, afaik with relatively universal courses. While they might have a preference for customisation, I think most would be willing to compromise for the benefits they get in return, especially if they weren’t able to put on their own course otherwise. Whether to let groups who participate do in person sessions is something I’m indeed uncertain about though. For groups that feel very strongly about customization, it is better to just run their own version.
Most group leaders should probably think more carefully about the time trade-offs of getting more things 80% right rather than few things 99% right.
I agree with this and essentially everything else you have shared in the rest of the comment.
Thanks for mentioning all of these! Bluedot has put out so much awesome stuff for the broader fieldbuilding community!
Could you expand on this a bit more? This is basically the main crux for us to be running this kind of program, or at least for including groups who would otherwise be able to put up their own courses. Can you think of some specific failure modes that we should be mindful of?
I think there might be two things here:
Customisation is hard and (groups think it is) necessary: Groups want something weird or custom about their courses (their own facilitators for just their group, in-person groups, different readings, translated content etc.). This is always true, because if they were okay with something standard their members could just take our standard courses.
(FWIW I think most customisations that groups want are probably not necessary, but people behave like they are critical blockers. Most group leaders should probably think more carefully about the time trade-offs of getting more things 80% right rather than few things 99% right. Quality is not the goal. I don’t think this philosophy works everywhere, but for (especially informal) group organization where stuff is bound to get dropped anyway it seems fair to accept.)
This customisation usually meant having to communicate and manage this. And there would be ongoing coordination overhead—inevitably a facilitator gets ill occasionally, or a room isn’t available, or people haven’t done the readings and want to reschedule. And then for each of these events there’s some extra coordination layer added for the group. We automated more of this over time, but it’s still always clunky if say a facilitator is ill at short notice and we need to find a substitute.
Integrated automated systems not set up for customisation: This was exacerbated because our systems are primarily designed for us to run our courses, rather than other people. They were fairly tightly coupled, meaning it was hard to just take one piece (we’ve improved this now, although it isn’t perfect). This meant we had to do a lot of hand holding to explain how they worked, fix things when people used them in ways we didn’t, etc. If we had built it more like a self-serve SaaS product this would have reduced our support burden / the amount of back-and-forth, but this is very hard to do with such a small team.
I’m not quite sure what the lessons are here. I think if I was to try to support as many groups with ops support now I might try (moderate confidence, please don’t take this as perfectly accurate—I also suspect speaking to many diverse group leads would lead to better insights here):
Build technical tools (e.g. for scheduling, admissions, hosting readings) that:
can be used entirely self-service by group leads
are modular so people can put together their own custom course from building blocks, but with an obvious default that plays well together
are very easy to get started with (e.g. free hosted versions, intuitive interface/video tutorials)
Build resources such as:
curricula and session document templates, with instructions on how to use them inline
marketing templates
template Airtable bases / Google Sheets for common course functions
evaluation rubrics, to check courses are going well / what responsibilities of course leads should be (but not actually tell them what to do, just what to achieve)
AVOID trying to write a ‘guide’ to running a course. Despite how useful these could be, people usually don’t read them. They also are a pain to maintain as other things evolve.
AVOID trying to outsource more ‘human’ operations
AVOID catering for all custom set-ups—draw a boundary at what is delivering the most value for groups
Thanks for expanding on this, Adam!
I’m not sure I agree with this, as AIS collab has done this kind of coordination before, afaik with relatively universal courses. While they might have a preference for customisation, I think most would be willing to compromise for the benefits they get in return, especially if they weren’t able to put on their own course otherwise. Whether to let groups who participate do in person sessions is something I’m indeed uncertain about though. For groups that feel very strongly about customization, it is better to just run their own version.
I agree with this and essentially everything else you have shared in the rest of the comment.
I’d also be keen to hear more about this!