This agreement defines how root-systems handles money as a pod, specifically any funds collectively held in virtual accounts within any venture of Enspiral. Our goal is to make financial flows to and from the pod as transparent as possible and in a manner that allows for members to have a balance of security, flexibility and opportunity in how much remuneration they receive.
One month pay = base salary + ($500 x buffer level) + ((charge out rate x (buffer level x 5)%) x billable hours)
This is the monthly amount a core member will always receive, no matter what number of hours they work.
The buffer is what enables us to provide security to members, it is cash in the bank. It smooths out the feast-famine cycle that comes with doing contract/project based work. A unit of buffer is the sum of how much we take out of the pod as remuneration in a month. In general the more buffer we have the less we need to focus on making money.
Our buffer target is 4 months worth of our collective remuneration. To break this into scale we have 5 states/levels:
- Level 0 = We have less than 1 month worth of employees base salary in the bank.
- Level 1 = We have 1 month worth of employees base salary in the bank.
- Level 2 = We have 2 months worth of employees base salary in the bank.
- Level 3 = We have 3 months worth of employees base salary in the bank.
- Level 4 = We have 4 months worth of employees base salary in the bank.
How much a member costs per hour to the client.
The number of hours a member was billable in a month.
Moving up or down the scale is seen as an event which will have side effects. Side effects may be defined in other agreements and/or commitments. Buffer transitions should be recorded in a commitment detailing the side-effects in a migration style format. Side-effects should have links to any pertaining information. eg:
## Buffer 1 ### Up - [side effects that occur when buffer moves to a level 2 buffer]( ). ### Down - [side effects that occur when buffer 1is moving down to no buffer]( ).
By coupling several factors to buffer events we can create a self regulating system. The intent is that as the buffer increases so to does the money flowing away from the pod. These are the scaling money outflows and do not include fixed costs such as space hire and saas tools.
The pods funds come from the following sources:
We sell our time to work as directed - often augmenting an existing team. We charge by the hour.
We manage and deliver a project that is extending/refining an existing code base. May be charged by the hour or by negotiated value.
We manage and deliver a project with a new code base.
Typically a days work these are tools we use to deepen our and the client's understanding of the requirements.
A fixed monthly sum paying for us to update, refactor and slowly develop the code base.
We get paid a subscription for a hosted service we provide.
Money flowing away from the pod happens as follows
Paying for our operation cost has the highest priority and happens before paying individuals.
The base remuneration is a fixed sum that all members receive. It can go up as buffer levels are developed. It has the second highest priority.
An income share can be agreed to be given to an individual member as a means of topping up their base income. The income share is between 0-20% (buffer level dependant) of the billable rate multiplied by the hours worked - unless agreed otherwise. An income share can also be agreed internally between members by unanimous agreement.
Contribution to the common is done as a percentage of total revenue of the pod/manth. Unless agreed otherwise this is a scaling amount of between 0-20% depending on the buffer level.
Contribution to other pods is done as a percentage of total revenue of the pod/month.
Paying for contractors by the hour.
Invoices are sent out as soon as possible to the customers via xero.
A cashflow report is published at the end of each month.