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.
+1. Like Marisa mentioned, some operations individuals get jobs without applying to jobs via the "traditional" route. I started off as a contractor and was promoted to a full-time employee.
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.
Regarding your first question, I think this is correct. I spoke to some EA operations folks at the 2019 EA Global and they said that the need for operations people has decreased. Seems like after the article came out, there was a large influx of people applying for different positions and those positions have been filled (for the most part). This isn't to suggest that there aren't any operations positions open anymore - I'm sure if you look at the 80k Job Board, you will find operations job opportunities.
Regarding your second question, I don't have a good sense of how easy or difficult it is to get an operations position at an EA org these days. My general sense is that there are still quite a bit of qualified candidates applying to open operations positions so individuals who only have some but not a lot of operations experience may experience a disadvantage when applying to those positions. I can't speak on behalf of any other EA org but at CHAI, we occasionally use contractors on a temporary basis to off-load some of our operations tasks. If you have some but not a lot of ton of experience (as you put it), I would suggest that you reach out to EA orgs that you are interested in and see if any of them are looking for any short-term / contractors.
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.
+1. Like Marisa mentioned, some operations individuals get jobs without applying to jobs via the "traditional" route. I started off as a contractor and was promoted to a full-time employee.
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.
Regarding your first question, I think this is correct. I spoke to some EA operations folks at the 2019 EA Global and they said that the need for operations people has decreased. Seems like after the article came out, there was a large influx of people applying for different positions and those positions have been filled (for the most part). This isn't to suggest that there aren't any operations positions open anymore - I'm sure if you look at the 80k Job Board, you will find operations job opportunities.
Regarding your second question, I don't have a good sense of how easy or difficult it is to get an operations position at an EA org these days. My general sense is that there are still quite a bit of qualified candidates applying to open operations positions so individuals who only have some but not a lot of operations experience may experience a disadvantage when applying to those positions. I can't speak on behalf of any other EA org but at CHAI, we occasionally use contractors on a temporary basis to off-load some of our operations tasks. If you have some but not a lot of ton of experience (as you put it), I would suggest that you reach out to EA orgs that you are interested in and see if any of them are looking for any short-term / contractors.