My personal impression is that it's a bit easier to find operations staff than before, but still difficult.

We wrote this update at the top of the original article:

Note: Though we edited this article lightly in 2020, it was written in 2018 and is now somewhat out of date.

Due to this post and other efforts, people in the effective altruist community have become more interested in working in operations, and it has also come to seem easier to fill these roles with people not already active in the community. As a result, several recent hiring rounds for these roles were successful, and there are now fewer open positions, and when positions open up they’ve become more competitive.

This means that the need for more people to pursue this path is somewhat less than when we wrote the post. However, many of the major points in this post still apply to some degree, there is still a need for more people working in operations management, and we expect this need to persist as the community grows. For these reasons, we still think this is a promising path to consider. We also think the information on how to enter operations roles and how to assess your fit for them will still be valuable to people pursuing this path.

Worth flagging that we at Rethink Priorities have had no trouble finding many well-qualified candidates when we do our operations hiring.

is there currently a need for more operations people in EA orgs?

I've heard differing opinions on this from different organizations, and I think this is in large part because different organizations have different standards for operations hires. 

For example, an organization that thinks that having an EA-aligned hire is important and is looking for someone with significant nonprofit/operations experience will have a more difficult time filling a role than an organization that's just looking for someone with certain soft skills (e.g. problem solving, learning quickly, etc.). I think EA organizations tend to lean towards being more relaxed about their requirements, especially for junior roles, which is why it isn't as hard for them to find operations hires. 

That said, I think that having less strict hiring standards can lead to less-than-optimal hires, so even if there isn't as much need  per se for operations people, you can still have a big impact here if you're an especially good fit. I've heard of some complaints about high turnover in operations roles (senior roles can be very stressful since you're juggling quite a big, while junior roles can be boring since you'll end up doing a good deal of admin work), so if you're reasonably confident that you have the personality to stick with operations for a long time, you can have more impact by acquiring more skills and preventing your organization from having to do another costly hire a few years down the road. Similarly, people who have special skills (e.g. technical knowledge for automation, bookkeeping, HR, knack for organization, etc.) could have a higher counterfactual impact in an operations role.

So tl;dr, yeah, we probably technically don't need more operations people, but that doesn't mean you can't have an impact working in operations.

Yeah it seems accurate that the need for operations folk is significantly less than in 2018. That said, I've seen plenty of operations job postings in the last year or so, and it looks like e.g. CEA and OpenPhil currently have roles on the 80k job board. Combining that with the fact that EA organisations seem to generally be growing, it seems like there's still a need for more ops people in EA orgs overall. I guess the harder question is similar to your second one, namely whether such roles are currently easily filled with  the in-EA people already aiming for them or with non-EA applicants, vs. whether there'd be a benefit to more EAs (with a particular amount or type of experience) doing so. I don't have much of an answer to this, unfortunately.

One random thought on this is that  different kinds of operations experience might can be important as well as different amounts of experience.  I have the impression that EA orgs are getting large enough that operations roles can get fairly specialised in some places. For example, I'm not certain, but I think I've seen roles for people focussing on automation, for a Salesforce admin, for junior accounts people. I could imagine that for these roles, experience in the right specific thing might be an advantage, even if the experience isn't that long. (Though I wouldn't take that too strongly.) Something pointing in the other direction would be that, for more specific roles, value-alignment may be less important and so it may be easier to recruit from outside EA.

Of course I don't know how much meetings you have to schedule, but spending 1h/day for scheduling meetings as a full-time PA doesn't sound like a lot of time to me (? - would be interested to hear what others working in assistant roles think).  Scheduling meetings and doing it well so that the person you are supporting doesn't have to spend a lot of time on it themselves and don't worry about, is one of the things where a PA really add value. I think there is a limit on how 'efficient' you can be with scheduling meetings while still making it as easy as possible for the people involved in the meeting, so I wouldn't worry too much about spending some considerable amount of your time setting up meetings.

Besides using tools like calendly where appropriate the only other concrete piece of advice that comes to my mind is that is very useful to know the details of the preferences of the person (or people) you are scheduling meetings for, such as their prefered times for meeting, what kind of flexibility they have for other times of that's needed/the only option due to timezones, etc.

One general answer and one specific answer. (Numbering is my own and doesn't correspond to your questions.)

1. When implementing a new system that will be used by a variety of people in your org, it's important to make this as easy as possible for them. As Martin said, if you end up with one person who doesn't want to use the system, this will greatly increase your work.  When you're choosing a new tool or system for people, you should assume that all of your new users don't care about it, and that any time they have to spend learning the new system will be time they'd rather spend doing something else. To that end:
   1. Don't just ask people to read the software's own published user guide. Even if it's really great and you couldn't imagine making anything better! People don't want to click on links, they don't want to go somewhere else and see new branding, they just want you to tell them what to do.
   2. Do write specific instructions, in an email, as clearly and concisely as possible. Even if those instructions mirror the software's user guide, it's likely you can make them more concise because your instructions are for your org's specific use case. 
   3. Do offer to help anyone who struggles with the new system. It's unlikely anyone will take you up on this offer, but I think it makes people feel like you know they don't want to do this thing you're asking them to do.
   4. Be ready for people to keep trying to use the old system. Keep trying to shepherd them into the new system. Don't give up, don't resign yourself to the two-system world. People will fail to see your first email, but happily respond to your follow-up. Seize opportunities to walk someone through a concrete example: Maybe they didn't set up their Expensify account the first time, but now they're asking for reimbursement, so you can (nicely, graciously) force them to use Expensify to get it.
2. BERI uses QuickBooks Online (QBO) as our accounting software. It works well enough, but has a lot of quirks that make certain things much more difficult and confusing than they have to be. Consequently, I'm (slowly, hesitantly) looking into other options, Aplos in particular. Obviously I'll want to try out all of our normal transactions and reports in Aplos before transitioning. But even if all of that works out really well, one thing I'm very worried about is loss of audit trail: QBO keeps a record of every change to every transaction, including the time, date, and user. I've only used this occasionally, but when I have it's been a lifesaver. I'm not sure how I'll get around this if we start using Aplos, but it's definitely something I'll be keeping in mind. This concern would apply to any important piece of software that stores a complex history of interactions. 

We use Slack, Asana, Greenhouse, Notion, and Expensify (which we use in collaboration with BERI). It's worth trying out a few software options with a small team to see which one suits your needs the best. I'd suggest that you have 3 people try out one software at a time for 1-2 days to see what works. Software should be ultimately easy to use and easy to onboard new people seamlessly. Any kind of software that has a lot of complicated features and takes a long time to learn is likely not going to be great because if it's complicated to use then new members will be less inclined to use it and the software will ultimately become useless. One bottleneck for software that I've encountered is making sure that everyone actually uses it. For example, if you are going to use a software for hiring purposes but one person in your team doesn't want to use it or not willing to learn it, then things will likely get more complicated on your end as the person who is managing the software. Even if one person doesn't use the software, your work will grow quite a bit since you have to balance 2 systems instead of one. It's a simple thing to tell people who are looking into implementing software but it's an important thing to emphasize. Some software are more flexible in terms of its use (i.e. modifying layout to suit their needs, etc) which may mitigate this problem a bit. As long as everyone is using it, then this should be fine. It's worth documenting norms and rules related to any software and have new members read that document prior to using the software (although I often find norms surrounding software are fairly easy to grasp simply by using it for some period of time / intuitive). Another thing I'll note about software is that software should be easy to use collaboratively and you should make sure that the software has the ability to tag different people, share documents easily, have multiple people comment on one project, etc. I suspect pretty much all software has this feature but it's something to keep in mind nonetheless. 

My general philosophy is that software is quite important to consider since it's going to be much harder to shift your team to use a different software down the line. Suppose you choose a software somewhat haphazardly and you want to use a different one down the line, then it's going to be quite hard to do so. I've often found people are reluctant when it comes to learning new software. The classic woodworking advice, "measure twice, cut once" is sort of the motto here. Also, for me, I try to keep using the same software as long as possible until a serious problem shows up. Like I mentioned before, getting an entire team to use a new software is tedious and takes a long time to implement and even if you do implement it, perhaps you will encounter problems with the software that you didn't think about before you started to use it. There will always be new software that come out and some of them likely offer slight improvements compared to your current system but personally, unless those improvements are substantial, I ignore them. 

Several months ago, our team all switched over to using Asana. Before that, some were using Asana, some Trello, and maybe some neither. I believe the switch-over went pretty smoothly and there wasn't much resistance to using the new software. A few things that we did which may have contributed to the good adoption were:

• Before selecting Asana, we asked staff to list all the features they'd like in a task management software, did research to compare a few options, and chose the one that met most (or maybe all) of staff's requested features
• We acknowledged that this is a big shift, it'll take a few months for everyone to get comfortable with it, but that we expect greater efficiency in the long-run; expressed appreciation for staff doing the work necessary to figure out this new tool; reminded staff that this is the tool which meets most/all of their requested features
• Wrote a guide about how to use it (I thought this didn't seem very necessary, since Asana has lots of their own tutorials and instructions, but given Sawyer's comment, maybe that helped!)
• Together as a team over the first few months, we established conventions about how we use Asana, and documented those as a separate section in the guide (new staff read this guide as part of onboarding)
• We held frequent (weekly?) coworking sessions for a little while, where we could ask each other questions about Asana and/or share tips

We do work tests for all roles, operations or not. I think they are far and away the most valuable part of our hiring process.

The ones I have found the most useful for operations hiring:

• Having people to work through hypothetical complicated financial problems like sending a candidate a list of rules for how transactions should be entered into a spreadsheet, then giving them a list of sample transaction with tons of mistakes and asking them to correct the mistakes, and then giving a list of new entries and seeing if they do it correctly.
• Asking someone how the would resolve a hypothetical complicated situation involving HR compliance, financial compliance, etc. all bundled together.

The least helpful:

• Asking people to write something (especially if the role involves communications) - folks interviewing often just don't seem to know your organization well enough to communicate about it well prior to working at the org., and it's really hard to compare these against each other besides on the basis of grammar, etc.

In a (written) work test I would usually try to have a situation that is similar to something slightly challenging that would be encountered in the actual work (Something  that is based on an actual situation but adjusted so that it works well for a test environment is usually good.).  This allows to get at least some idea on how people would address  a problem at work in practice and I would try to incorporate to test for some of these skills:

• General problem-solving capability (by making the task open enough to allow for some creativity)
• Ability to follow instructions (by giving clear instructions on what needs to be done including relevant details)
• Ability to structure thoughts and organise things (by asking eg to create a high-level timeline for some event planning or other activity)
• Attention to detail (by a) potential documents the candidate creates and b) including bits in the tasks that get easily missed without a strong attention to detail) 
• (Written) communication skills (by asking eg to write a reply to an email as part of the task)

What exactly you would do would of course depend on the specific characteristics of the role (eg if the role involves a strong Finance component you would probably add something specifically relevant to that eg dealing with spreadsheets). 

For these kind of generalist skills, a work test in my experience works relatively well in separating very good from merely 'okay' candidates (And usually quite easily identifies bad candidates.)

There are other skills that are very well tested in interviews or similar situations and the combination of a work test and an interview has in my experience worked to judge candidates for (junior) ops roles.

Fellow group organizer here! (and former uni club leader, though not for an EA group) Honestly I don't think there were that many specific skills I learned from operations that helped me in group organizing, but rather it was the general operations mindset, which to me involves: a) noticing when things aren't running smoothly as they can be (for me this is feels like a special kind of stress, and if I'm not careful, my brain directs the blame towards other people involved in the system rather than the system itself), and b) trying things, whether that be new management structures, different software tools, etc. In particular I've found that familiarity with tools like Airtable, Slack, and Asana has been helpful for group organizing but you can probably find resources for that on the EA Hub.

I'll answer the rest of your questions separately. 

How can experienced EA groups best provide organizational support for new/small ones?

I consider myself a new organizer so I don’t have much to add here other than a) one-on-ones, and b) sharing systems etc. that work for you (e.g. for tracking attendance, advertising, workshops). I think every new group is going to have different questions and different needs so I suspect there’s not a one-size-fits-all formula, which is why I think one-on-ones with organizers can be especially helpful, since you can gauge their bottlenecks and help brainstorm solutions.

How can EA groups grow their teams and activities while maintaining good team coordination and management?

Short answer: Asana. Long answer: Clearly define everyone’s roles and responsibilities and delegate wherever you can. As you get bigger you’ll probably want to have something like a traditional management structure, where e.g. the President oversees four committees, and each committee is run by one person, rather than one giant executive board. That way the President doesn’t have to keep track of every little thing that’s happening. This works best if you have a lot of people who are interested in helping out and are actually responsible. 

Also: be realistic about what you can accomplish. If you don’t have enough people/capacity to do a thing well, it’s not worth trying to do the thing mediocre-ly. 

I'll have a go at adding some more ideas for #2. (Similarly to Martin, I don't feel like this is my area of expertise and I'm sure there are others in the EA community who've thought about thisway more than me, but here goes for a try: )

In an organisation that has paid staff one important thing for commitment would be making sure people are compensated well. While volunteers are unpaid and to a large extent doing it for the impact of the role, I wonder whether there are easy-ish ways to optimise the non-money benefits  that volunteers are getting out of the role – e.g. skills, connections and so on. I guess one way to do this would be just to pay particular attention to volunteers "as clients" when doing the group's normal community-building activities. Alternatively, are there benefits that can be provided specifically to volunteers – like maybe connections to more established people doing similar work to the volunteer's role, or social activities specifically for the volunteer team? (Though those probably aren't low-cost, now that I think about it!)

Martin's idea of a retreat could be good for the engagement goal too – at EA Cambridge, where I'm a volunteer, there was  a committee retreat one year. To be honest I don't remember what the main goals of the event were, but I think one benefit was helping me feel more engaged/committed in the committee that year.

The other main area I can think of that might help is ensuring that volunteers  have plenty of ownership and space to make meaningful decisions and innovate (and that things stay that way as the team grows), both so that people feel a sense of responsibility and are more committed, and just to help the work be interesting. Like, where possible, delegating an area of responsibility, a problem or a sizeable project rather than the implementation of a specific solution; and ensuring that volunteers know what the extent of their freedom to change things is. 

I don't have any experience with organizing EA groups at a university  so I'm not the best person to answer these questions but I'll do my best. 

Regarding bullet point #2, I think there are two things that are worth doing. First, praise them publicly and privately about their work. If they contributed to something that went well (such as an event), then public acknowledge their effort to the larger community and thank them. Volunteers (and operations folks as a whole) do a lot of thankless work that is largely seen as "easy" by a lot of people so having leaders acknowledge them is helpful. I also think you can praise them privately as well with a simple thank-you email or simply tell them face-to-face (or virtually these days). I often like to tell any operations assistants or volunteers that their work matters. I like to explain the causal link between the successful completion of their duties and the end goal. For example, if the volunteer doesn't create a template for the invite, then this delays the invites for the event and this puts the event in jeopardy. I think volunteers don't have a keen sense of how their work impacts the end goal of a project because they don't have the birds-eye view of the project like leaders do; they don't possess the ability to see the causal link between their work and the end goal. It's important for leaders to clearly draw that line for them so they understand how their work integrates with the larger picture and hopefully, how integral their work is to the project. 

Regarding bullet point #3, I think having publicly available resources is a good idea. For example, at CHAI, we use Notion to document all of our internal logistics so any new member can familiarize themselves with our inner workings. If you haven't already, perhaps writing a set of guidelines for new/small organizations is useful. You can write a guide on organizing events, recruitment, marketing, etc and all of the different aspects when it comes to running an EA university organization. Also, documentation of your "missteps" is valuable. What lessons did you learn along the way as you organized events on campus? What former processes did you use before settling on your current one and why did the former one "break"? This gives new/small orgs an insight as to how to think about their own internal systems as they begin to grow and can learn from your previous mistakes and know what to avoid. 

Another thing you can do is hold small retreats (virtually for now, obviously) where you invite leaders from new/small orgs and hold talks about various aspects of running an organization.

For point #2, one speculative thing that comes to mind is the legal and governance structure of an incorporated organisation, i.e. being incorporated, and having a board – whether a board of directors/trustees who have legal responsibility for the organisation and whom the team ultimately report to, or an advisory board.  

I know that plenty of larger EA groups, particularly national ones, have these kinds of things already, and I wonder whether it would be beneficial for more large EA groups to do so. (I don't know what the answer to this question is.) Possible advantages that I can think of of such a setup:

• If you can find board members who are knowledgeable about the area – like maybe some EA community-building funder, or a leader of a larger EA group or something – their input might be great for strategy.
• Running the legal entity's operations could be good skill-building for the organisers, e.g. if any of them want to work in operations or entrepreneurship.
• It might be better for longevity and stability of the group – the board would always be responsible for the organisation, so if a dedicated group leadership team moved on before finding good successors, it would be the board's job to try again later.
• If there are paid organisers, they could be on payroll, which might be nicer experience for them than being paid directly by the funder. If the group ever wanted to rent property, it could do so in its own name.
• Particularly if it's a charitable structure, having a legal entity might help with outreach due image reasons, particularly if targeting professionals rather han students.
• If a  charitable structure, it might help get more funding, or funding from more diverse sources.

DIsadvantages I can think of include the effort and administrative complexity (which for a charity, might be very high), the time cost to the board members, the financial cost (e.g. incorporation fees, insurance etc, maybe legal advice or professional fees depending how much you did yourself), and maybe worse consequences if things go wrong (like forgetting to do some legal filing or doing your accounting wrong or something). I also  have no idea whether groups that are student societies are allowed to be incorporated.