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.
Robert Benjamin Sun 29 Apr 2018 4:22PM
The need you described seems like it still fits within the Ops Team model. The Tech working group is setting the policy, which it sounds like the result might be the Tech Ops team to start would be comprised of a minimum of 2 Developers (@mayel @victormatekole ) and 1 tech coordinator. If more developers or coordinators are needed even from a training perspective they could be added at any time the Tech Working group deems necessary.
From a budgeting perspective there would be a set amount put into the Tech Ops team pool. For the 1st six months if the developers don't want to claim their split of the pool then it would all go to the coordinator. Either way the hours contributed by each Op team members would be tracked so real costs of running and up keeping the platform could be properly captured and budgeted for in the future.
The risk to just creating 1 "compensated" short term Coordinator position inside of each of the 3 working groups and not setting up the Ops team structure is that the volunteer pool with the necessary knowledge and inclination to cover needed operations critical areas will not increase.
Matt Noyes Wed 2 May 2018 4:22PM
I like Robert's approach of allocating funds to teams. Tracking/documenting time spent and spending seems tricky to me as a practical matter, I like the way OpenCollective does this.
Matthew Cropp Wed 2 May 2018 4:35PM
After some further thought I think I agree with Robert's take here with one caveat:
It will be tricky to figure out in advance how much we should budget to each team for the labor piece, so I'm wondering if it makes more sense to create an overall monthly labor budget for all three teams that is then divided up pro-rated by time contributions? Perhaps one month there is a big time-intensive technical issue that requires more than usual Tech WG hours, while another month there could be a moderation fracas that requires greater than usual Community WG Ops Team time?
As such, having a single labor compensation pool (say, 50% of the previous month's OC take, or a set amount per month that is adjusted quarterly) would seem to be more flexible than dividing the funds into three separate pools.
Robert Benjamin Wed 2 May 2018 4:40PM
I couldn't find a tracking tool on Open Collective? Are you referring to someone just submitting an invoice? Tacking is pretty important if we are to budget long term as well as for transparency where payments made to members is concerned. There are probably some pretty simple solution for logging hours.
Matthew Cropp Wed 2 May 2018 4:42PM
Yeah, we would likely need a separate time-tracking tool, with people invoicing OC for their pro-rata share on a monthly or quarterly basis.
Matt Noyes Wed 2 May 2018 4:43PM
I was thinking of submitting an invoice - and having a record of submissions. Maybe we need something like Taiga.io?
Mayel de Borniol Wed 2 May 2018 4:45PM
I'm also involved with FairCoop which has been using custom task manegement and time tracking tools for some time and the Open Cooperative Ecosystem team is currently working on improving the UX and turning them into agent-based microservices to make them more easy to use for different things rather than going all-in with a monolithic app.
Robert Benjamin Wed 2 May 2018 6:20PM
Yes dividing between the pools is tricky to start. In the process of creating a sample budget to see how best to do that. The starting premise is that there really won't be enough money to properly fund the pools to begin with and whatever split we start off with can be adjusted later as an imbalance in allocation becomes evident. Though there will be more detail of this in the Finance discussion an overall budget allocation might look something like this.
Total Anticipated Monthly Revenue
Anticipated Hard Costs (keeping the lights on, anticipated Storage Cost Per User)
Contingency Reserve (10% to start)
Available Operation Critical Admin Renumeration Pool
Initial Weighted % Split (60/30/10) for Tech/Community/Finance.
If you run some quick numbers you see a $4000 annual budget ($333 monthly) disappear pretty quickly. Lets say there ends up being $180/month in that Renumeration pool. That's like $108/month split between the entire tech team.
Of course these numbers get better with more members which is why achieving some attainable scale is important.
Matthew Cropp Wed 2 May 2018 6:26PM
It feels at this point/scale any attempt to ballpark a working group split would be a bit arbitrary, and could result in outcomes where rates of compensation vary wildly depending on if there's a lot or a little work to be done in a group in a particular month. So I think it makes sense to treat it as a single pool to start, and then potentially move to splitting it once we have some time under our belts to gauge a sense of how time requirements are shaking out.
Matthew Cropp · Sun 29 Apr 2018 3:00PM
At our Tech WG call last week, @victormatekole @mayel and I discussed this, and one thing that came up was that, from their perspective, getting from here to there is going to require focused organizational/coordinating work that neither of them have the capacity to take on, so, the #1 need identified in the meeting is to develop a (at least symbolically compensated) coordinator role to do such things as build a database of member skills, schedule regular check-in calls, etc. Their next step is to start building a document outlining the role's scope, which will then be shared with the Tech WG for additional input.
As I've ruminated on this more, my sense is that it might make sense to design a similar role for each of the three working groups with a set end-point (say, 6 months), at which point the group governance and compensation transitions to the Ops Team model that you've described.