Post edited 1:25 pm – September 2, 2010 by wspademan
Here's my proposal for IT compensation. After this discussion, I hope to generalize this policy for Common Good Finance as a whole. Every point here is open to debate. (In particular, my view of salary amounts may be wildly distorted because my family and I have lived intentionally below the poverty line for a couple decades.)
Goals and Constraints
A. Primary Goal. The Common Good Bank System will have the software and hardware it needs, in time for the bank to open in autumn 2011.
B. Maintaining the Integrity of the Primary Goal. The Common Good Bank model will not be subverted or diminished by the means we use to launch it. In particular, our system of compensation for engineers (and others working to establish the Common Good Bank System) will not make the Common Good Bank System itself less egalitarian, will not make Common Good Bank stock less fungible, and will not cause the Common Good Bank System to reward ownership (The Common Good Bank System is designed to be a nonprofit business that rewards only labor.)
C. Control. Common Good Finance (the nonprofit organization component of the Common Good Bank System) will have ultimate oversight of IT planning and development — both before and after the bank opens.
D. Collegial Collaboration. As much as possible, we want work on the Common Good Bank project to be a collaborative effort among peers, rather than a dictatorial hierarchy of bosses and employees.
E. Range of Compensation Options. In order to attract participation by highly competent specialists with diverse needs for compensation, we want to offer a variety of compensation options. In particular, we want to include among those options: immediate pay, near future pay, and stock.
F. Financial Constraints. All compensation must come from somewhere: ultimately either from gifts to the project or from the bank's earned income. The less gift money we spend, the easier it will be to raise it (and therefore the more likely the project's success). The less we spend of the bank's future earnings, the sounder and more fungible the bank's stock will be (and therefore the more likely the bank's success).
G. Legal and Regulatory Restrictions. SEC regulations make a pre-charter public offering prohibitively expensive (leaving us two options: a private offering or NO offering). Bank regulators require evidence of substantial investment before a charter application. Private offerings cannot be publicized and generally only accredited investors are eligible. State banking regulators prohibit us from accepting donations from the public to "start a bank".
H. Time Constraints. For a variety of reasons, we need to get the Common Good Bank System up and running as soon as possible, ideally by October 1, 2011. Therefore we want to start work immediately, even if immediate compensation and formal stock options are not yet possible.
I. Effectiveness and Efficiency. Within these goals and constraints, we want to choose the shortest and surest path to our primary goal, taking care however that the means be never so foul that the ends fail to justify them.
Context
J. Membership Campaign. Over the past six months, Common Good Finance has designed an exciting membership campaign that we plan to launch in October. This campaign will fund all three stages of the Common Good Bank project at once and obviates any need for a private offering. In effect, it allows us to publicize and accept investments from the general public, by structuring those investments as "forgivable loans" to Common Good Finance. Common Good Finance then becomes a community loan fund, which will ultimately invest those funds in a Common Good-type bank startup. This plan will also save about $100k in legal costs.
Assumptions:
We can finish what we need, to be able to open, in 12 months or less.
Common Good Finance should expect to pay up to $800,000 for IT planning and development.
We can realistically expect to do this with the equivalent of (at most)10 full-time engineers and support personnel, paid an average of (at most) $80k a year (for example, two each at $120k, $100k, $80k, $60k, and $40k). This presumes that most people will be willing to work for about half (or less) what they could get elsewhere, just because they want to work on THIS.
Policy (proposed):
All members of the IT team will be volunteers and/or independent contractors.
If Common Good Finance were hiring people as employees, we would pay everyone at least $15/hour. This formal recognition that $15/hour is a minimal living wage will influence our collective expectations of each other.
We will try to find (only) people who will work for $60/hour or less ($120k/year, annualized) and will pay more than that only if we have to (presumably because the people we want will not work for less).
The IT team will have a strong say in choosing who is hired and for how many hours a week, how valuable each person's work is to the project (and therefore what their maximum nominal hourly rate is), who can commit code, quarterly evaluations, who leads what, and how the group collaborates. Years of experience in IT will be an important consideration in how each contractor's work is valued, initially.
Each contractor will choose their own hourly rate, limited by a maximum set by the IT team (as described above). If their chosen rate is lower than the maximum, then any difference between the two will be recognized (gratefully!) as a donation to Common Good Finance.
Since Common Good Finance will have essentially no funds until we launch our membership campaign in October, contractors will need to choose how much pay to accept as stock and how much to accept as shorter-term delayed compensation (presumably by the end of the year). Either way, the contractor's work is an INVESTMENT in the project. There is no guarantee that money will come in — either in the short term or in the long term, until we succeed.
Once the membership campaign is well along and we have sufficient funds in hand, no "delayed compensation" will be necessary, so new contractors coming in after that time will choose how much pay to accept as stock and how much to accept as immediate compensation.
We will encourage contractors to accept as much of their pay as stock rather than as immediate or delayed compensation. Every dollar of pay accepted as stock reduces by one dollar the amount of donations and "high risk" capital that Common Good Finance must raise.
The amount that contractors can receive as immediate or delayed compensation is limited to $30/hour ($60k/year, annualized). The remainder, if any, must be accepted as stock.
We want contractors to be able to get paid fully as soon as possible — in particular, before financial investors can recover THEIR investment. However, we want to avoid creating separate classes of stock in Common Good Bank. Instead, for pay that contractors choose to accept as stock, Common Good Finance will aggregate those amounts as a collection of loans from the contractors to Common Good Finance. The loan terms will be essentially identical to the terms for stock in Common Good Bank. Common Good Finance will then receive stock in Common Good Bank, in recognition of its (the IT team's) contributions. This will allow Common Good Finance to pay the contractors with highest priority, before the financial investors can recover their investments. In effect, "stockholders" who WORK for their stock get to sell their stock first. We expect this to happen within a year after the bank opens.
I don't know too much about compensation because, truthfully, I've never been employed full time. I've been told that salary is important and that benefits make up 1/3 of the value of a salary.
Life can be expensive, so I understand that. Personally, I'm looking for work that is part of the kind of social change I'd like to see in the world. For this to be truly sustainable, thishis work can sustain me as well. That would be much more fun than simply taking a 9to5 that pays well and then putting that money into social change. It'd be much more fun because my work would be part of that social change.
I'd like to be paid a fair market value (or something close to it) because then I won't be sacrificing the contribution money can make to community programs.
As to specific pay, I'd look to salary.com with searches of "Computer programmer" and "Software Engineer". This is 60-70k for level 1, 80-100k for level 3 and 100-130k for level 5.
I like the idea of MOU contracts because that would give me reassurance in putting in my time. I assume other participants would like it too.
As Arkmundi calls attention to the value of "good employment", I think it's important to include those benefits that come with typical employment elsewhere. Usually this isn't associated with workers that are identified as "contractors".
Similarly, the ESOP sounds like a good idea, though I did not like Arkmundi's use of the word "absurdity." I am now particularly curious to understand a bit more about the "reward labor not ownership" idea. 1) Because I suppose that risking one's money might also deserve reward and 2) Because won't the shareholders be owners?
Thank you and I apologize. As your comments have made clear, we need to back up a step and agree first on some goals and criteria for IT Compensation Policy. I have added a proposal for those as a separate section in the policy proposal. I also inserted a "context" paragraph about our planned membership campaign, that addresses the most difficult constraints surprisingly well.
Post edited 9:22 pm – August 31, 2010 by wspademan
Hello Everyone,
Why the hesitancy to go with ESOP model? I like many of arkmundi's points… (I see in later posts its because this option is only available for employees…?)
Johnathan makes a good point:
I think 10 programmers seems like a lot to start with and there are plenty of programmers that are willing to work for much less than you are suggesting.
I think arkmundi's comment deserves discussion amongst the team/board/etc.:
My intuition informs me that the primary investment is in an Internet-only bank. Hence, the time invested on the part of the CGB-IT team is primary, as in first. Attracting the necessary capital as a bank will be made easier for having proof of innovation in hand.
And another astute comment:
On an individual-by-individual MOU negotiated basis.
You want to make a policy, but it's getting a bit too specific since you, yourself, are hoping that at least some of the IT team will donate hours or voluntary request a reduction in pay.
And arkmundi speaks to what I initially felt when reading the proposal:
Sell-able stock would require in my mind, a public offering, SEC oversight and a whole bang-doodle of additional complication.
But I don't know enough about ESOP and the such to give an educated response.
And he also speaks to what I would really like to know — where is the IT team on this?:
I have consistently recommended that the CGB IT Plan endorse a join-and-contribute approach to open-source software utilization. That approach suggests making use of existing open-source software to the maximum degree possible, rather than starting a new code base from scratch.
William Spademan writes:
"the Articles of Incorporation should show two classes of stock…" — This is unnecessary and counter to an egalitarian spirit.
Can you explain further?
There are too many moving components/variables in this project to be an Idelist/Purist. I grow wary when I hear statements like this:
In an ideal society, as long as everyone gets at least a living wage, no matter how deserving a person is, there should be a pretty low maximum wage…
If there were one piece of advice I could cement into the heads of the leaders of economic and monetary reform, it is this: don't be an Idealist/Purist and don't develop policies with that mindset. It lacks systems thinking.
There are more ideas to discuss and fine-tune. I look forward to our call tomorrow morning.
AMERICA BEYOND CAPITALISM: THE PLURALIST COMMONWEALTH; by Gar Alperovitz, Lionel R. Bauman Professor of Political Economy, University of Marylan; http://neweconomicsinstitute.o…..ummary.pdf
Most important are enterprises that are practical, anchored locally, and which either alter inequality directly or use profits for public or quasi-public purposes (or both). Employee-owned firms, co-ops, neighborhood-owned corporations, and a wide range of municipal and social enterprises, along with municipal and state investing agencies, are among the key locally based institutions of the “Pluralist Commonwealth” articulated in ABC.
That individuals work harder, better, and with greater enthusiasm when they have a direct interest in the outcome is self-evident. The obvious question is: why aren’t large numbers of businesses organized on this principle? The answer is: roughly 10,000 are. Indeed, 11.2 million Americans now work in firms that are partly or wholly-owned by the employees, three million more than are members of unions in the private sector (Bureau of Labor Statistics 2008, Table 3; National Center for Employee Ownership 2008).
Although there are 300-500 traditional worker co-ops, most worker-owned businesses are organized through “Employee Stock Ownership Plans” (ESOPs). Technically an ESOP involves a “Trust” which receives and holds stock in a given corporation on behalf of its employees.
In Ohio a survey completed in the mid-1990s found that employee ownership was becoming more democratic over time, with three times as many closely held companies passing through full voting rights to ESOP participants as had occurred in a previous 1985-86 survey (Business Week 1991, Logue and Yates 2001).
Most Americans have been taught to think of social ownership as inherently inefficient, undemocratic, even tyrannical. In the near term, the various practical efforts the book reports upon may be as important for what they teach about possibilities as what they accomplish in altering major trends. In this sense they are both precedents and instruments of popular education which help teach the practicality and common-sense nature of new principles. They may also slowly help build and nourish a larger community-building and more cooperative culture. ABC stresses that the fiscal crisis, on the one hand, and globalization, on the other, are forcing ever greater attention to neighborhood, municipal and other forms of enterprise which produce income flows for services—and to employee-owned firms and other institutions which anchor jobs in local communities threatened by global trade disruption.
It doesn't matter whether you call us employees or contractors – the difference is the same. That difference is hiring someone to do a specific job, presuming you know what that job is, can describe it, know what the competencies are for its performance, can find-hire-pay good people, have some measure for success and an ability to fairly evaluate the jobbers. What I propose is a completely different model, the one which is prevalent in the open-source community, and so with substantive proof of real-world validity.
That model recognizes the necessity of granting the greatest degree of freedom to developers, because the essential act is an act of creation. There is now ample proof of the exceedingly good results to be had when creative software development work is performed with such freedom and openness. Free & open is also a human culture. Team building and team playing require as much emotional intelligence as they do technical smarts. I could go on and on in this vein. The key proposal is CGB-IT as open-source project, with all that brings, and its a great deal.
If you can see that basic assumption as fundamentally valid, then the next step is to address the concerns expressed in this thread for fair compensation. All sustainable open-source projects have a commercial component, for the obvious reasons. There are various ways of doing that have been tried and proven to be successful.
I have laid out the alternative which I believe works best for both the CGB effort as a whole and the necessity to build a competent CGB-IT team that has a meaningful chance at success. And yes, with myself as a member of that team. That alternative is team as key stakeholder in future revenue, hence shares. Those are protected shares using an ESOP plan. There are obvious incentives at play. You say:
Yes, will will want to compensate labor with stock, at this stage when we have no cash. But Common Good Finance Corporation will not have any employees (just independent contractors), so our stock compensation plan will not be an actual ESOP.
The question is who then owns the bank and has a share in banking decisions and banking revenue? To suggest that the CGB will not have any employees, no ESOP and hence no means to provide the advance guarantees that come with such formalities, is to suggest a plan that I can have little faith in. ESOP's raise the status of employees to that of co-owners, and effectively eliminates that age-old dichotomies of capital vs labor, management vs employee, etc..
The suggestions I have made, expecially with respect to a specific employee-owned class of stock, are not individual-by-individual. Its for a block of stock owned in common by the CGB-IT team. It suggests for instance $10m in capital shares plus $1m in employee shares. The CGB-IT team must then work diligently and competently to deliver, as a whole. The parity I've suggested also doesn't presume in advance what the individual's share in the common block would be.
The absurdity of your suggestions to eliminate ESOP considerations are further punctuated by the fact that banking for the common good in very large measure must be about good employment:
That vision calls for such concepts as social justice, fair trade, equity, full employment, decent work, living wages and other matters pertaining to the human dimension of our shared endeavor.
How is it possible to derive "common good" from bad practice? Hence, we are at an impasse.
Post edited 10:46 pm – August 30, 2010 by wspademan
Jonathan Sandberg says (by email):
My suggestion would be to first identify a technology manager to orchestrate the project using subcontractors. Begin with developing a UI (User Interface) Mockup then proceed with the programming. I would start out on the cheap with minimalistic core functions then add additional functionality over time. Without spending a lot of time on the analysis, my hunch is that $250-$500k would be an attainable total budget for the project…I anticipate work could begin immediately and inexpensively at $10-$12k per month plus minimal expenses.
I think 10 programmers seems like a lot to start with and there are plenty of programmers that are willing to work for much less than you are suggesting.
From a project management standpoint, I would concentrate on that mock up of the UI as something to use for fundraising, PR, advertising, etc. I might consider starting with a Drupal platform for the UI and CMS then proceed with development of custom modules to implement whatever specialized security protocols are needed.
One feature of using Drupal as a platform is its ability to manage multi-sites which I think might be important for banks with "branches":
"One feature I should point you to is multi-site: you'll be able to handle all those banks under the same Drupal installation (but not necessarily using the same database"
Depending on your current funding this could be started immediately with just a Project manager, designer and one or two engineers.
Thanks Richard, I have clarified a few things in response to your comments (especially #3, 5, 6, and 10, as shown in green). I would like to wait for others to weigh in before responding.
1. We can finish what we need, to be able to open, in 12 months or less.
You know that's very ambitious. It will take as long as it takes to bring the necessary human & capital resources into the project. As a "project" it will require good management practice, the expertise of which is to keep all things balanced, including time-frames. The emphasis early-on should be on that – the necessary expertise.
2. Common Good Finance should expect to pay up to $800,000 for IT planning and development.
Again, it will take what it will take and its too soon to set such targets. $800K as a target may be too high or it may be too low.
3. We can realistically expect to do this with the equivalent of 10 full-time engineers and support personnel, paid an average of $80k a year (for example, two each at $120k, $100k, $80k, $60k, and $40k). This presumes that most people will be willing to work for about half (or less) what they could get elsewhere, just because they want to work on THIS.
There you go again dictating policy rather than professing ignorance of the requirements. In fact, I could argue 10 is too many. Building good open-source IT teams takes a lot, and an investment into the skills of the people involved, a lot of mentoring, and team-playing. Like all good things, there is a "proper" time to maturity and it remains too early to say.
4. All members of the IT team will be volunteers and/or independent contractors.
Why should the members of the IT team not organize themselves more formally? Why not a Common Good Finance Corporation which is wholly and only an ESOP?
5. If Common Good Finance were hiring people as employees, we would pay everyone at least $15/hour.
Yes, that's my exact recommendation, some expectation of minimum pay plus stock options.
6. We will try to find people who will work for $60/hour or less ($120k/year, annualized).
That would be ideal, a middle ground for qualified Java EE/SOA software engineers.
7. The IT team will have a strong say in choosing who is hired and for how many hours a week, how valuable each person's work is to the project (and therefore what their maximum nominal hourly rate is), who can commit code, quarterly evaluations, who leads what, and how the group collaborates. Years of experience in IT will be an important consideration in how each contractor's work is valued, initially.
Its all about the relevant contributions, in final evaluation, that the code works, both technically and functionally, and for the team as a whole. I believe more in the equality or parity model, so as to eliminate such judgment calls, as the judgment will always be in hind-sight, and most often inadequate to the task.
8. Each contractor will choose their own hourly rate, limited by a maximum set by the IT team (as described above). If their chosen rate is lower than the maximum, then any difference between the two will be recognized (gratefully!) as a donation to Common Good Finance.
Again, presuming the independent contractor model for employment. I'm not saying that there won't be contractors, as they will likely be necessary. Its just not the first ask or the primary means for the CGB-IT team.
9. Since Common Good Finance will have essentially no funds until we launch our membership campaign in October, contractors will need to choose how much pay to accept as stock and how much to accept as shorter-term delayed compensation (presumably by the end of the year). Either way, the contractor's work is an INVESTMENT in the project. There is no guarantee that money will come in — either in the short term or in the long term, until we succeed.
My intuition informs me that the primary investment is in an Internet-only bank. Hence, the time invested on the part of the CGB-IT team is primary, as in first. Attracting the necessary capital as a bank will be made easier for having proof of innovation in hand.
10. Once the membership campaign is well along and we have sufficient funds in hand, contractors will choose how much pay to accept as stock and how much to accept as immediate compensation.
Yes, there should be flexibility within certain parameters. Waiting for "sufficient funds" however doesn't work for the code-first approach.
11. We will encourage contractors to accept as much of their pay as stock rather than as immediate or delayed compensation. Every dollar of pay accepted as stock reduces by one dollar the amount of donations that Common Good Finance must raise.
Again, I suggest the CGF as CGB-IT plan innovators and developers, not on a contract basis. There are other means than contracts, like the writing of MOU – memorandum of understanding. The core understanding is that someone works for xx hours for yy period of time, they will be compensated with dd dollars as base pay and ss in stock options, converted to stock upon successful launching of the entire banking operation.
12. The amount that contractors can receive as immediate or delayed compensation is limited to $30/hour ($60k/year, annualized). The remainder, if any, must be accepted as stock.
On an individual-by-individual MOU negotiated basis.
13. For pay that contractors choose to accept as stock, Common Good Finance will aggregate those amounts as a collection of loans from the contractors to Common Good Finance. The loan terms will be essentially identical to the terms for stock. Common Good Finance will then receive stock in Common Good Bank, in recognition of the IT team's contributions. This will allow Common Good Finance to pay the contractors with highest priority, before the financial investors can recover their investments. In effect, stockholders who WORK for their stock get to sell their stock first. We expect this to happen within a year after the bank opens.
There are too many assumptions here to adequately address. The primary concern is how skilled workers who opted for stock recover their investment of time as income. Sell-able stock would require in my mind, a public offering, SEC oversight and a whole bang-doodle of additional complication. Another approach is to keep it as a private offering, and that the stock be dividend paying stock. I again suggest, in two classes, one for capital investment and the other for worker investment, so as to treat these very different classes of investors with the due diligence required for each separately. Returns initially would be slow, but be expected to accelerate over time.
I have consistently recommended that the CGB IT Plan endorse a join-and-contribute approach to open-source software utilization. That approach suggests making use of existing open-source software to the maximum degree possible, rather than starting a new code base from scratch. If an open-source banking software project existed that spanned the entirety of operations as we envision it, then that one project would suffice. That's why we have invested our time primarily in researching the existence of such a project, or some reasonable facsimile, what we have described as "candidate" projects.
I have concluded that there is no one open-source banking software project, but continue to invite that possibility. There are, however, good "candidates," that include: mifos, cyclos and ERP systems jfire, kuali, opentaps, openbravo, and adiempere, among a long list of various projects provisionally deemed acceptable or not, for their functional and/or technical merits or demerits.
In other words, its not a matter of casually starting one more open-source project that fails because the effort can not be sustained. To succeed, the project must attract developers, on a number of key points. CGB-IT is a "project" one component of which is to be a sub-project of one or more other open-source projects. The CGB-IT project team must, hence make an early decision to adopt & develop, and that has the been my entire thrust since April. I'm suggesting that the CGB-IT team be a participant in, not an initiator of a project, at least at the start. At some latter point in time, it may make sense to "branch" our effort as a stem, like opentaps did from ofbiz, one of the Apache core projects. But certainly not at the outset.
The project, like all successful open-source projects, must prove itself to be financially viable in order to be sustainable – there must be income for project code contributors, because they have a way to leverage the code in their respective domains of activity.
The project must also be technically viable in terms of current usage. The web application development framework should for instance, be tending to greater usage, hence Java/Spring, and developers should have access to all the necessary resources for discovery and usage, including an IDE like Eclipse. Java, Spring, Eclipse, the Apache web are all themselves open-source projects. Leverage & reuse is very much part of the culture as a whole.
The project must be socially viable as well, as in inspiring and doing good. In that respect, the CGB project meets a primary criteria, at least in design. The chasm between design and actuality, however, is deep, and getting through will take a rugged spirit, and a team willing and able to make the trek. I believe the Common Good Bank project as an Internet-only bank is only partially viable. The challenge is to make it wholly viable, covering all bases. The income model for developers is a core concern. It must be made obvious and be acceptable to the players involved, early on, as like right now. Until that has been accomplished CGB will remain a fiction with its story relevant only to the imagination.
Post edited 7:02 am – August 30, 2010 by wspademan
Richard, thank you for getting us started on this crucial discussion. Mostly I agree with what you have proposed. However, (A) I have some disagreements and (B) there are some countervailing realities that must be considered.
A. Here are my disagreements:
4. so add in provisions for an ESOP – employee stock ownership plan
Yes, will will want to compensate labor with stock, at this stage when we have no cash. But Common Good Finance Corporation will not have any employees (just independent contractors), so our stock compensation plan will not be an actual ESOP.
5. the stock offered would be in the Common Good Finance Corporation. Stock would transfer to the Common Good Bank
Stock in Common Good Finance Corporation would be no better than a promise to start a bank. So we might as well just offer stock in Common Good Bank — as a promise, pre-charter; then as actual stock in the bank once it has a charter. If we can avoid Common Good Finance Corporation having any assets (doing everything instead through our nonprofit (doing business as "Common Good Finance" without the "Corporation"), then we will save at least $50,000 in auditing costs.
6. the Articles of Incorporation should show two classes of stock…
This is unnecessary and counter to an egalitarian spirit.
7. insure shares against share value dilution over time (for example through risk taking behaviours), by applying monetary penalties
If you mean monetary penalties to the corporation (or the bank), then this makes no sense, because the value of the corporation IS the value of the stock. If, on the other hand, you mean insuring the value of only the "time" shares, then again this would be counter to an egalitarian spirit.
10. provide additional stock to those assuming managerial roles (CEO, CTO, CFO, CMO, etc.).
I agree with this only if it is necessary pragmatically. In an ideal society, as long as everyone gets at least a living wage, no matter how deserving a person is, there should be a pretty low maximum wage and within that range (minimum to maximum) compensation should be based on supply and demand (what I am calling "pragmatics", but which can also serve to allocate popular jobs fairly).
B. Countervailing Realities. Common Good Finance currently has no assets, no prospects for a bank loan, no prospects for a loan from any alternative lender, and no success to date in securing grants. All we have is a great plan and thousands of individual supporters. Anything we pay or promise to pay people doing work at this stage has to come from somewhere. Someone has to donate or risk that money.
We plan to raise a certain amount of donations and a certain amount of captial (through forgivable loans from individuals). Once we set those amounts, those amounts will constrain how much we can spend on pre-opening labor. Our current plan is to raise $250,000 in donations and $1,250,000 in pre-opening capital, starting in October (one month from now) and finishing around the end of the year. Raising that much in a few months will be very very hard, but possible, I believe. More is harder and would take longer, making success proportionately less likely. We need to have confidence that the target amount will be enough and we need to make that call within the next couple weeks — before we launch our membership campaign.
We COULD create (either in fact or in effect) a separate company that would develop the software, make a big profit by leasing the software to Common Good Bank and other banks, and pay the developers and other investors a lot of money. However, (a) that doesn't feel quite right to me philosophically — I'm not quite sure why — and (b) creating a separate for-profit enterprise would, I believe, more than double the size of the IT effort, since the commercial nature of the software company would require a whole commercial infrastructure (separate from Common Good Finance and Common Good Bank). Feel free to argue this point.
The upshot of all this is that we cannot afford to pay ten or even five engineers $100 an hour each for a year, even though you and others working on Common Good Bank IT are worth more than that. (Note that we have to pay lawyers, bankers, government, administrators, and suppliers out of the same pool of capital.) As in most nonprofit work, we will need to ask people to work for less personal financial compensation than they could get working for the military industrial complex. Already we have many lawyers, bankers, fundraisers, and administrators working for less, little, or nothing.
I will draft a proposal (based on yours) that takes these realities into account and will post it here soon. Our compensation policy will need to be pretty simple and loose, because we are hiring independent contractors, not employees, so the workers will largely dictate the terms.
Post edited 8:39 am – August 29, 2010 by wspademan
Richard Kerver writes (by email):
We spoke Wednesday about various approaches for ensuring fair, equitable and delayed compensation for the people making the CGB vision a reality. That vision calls for such concepts as social justice, fair trade, equity, full employment, decent work, living wages and other matters pertaining to the human dimension of our shared endeavor.
I believe the time to get this right and to inject the necessary DNA into the organization is now. Our joint effort to attract high quality, hard working individuals, with the right skill sets is contingent upon having a compensation package in hand for services rendered.
I have thought long & hard, for many years about such issues, in this and other contexts. I have also voiced my concerns about these matters, since day one, both personally and as a representative of the class of all individuals who will work the bank into existence. We will succeed only to the degree we get it right. To use a Ghandian term, it's the law of Karma. And the debt of the many future beneficiaries of the CGB should be paid back, in abundance to those who made it happen.
I recommend an approach which will:
provide some base living wage throughout the development cycle, through loans, either from the capital development plan you've circulated, or commercial lending, or grants
by "living wage" I suggest at least $30,000 a year, which equates to roughly $15.00 an hour for full time work (40 hrs/wk for 50 weeks)
recognize that this wage is a minimum and will be insufficient to attract the people we need
so add in provisions for an ESOP – employee stock ownership plan
the stock offered would be in the Common Good Finance Corporation. Stock would transfer to the Common Good Bank
the Articles of Incorporation should show two classes of stock: 1> class A shares for investment dollars and 2> class B shares for investment time, with articles governing their issue and governance. The two classes of share ownership should be well balanced in value and recognize the equal importance of both the monetary and human resources required to bring the CGB into existence.
insure shares against share value dilution over time (for example through risk taking behaviours), by applying monetary penalties
value time shares at $100 an hour for technical workers, setting an annual base wage for these workers at $130,000
value extra-ordinary contributions to the development cycle through bonus stock, calculated at year-end through an employee peer evaluation process, timed in conjunction with the CGF having successfully completed its initial development cycle
provide additional stock to those assuming managerial roles (CEO, CTO, CFO, CMO, etc.).
I look forward to working out these details with you and other members of the functional steering committee.
print page
Login 
Register 
Search 
Home
Add a New Topic
Reply to Post
Quote and Reply 
Print this Post 
Topic RSS 
