Creation of Admin Ops Teams
During the April 16th membership-onboarding call there was discussion about the need for a more formalized administration structure to help insure adequate day to day coverage of a few areas critical to platform functionality and usability. These duties have historically been covered by a small group of volunteers comprised of early/founding members. The following pre-proposal was contributed to by Matt Noyes, Matthew Cropp, and Robert Benjamin prior to presentation for group feedback.
Operations-Critical Admin Teams Resolution
In order to provide for seamless and continuous platform operations coverage while still maintaining fluidity of member volunteer engagement (especially as social.coop scales), it could be beneficial to create “Admin Ops Teams” in the three following Operations-Critical Areas: Tech, Community, and Finance. For example a Tech Team would cover all things hosting, site maintenance, and development, a Community Team anything membership based, and a Finance Team would perform budgeting duties or those usually assigned to a Treasurer.
Each Operations Team would execute work within the parameters and scope of the policies provided by their corresponding Governance Working Group. The teams would self-manage to ensure coverage and participation by a diverse group with needed skill sets or desire to learn. The team members would be given greater administration access than would be afforded general membership.
Remuneration
There has been a good amount of discussion around the need for some kind of remuneration for performance of Operations-Critical Admin duties. Though it may be necessary at a future date to create paid staff/contractor roles, in the meantime, a somewhat simple way to incentivize volunteer coverage would be to create a working budget that allocates monthly funds for each Operations Critical Admin area. With volunteer hours managed transparently through Open Collective, the allocation could be split (per month pro rata) between corresponding Operations Team members.
Remuneration would be for OPERATIONS CRITICAL duties (however that is defined), and not for general governance duties like Working Group participation for which there is an expectation that all members participate in some way at their own chosen level. The expectation is that while the platform is small the amounts paid to any given team member would not be substantial enough to be considered “compensation” for the work performed but could provide partial offset for the expense of committing time keeping the platform up and smoothly running. For context on a funding methodology that cold support Operations Teams approach see larger budget allocation discussion.
Equity
As power may accrue to both Governance Working group members and Operations Team members by way of their already having specialized knowledge, or through the development of specialized knowledge, it would be highly advisable to require rotation of Operations Team members, not as a strict rule, but as a general principle, and adopt a mutual education approach in which people who have the skills needed for the operations train their replacements.
Additionally, as there is a risk of inequity in the formation of the Operations Teams, proposals dedicated to driving platform diversity and equity will be forthcoming.
Nathan Schneider
Mon 14 May 2018 3:59AM
I admire the basic structure and gist of this proposal, but I think it's time to start including monetary compensation, first of all to ensure time-privilege isn't a prerequisite for contribution.
Sam Toland
Mon 14 May 2018 9:07AM
Support the principle of this proposal & all the practical elements that I have had a chance to get to grips with. However, I haven't had the time to adequate evaluate this, so I am abstaining (in the positive way :) ). Great work moving this forward
Nick S
Mon 14 May 2018 11:30AM
Just to be clear, concerning Nathan's point, I saw the question mainly in terms of "creating teams" (as per the thread) rather than specifically "creating volunteer teams". Perhaps the distinction should be clearer.
Robert Benjamin Wed 9 May 2018 12:00AM
Agreed.
Nick S Wed 9 May 2018 11:15PM
Bank holiday weekend means I've not been keeping up on loomio very well lately, however, here's a sketch of an idea.
- Existing admins compile a fairly exhaustive list of all the jobs that need doing.
This may take a while to unpack if the work is currently ad-hoc, but it can be a working document. For example: monitoring backups, documentation, moderating, domain renewals, disaster recovery. Recruitment, scheduling, allocation (as per below) may also need to be recognised jobs.
- Rate the jobs by a) frequency, and b) role.
"Frequency" indicates roughly how often a job needs to be done, and might be: daily, weekly, monthly, annually, and possibly "never/unpredictably" (disaster recovery and that sort of thing)
"Role" tries to indicate who can do the job, and may have more than one variable (tech vs non-tech, accessible to newbies or otherwise), but otherwise tries to keep to a small number of understandable roles/grades of skill.
Order them into your "Maslow's Hierarchy of Maintenance." (Strictly there'd be two of them, since there are two variables, but we are trying to keep it simple)
Recruit a roster of people, categorise them by the roles they can perform and time availability.
Does the pyramid balance match the roster? Typically it might be too top-heavy, i.e. inaccessible to newbies and junior technicians. If so, maybe some work can be done to make balance it out by automating or simplifying the jobs.
Assign people to jobs somehow. Each person/group should get a list of jobs, their frequency, some documentation, and a buddy to go to for help when then need it.
Review this periodically to allow for rotation and improvement of skills/processes, and to guide recruitment.
Perhaps the above process might be minimally adapted for finance and community groups. The general aim is to match the jobs to people such that responsibilities are clear and there are enough hands to do the work.
A ticket system, which can also remind people when they're due to do some job, seems a good thing to have.
Some comments:
- Remuneration doesn't yet figure into this, because it was conceived for a volunteer-run organisation.
- There may be problems to solve: like a mismatch between jobs and volunteers. But knowing this means knowing where recruitment is needed.
- Recognition might need to be considered too. How can the more lowly or brain-f*cking jobs be made more fun, social, or generally more thankful?
The inspiration for this was when I was running the website/IT for a volunteer-run charity. I was also a volunteer. I found it really hard to get any help at all, since almost everyone else who was prepared to volunteer found most of the IT too technical.
I imagined a kind of Maslow's Hierarchy of Needs for admin - I wanted move as much work down to non-technical base of the pyramid, and leave a bearable tip of techie stuff for someone like me. So, WYSIWYG content editing, automated spam account deletion, mail admin via web UI, generally automate/wrap the technical stuff whenever possible. This sort of helped... except even I struggled getting Drupal to do the things I needed, and they mostly use Facebook now I've moved on :/ Of course, I'm confident we won't have that problem!
Robert Benjamin Sat 12 May 2018 8:48PM
Sounds amazing. There was talk of an immediate need for a Tech coordinator. Maybe as soon as this passes you could do a formal proposal in the Tech Working Group to adopt something like this initially for the Tech Admin Ops team. Then join @mayel and @victormatekole (current tech admins) on the initial Teach Ops Admin team and help develop this out. Would be good to include the training "pairing" that @darren4 mentioned with a 6 month rotation horizon. You could draw the additional volunteers from the deep pool of volunteer canidates from Mayels poll. So basically the initial team would include 2 admins and 1 coordinator each with a "trainee pair" (a total of 6 people).
Darren Thu 10 May 2018 3:58AM
Sounds like a pretty good plan to me.
"How can the more lowly or brain-f*cking jobs be made more fun, social, or generally more thankful?"
Made me think of the interesting open source social food gardeners web platform project growstuff.org I was watching the early development of a few years back.
The main dev is big into making it a community project and in educating people to code.
To make things more fun/social, to share knowledge, and hopefully get better quality results, they encourage development to be done via 'pairing'- people working together in pairs (or small groups)via a live link - video, audio or text chat + screen sharing or some kind of collaborative txt editor (something a bit like etherpad or google doc) all depended on the task or participants.
I wonder if we should encourage pairing for social coop Ops Teams tasks?
Obiously doing stuff via pairing is likely to take longer, possibly much longer, than someone with the skills just bashing it out, but the benefit is that its social, thus hopefully more fun and creating stronger social bonds, also it would be skilling up coop members, making more able to take on tasks and improving social coops sustainability & resilience.
In a few different projects I've paired with people editing website/flyer texts via etherpad, sometimes its helped improve motivation to get it done, and I've always found it enjoyable.
I guess implementing something like this would require some work setting up and coordinating, and probably initially more time from the people already running things, but, particularly if the pairing is promiscuous, could quickly could lead to having more people in the coop with the necessary skills and knowledge to share the load and keep things running smoothly.
Matt Noyes Thu 10 May 2018 5:04AM
In workers collectives in Japan, they pair people to share skills -- calling it tomoiku, or mutual learning.
Nathan Schneider Sun 13 May 2018 9:12PM
My creeping concern is that starting from a volunteer basis could get in the way of ensuring we have a diverse set of leaders from the start...
Darren · Tue 8 May 2018 11:12PM
To slightly expand on the comment attached to my vote for creating volunteer Admin Ops teams. I think Admin Op team members should probably all be members of their respective governance working group so that they can effectively share information about what they are doing and how its progressing.