Compensation framework

Organization circle
21

I also think this is better, thanks for the work @wouter

But I still do not feel not totally comfortable with it. My main concerns after reading it are:

  1. Why is the 30 % for sales percent independently from the product circles budget?
  2. I also think there should be an incentive for providing BBB servers, so fixed costs deducted first should not only contain server costs but also service costs, e.g. if it is provided by another coop.
  3. For me it looks complicated to distribute income to every circle, wouldn’t that also mean that every circle needs to do budgeting and bookkeeping? That is quite some work and opens multiple points of failure if circle members are not on point with their finances…

I hope this doesn’t come around to negative. I like that a fixed rate seems to be now changed for “bounties”/estimates and the calculation after the end of each trimester.

2 Likes
22

I also feel this needs discussion, as I have two concerns:

  1. Logistically, “30% ongoing commission” seems like a lot of accounting work to maintain. I need to know this member subscribed for 6 months then terminated their membership, that one was in since March, etc. and in the end, these amount to 30% of EUR 10 per month scale of money each, but have to be evaluated and reviewed individually. I just don’t think the labour is worth it.

  2. I log my hours when I meet with potential clients like Dat and Our Networks. If I take a commission then I am double counting the labour.

I am supportive of having a way to compensate for sales work, but in a low overhead way (e.g. something that ends such as first X months of revenue) and having clear indication of how to log sales work. I feel that there may be a distinction between “internal sales” vs. “resale”. When I talk with potential clients, I see myself as “an employee of Meet.coop” but if someone who is less involved in Meet.coop operations (e.g. not in our Circles or time tracker) sources a client to Meet.coop, that’s more like a reseller relationship.

In a way we are already doing that. If we get a bill from Webarchitects for the collaboration tools we use (@Graham is sorting that) it won’t be raw server costs, I assume it includes service fees. That’s similar to if Collocall bills us for server monitoring service, or Koumbit bills us for setup.

It’s hard to draw that line between what is service and what is not. For example, does Hypha send a bill for service to set up virtual office practices, or @osb sends a bill for marketing services, and @melissamcnab for design services?

My proposal is, every budget must be approved by a Circle according to its budget, whether it’s hardware, collaboration tools, marketing, design, etc. and the only bills that we can pay are the ones that have a budget allocation from a Circle. Most like, we will prioritize hardware costs, but that is a decision of the associated Circle.

I think we can devise a low overhead way of doing this, but it’s probably necessary to prevent everyone getting blocked on a central “budget committee” that doesn’t have enough visibility into specific Circle needs. For example, if I tell Technology Circle now that you have a $3000 Q4 budget and you are responsible for server payments of ca.meet.coop, your Circle can pretty quickly decide on server provider, how much to allocate to Collocall for its sysadmin service, the roadmap and which work is compensated which is out of scope for Q4, etc. but if you try to take this up at an All Hands meeting, we’ll probably burn through 2 All Hands (about 20 person hour).

Logistically, you can just have a spreadsheet that sums up to $3000 and make sure to allocate no more than that to the tickets in Deck.

1 Like
23

let’s see how we can resolve the observations made

right now we need a first version of a working compensation framework, and I agree that in the future we’ll want mechanisms that consolidate cooperative reserves and possibly dedicated funds.

the mechanics described take all revenues of the selected period and allocate direct costs for servers and payments, and for the sales compensations. The remaining revenue is then spread over the Circles primarily. This could also be different of course, please make a proposal as you consider more appropriate.

In previous discussions people agreed that a sales compensation as a percentage over revenue would be most sensible, as in many cases it can be tricky to track time and/or decide bounties on a case by case basis. Administration will need certain detail, as to know who worked what new members and to what periodic compensation does that lead.

Maybe we should go into more detail and discuss the use cases for how we attract and onboard new members.

One case is where people / orgs have heard about meet.coop and contact the contact@ mail and/or register and engage through any of the other open platforms (mainly the forum for now). We can consider this expression of interest a “lead” and according to certain logic assign this among the Product Circle for follow up. Maybe here we can define a few standard steps and budget (time) for helping the potential member to join. In that case the % sales compensation can be left unclaimed and channelled into the Product Circle budget.

A second case is where Operational members (and their staff) proactively approach people and orgs in their network and achieve new memberships. The sales compensation was thought for this case in particular. It is designed to generate sales and limit the need for coordination between us. Consider that not all staff from operational members is part of the Product Circle - we’d expect maybe a minimum of one per ops member engaged in sales to be member of the circle to convey experience & agreements more easily from ops member ↔ product circle?

A third case is like the previous one but more than one ops member has been involved in the sales process. In this case both claim part of the compensation and will need to agree how they divide it. It’d be helpful if sales work is still time registered but maybe with a different tag?

Indeed, there should never be double counting! But in the model we’re envisioning here together, your meeting with potential members would be either entitled a bounty in the task tracker (from the Product Circle) (in the first case) or a sales compensation (in the second case).

Back to the admin work to keep track of ongoing membership revenues: somehow we’ll want to have an updated overview of all members and of what type and level. I’m afraid that that’s not 100% to be inferred from OpenCollective, but mostly it should. Is there then a way to automate i.e. connect to the OC API to track this in a spreadsheet or so? We’ll need to work on that spreadsheet in any case…

+1

I’m keen to hear your proposals to how we can improve the mentioned critique in a workable first version compensation framework.

1 Like
25

Feedback Compensation Framework

Thanks a lot for the contributions to the compensation framework. Things start to get shape and many good points are being made. Nevertheless, we still see some points worth discussing. We want to mention some critical points and propose a slightly different approach:

Criticism on proposal:

  1. Sales is treated differently than other circles.

Treating sales work differently then other work circles inherits a problematic concept from regular capitalist business. It leads to sales being disconnected from the common vision. An incentive based on new user members can lead to sales circle thinking mainly in new sales rather than sustainable customer relationships. And, as mentioned above by benhylau, is difficult to calculate.

  1. A money-based bounty in combination with expected working hours leads again to a fixed hour loan

For a single worker the benefits of the collective project is disconnected from their own benefits. No matter how well meet.coop performs they get their (low) hourly rate. The success is not distributed to the workers, while in case of failure the member collectives need to rebudget meet.coop to pay the bounties. It brings a lot of calculation, which in the end is just transferring money from one side to the other and back.

  1. A money-based bounty system is hard to handle in terms of budgeting, speculation and accounting.

As already discussed above every circle needs to do accounting. The budget needs to be there and agreed in advance. There is even the problem of dynamic exchange rates as we all work in different national economies.

Collocall proposal:

  1. Take sales provision out of compensation framework discussion. Sales provision for member organizations etc. should be discussed independently and the Product circle is already responsible for sales.

  2. Tasks should be estimated in hours and not have a money bounty, as we see multiple problems here:

  • Changing exchange rates

  • Disconnection from actual success and available money

  • Value of a money bounty can be very differently depending on location

  • very similar to “cloud work” concepts

  1. We would like to add to the " Calculation of Compensations" part: " Members can decide if they want to get their benefit paid out or if they want to do solidarity transfers to other members/circles. Members can also apply for higher compensation."

  2. The fixed costs include services that are connected to server hosting. If (paid) services are provided by members the hours worked on them are not tracked within the meet.coop system. If inequalities appear at this point, they can be addressed as mentioned in point 3).

We’ve also thought about proposing the use of story points instead of time estimates/tracking, but didn’t want to make this discussion even more complex so we stayed with time estimates/tracking. (https://www.scrum.org/resources/blog/why-do-we-use-story-points-estimating) We’ve also discussed combined with this step to drop time tracking and do calculations on achieved story points alone.

Main Advantages of story points:

  • easier estimating of work, because everybody works on different speeds

  • w/o the use of time tracking there would be more incentive to improve processes

In further discussion we have to find a solution to different currencies and dynamic exchange rates. We need to have a compensation system with as little money exchange as possible and risk distribution of dynamic exchange rates.

1 Like
26

I think a lot of good points are brought up here. Personally I am in favour of dropping time tracking altogether and use story points, with the acknowledgement that we will in the future compensate the “start-up hours” we have tracked until this new policy is in place.

In my mind story points ~= hour-estimate money bounty > time tracking (negative incentive to get the right things done fast). To me, story point vs. hour-estimate money bounty is roughly equivalent. The idea of “story point” is harder to grasp unless you are familiar with SCRUM, so I am a little worried, whereas hour-estimate is one less abstraction. When we have the money, we are definitely able to revise the “hourly wage” such that a 4h task can pay according to available resources of the co-operative. Remember, we co-own this, and decide how much is the “hourly wage”. So in effect, it’s hour-estimate is just user-friendly story points.

I agree.

Are you also proposing we assign as many hours as we want in each Circle, as long as they are collective decisions, and members will get allocation based on those hours each quarter-end?

For example, if @benhylau worked on tasks with 100 total hours allocated and @rastlos worked on 200, and at quarter-end our Circle has $3000 to divide, then @benhylau gets $1000 and @rastlos gets $2000. This is true even if @benhylau works really slow and spent 400 hours on the 100 hours of tasks. I think this is correct. If things change scope drastically, @benhylau should be asking the Circle to revise estimates.

In the case where we made only $300, we’d be working for $1 per hour and nobody wants that! How do we “carry” those unpaid hours for when we are more profitable? A fixed hourly, perhaps as a minimum wage, would treat $25-$1 = $24 as deferred wages perhaps?

I generally agree with taking Sales allocation into Product Circle to decide, and come out of Product budget.

I don’t think exchange rates are an issue because OC has TransferWise integration and the exchange rates are very low, median rate plus ~1%.

27

Too much complexity coming into play here for me. I’m no wiser having read the linked article on story points. I would say that the vast majority, if not all, of any work that I contribute to the project will be not about software development. It will be about marketing, governance, admin, etc. Not sure how that can be accommodated within a paradigm that doesn’t account for the time a task will take.

1 Like
28

Great discussion and ideas here - thanks all.

I also like the idea of story points - but agree with Graham that points might be tricky… and with Ben that allocating Time ‘bounties’ would be better than monetary amounts… since presumably we are going to have a fixed income (for any given period) and a varying amount of tasks… hence the rates we pay for tasks may need to vary… at least in the short term until we are solvent.

I also don’t understand how these budgets will be set at the start of each quarter, or does everything happen in retrospect? For example, if we were kicking off the budget setting process now we would need to know our total income for the coming quarter, allocate it to the circles according to the percentages, and then set bounties on tasks… and then (if I have understood the proposal correctly) people that have completed tasks with bounties would invoice and get paid accordingly…
But this assumes we know our income at the start of the quarter - which we don’t… (although I guess we could make an estimate based on current members, and assume no-one cancels, or if they do we deduct these losses from the next quarter - and add in any additional funds raised from new sales to the next quarter) - but this gets MESSY, fast.

The above proposal (as I have understood it) also assumes we have the required budget to allocate to the required tasks for the quarter - which is also not true, especially now in start up phase… so what are we saying…? That we will allocate un-earned income and hope for the best? (sounds risky to me) or that we will only allocate available funds? (also doesn’t sound wise if we know that X tasks would bring in a big sale… but we don’t have funds to make it a paid task…)

What I am sensing is that we need to find a way to share work fairly - and any profit. And until we have more income than costs we are going to have to accept lower wages / volunteer a bit, or go into debt…

So I would suggest we set a budget for ‘paid’ hours at the start of each quarter - based on our known income minus our known costs (and hope that income from new Members more than covers people leaving - which should be the case or this is never going to work!).

Initially - like now - this budget will be VERY small - but real.

We can allocate this budget to the Circles as proposed - (not sure where the %s came from, but they might be ok to start with)

And they can allocate these budgets (as hours) to the most essential tasks
And they should be time-tracked - and paid as suggested above.

But we also need to do more tasks, over and above the available budgets, if we hope to grow and become sustainable… So I suggest each circle is also allocated a certain number of ‘hours’ for ‘Growth work’, which are tagged as such in the Deck, and tracked in the time tracker with a tag.

These hours are initially contributed as the 40 hour commitment of Operational Members, after that (i.e. once a Member has completed their 40 hours) any additional profit for the quarter is split between the Members, proportionally according to the number of extra hours they have worked.

People working on these tasks would not expect payment at a fixed hourly rate - but a profit share instead - capped at the £25/hours rate - with any additional profit going back into the pot.

This seem more realistic to me in that we don’t go into debt - and it forces us to be realistic about income and budgets, and to think very hard about what is essential paid work (since we can only afford so much) and what is ‘Growth work’ (i.e. needed in order for Meet.coop to grow) and other ‘nice to have’ tasks…

2 Likes
29

These steps in resolving the compensation framework are great :+1:

A reflection though, on ends and means . . What’s primary is contribution framework. Compensation = a subsidiary aspect of contribution. The aim of meet.coop is not livelihood work/labour market work/service user payments. These are means - the aim is commons-cooperative economy and P2P organising capability in the mutual sector. So . . just putting down a placeholder here, for contribution framework. Core to the agenda of the org ops circle.

Meanwhile back at the ranch . . establishing operational arrangements (=cash flows) for user accounts, server costs, payments for sysadmins. Paying the rent, putting food in the fridge :+1:

1 Like
30

Sharing this from our August 21, 2020 Organizational circle meeting.

Bold text is the direction we are thinking to go with.

Income allocations

  • Oli suggests profit share (revenue from previous quarter subtract overhead, agreed by all, divided by hours allocated to tasks, agreed by circle)
    • Ben: this punishes early involvement
    • Oli, Graham, Ben: simplicity is key
    • Graham: separate out early stage vs. future
    • Ben: Collocall, story points idea
  • Circle-specific allocations should start out equal per circle but subject to collective revision
    • Ben: this would lead to hours across groups being paid at different rates
    • Graham: not sure why we have this layer
  • Scrap time tracker moving forward?
    • Graham: don’t know how much time it takes us to run this operation, we need to know
    • Don’t scrap it, but after this plan is in place, compensation is based solely on task board time estimate allocations, not time tracked. Time tracking is solely for business planning purposes
    • There will be a plan to repay previously tracked hours at undetermined rate

@Graham @osb the item I wanted to discuss but forgot what it was… was how sales compensation is handled. We still need to sort that!

31

Dear all, I’m trying to figure out the many wise contributions made to this discussion and to start drawing some conclusions, how difficult it may be :wink:

  1. Simplicity is key. Several people are warning for a growing complexity, and with such a diverse group, diverse roles and diverse time commitment and highly changing economics, whatever we decide, it will need to be simple to understand and to explain to our colleagues at our respective organisations. We’ll want to avoid endless discussions and possible disputes about unclear and possibly unjust compensations.

  2. We will err, but iteratively improve the framework. It’d better to start perfectly right, but given the collective learning and changing organisation & economics, that’s nearly impossible and we’d better get started and be prepared for the changes.

  3. Time tracking. The last Circle meeting suggests we keep tracking time, so we learn how much effort certain tasks costs and we get better in estimating compensations and planning our operations.

  1. Assure compensations are generally paid at equal rates, be it through the compensation bounties set in the task board.
    We would NOT want to pay tasks in one circle differently than in another. That’s why the 25€/hour rate was suggested as a general norm, or aim. Of course with the flexibility that a task X estimated with 4 hours of work, i.e. a 100€ bounty could be performed by one in 3 and another in 5 hours, still keeping the same bounty. Only major deviations in task scope would encourage a task owner to get back to the Circle and discuss the workload & compensation. We do need to settle for a “central” currency to set bounties so we talk about the same thing. I’m afraid that the majority of operational members right now is in the Euro-zone, so that being a good candidate. In any case, the amounts can be exchanged with limited costs.

  2. [quote=“benhylau, post:30, topic:249”]
    Circle-specific allocations should start out equal per circle but subject to collective revision
    [/quote]
    I take it that no one is arguing that each Circle has the same amount of work to do, but one option would be to distribute it equally at the start, evaluate periodically and adjust accordingly.

  3. Sales labour compensation. I’d like to thank ColloCall especially for their reflections on this matter and want to discuss how we can avoid the problematics they and some others signal.

a) Compensating work sales differently from other work comes from the understanding that generating revenue is paramount for our project to reach breakeven or a certain sustainability level;
b) it can be especially hard to collectively estimate how much work is needed to convince a potential party to become a member and therefore agreeing on a bounty based on that specific work for that specific member is extremely hard. It is not uncommon to use a percentage over revenue to compensate for this kind of work, as a much simpler method, much clearer to explain to all parties involved and much simpler to administer; Also I’d avoid a % over gross margin or some other construction, as it can easily become very hard to explain and understand what the results will be.
c) the doubt about potential disconnection with the common vision we should proactively monitor and adjust as we go. Note that only operational members (being voted in as such by the existing membership) can do this work;
d) the doubt that sales people mainly think in new sales rather than in sustainable “customer” relationships I’d say is a rather limited risk: consider that members make monthly contributions right now and the sales compensation is directly linked to their happiness and continuation as members. Our organisations (generally) invest in lasting relationships and serve their communities, so they have a vested interest in keeping them happy and make sure they continue on board. Our sales labour compensation tries to reflect that, on a month to month basis, and I’d hope also on a year to year basis (possibly consecutive years we’ll want to lower the percentage though).
e) there will be different sales use cases that we need to develop. Two main use cases we can foresee now:

  1. Operational members deploying an active strategy to generate meet.coop sales. A new member that has been proactively approached and accompanied by a particular operational member before reaching standard meet.coop communication channels (contact@ mail, forum). In this case the sales compensation should go to the operational member to make sure they have an economic incentive to invest in this sales work and encourage their relationships to join meet.coop.
  2. Expressions of interest that reach the meet.coop channels (contact@ mail, forum) and are followed up by the Product Strategy and Services Circle. In this case there maybe various ways to accomplish a successful membership joining. One could be that the lead is in the network/geography/interest of a specific ops member and without much ado this member follows up. Another could be based on availability, so if Alice (member of the Product Circle) is available or on guard, she follows up. Yet another is that Bob follows up, but finds out that the potential member has some specific use case and he decided to discuss with Alice or maybe even with Dave. In these cases it might not be appropriate to just assign the full sales compensation to anyone person. It might be better to assign the full compensation to the Product Circle, which in turn defines some standardised bounties, like “following up expression of interest - 15 minutes”, “online call with (highly) potential new member - 30 minutes” or whatever the Product Circle deems appropriate. The Product Circle can then see what more detailed strategy is needed to be most effective with the least time investment of its members.

Do you think it makes sense to keep such dual sales strategy? Please consider that we want the ops members to actively engage in sales and they cannot add any direct markup to the meet.coop tariffs (as greed in the Service Levels definition).

f) about the difficulty in administering compensations: we’ll need to develop a decent admin workflow and spreadsheets where we keep track of all membership contributions each month, assign the sales compensation to the ops member or product circle and automatically generate the revenue assigned to each Circle. Each Circle will need to track effectively the task bounties and time (for evaluation purposes) and sum the bounties to each ops member. That requires some work to set up and to execute periodically, but I’m sure we can pull that one off, as long as we have a shared understanding and consent about the basic framework that we are trying to put in place.

g) Initial investments and delayed compensations. This is in my eyes the most tricky part. We have several hundreds of hours invested in the first say four months (May - August) but only approx 3k€ revenue generated. As could be foreseen, most part of the initial investment cannot be compensated straight away, or as the last Org Ops Circle meet suggests:

We could play with the rate, but most importantly we should think of the time period over which it can be paid. Possibly we could assign a percentage of the gross margin to pay the initial investment, and depending on how successful we are collectively, the initial work will be paid earlier or later.

Also we will experience that even now that we install the initial compensation framework, we won’t have sufficient revenue to generate all the work needed to get started really and build up the organisation. How do we go about that? If we’d get some grant proposal funded, then that would possibly help a lot to kickstart and compensate the work. But before or without that, we will still want to go forward and encourage ourselves to do work while not being able to pay it inmediately. Do we allow the Circles to generate “debt” towards the Circle members and operational members? What limits do we find reasonable? At the start we didn’t want to think of it, but towards the future we should have more clarity over what would entitle anyone of us to generate future compensations, if and when the collective is to be successful.

h)

+1 this is part and parcel of the contributory accounting framework.

2 Likes
32

Hi there,
I’ve compiled the discussed elements into one document called “Compensation Framework”. You can access it here:

Please have a look and if there’s blocking issues, let’s zoom in and have a more detailed discussion.

2 Likes
33

imho our proposed compensation framework is getting too complex to start off from scratch. Especially having only limited funds available in the short term makes me doubt about the bounty system. Managing bounties as a way to pay salaries is not very common, but it might work when there’s sufficient funds coming in (it would be good to have references and case studies). Maybe that’s something we can introduce in future iterations.

In many cases a task requires more than one person’s eyes: it needs to be defined, realised, reviewed and validated, so often the idea of assigning a bounty for the task to one person isn’t doing justice to the actual collaborative nature of the work.

In any case, all schemes will have their drawbacks. What I propose now is to radically simplify it: take the (Circle) budget that was built up in the previous trimester and distribute it over the core team members, according to time commitments for the coming trimester of each core team member.

In a few words plus diagram, see here a simplified doc: https://cloud.meet.coop/f/6503

It also includes a time dedication summary of each person / org member in the setup period.

Of course we can still do the bounty system, but it would need more work than what is defined so far in the first proposal, here: https://cloud.meet.coop/f/5776

Please read both and comment and we can remix to whatever we find suitable.

But let the first version be simple :wink: and take it from there, iteratively.

2 Likes
34

I like the simplicity and low overhead nature of this. How I’d propose to operationalize this is map the commitments to roles. Taking Org Circle as example:

Role Budget Q4 2020 Q1 2021
Legal and organisational governance 0.2 ? ?
Operations (virtual office, internal processes and training) 0.2 Hypha ?
Financial bookkeeping and accounting 0.2 Platform 6 ?
Business strategy and planning 0.2 The Open Co-op ?
Membership and reseller management 0.2 ? ?

So we start with some initial value of budget as a % of Circle budget, and if we over time learn “Membership and reseller management” takes very little time, we can adjust the weight.

This is kind of like bounty, but at the role level instead of task level, which is essentially “category of tasks”. This is low overhead, and members can have more predictability about what they can bill at the end of each quarter. As Meet.coop, we have solid commitment on the essential tasks at the start of each quarter.

I think this can work as long as we do a good job defining the roles.

1 Like
35

Here is a quick update on what the Org circle proposes as part of the compensation framework that takes into consideration contributions at various phases:

  1. 2020 Q2 to Q3 Founding Phase – hours logged up to end-September will be considered Founding Hours.
  2. 2020 Q4 to 2021 Q4 Sweat Equity Phase – while this period will provide basic financial compensations as we grow the co-operative, we expect to not be able to pay a fair wage and therefore we will continue to track hours.
  3. 2022 Q1 onwards Fair Wage Phase – by Q1 of 2022, we hope to have a sustainable business that can provide fair wage to all workers, and also to repay the hours logged in previous two phases. It is possible that Founding Hours may be treated differently from hours logged in Phase 2.

In addition to this, we will be doing quarterly distribution of profits to members. The first one is expected to cover up to the period of 2020 Q3 and will happen in early October. We will also conclude our Founding Phase, so please make sure your hours are in time.meet.coop by September 23, before our last All Hands of Q3.

The process of distribution is being drafted by @wouter @osb across a couple documents in https://cloud.meet.coop/f/5774 and will be presented at the next All Hands.

1 Like
36

yes, thanks, Ben.

Please are members of Circles, do update your timesheets, so we can close the counts until Q3 :slight_smile:

37

If y’all wanna send me a few quid to cover the rent that would be a satisfying compensation framework for me!

2 Likes
38

Yeap, all of us actively engaged in the Circles do want that :wink:

As agreed in the All Hands two weeks ago, today we plan our first distribution meeting.
Please fill out a summary of the work done in the last Quarter (Q3) in the finance spreadsheet

I have recompiled all documents about the compensation framework in a latest update. That’s an intent to summarise how we got here and how we decided to come to this first version of the compensation framework. Further comments are welcome of course :slight_smile:

See you at 15h CEST in the main room!

2 Likes
39

What do we need to do to kick off the next round of compensation? :wink:
@benhylau do we have somewhere people can start submitting their ‘requests’?

40

What we decided at the final meeting of last year was I will prepare the spreadsheets for our Jan 8 Org meeting for review. Following that, at our first All Hands of this year on Jan 14 we will announce the revised process, and Jan 21 All Hands will be our distribution meeting. That’s what I remembered.

2 Likes