Skip to content

Latest commit

 

History

History
579 lines (409 loc) · 55.2 KB

company.org

File metadata and controls

579 lines (409 loc) · 55.2 KB
Raw

Legalese, the Company

  • What organisational structure, governance model, and communication processes does Legalese use?
  • How does Legalese deal with contributions, cash, equity, and other expressions of finance?
  • What expectations can every project participant have about other participants?
  • In particular, what common vocabulary and knowledge should participants possess?

Discussion of this document is welcome on the #mgmt-organisation and #general chats.

Welcome, New Contributor! 🎊

You are here because someone requested that you be onboarded.

Onboarding consists of two parts: Initial Onboarding, and Role-Specific Onboarding.

Part 1: Initial Onboarding

This is the initial onboarding process that everyone has to go through. Unless otherwise specifically and publicly approved by the compensation committee, the completion of Initial Onboarding is a prerequisite for any discussions of compensation and/or a stake in our organisation. As we are a deep-tech, multi-disciplinary startup, the kind of problems we work on are not easily solved. We may decide in our discretion that you are not a good fit for the Company at the particular point of time, however, we do promise to communicate that to you and to give you a fair (in our opinion) chance.

You will need to walk the path, especially if you want committer access to the repository, or to potentially get paid.

The tasks to be fulfilled for initial onboarding are:-

  1. finish reading this document (a.k.a. company.org), and accept the terms of engagement
  2. finish reading the Welcome Booklet (and the readings set out therein)
    • The Welcome Booklet PDF explains why we exist. It also sets out a reading list which will help you come up to speed with the state of the art in legal informatics. Read it, and the readings in it. (At some point we will move the text of that PDF into this file.)
    • In a traditional organization, a new hire might spend a couple of weeks, even a couple of months, in training. If McDonalds can have a university, we can have some amount of training. In the software world, we think of training as READMEs, FAQs, docs, and onboarding videos.
    • The work we do is harder than flipping burgers, so it will take you longer to read all the books. It often takes up to a year for a new contributor to be fully onboarded. Books take time to read.
  3. sign the Contributor License Agreement
  4. read and familiarise yourself with the content on our website, our terms of use, privacy policy, and Code of Conduct; and
  5. demonstrate literacy (reading and writing) and share your core competence with the team.

Any exceptions to the above must be specifically approved and sponsored by at least 1 cofounder, and one team lead in the Company.

Part 2: Problem-specific / Role-specific Onboarding

This part will be continuous and ongoing throughout your lifetime with us. As you might have gathered from the name, the pre-requisites under this onboarding arm will vary according to problems and/or roles that you wish to take on.

Legalese is a big project, on the scale of a database language (like SQL) plus a database engine (like InnoDB). While it is possible to make useful contributions quickly, the more challenging parts of the project require you to come up to speed on some of the underlying ideas and technologies.

Before working on any existing issue, please follow these steps:-

  • check our existing issues on Github to see if anyone is already working on it –> these people will be part of the relevant roles that you will need blessing from
  • ensure that you have satisfied the pre-requisites to undertake the issue (if you’re unsure what these are, check with the team on Slack)
  • go to all relevant circles and nominate yourself (if you don’t know which circles might be involved, ask on Slack)
  • get positive public confirmation from the relevant circles, roles, and current assignees on Slack that you can proceed with the issue

PLEASE REMEMBER THAT unless you have the compensation committee’s written and public approval (i.e. on Slack, a legalese-domained email, or in a validly executed contract) on compensation, no financial relationship can be assumed.

Legalese does not make /private/ promises or representations with anyone. So if someone in our team promises you anything on behalf of Legalese, you should know that it is invalid and unenforceable.

If you are new to any of these:

  • opensource projects
  • high-tech, high-growth, innovation-driven startups
  • commercial organizations
  • distributed/virtual/remote organizations

you may find that the way we work is different to the way you have worked in the past, because we combine elements of all of the above.

As you will come to realise, we adhere to many principles, beliefs, and their associated bastards (e.g., Holacracy). As a company, however, we don’t have many rules but we do have three commandments that operate jointly and concomitantly extend to everything:

1. Respect people; and do not make or expect another person to do what he/she is unwilling to do

  • If you want an issue solved, you are empowered to follow the prescribed protocols to solve it. This includes persuading the relevant persons to do what you cannot or will not do. If this does not happen, be prepared to accept that it probably will not get solved.
  • We want to hire, reward, and tolerate only fully formed adults. Mostly this means relying on your logic and common sense, using proper grammar and spelling where contextually significant, searching for duplicates before posting, RTFM, being respectful of others’ time, resources, and opportunity costs, clearly communicating needs, boundaries, expectations, and feelings, checking yourself for the Dunning-Kruger Effect (i.e. being able to effectively and objectively evaluate your own abilities and your ability to do your job (whether self-assigned or otherwise)).

2. Have integrity – do not make promises on behalf of the company or other people in the company without going through the exhaustive protocols

3. Bias for public – by default, all company-related conversations should be held publicly. This means either in email copying collective@legalese.com and/or on a public channel on Slack

  • If there are good reasons why the conversation cannot be open, then create a private chat on Slack and invite the appropriate people to join it – preferably more than one other person. Private chats are not logged to our public archives.
  • Good reasons for going nonpublic, where more participants is better than 1-on-1, include:
    • you need to expose data that is confidential to an end-user
    • you want to discuss a possible ethics violation of another contributor, without publicly libeling them
    • you want to discuss your own compensation privately.
  • Possibly-good reasons for going private, 1-on-1 include: chatting about your feelings, health, family, non-company business, etc.
  • In the eyes of the company, secret 1-on-1 conversations never happened (and we don’t care who your secret Legalese buddy is) – if it didn’t happen on Slack, on a mailing list, or at an official summit, then did it really happen? By analogy, in a seminar-style class, if you ask questions in class, you get credit for participation; if you wait until the end of the lecture for everybody else to leave before you approach the professor privately, no credit.
  • In traditional organisations, managers are intended to be single-point-of-contact gateways to the rest of the organisation – they act as a filter so you can get work done. And when you talk to them, you are respecting the “chain of command”: your manager is responsible for conveying your discussion to the rest of the organization, if appropriate.
  • However, Legalese doesn’t have the “agricultural surplus” to support a manager class. Instead, guided by Coase’s Penguin, we make everything public by default and expect you to filter it. Having a single point of contact that represents the organization is a luxury. Very well-heeled clients may be entitled to an account manager, but contributors and staff are not.
  • To sum up, if you want to engage with the organization, talk in a public channel. If you don’t know where to talk, start with #general. If you try to talk privately with someone you think is in charge, you are probably wasting both your time and zers.

1. What we think of companies and users  💑

  • companies build products; entrepreneurs build companies
  • developers build products for users; but users can also be developers

2. Roadmap and where we are now (as of: 5 June 2016) 🏌

3. Organisational Architecture 🎪

  • 3A. Inspirations
    • opensource projects
    • opensource businesses
    • teal organisations
  • 3B. Communication channels
  • 3C. Bail-only Design
  • 3D. Compensation

4. Frequently Asked Questions 👾

  • 4A. About the organisation
  • 4B. About money & compensation
  • 4C. About the future

1. What we think of companies and users 💑

Companies build products; entrepreneurs build companies

In the early days, when a handful of founders are doing all the work, it’s easy to lose sight of the distinction between working in the company and working on the company, a distinction popularized by Gerber. Those who work in the company are staff; those who work on the company are management or maybe leadership or something like that. Founders, especially in the early days, wear both hats.

See also Lazy Leadership.

The traditional model of staff vs management is under attack from new models like Holacracy, which believes that the management function should be distributed across staff, rather than reserving it to specific individuals who carry the burden of being paymaster, boss, and lightning rod.

Developers build products for users. But users can become developers!

We can look at it from a different angle. The opensource world is already used to muddying the boundary between user and developer.

Engineers are used to layer models (for example, the OSI 7-layer network stack). The commercial software world might use an organizational boundary to separate users (above) from developers (beneath). There might be more than two layers: in between, there might be tech support or consultants as well.

Opensource invites boundary-crossing between layers. Such promiscuity disgusts some people from the commercial world, but is widely accepted in more progressive segments of society.

Engineers help to develop a product for end-users. Developers work on Legalese to make a product that some random end-user can use in a number of ways – for example, to produce contracts, resolutions, and workflows; or to learn the meaning of such documents by exploring scenarios.

Where do these developers come from? Often, the lifecycle of an opensource developer begins as an end-user who initially just consumes the product. Then she starts helping others in the support forums. She progresses to file issues, fix bugs, and add features. Eventually she becomes a code reviewer approving or rejecting other people’s pull requests.

Now think of the company itself as a product. Think of developers as end-users of the company. In that sense, managers are developers, not of the end-user product, but of the company “product”: they help make an organization that developers can use in a number of ways. For example, to obtain expense reimbursements, salary, project fees, and equity upside. Or to learn the meaning of such rewards by exploring scenarios. This category of individual is traditionally called “management” and represents an element of social order that has been around since the invention of the agricultural surplus. They do work which is not product engineering, but is vital to the company nonetheless: for example, before the company is cash flow positive, these “managers” are responsible for going out and talking to investors and bringing capital in, so that the company can afford to pay the engineers who write the actual code. They are responsible for the unglamorous duties of filing paperwork that the government requires: for example, audited accounts. They are responsible for getting the t-shirts made (but product engineers are responsible for fiddling with CSS… which is worse?). No one at Legalese has a purely product engineering or company engineering (i.e. management) role.

The same idea shows up in https://www.tesla.com/blog/master-plan-part-deux

In the same way that opensource development invites conversion from users to developers, an opensource company invites conversion from engineering to management. Developers can work on building the company. But they don’t have to stop being engineers. Anytime an engineer participates in an employment interview, helping to screen new hires, she is performing a management function, without giving up her engineering role.

Both Legalese the company, and Legalese the product, are things that can be versioned and milestoned. Both have end-user personas and requirements specifications and use cases and story cards. Both have a release approval process. Both invite users to become developers.

On the product side, before an contributor can work on certain parts of the codebase, they must first earn badges to prove they are qualified, often by reading specific books (e.g. Learn You A Haskell For Great Good) or videos (like The State of the Art of Legal Technology Circa 2015).

On the company side, before a contributor can work on certain parts of the company, they must first read books like Holacracy, the Five Dysfunctions of a Team, and the Art of the Start. But these are just badges, and at the end of the day anyone can level up into any role based on capability and inclination – as with any opensource project, in theory.

2. Roadmap and where we are now

Who is being compensated and what for

  • Job: v1 development and v2 support
  • Dustin: L4 research and development

What we're looking for in a v2 web developer

  • Experience with: JavaScript, HTML/CSS, Node, ReactJS (Redux/sagas), RESTful APIs
  • Plus points: SQL (Postgres), Docker, AWS EC2/ECS, OAuth, HTTP, Python
  • Things which will reduce onboarding time and/or signs of a strong developer: TypeScript, Coffeescript, Angular, Ember, Vue, Webcomponents, Linux, bash, zsh, emacs, vim, Markdown, Perl, C++, Elixir, Ruby, Lisp, Racket, Java, MySQL, R, Selenium
  • You should ask about our R&D work instead: Haskell, SMTlib, Z3, B, Z, Idris, Agda, Coq, Racket, TLA+

3. Organisational Architecture

3A. Inspirations

Opensource Projects

Legalese belongs to the opensource and Creative Commons traditions of Wikipedia, Git, Linux, and Public.Resource.Org, to name a few.

The Internet is built on open software and open standards. Legalese aims to be a major infrastructural pillar of Internet-enabled future commerce, in the same way that Wikipedia has become a major pillar of online education and research.

Opensource Businesses

Legalese costs money to run. Where will that money come from?

Some opensource infrastructure projects are embarrassingly underfunded. OpenSSL and GPG recently put out calls for donations. Legalese must be more sustainable than just relying on donations. That means incorporating as a business, maybe getting venture funding. There are many precedents for opensource businesses, including MySQL and MariaDB.

Remote-first company

~”Teal” Organizations~ Self-managing organizations are better suited to Internet-era post-industrial conditions. We take guidance and inspiration from:

Many opensource efforts have much in common with Teal organizations.

Any sufficiently complicated company w/o management contains an ad hoc, informally-specified, bug-ridden, slow implementation of management. https://twitter.com/wycats/status/368752712894017536

A Teal or Holacratic architecture doesn’t mean anarchy. It doesn’t mean absence of management. It means self-management. In a Teal organization, people spend more time doing management than in a traditional business. The difference is, people manage themselves and one another; they don’t manage up and down.

  • Participants
    • Individual human beings elect to participate in the company. Volunteers, interns, employees, contractors, opensource developers, content contributors, mailing list subscribers – all are Participants. By participating in the company, they agree to abide by this governance model, and they have the right under this governance model to make requests, ask for advice, and be asked for advice. They also agree to subject themselves to the dispute resolution process.
    • A special category of “end-user” or “customer” exists. They are not considered a “participant” operating under this governance model until they take on a differentiated role, such as moderator, community leader, or opensource contributor. When they do, they are onboarded to this governance model, mostly by reading this document.
  • Roles
    • A Role expresses a set of work processes. In a restaurant, Roles might be Waiter, Chef, Host, or Cashier. An individual at the restaurant might enact multiple roles: in a small restaurant, the Host might also act as a Cashier and a Waiter.
    • Individual participants can be onboarded to one or more Roles in a company.
  • Circles
    • If multiple individuals play the same Role, they form a group called a Circle. Circles are a unit of abstraction and MUST exhibit consensus when dealing with other parties, even if that consensus is simply a statement explaining that there is no consensus yet, and describing the conflicting positions.
    • In a restaurant with multiple chefs, the Circle might be called Kitchen, and the waiters might deal with the Kitchen as a unit of abstraction: orders go in, dishes come out. Waiters don’t want to know which chef is preparing which dish. Chefs don’t want to know which waiter is serving which table. There is just a hole in the wall and a little bell that goes “ding!”
    • A Circle may appoint a member or members to act as http://www.holacracy.org/glossary|Rep Links) – representatives of the Circle to other parts of the organization. If a waiter hears consistently from diners that the steaks are coming out too rare, that waiter needs to be able to raise the issue either with the entire Kitchen circle, or with one representative of the Kitchen who collates the feedback.

Transparency It is annoying to not be able to find information when you need it. It is also annoying to be interrupted by people asking you for information.

All information relevant to other people in the company, particularly information that crosses the organizational boundary, SHOULD be recorded in a shared location accessible by other participants. This includes questions, discussions, decisions, policies, and processes.

Chat logs and mailing list logs are available and searchable in the messaging system. Note that direct messaging between participants about company business is discouraged. Even if there are only two participants of a Circle, the discussions within those participants should be conducted in a shared venue, and logged for the benefit of other participants of the company, and for the benefit of future members of the Circle!

So long as non-Asperger humans are involved in the project, face-to-face and tele/video conversations between team members are unlikely to ever be stamped out, but they MUST be minuted in a forum/archive accessible either to the relevant circle or, preferably, company-wide. The point here is that ephemeral discussions may live on in the memory traces of the participants, but the human mind is a fallible thing; over Thamus’s objections, we adopted writing, and we should make the most of it.

Some exceptions exist.

  • Confidential information relating to private matters regarding participant/employee health, family, etc, may be excluded.
  • Chats about non-company business may be excluded. “Lunch?” “Yoga?” etc.
  • Confidential, sensitive, or proprietary information such as passwords, competitive trade secrets, and user data protected by personal data privacy legislation may be excluded from the general transparency rule. In such cases, participants, roles, and circles may elect to share data within circles instead of with the whole company.

All information should be fully public, even to non-participants of the company, unless there is a compelling reason to keep it private. Reasons to keep information within the company include: half-baked discussions-in-progress should not be exposed to misinterpretation by an uninformed public; competitive strategy may hurt the company if disclosed at the wrong time or in the wrong way; information relating to partnerships may be covered by NDA.

Advice process

Before making a decision, a role player (acting on behalf of their circle) MUST seek the advice of all parties who will be substantively affected by that decision.

Request process

Any participant can submit a request to any other participant about the way ze performs their role generally, or about a particular action specifically.

Dispute resolution process

If a conflict arises which is not naturally resolved within a circle, dispute resolution process defines an escalation pathway: a dispute resolution committee involving representatives from all advisory parties MUST be convened. If the dispute is not resolved within that committee, larger and larger advisory committees are convened. (In practice, the dispute is referred to larger and larger gatherings of the community. (There is a tension between the frequency of such referenda, and the size of the dispute. The decision to defer to a larger committee may be made by the dispute resolution committee.)

Contribution process

Content contributors and technology developers are subject to the usual conventions of software projects. They may submit pull requests or have merge authority. The set of Maintainers is a subset of the set of Contributors. A Contributor may be promoted to Maintainer by consensus of the Maintainers.

Training for aesthetics

In organizations expressing design-driven innovations, important decisions often fall into an aesthetic rather than technical or economic domain.

Part of new-participant onboarding MUST involve recruitment for, and training in, the dominant aesthetics, principles, values, vision, and tensions of the project.

Minority or opposition opinions should be actively sought and aired. Consider the “Devil’s Advocate” process. We believe in the disagree and commit strategy http://electronicdesign.com/energy/disagree-and-commit-risk-conflict-teams.

Corporate form

  • Legalese is incorporated in Singapore as a Private Limited company.
  • Legalese needs to be scrupulously aware of the Legal Profession Act.
  • Legalese offers a number of products and services. Some of those products and services are free. Some are paid.

3B. Communication Channels

We read HBR’s piece on transparency traps and quite agree with it. That said, we also like the efficiency of not having to repeat ourselves and the benefit of receiving feedback / contributions from competent people. It’s a balancing act, we’re still figuring it out.

For now, we use

realtime chat
Slack

At the moment, this is invite only. But this is due to Slack fees that we may incur, rather than a desire to keep our Slack channels entirely private. As far as the project is concerned, we treat this as a mostly public forum (unless a channel is expressly designated as confidential or private). We do spring clean, though. Every 3 months or so, you can expect us to do a little spring cleaning to rid Slack of

  • people who aren’t contributing meaningfully in any capacity (or people we’re not expecting to contribute in any meaningful way); and
  • people who have been idle and are unlikely to be called upon / expected to be active in the near future
email
Google Groups (collective@legalese.com is the primary address)
  • You can browse the archives.
  • The default is that unless a communications is CC-ed to collective@legalese.com (or appropriate circle), it never happened and is not representative of Legalese.
  • This is also the mailing list https://groups.google.com/a/lists.legalese.com/forum/#%21forum/talk, where we house everyone who has expressed a desire to join the team, fly-on-the-wall with the team, or just desired to be privy to Legalese’s engagement with the outside world
source code, legal templates, and some documents
http://github.legalese.com
other documents
Google Drive: http://drive.legalese.com.
project management and task tracking
issues.legalese.com.
in-person meetings
an in-person meeting is only considered a valid project meeting only if the online project group are notified with minutes.
  • in-person meetings are a natural human instinct, but easily become an anti-pattern. If project team members are omitted from the meeting, intentionally or inadvertently, cliques form, communication breaks down, decisions are made in secret, project members complain “nobody tells me anything”, and the integrity of the organization fails.
  • In-person meetings are acceptable if and only if:
    1. all relevant individuals are invited to the meeting
    2. provisions are made for people to participate online
    3. minutes are saved onto the appropriate folder on G:Drive and notified to the appropriate slack channel
    4. comments and discussion after the meeting are considered as valid as in-person interaction during the meeting
    5. decisions made during the in-person meeting may be reversed or revised pursuant to online followup – this has to be made clear to the other party

3C. Bail-only Design

Adhocracies tend to be highly informal, with people joining and leaving projects all the time.

By analogy with crash-only software design, a bail-only organizational structure aims to increase robustness by removing critical dependence on any individual, allowing any participant to leave the company at any time, and rejoin at a later time – or never!

Swappable roles are emphasized over job titles and fixed areas of authority/responsibility. Any individual who satisfies the prerequisites to assume a role may do so.

3D. Innovation: Compensation

In a purely volunteer not-for-profit project, little is needed beyond an IP/copyright assignment.

Legalese may take a commercial, for-profit form to maximize sustainability and satisfy investors. How will participants be rewarded?

We draw on the conventions established in the startup industry to manage expectations. If the company has cash available, and participants need to draw a salary from Legalese to continue contributing, then an employment or contractor relationship can be established. If the participant is willing to trade equity for cash, then the participant can be registered in the stock pool. Ideally, cash and equity should be interchangeable.

Compensation could be determined by a participant’s fellow Circle members and immediate business units. Or maybe we do a next-generation approach using some kind of Swarm or Assembly or other Distributed Collaborative Organisation model.

Compensation discussions held during the 2016 Legalese Summit

Reference exit scenarios

Ludicrous Exit
The company exits for $10B after 8 years.
Decent Riches
The company exits for $60M after 4 years.
Sad Puppy
The company exits for $150,000 after 2 years.
Death
There is no exit and we agree to shut it all down after 3 years.

Requirements

This section records requirements expressed by people on the team. It aims to anticipate the expected requirements of future participants.

Component: Survival [[https://en.wikipedia.org/wiki/Kiasi][(Kiasiïsm)]]

  • Staff need to have enough money to survive and focus on the job, without having to take outside jobs.
  • It’s a bad idea for founders to pay themselves so little they can’t work full time on the startup.

Component: Opportunity Cost (Kiasuism on the part of the Contributor)

  • Don’t lose relative to something else.
  • “I spent two years working for a startup and all I got was this stupid t-shirt.”
  • Happy Path: If Person A could have made $100,000 doing independent consulting or working for a Big Company doing a Boring Day Job but instead spent their time at the startup, they should get at least $100,000 upon exit. If Person B could have made $200,000, ditto.
    1. People should feel like their opportunity cost was respected.
    2. There could be a certain discount to represent the fact that they are taking a risk – see next section, Dreams of Avarice. Founders usually take a pay cut to do their startup. At least, that’s what investors want to see.
    3. If there is not enough money at the time of exit to give both Persons A and B $300,000, then the compensation should be reduced pro rata, pari passu. So A gets $50,000 and B gets $100,000.
    4. If the specific number is not known, then the compensation committee can make a suggestion. And if the negotiations fail, then there is no deal.

Component: Replacement Value (Kiasuism on the part of the Company)

  • Nobody is irreplaceable, so if somebody wants to get paid more than their work costs to the Company, maybe the BATNA is: no deal.
  • The company should ask: what would it cost to contract out that piece of work? This is “core competency” theory.

https://open.buffer.com/introducing-open-salaries-at-buffer-including-our-transparent-formula-and-all-individual-salaries/ (we should add a lawyer grade.) From Kahnemann, perhaps this component should be a nonlinear function, that more or less caps out around $75,000 a year, adjusted for purchasing power parity. http://economistsview.typepad.com/economistsview/2008/03/income-and-happ.html

Component: Greed

  • We don’t want to micro-detail the intangible contributions – people should act in the best interests of the company, and evangelize and speak at conferences and make introductions, without asking for a cash reward each time; they should feel that they will benefit down the road, out of equity upside in the future, that will be worth way more in the future than cash today.
  • We could stack rank these equity awards or we could leave them in an unexamined pot.
  • Much of this component should be satisfied by one’s equity holdings.

Initial Snowflake Concept

  • The “Snowflake Award” shows up as a bonus at the time of exit, out of the equity stake. It is very hard to measure the serendipitous contributions that each person makes, so we just trust that some other people may get a little more than you, and that’s okay.

Initial naive proposal

  • If the above components are all satisfied, then the Snowflake Award is $1M to each participant. And you can take that money and buy some therapy to feel better about yourself.

Adjusted Snowflake Algorithm

  • Monthly, everybody is allocated the kiaxi + kiasu minimum, then they get to decide what proportion of this is desired in equity.
  • Quarterly variable could be contribution.
  • Different people will then hold different amounts of equity.
  • In the Decent Riches scenario, the exit is $60,000,000. Investors own half the company, and they get $30,000,000. The other $30M is available for distribution to contributors, which is the pot.

pot = 30,000,000. How do we split the loot from the heist?

  • First, the snowflake award. every contributor who has been with the company for a certain amount of time gets $1M. This is a bit like a professor being awarded tenure. Maybe we take the idea that everybody gets an equal split of a certain percentage of the pot. For example: if there is a acquisition for cash and the pot is 30,000,000.
  • We decide to take one-third of the cash exit and distribute that equally among all Snowflake contributors.
  • The other two-thirds are distributed pro rata by shareholding.
  • The one-third vs two-third could by any N vs (1-N).

Component: Intangible Contributions

  • Person A is a great fit for the startup. They create more value working at that startup than they would working anywhere else.
  • The Contribution Adjustment could be stack-ranked on a quarterly basis based on outcomes.
    • For example, introduction to investors could be rewarded. But if the investor actually invests, the contribution could be adjusted up.

Component: Location Something like what Buffer has done: https://open.buffer.com/introducing-open-salaries-at-buffer-including-our-transparent-formula-and-all-individual-salaries/

Component: Cash/Equity Tradeoff

  • Instead of taking $100 in cash, each contributor can choose to take $50 in cash and invest the other $50, buying equity at the last priced-round rate, or some adjusted interpolation, extrapolation, or approximation thereof. Or each contributor could take $0 in cash and $100 in equity.
  • At what price should contributors buy that equity?
  • Should there be a discount? Contributors would say, yes. Other purely financial investors would say, no.
  • Perhaps the company could point out that the contributors are already getting an intangible benefit because they have the option to buy shares at all; the man on the street does not. And every $50 that they buy today will turn into $5000 in 4 years – or to $0. So it’s an all-or-nothing situation, and they shouldn’t quibble about a discount. If they’d gotten a discount, the $50 they put in could turn into $6000 in 4 years.

Base plus project?

Base rate
negotiate an hourly/monthly base rate with the compensation committee, but attached to the badge/role rather than the person.
Project rate
like bountysource. This feature is worth $X to the company. Go do it. Get paid.
  • Each contributor gets to decide their cash vs equity split each month.

Scenarios

  • What happens if Person A does not contribute to the product, but introduces a $2M investor?
  • Should this be paid as a finder’s fee?

Issue-based compensation

  • Anyone can file a new issue in Github Issues.
  • Only the Issues Committee can put price tags on issues.
  • Anyone can start working on an issue. If their pull request satisfies the issue and is approved, they get paid.
  • Let’s not measure everything too much because unmeasured work increases the value of our equity anyway.

Considerations

  1. Do we overvalue people with existing jobs? It is standard to forgo “normal dayjob” levels of compensation to work on their startup.
  2. People who join earlier are taking more risk and should be rewarded accordingly. This is the Risk/Reward Ratio.
  3. All of the above needs to be tax-structured and optimized.
  4. We don’t want to distort people’s behaviours – we want to create a structure that brings out the best in people without stressing them out or making them do unnatural things.
  5. How do we filter new people who want to join the company?
    1. Either fulfil the minimum criteria which have been defined as issues – write documentation, or write code.
    2. Or demonstrate unexpected value to the company on your own initiative, and then be approved. You pay your own airfare to the Legalese summit.
    3. Along the way, don’t collect any vetos from any of the existing cabal.
    4. “Congratulations! You have been on the opensource project for quite some time, and now your probation period, which you didn’t know about, has ended. We would like to offer you a contract to cover a base rate to spend more time on the product side and be a part of the team. We will now cover your airfare to the next Legalese summit.”

Proposal 1

Each participant’s compensation is their task fees plus badge rate adjusted for activity level plus circle bonus.

Task Fees

  • When a circle needs something done, it posts a project/task in Github Issues, with the following attributes:
    badges
    qualifications needed to accomplish that task.
    short credit
    estimated short-term value add, typically measured in cash
    long credits
    estimated long-term value add, typically measured in equity
    hard deliverables
    required acceptance criteria
    soft deliverables
    if the task is done by a certain deadline, or in a certain way, additional short and/or long credits are awarded.
    mutex
    either exclusive or open.
    mushroom
    recurring tasks are mushrooms which anyone can clone and claim.
  • The short and long credits are allocated out of a budget set by the circle’s parent.
  • A project/task may be restricted to a specific role or circle; or it may be unrestricted. Such a restriction is expressed through the badge mechanism.
  • If mutex==exclusive then the task can only be assigned to one person at a time.
  • If mutex==melee then multiple people may compete to execute the task. The first person to demonstrate delivery may win the prize.

Auction Mechanism

  • It is possible for prospects to negotiate elements of a task after it has been posted, so that the short/long credits may float until the market clears. However, such negotiation must occur in the task comments directly. An auction model may arise with multiple prospects bidding for a given task.

Credits

  • Both short and long credits are convertible to a mix of cash and equity.
    • short credits may be converted to 100% cash and 0% equity, or 80% cash and 20% equity, or anywhere in between
    • long credits may be converted to 0% cash and 100% equity, or 20% cash and 80% equity, or anywhere in between.

Badge Rate

  • Every participant is entitled to badge rate, multiplied by their activity level.

Badges (“Skills”)

  • counts the number and size of badges held by a participant, like plates of sushi at a conveyor belt restaurant.
  • Badges may run in series, like Javascript Programmer Bronze, then Javascript Programmer Silver, then Javascript Programmer Gold.

Seniority

  • is represented by a special badge that increments every month. A decay function may apply to cover any interruptions or absences. Think of this as the traditional salary band, but with less weight.

Roles

  • are represented by one badge for each role.

Badge Weights

  • Each badge of each participant possesses a weight rating – a rational in range [0,100]. If participant wins a bid on a project/task, but does not deliver it to the satisfaction of the commissioning party, they get to choose which of their badges should lose weight. If the project is accepted, the weight increases. When the weight goes over a certain amount, they earn the next badge in the series.
  • Don’t bid for jobs that you don’t think you can do, especially mutex jobs.

Activity Level

  • The number of short+long credits achieved in a given period determine the activity level for that period. The activity level is a value between 0 and 1. You may read it this way:
    0
    participant was effectively inactive
    0.5
    participant was part-time
    1
    participant was full-time

As Code

function Company(params) {
  this.compensationPoolSharePrice = params.compensationPoolSharePrice; // 2 would mean in $2 per share

  var equityToCash = function(equity) {
    return equity * this.compensationPoolSharePrice; // if the current value of the company's equity pool is $2 per share
  };

  var cashToEquity = function(cash) {
    return cash / (this.equityToCash(1)); // inverse
  };
}

function Task(params) {
  this.company = params.company;
  this.badges  = params.badges;
  this.short   = params.short;  // short credits
  this.long    = params.long;   // long credits
  this.hard    = params.hard;   // hard acceptance criteria
  this.soft    = params.soft;   // soft acceptance criteria
}

var shortCashMin = 0.80, shortCashMax = 1;
var  longCashMin = 0.00,  longCashMax = 0.20;

function creditsToCashAndEquity(type, quantity, cashComponentDesired, company) {
  var cashComponent;
  if      (type == "short" && cashComponentDesired < shortCashMin) { cashComponent = shortCashMin; console.log("equity component of short credits may not exceed " + (1-shortCashMin)); }
  else if (type == "short" && cashComponentDesired > shortCashMax) { cashComponent = shortCashMax; console.log(  "cash component of short credits may not exceed " + shortCashMax); }
  else if (type == "long"  && cashComponentDesired <  longCashMin) { cashComponent =  longCashMin; console.log("equity component of long credits may not exceed " + (1-longCashMin)); }
  else if (type == "long"  && cashComponentDesired >  longCashMax) { cashComponent =  longCashMax; console.log(  "cash component of long credits may not exceed " + longCashMax); }
  else                                                             { cashComponent = cashComponentDesired }
  var equityComponent = 1 - cashComponent;
  return {  cash:                      quantity * cashComponent,
          equity: company.cashToEquity(quantity * equityComponent) };
}

var activityLevelFullTime = 20;
var activityLevelPartTime = 10;

function Participant(params) {
  this.company    = params.company;
  this.riskRating = params.riskRating || 0; // real
  this.seniority  = params.seniority  || 0; // int
  this.multiplier = params.multiplier || 0; // real

  this.badges = { }; // qualifications earned over time

  this.compensation = function(tasks) {
    var totalTaskSize = tasks.sum(function(t){return t.short + t.long});
    var activityLevel = (totalTaskSize > activityLevelFullTime ? 1   :
                         totalTaskSize > activityLevelPartTime ? 0.5 : 0);

4. Frequently Asked Questions

FAQs about the product

you can start by learning the product from an end-user perspective.

FAQs about the organisation

Why do I keep getting redirected to the group chat? / My main point of contact with Legalese is X, but when I try to talk to X about Legalese, X doesn’t seem to want to talk to me directly; instead, X tells me to talk on the mailing list, or the group chat. Why are they being so rude? Who do they think they are?

They’re not being rude to you; they’re just being polite to other people. Other people who should be involved in the conversation, and would object to side conversations. Or people who would benefit, tomorrow, from seeing your conversation today. Some of these people might not even be with us yet: they will join tomorrow. Their access to historical discussions means they can learn what happened without having to bother you. This is the fundamental value proposition of the technology called “literacy”: it scales better than the alternative, which is orality._

This may be your first experience interacting with an opensource community. Legalese – the opensource project – is not a traditional organization with a central point of contact. Legalese, the commercial entity, does offer that kind of support, but only to paying customers. The closer you are to being a paying customer, the more you can expect confidential, personal support. The closer you are to being a project participant, contributing bug reports and pull requests, the more you should expect to talk to your fellow participants, not to some figurehead. The PR spokesman may be the voice of the organization, but ze doesn’t have more executive authority than anyone else.

You wouldn’t phone up the managing editor of your local newspaper and demand to have the news read to you.

Then I want to talk to somebody who’s in charge! Easy! Find a mirror. You’re in charge.

First, professors invented the seminar because it was more scalable than one-on-one tuition. Then they figured out they didn’t even have to turn up, half the time, and the learning would still go on, as long as the students were there.

In the same way, if you want to interact with Legalese, you already can. If you want to report a bug or file a feature request, go ahead: use Github issues. If you want to spend company funds, bring up the issue on the #finance chat. If you want to complain about the organizational structure, go to #mgmt-organisation. If you want to represent Legalese to some third party entity, you can, so long as you do not commit anyone else within the company to act, without getting their approval first.

Okay, then where do I find letterhead? The Legalese logo and artwork are available under logos. You can also get corporate letterhead under the stationery folder

How do I invite a new person to the project? There’s an onboarding workflow; running that workflow is the responsibilty of the Onboarding Role. To trigger that workflow, speak up on #general. The Onboarding Role will canvass for objections, and if none are received, will kick off the workflow.

Tell me about the scalability of Legalese This is a software project. If some kind of user request needs human support, and it looks like that class of user request is going to be recurring, we need to find a way to hand off that user request to a network of partners, e.g. law firms who have staff standing by. We focus only on components that are scalable through software.

It is the essence of computer science that if a methodology does not scale up, then it isn’t a methodology at all. Robin Milner, Is Computing an Experimental Science?

Are you a non-profit entity? No. We are a for-profit with currently no profits. There are many moving parts. We are flogging ourselves for not moving fast enough. We are pleasantly surprised but also therefore immensely grateful for everyone’s patience and indulgence so far.

How much law do I need to know? Not much, it changes all the time anyway and from jurisdiction to jurisdiction. But you should ​*understand*​ it. Understand what people mean why they say they need a lawyer, what lawyers actually do, what lawyers pretend that they do (unfortunately, most of them don’t even realise that they’re playing pretend), understand what a contract, a workflow, an outcome consists of – these consist at least of dependencies and modalities that need to be understood. See: Rudyard Kipling’s six honest serving men.

What if this is not what I want and you guys don't seem to want to / be able to give me what I want? That’s okay. We all have a right to say no to what isn’t quite right for us. It isn’t a dichotomy though – we are an open source company and you are invited to fly-on-the-wall and tourist with us until the day you feel like it’s aligned with what you want.

At the same time, embrace the polyamory! Embrace the other options out there! We like to think that the wabisabi beauty of our organisation is that the decision tree doesn’t end with us and nothing at all. There may be accrued intensional states (e.g. ‘disappointment’), but the decision tree is uh, all the world​ and all of its opportunities.

Can I attempt a fable? So… I’ve never read/watched The Hunger Games, but from what my students tell me, I think it may be relevant. Otherwise, just treat it as my submission of evidence why I am so crap at writing that lawyering was the obvious way to go: the protagonist thinks she knows what her one true love (“OTL”) looks like and ought to look like. she meets Handsome-Man, who looks a lot like what she imagined her OTL to look like and was like omg, he’s perfect! Uh. Almost perfect. Well, if only…

Now, see, that’s the problem, “if onlys” do not sit well with the concept of OTL. So this poor girl went on a host of adventures, and at the end of the day, realised that all she really had and wanted was pita bread. I think this means that whether Handsome-Man can be moulded (snigger) to become your OTL doesn’t really mean much when you’ve got a yeast infection. The folllowing video was educational: https://www.youtube.com/watch?v=bZ3pU-saMLQ

FAQs about compensation

Does Legalese have money? Short answer: No. Long answer: Zilch.

What the frak? I thought you guys paid for all that cool stuff during the summit, have been flying around for conferences, and eating oh god, /all that food/ Uh yeah. Humans paid for those. Mostly, very mostly, Meng. Sometimes Chiahli. Sometimes Alexis. In fact, the humans in the organisation have had to lend the company money for its meetings, flights, sustenance, intellectual nourishment, etc.

Who is majority shareholder? How is the organisation split? On paper, Meng. And if I may be so bold as to direct your attention to the Q&A immediately in the foregoing, I put it to you that there is no split, no paperwork on the split because there is nothing to be split.

But you've been working on these for a year! For no money? Or equity? (gulp) That is correct. But I should also add that following in the trend of lending money to the organisation, we have also been tapping on some or all of the following to subsidise our work on legalese: savings, the legal industry’s incumbents, family, friends and fools.

Can I have money? It depends. We can lend some money to the company to pay people to build v2 (if you don’t know what this entails, you should probably read more of the information on GitHub).

  • Why v2 and not v4 or v5, you ask
    • Later versions if we can afford it. We ​*are*​ building a full-stack startup the way Intuit and Adobe did it from ground up. But until we find investors who are willing to let us spend their money on research, we first need to have a product. Or at least masquerade our research spending behind a product. We don’t have a product. We take guidance from the way Uber didn’t spend their first few years and money on self-driving cars (despite that being ​*the*​ grand plan), and did that only last year: http://www.theverge.com/transportation/2015/5/19/8622831/uber-self-driving-cars-carnegie-mellon-poached
    • Talking to the Valley people (VCs, other founders) this past week has also helped validate that. Investors don’t want to fund research projects. They want to see growth, traction, product-market fit. V2 is our attempting at starting with those.

Wait. What? NO product? We have googleapps. And that spreadsheet thingy. I know it’s a trope that we should ship products before we feel ready, and ship products we are embarrassed of, but I’m sceptical if that extends to a product with a human UI (i.e. meng) for a software product. Probably not.

So what about the genius minds like ours? We are doing the real hard work, that is, the invention and the research. What does all this mean for me? You are critical to our long-term success. And we are working very very hard to find ways to enable and empower the research arm. In the early days though, this means looking for public grants, research grants, collaborations. Virgil has been a god-sent cheerleader on this, but this also means that the researchers on the team will probably have to be aggressively applying for grants and partnerships. The resilience to rejection, fortitude and perseverance to keep working at it, finding new money wells, finding ways around money walls, seems like good character building. The point is, the process is not going to be easy.

But I want to create meaning! Not this time-wasting begging for money, writing applications, doing everything that eats away at my research time We love that! Go do that! I hear there’s a few companies and universities out there with specific departments for that. Unfortunately, our startup can’t quite pay you to do that yet.

Can I just work for equity then, since you have no money? Bingo. Read Compensation in further details above or ask on slack. Anyway, we want to structure it such that equity and compensation eventually becomes interchangeable. Now that we know how to structure it though, we just need to actually, uh, structure it. This involves long and extended conversations with everyone on the team. And architectural planning to ensure that it doesn’t freak out the investors. This will probably take awhile. So yes, you probably can work for equity (subject to holacracy rules and compensation committee’s rules), but what that means exactly, how much that is, will probably take us at least 3 months to get back to you on.

Can I get something in writing? We can probably generate an employment agreement in writing once the procedures are followed through with. We can also probably generate a bunch of other documents. But if you want equity in writing, we have nothing to carve from now. And you should probably also realise that, that is essentially asking if you can have a piece of paper from us to tell you that we have no money, but when we do have money, we may splice some of that off for you and everyone else based on a yet to be defined metric…….