clef / handbook Goto Github PK

I would suggest adding these 3 provisions:

• Help with 83b elections for your options
• When you leave the company, all vested options do not expire. Options exercised 90 days after leaving the company are treated like NSOs due to the law. You did the work, so you've earned the stock.
• Options expire at least 15 years from issue. With IPOs happening on a far longer time frame, a 7-10 year option expiration date is now too short. Facebook took 8 years to IPO, and with your long term focus I think it will match with your philosophy.

As an employee engineer who left a relatively successful startup and never bought his relatively valuable options because the AMT got way too large along with other issues, I will never work for another startup again unless they are providing many year RSUs or have the above provisions.

Most companies are very resistant to adding the above 3 provisions, so most engineers quickly learn to not bother with it unless the company advertises this fact from the start. You lose a lot of potential engineers at the first email as a result, because they won't even bother to reply. You'll help your recruiting pipeline by doing this!

In the words of @techiecheckie on Twitter,

Your recruiting document is trying really hard but not enough. Recruiting diversely means little w/o hiring followup. I'd prefer to see explicit numbered diversity goals rather than, again, vague non-committance. Especially bc you already know your most diverse pool of applicants will come from ppl least likely to get in.

Tweets start here.

I was considering how your handbook might grow & change over time both as the number of employees at your company grows and as some of your employees gain tenure. It might be interesting to add tags to the repo to mark certain company milestones (e.g. "10-30 employees", "1 year in business"). This might let future startups more easily look back at versions of your policies that worked well for you when Clef was smaller/younger, and in the future might let you reflect on how your policies have changed as you became a larger company.

To combat pattern-matching and other biases, a framework for how candidates are judged is crucial.

I know this sounds super corporate and stiff, but each candidate should be judged against a standard. If that standard isn't codified, it's prone to manipulation by bias.

The content here isn't that good, and most of it wouldn't fit for Clef, but I think it could be adapted to work really well:

http://www.hope.edu/academic/education/studteach/ProfessionalInterviewScoringRubric.pdf

In the words of @techiecheckie,

No mention of trans healthcare anywhere makes me, as you know, a trans person, nervous as hell. Maybe it's somewhere. But mentioning it explicitly would put a lot of trans coders instantly at ease.

@brennenbyrne also shared some thoughts:

yeah, this is something we did a lot of research on, and I agree that we should add a note about it. there's good news and bad news about this; the good news, CA requires healthcare providers not discriminate for most care. so any healthcare we provide is "trans-inclusive" in a broad sense. Unfortunately, in our research, there were no policies that didn't have strict requirements about trans-specific healthcare. All policies required psychological evals that force trans folk to be outed to their employer and "evaluated" before they got access to the care they need. We avoided Kaiser because they have a reputation for being the most difficult to work with for trans folk, but we couldn't find anything that gave better coverage for trans folks or had less draconian reqs. The lack of result kept us from mentioning it. We should talk about that finding and decision, though -- I'll work on it.

Tweets start here.

It's awesome that you all have released this - but for other organizations to use it, you really will need to add a license. If the whole thing was created in-house or as a work-for-hire, you should be able to release it as CC0 as we've done, which allows anyone to use and modify it however they like!

@kelseyq made a note on Twitter that we should include policies on on-call rotations and compensation for them.

This is definitely something we should add!

From @techiecheckie on Twitter,

Not a concern but a suggestion: Add that repeated microaggressions will count as harassment. Mentioning that expands the scope of harassment to things that privileged communities don't think of as harassment. E.g. Twice I've tried to have qpoc meetups and had white ppl tell me to "be more open" or "why just PoC??" That's not outright obviously a problem to most white ppl, and as a qtpoc, I'd have trouble bringing it up if it wasn't explicitly against the CoC. And this might be a hella long shot but I'd love for a company to flat out say "we don't consider reverse -isms real".

Tweets start here.

In the words of @techiecheckie,

"Clef is located in Oakland. This is a massive area of gentrification in California. I think it would really add something to make a pillar of Clef about serving that community that houses you guys."

I think we're already doing a lot to work with and in the communities around us (though we can always do better), but we should explore how we can incorporate and discuss this better in the handbook.

Tweets start here.

Guys I'm very very excited that you're doing this, and would hope more and more companies adopt your ideas and implementation, with enough of these around and open to everyone for review and to learn from we could probably achieve sort of "creative commons" of company policies, with easy and well-understood best practises... Oh the possibilities.
Anyway your documents are great and very straight forward, but I think you're lacking more concrete examples - you could probably link to a some do's and don'ts (especially disputed ones) or maybe link to sources (if available) as to why the conclusions in the documents are the way they are, allowing for more scrutiny, oversight and reasoning to be done by everybody.
I know you're probably know all the reasons and would like to keep this document as clean as possible providing only the distilled information, but it would be great for people outside of your community to glean more into your process that way, and I'm sure new (and possible future remote) employees would appreciate the extra sources.
And again thanks for your great contribution to society!

You do a great job setting a clear guide for starting salaries based on experience and role (although I have to echo kcshearon's issue #37 on the discrepancy between "technical" and "non-technical" roles, a distinction which seems more a vestige of past exclusionary practices in the industry than one that has a meaningful role). However, there's no standard outline for pay increases over time, which will be important for retaining the employees you hope to keep and develop over 6+ years.

Just as "Traditional salary negotiations are also heavily biased because they rely on individual gut feelings and negotiation," which "favors candidates who come from more privileged backgrounds and are afforded more confidence during the hiring process," traditional raise increase negotiations have similar issues. As a first step, I would recommend considering a flat % increase based on years worked at Clef, along with a stepwise increase of +20k for employees who pass the 5 years of experience mark that factors so prominently in starting salary (or +30k for non-technical, if that discrepancy is retained). The flat % increase could be local CPI + GDP growth, or 5%, whichever is greater.

For example, consider technical employees X and Y, hired at the same time. X has 6 years of experience, while Y has 3.5 years. X starts at $120k, and Y at $100k. After 1 year, they'd both receive a 5% increase, to $126k and $105k, respectively. 6 months later, Employee Y would have reached 5 years of total experience and receive a $20k increase to $125k , and 6 months after that they'd both receive a 5% increase, to $132.3k and $131.25k.

(5% might be a little high, but it makes the example easier.)

This ensures that new hires with less experience don't start at a higher salary than employees who have been at Clef for several years, and that salary increases can be considered fair and reliable. There's still a slight discrepancy, but it's small enough that it doesn't conflict with your values.

On Twitter, @techiecheckie suggested that we expand our EOE document to feel less vague and more applicable/useful to trans and disabled people. In his words,

The EOE section is too short and vague to be useful to: a) disabled ppl, b) trans ppl. Reading it, it flat out sounds like a form letter I can download off a cheap lawyering site. Many companies write these same words and never follow through. Ppl who need them therefore don't use them out of fear. If you want to really make it clear that this is IMPORTANT to you, it needs to detail much, much more than it does. Substantial, well-thought out work in this section will attract a lot more diversity than lip service.

Tweets start here.

Clef has a great array of perks and benefits, but I think an important one that's missing (and would fit in well with the founder's values) is matching contributions to (local?) nonprofits. It should likely be restricted to donations made to 501(c)(3) public charity organizations (the tax-deductible donations kind - not to private foundations or political action committees or campaigns).

It might make sense for these matching contributions to be capped. If so, perhaps matching contributions could come out of the same pool of money set aside for continuing education. This allows more employees to take advantage of the $4k/yr, and more fully (since tuition or other expenses likely wouldn't be a nice round number, this would allow employees to use their remaining benefit).

Similarly, Clef should be open to donating employee time to nonprofits. This could be from the same pool of time as the work hours for learning projects (although the cap of 4 hrs/wk might need to be restructured to a cap of 8-16 hrs/wk, accumulating at a rate of 4 hrs/wk to make this feasible).

It will be great if this project could be easily to download and read offline or on reader. Maybe link it to gitbook but it require some changes in files (using local paths instead of absolute)

It's great to see you are publishing information like this so clearly for your employees, and to promote transparency in this traditionally opaque topic.

Thought I'd mention a related, very new effort on GitHub: The Open Guide to Equity Compensation.

It's a collaboration between myself and Joe Wallin, with the goal of better documenting the equity compensation and taxation. You may find it is a helpful resource to explain some topics here — and we'd be interested in suggestions.

15 days of paid vacation per year is great. In accordance with the value that inspired the sabbatical, I'd suggest capping accumulated vacation - perhaps at 30 days, or 2x annual accumulation - with the goal of encouraging employees to use vacation (not save indefinitely) while still enabling them to take extended vacations.

You all have a great Code of Conduct policy so far! But it could be even better if you expand the language of inclusion beyond the "standard legal requirements" - have a look at 18F's for some really great additions:

https://github.com/18F/code-of-conduct/blob/master/code-of-conduct.md

In particular,

Negative or offensive remarks based on the protected classes as listed in the GSA Anti-harassment Policy of race, religion, color, sex (with or without sexual conduct and including pregnancy and sexual orientation involving transgender status/gender identity, and sex-stereotyping), national origin, age, disability (physical or mental), genetic information, sexual orientation, gender identity, parental status, marital status, and political affiliation as well as gender expression, mental illness, socioeconomic status or background, neuro(a)typicality, physical appearance, body size, or clothing. Consider that calling attention to differences can feel alienating.

Referrals, especially coupled with referral bonuses should be something that starts with a number of warnings. A $ bonus unconsciously triggers expediting trials, and you’re likely to access your immediate network more often than the fringes of it, which in itself can be one of the quickest ways to build a monoculture, despite your best efforts.

Also, I’m a little cautious about referrals being the top of any sourcing document. In this case, the idea that the best signal about a candidate being successful at Clef should not be just a part of an employee’s understanding. The entire sourcing process, across your ATS should aim to mitigate risks and answer that question.

I also think this document should acknowledge that very often, referrals from a candidate perspective come from a certain (sometimes deserved, sometimes by chance) entitlement of network: a chance meeting at a conference, picking company A vs B is the difference between an exceptional network and a weak one, directly correlating the potential of referrals.

So I’d love it if this section was listed with the idea that referrals are helpful, but keep an eye on the plucky, skillful underdog who’s flying under the radar and needs that break.

In the words of @techiecheckie:

"I need to know beforehand if this is going to be some "find all 4-tuples summing to k" question on a whiteboard, or like a real question in real circumstances. I instantly turn down interviews that have bad interview circumstances because half my interviews were by outright jerks. It should be clarified for the diversity angle because people will turn down poorly thought out interviews if they can."

Tweets start here.

I would recommend noting if new parent leave can be taken in part or must be taken fully. And if in part can it be n parts or any fraction the parent choses. I found that being able to take it in segments helped my wife and I tag team and extend how much time we were able to stay home with the baby before having to put her in daycare. It also allowed some extra flexibility which was welcome when dealing with issues like lactation problems, etc which can happen at various points in the first 3 months of life.

Hi @clef/employees! As we've heard more from people on the subject of office hours and remote work (see #59 for some awesome commentary by @sarahmei, @zspencer), I've had the sense that (a) we should change our policies around remote work; (2) if we change our policies, we'll need to figure out some ways to experiment and grow to match them.

I want to propose that we put in some structure to simulate more remote work, so we can get a better sense for how it feels as a team and how we can create systems that support it. The primary goal with these structures is to learn: this may mean that they cause issues in the short term, even as we're learning how we can improve in the long term.

The general gist of how we do this is that we all spend more time outside of the office working on a regular basis. This will test our ability to communicate & use tools like Slack, Trello, and Google Drive to operate efficiently even when we're not in the office.

I've thought of two ways to do this:

1. We pick one day a week and all work remotely (from home or from another location) for that day. This would be pretty easy to coordinate: we all just have to pick a day (say Tuesday) and then not show up.

2. We all commit to spending one day a week out of the office, but it's not predetermined to be the same day as everyone else or the same day every week. This would be a little harder to coordinate. To make this work, we could block out on a company calendar when we'll be out of the office and let everyone know with good lead time what day it will be. I also think it may be useful to block out days where explicitly everyone is in the office (maybe Monday and Friday), so we can have important all-hands meetings (like our product sync and all-hands).

I'm leaning towards (2) because I think it better simulates what remote work actually is, but I'd love to hear everyone's thoughts on the matter (and any suggestions outside of 1, 2).

Thoughts?

In @techiecheckie's words from Twitter,

I'm a little confused on your alcohol policy. Is it saying that in general, no alcohol at Clef save special events? And in the case of special events, it must be beer or wine? (Maybe just outright warn people which events will be dry/not, and what days alcohol will be brought in.)

Tweets start here