Single global dev team: integration process, rules to be certified (and thus paid), and rates

International Processes
1

[WARNING: we start this conversation on the dev type of contributors as for now we only have money to pay for the dev roles on the global product team, but the conversation will need to be held for all contributors of the global product team.]

During the Melbourne 2017 gathering, we have deeply reviewed the way we work as a global team around our common platform. One of the outcome of this gathering is our common will to switch from local dev teams/pipeline to a single roadmap/pipeline and as a consequence, a single dev team.

Here is a first proposal from my understanding of what we came up with, as a start to reach an agreed upon process.

1- The integration process

a- New contributors

When a new dev is interested by the project, the first step, before they can be paid for his contribution, is to start contributing on a volunteer basis. The purpose of this is:

  • to enable the dev to understand from inside what it is to work on OFN and see if that’s what they wants
  • to enable them to get to a point where they can start to create real value for the project (which would justify being paid)
  • to enable the rest of the dev team to gauge if skills fit to what the project need, in term both of technical (coding abilities) and social (communication abilities) skills.
    So any new dev need to start picking some issues and committing some first PRs.

b- Certified regular contributors

After that, a developer who wants to be paid in order to be able to really invest time on the project can request to be certified. When they are, they will be able to invoice contributions.
To be certified, the dev must meet three conditions:

  • Have the tech skills required in order to make sure that they deliver real value for the time paid for. The other devs can gauge that based on the first contributions of the dev. If they think some important tech skills are missing, they can orient the dev to some issues where they will be able to learn the missing crucial skills.
  • Have the communication skills required in order to make sure no paid time in inefficiencies due to lack of communication, and ensure a global consistency of the team and processes. That means he has to be part of the Slack conversations in the #dev channel, reply to questions on GH, give feedbacks and review to contributors, ask questions as soon as something is not clear to get a consent with other devs on how to solve an issue, participate to speccing sessions, etc.
  • Dedicate at least one full day per week on the project, in order to make sure that the certified devs are commited and engaged, and that if they take an issue they are going to deliver quickly and don’t block the processes. It doesn’t have to be every week the same day, and can be like 2 half days.

c- Certified occasional contributors

For now, the project really needs committed and engaged developers, but on some issues occasional contributions can also help to make things move faster. So in case this is needed, devs who have both the tech and communication skills but can’t commit to a regular contribution basis can request to be certified as occasinal contributors and be paid for their contributions. In that case, they will be offered by the global product team to take some specific issues and will be paid for those contributions. Any other contribution they make on their own initiative will be considered as volunteer contributions.

2- The rates for certified contributors

The philosophy behind the redistribution process is that the value generated by the project should be distributed fairly to those who contributed to create the value. Inspired by the contributive/value accounting, our aim is to set up a retribution system that is not “equal” but “fair” and take into account:

  • the difference of value created by an OFN junior or senior dev in one hour. For that we are inspired by the Japanese “ShuHaRi” experience level system. “Shu” is a beginner, “Ha” intermediate and “Ri” master. Those are level in mastering an art. It seems fair that a “Shu” is not paid as much as a “Ri” as with the same time spent, the “Ri” will create more value for the project than a “Shu”.
  • the cost of living of contributors. It is not fair that a dev who live in a very expensive city is paid the same as a dev working in a small countryside where rents are much cheaper for instance. Or devs in India and Australia.
    I suggest on that point to use the cost of living index. This is given by country, but it is also possible to compare between cities.
    I suggest we stick to three cost of living categories to start with and iterate on the first cases.

A first discussion were held on the topic here
I updates the rates table with a Shuhari tab and a first propoal as a base for discussion. We will need people from those different catergories to see if that seems fair. Here is what it could look like:

Questions to be discussed:

  • as there is no local dev team anymore, the dev should invoice directly whoever has the money and is paying. Or can a local instance invoice for some dev work by a local team? I would find that contradictory, no? For instance until now when Matt has worked for OFFrance issues OFN UK were invoicing OFFrance so adding up some instance fee on top of Matt’s rate. But now there is not anymore OFFrance paying for some specific work, but a global pipeline, I think there should be no fee added by any instance on those rates.
  • Should we talk of a day or hour rate? Hour seems fairer to me and avoid to play with legal day work in each country, like if it’s 6h in Scandinavia and 9 hour in India, it doesn’t seem fair that they are paid the same for a day of work.
  • How do we deal with conversation rates fluctuations? Do we have one reference money that we base our rate on? Or do we “lock” the rates in the different currencies used and try as much as possible to pay in the same currency zone? I woud vote for that actually.

Ping @Kirsten @serenity @lin_d_hop @NickWeir @tschumilas @enricostn @sauloperez @Rachel @oeoeaio @maikel @danielle
@sreeharsha it would be great to have your feedback on fair rates in a country like India, I googled it but have no insights on it.

2

Sorry that I don’t have time to reply fully right now. I think a lot of the above is good. My concern is that this description of certified developers would exclude Matt, Keir, Susana and Steve ie all the UK developers. All have done great work and I want to support their continued involvement in the project. Thus excluding ‘punctual’ developers (to me punctual implies ‘on time’. Perhaps we mean ‘occasional’?) does not seem like a wise approach to me given our shortages of developers?

At the very least we should include a definition that works for Matt. He is far too good. Susana, Keir and Steve have all been more occasional and are less committed to OFN due to other commitments so maybe we need to consider a definition of occasional developer and approach to them that is more inclusive?

1 Like
3

We don’t have any devs in Canada - but I like an approach that structures their engagement like this. It means when people are interested in developing with OFN, I know what to tell them about how it works…

I also think this process needs to be more inclusive of occasional developers though - it seems to me that a lot of the contributions to OFN so far have been from people working/volunteering occasionally. So I’d like to be inclusive of them. BUT, I also understand that there is a limit to how many people can be working on this efficiently and more people is not necessarily better. But, I think we should at least have a way to keep people who are currently doing development engaged and involved. So I support what @lin_d_hop is saying here. Maybe we don’t encourage new occasional develolpers, but we need to be inclusive of people currently engaged.

4

On the point of invoicing directly: I think it would be very inefficient regarding international transfers and complicated legally. If I want to be employed by OFN Australia, I have to get paid by them including taxes and super contributions and holiday pay. I don’t think our development model should interfere with our legal structures.

5

Thanks for your feedbacks! I agree basically with all of you.
@lin_d_hop , “occasionnal” works better I guess, my bad, I changed it.
For me Matt would be a “certified regular contributor”, no? He is tech good, he communicates (I see him comment on GitHub, Slack, etc.) and he seems to work pretty regularly, no? Doesn’t he work at least one day per week? One full day could be two half days, but I think it’s important that the team know when regular contributors are working or not, so that they can work simultaneously, no?
And for occasionnal dev in UK, don’t they work on issues you ask them to work on? In that case for me they enter the definition we gave above, no? Saying our intention is to have more regular than occasionnal dev doesn’t exclude that we can have occasionnal devs. But we also need to be conscious that we collectively might not have the budget to both secure regular/committed dev and pay for lots of occasional contributions…
But anyway, please feel free to rephrase if you feel it doesn’t reflect all that properly, I made the thread a wiki. I’ll try to rephrase a bit now.

@maikel I get your point, but then we should agree that those rates are what is invoiced whoever invoice (an OFN instance for a dev or a dev himself) else we would have discrepencies, like if the global money is in Aus and OFN Aus pay you the cost will be lower than if the global money is in France and we pay you if OFN Aus add structure costs. If France allocates 40K to finance the global pipeline, I don’t think it would be fair that local instances take a margin in devs cost, it’s not subcontracting anymore here, it’s not OFN Aus doing job for OFFrance.

6

@lin_d_hop do we agree that certified occasional devs are paid only for issues they are asked to work on (like things that will be in the delivery backlog basically)? Like if they decide to work on some non prioritized bug they won’t be paid? Or should we just say that if they are certified occasional dev, when they decide to work on something, whatever GH issue they take, they are paid for that?

7

I think the threshold here is the certification, i.e. the acceptance of a person from the community. Once a person is accepted they should be payed I think, occasional or regular. The community should have the possibility to “de-certify” a person as well if they’ve been inactive for X months.

People are in different life situations and I don’t think enforcing regularity is the most motivating, but we shall of course say that we encourage it. For the devs to have a clear view of who’s working when could rather be solved by having a calendar (or something) where everyone tries to fill out two weeks or a month ahead the days/hours they will be available for OFN.

1 Like
8

I think I see the issue here - one question is about the compensation a developer receives (ie - hourly rates based on skill level and costs of living in their area as you describe above). But there is another issue about whether the dev is an ‘employee’ (of an instance, or it could be of a dev firm perhaps) or a ‘freelancer’. If a dev is an employee, than there are additional aspects to their compensation ‘package’ - are any deductions take from their salary? (ie: in Canada, pensions, health deductions… would be mandatory for employees), do they receive vacations or payment in lieu of vacations? - are there expectations of the employer beyond the OFN coding (ie: do they attend team meetings, participate in other employer activities…) So - we maybe need to develop processes that give both options - a. the deve is an employee, and b. the dev is an independent freelancer (consultant). People in different life circumstances would choose what works best for them, given the tax situation in their country.

From the point of view of a ‘funder’ - ie, if OFN-CAN has money to pay for a global developer - then I think I just need to know 1. which of our developers is best suited for the project, and 2. what the cost is. It might be that it costs me more if the ‘best’ developer for the project is an employee somewhere (an instance or other), and that employer has some costs beyond the straight wages paid. I think thats fair - its the total ‘cost’ of that developer (their time, the cost of the support the organization gives them, the cost of their recruitment and support in a team - like an office…The costs are more than wages.)

9

I think you are right to point out @MyriamBoure that we need, as a global instance, to prioritize work. (That is, in my view, one of the key advantages of a global instance in the first place.) If there are developers who are ‘freelancers’ - and thus, they don’t report to an instance or employer (instance or other), then somehow we need to link them to an entity/individual? who ‘directs’ their work/priorities that we are paying for. In other words - someone who ‘authorizes’ that x amount of work/hours will be compensated. Otherwise - we could end up with some really bad relations where someone just assumes they were going to be paid and then weren’t.

10

@tschumilas that’s not exactly what I am saying, but maybe I was not clear :wink:

  • the question is that the rate we agree on to pay for “dev work for the gobal roadmap” should be invoiced to whoever is paying for it, nothing should be added to that. So if OFFrance pays for Matt’s work on the global roadmap for instance, either Matt invoice directly France as he is a freelancer so doesn’t make any sense to add OFN UK as a middleman. If OFFrance pays for Maikel’s work on the global roadmap and Maikel is employed by OFN Aus, then OFN Aus would invoice OFFrance, but with the same rate that we agreed upon.
  • the rate OFN Aus discussed with Maikel (which we use as a base for the “Ri” rate) was calculated to include holidays etc if I understood well so there shouldn’t be anything added on top of that by OFN Aus whe invoicing OFFrance… structure costs for me apply only if we talk about subcontracting, like in the case where OFFrance pays for Maikel’s time to fix the French servers for instance.
  • freelancers usually are paid more than employees because they don’t have any paid vacation, social portection, etc. So if the 61AUD/hour calculated by OFN Aus includes that it seems like a fare wage both for employees and freelancers then. I guess it’s not exactly what Maikel is going to be paid for per hour, it’s what OFN Aus would charge for Maikel’s hour work, so that they can pay for Maikel monthly salary, paid hollidays, social protection, etc. Am I right @maikel @Kirsten?
  • In the new process we have set up developers don’t “report” to any specific instance or employer, they report to the global product team (POs, TD and other devs). So the paid dev should only take issues that have been prioritize by the product cureation team and specified.
11

@sigmundpetersen I really like your proposal and the way you phrase it :slight_smile: Feel free to update the proposal to make what you say clearer, it’s a wiki.

12

I think we agree @MyriamBoure - I just didn’t understand that when a dev is an ‘employee’ , that these additional costs (employee costs like vacation…) are already in the rates you presented above… Whether the ARE already in the rate or not – I’m saying they are legitimate costs of doing business, and should be included in the invoice to the payer. (Indeed, they should be broken out on the invoice as ‘overhead’ or something like that, so that the payer is very clear.) Then, for a dev who takes both roles - sometimes working as an employee of an instance, and sometimes working as an independent freelancer - the per hour invoice amount will be different for the same individual - that’s ok - we just need things to be fully transparent and both the devleoper and the payer see that.

13

Once we hash this out - we could do an invoice template maybe - with an ‘instruction’ sheet that makes all this clear. (Likely you’ve already thought of that - but it just popped into my head.)

14

I agree that an instance should not just add some random margin on top of rates to make profit. But I think it’s just a matter how it’s structured and communicated. When I do a dev task for France, it’s not just me. There are Kirsten, Danni, Sally and so on helping me. As far as I understand it, OFN Aus uses that margin to cover management and infrastructure costs. I’m also using the office from time to time. So the question is if we invoice all these things separately or if we bundle it in a fix margin. Or do I have to pay to use the office?

The current setup is very easy for me. I just invoice OFN Aus and they sort out the rest. And I don’t think we are wasting money. But maybe it has to be more transparent, like in the OFN we can see every fee that is put on top of the money the farmer receives. I definitely want a fair way of paying everybody.

That’s just my perspective and I have not been heavily involved in previous discussions around all this money stuff.

15

I will find the time to think through and reply properly to this in the next week. I agree with @maikel that the overhead for people invoicing to all the different instances is very high - not just the invoicing but because often the international funds transfer is annoying. Also for instances like Aus and I think UK, we are trying to give some people at least more consistency, and we have overheads, and we want to be able to gather funds together from different pools to provide that certainty of income e.g. we make the commitment to provide full/part-time work. This is important to us, and for retaining good people, and for enabling them to commit to OFN as their real, not ‘occasional’ job

16

Maybe we can determine this and do it globally instead of nationally, I think that is a possibility. I just need some time to go through the numbers and think about it. Will do as soon as I can

17

Actually then I think we need to agree on a rate that include the structure cost, so for instance add 10% to the rates above. So if the amount are invoiced by an instance that has overhead cost those are covered, and if a freelancer invoice directly he earn a bit more which is fair as he supports himself his paid holidays, he does himself the paperwork, etc. Freelancers should always earn more than employees as they don’t have the security, some months they don’t have any job, they have to pay themselves their professional tax, their holiday, social insurance, etc.
BUT I strongly disagree with including other time like the one of Danny/Sally etc in these structure cost as those people are supposed also to be paid for at the same rate!!! We said we can’t afford to start with to pay for the global product team non-dev (we can discuss again of course) but what we said is that ideally we want to pay all the contributor of each OFN day work (1dev, 1/3 test, 1/3 ux, 2/3 PO+TD) and all those people then should be charged for at the rate we decide together, whoever invoice that.

18

An image always talks better, so here to illustrate my point about “the amount invoiced should be the same”
Sorry Maikel I’m sure you love ginny pigs :innocent:

Screenshot from 2018-01-25 12-11-49.png880×415 57.3 KB

I could have done that with Sally or anyone else of course :wink:

19

BUT I strongly disagree with including other time like the one of Danny/Sally etc in these structure cost as those people are supposed also to be paid for at the same rate!!! We said we can’t afford to start with to pay for the global product team non-dev (we can discuss again of course)

I also agree, and again, I would like to include non-dev roles although that might mean lower rates for everyone. I really don’t like the privilege devs are given; every one of us is key to the success of OFN.

20

@MyriamBoure agreed. We already work that way in uk