Clef's company handbook
github.com
github.com
Some of these things seem ripe for deviating from before they even see their first legitimate use:
"It makes Clef look great when our employees speak at industry conferences" -- so employees are allowed to go four times a year, spending $1000 each time, subject to approval, oh, and this is a "benefit"? Anyway, it's nice -- but does this mean that if there's a conference somewhere, everybody agrees it's a great opportunity, but it's my fifth, and it will cost $1100, then we just shrug and don't go? No, I thought not, so why have the rule at all? What, exactly, is the problem they are solving by writing this stuff down?
I get it at a larger company, where you need to align expectations across a larger body of employees, but when you're <10 employees, you can literally just raise your voice in the room and say "Any reason we shouldn't send Joe to FooCon to speak about the FizzBuzz? It's a bit pricey, probably $1100, but it's it worth it right?" -- that's a much more transparent decision than anything written in a handbook.
This handbook doesn't preclude that; it just says that this is the minimum that every employee can expect without having to wonder what is reasonable or not. Every company, large or small, has exceptions to policy, and the handbook is just a way of making those guidelines common knowledge, so everyone can feel comfortable knowing what expectations are completely reasonable and what will require special consideration.
> so why do they feel the need to specify how many weeks of vacation you should have taken in the year leading up to the sabbatical you earn in your fifth year of employment?
One disadvantage of 'unlimited' vacation policies are that expectations are oftentimes unclear, and many people end up taking far less vacation time than they otherwise would or could. This disproportionately impacts women and minorities in the industry for a variety of reasons[0]. People who are used to being marginalized in the workplace (not necessarily at their current job, but in the past) tend to be less aggressive with their demands, even when their demands are completely within reason.
Furthermore, for people looking at long-term planning (people with families, or people with other obligations outside work), having clear expectations for not just the short term but the long term as well is a huge bonus.
[0] This isn't an argument not to have unlimited vacation policies at all - just that, if you do, you should be conscious of mitigating this effect.
That's why I advocate for minimum vacation. It sets a clear standard of how much vacation is expected but doesn't make you carefully dole out vacation days.
I think first and foremost, to each their own. If you don't like these policies, then don't work there. But don't go knocking them nearly universally. Start by asking the author "why" they chose certain policies or such detailed policies given the context.
Related, if anything is unhealthy, illegal, or skirting the law by paying lip service to the letter of the law, then certainly it should be called out. But I personally wouldn't put bureaucratic policies, such as the policy on attending conferences, in that category.
Second, putting to each their own aside, I have personally come across the "maybe works at a large company, but we are not a large company" argument many times and find it lacking. I have worked in very small, medium, and ginormous companies. I've worked in companies that were in the process of transitioning from small to medium. The ginormous company I worked at was, at the time, the worlds largest insurance company, and I was working in the investment division, which had one of the worlds largest AUM (Assets Under Management) numbers. So, investment company within insurance company that was an enormous publicly listed company, yeah, we had a few processes and policies in place. What I learned while there was how to leverag those to both get to the important work and to get more work done. I now feel that I was spoiled during that time, and often miss that "policy infrastructure" when finding myself in the middle of a cluster-f-uck at businesses without this in place (I currently do contract work so get to see a new environment every six months). And inevitably I propose a policy and inevitably I am told the company is not big enough to warrant such a policy and that my experience there doesn't translate to their company, and inevitably they ignore that prior to that experience I worked at our small family business, at a small credit union, and for a small county goverment office. And after the experience with the ginormous company, I have worked for multiple similar small to medium sized busiesses, and see the same issues cropping up again and again. But no, they are emphatic, they are a company to which processes and policies offer no value and I just don't understand their culture. Nevermind they hired me and several other contractors at exorbitant rates to come in and fix their mess; I should just shut up and fix it in the manner they made it.
Third, many tech companies are founded on the explicit premise that they will be high growth companies. When "In for a penny, in for a pound" holds true, then so does "an ounce of prevention is worth a pound of cure." I see that being relevant here.
Finally, software engineering is all about codifying applications into software. And yet, developers are often vehemently opposed to the same philosophy being applied to business (or god forbid we have to talk about documentation). Just as the computer is only going to do what it is explicitly told to do, when discordance occurs at a business, the lowest common denominator will be those things which have been made explicit. We all want to believe we are on the same page, but be honest, we often don't fully grasp the other person's position. Often, the problem with communication is the perception that it has occured, when in fact, it has not.
Explicit process and policies may be a chore and when done poorly they are harmful, but that is why one should iterate often and hold nothing sacred. They may seem bureaucratic but I'd rather be called a burocrat while I'm calmy navigating a crisis at work brought on by an external shock while my competitors are in-fighting and paralyzed by a dearth of solutions to problems caused not by the shock but by organizational problems cropping up because they didn't have basic processes and policies in place and so are having issues under circumstances of extraordinary stress.
But by all means, keep on keeping on. There are plenty of contract workers ready and willing clean up that mess, for a price.
I've only ever worked at ginormous companies and the most effective ones are the ones that are transparent about what kinds of policies, processes and guidelines should exist and why, and regularly review them for accuracy and sanity. In some cases, external regulation forces this (Sarbanes-Oxley, FDA CFR 11, DoD ITAR/EAR, etc), and that's a good thing as long as the company's policy/process owner is doing their job properly.
If I get sick my third week week, can I not take the day off? Can I not take a week vacation in my 4th month?
Honestly, I would never work for a company which is already enforcing micromanagement onto employees via HR software when the CEO knows everyone. Which is too bad, since i like the Clef founders.
Netflix, with 200 times as many employees, manages to trust their employees a lot more than this.
Policy here: https://github.com/clef/handbook/blob/master/Benefits%20and%...
I guess every company culture is a series of choices, but it is very hard to be diverse -- which appears to be one of Clef's main goals -- when you only recruit in a tightly limited geographic area.
I think as we keep growing this will definitely change. Would love to learn from someone like you who's obviously been super successful at doing remote well :)
This coming from a guy who worked from home for most of the past ten years, remotely managing a group of 100+ who were located in ten different time zones (including, but not limited to the US, Scotland, Hungary, India, Singapore, China, Mexico and Brazil).
Constant, clear communications and a stated set of mid- and long-term coals is absolutely critical. Get the team aligned, organize your product development, and ensure a consistent, timely feedback loop and you'll be ok. Also, make sure you get all the key players physically together at least 2-4 times per year.
http://stackexchange.com/about/management
http://blog.discourse.org/2013/02/the-discourse-team/
Maybe you have better links? Or maybe you weren't saying that Discourse and Stack Overflow did well on diversity; merely that you think Clef will do badly too? (They seem to be doing reasonably okay right now to me.)
Also, the gender of a company's management team doesn't necessarily reflect the gender distribution of all their employees. And I don't believe Discourse is owned by Stack Exchange.
It changes how seriously I would take his advice.
If someone says "I did X, and without X it would be very hard to do Y.", you would assume that they actually did Y. If you later find out that they didn't do Y, and further that the people they're advising to change their behavior and start doing X are better at Y than they were.. it's a sign you might feel free to ignore their advice.
Wanting diversity doesn't mean having unlimited willingess to sacrifice quality of work to get it.
I recently noticed that Slack also doesn't appear to support remote work. Kind of an ultimate irony :(
- It's not a ternary choice between being racist/bigoted, perfectly neutral, or practicing affirmative action. You (along with everyone else) have a set of implicit biases; to curb them and better yourself, you have to take into account things like gender, color or age.
- How do you not know these things in a small startup?
Which you can correct for without ever meeting the person in question or taking into account their gender, color or age.
How do you not know these things in a small startup?
I don't understand. Does starting a company suddenly make you stupid?
I work with a team that deals with a highly complex domain, and for us it is absolutely essential that we are close to and regularly interact with the rest of the business.
This can't be replaced by remote work unless I create an extra layer of analysts to tell the developers what to code, which is both highly inefficient, removes a lot of potential innovation that comes from the synergy between people looking at the challenges for different angles, and a lot less fun for everyone involved.
For me, what happens between developers and non-technical coworkers in the hallways and during lunch is an essential part of the process of making great products together that cannot be replaced by remote work.
(To be clear: within the dev teams we are completely set up for remote work, and any developer can work from home at any time without prior permission. It's certainly not a matter of lack of trust or facilities.)
As a small team, things move very quickly and decisions are made or reversed as new information helps guide us. This makes it really hard to keep up with company progress for anyone who isn’t in the office participating in all of the conversations that are going on. As a result, we put a high premium on physical colocation, even though this limits the geography that we can recruit from.
I think this is a common misconception and tools like Slack (or previously IRC) and smart scheduling of skype conferences can go a long way to helping. It's worked great for our team. Our size varies, but up to 14 people collaborating from around the country and world.
Remember, working remotely reduces environmental impact, gives your team more family time because you eliminate the commute, diversity has also been mentioned, larger hiring pool, multiple languages is often a nice side-effect and it gives you multiple time zones which is great for support teams.
Could it be that hiring remote forces you to be more conservative in choosing developers, favoring ones with ultra strong resumes (in the general sense, not strictly thing written in a PDF), therefore making you pay more for talent and passing on people which could have strong skills but less experience?
It seems reasonable that having people come into the office every day lets you judge them better and quicker, especially if they're not expected to be 100% autonomous. This would lower the risk of hiring someone you think has potential but hasn't proved it yet, which could turn out well for both the employee and the company (as he will be - fairly - paid less).
In my daily work at Pivotal Labs, also in NYC, I am embedded in a TDD, pair-all-the-time team. But I also frequently interact with the fully distributed Spring development team via internal Slack channels.
I don't think one approach strictly dominates the other in general. It's contextual. For example: I have ADHD. I have discovered that I actively dislike working alone. Pairing is a godsend for me.
Sure, remote pairing is possible. We have one Pivot with around ten thousand hours of remote pairing experience, and others with hundreds to thousands of hours of remote pairing experience. For most cases it is not as good as a single team in a single location and most of our remote pivots spend time in our offices.
It was tough. The big stuff, like getting projects pushed to our office (mainly previously outsourced stuff) wasn't hard. The boss made a phone call, and that was that. The small stuff was hard, the stuff from the employee perspective, many fresh university graduates, was hard. From interviewing to employee on-boarding checklists to establishing a training curriculum to benefits, rewards, mentoring, performance measurement. That was hard. Being part of a mega-corp didn't make this easier. Sure, there was stuff like a solid IT infrastructure and policies established from a leadership perspective, little implementable value existed as a turn-key solution, it all had to be adapted, mixed and changed.
Which was in great contrast with my first company, where very clear, consistent and gradually adapted policies existed (it was a small company, 1000 people, with a 400 year history and very very few people ever left).
Around a year later one of the internal consultants advising the department (and me, in particular) created a global roll-out of a 'minimum standards' type document to 20,000+ employees documenting everything discovered to be undocumented. I still refer to this handbook that covers all that needs to be understood in operations management to a minimum level (800+ pages).
Putting Clef's handbook on Github is fantastic. Not all of it might be applicable for everyone, but it is something where often there's nothing. But do think carefully, does this apply for us? If not, write it down.
Six months to earn 5 days of sick leave. Why is sick leave a privilege? You're either sick or you're not.
If I get the flu 3 months in, do I just take my two days off then come in and infect the office?
None of the companies I've worked for has set a limit on the number of days you could be sick for, nor encouraged anyone who didn't feel healthy to come in to work. I appreciate that some companies may do that, but I've never really understood how that works, given that illness is (mostly) not something you can control.
Further, an open expectation of 45-50 hours at a place that also encourages spending 4 of those hours on self-study seems fine compared to the risk-adjusted industry average.
Requesting is different from informing. "May I work from home tomorrow?" is not the same as "I am going to work from home tomorrow."
It seems reasonable to think this is codified this way because the alternative language of informing doesn't imply suggestion (b), but sure, it could also be due to the founders being control freaks.
In my experience, "you must ask for permission" is substantially different from "you don't have to ask, but your decision may be overruled". It sounds like your experience is different.
Perhaps the differences I see can be put into another context. Think about the action "eating off someone else's plate", rather than "working from home". Do you see the gap between informing and requesting in that circumstance? The difference seems huge to me.
Putting it in writing up front for employees is crucial and good.
I, like you, think that working so much will take too big a toll on your life, if you do it long term. But it could make sense short term, depending on you personal situation.
I think it's good that they're upfront about it, and gives me a general sense of confidence in the document. An employee applying for a job at Clef will be able to make an informed choice, which is great, because information scarcity makes taking a job a huge leap of faith...
I am curious how solve that bit when the company grows, in terms of numbers of employees, or in terms of valuation.
Also, if everybody is getting the same valuation in the long term, are you re-inventing the idea of a cooperative?
https://github.com/clef/handbook/blob/master/Hiring%20Docume...
"Finally, the candidate should come in for a whole day of talking to and working with the team.
..[after lunch] back to the office for one on ones with everyone."
Wow, I wonder how much they compensate you for a "team fit day".
I work for Pivotal Labs. For engineering hiring we do onsite pairing interviews that last a day, divided across two teams. Whenever possible, which is most of the time, on a real task on a real project.
The disruption is worth it, because engineers get to pick their peers.
Direct Reports.md Internal Transparency.md Objectives and Key Results.md One on Ones.md Product Manifesto.md Welcome to Clef.md
It should look like this, organized in the order you want people to read it (this is my best guess, another order might be better):
00 Welcome to Clef.md 01 Product Manifesto.md 02 Objectives and Key Results.md 03 Internal Transparency.md 04 Direct Reports.md 05 One on Ones.md
http://www.theguardian.com/women-in-leadership/2013/oct/14/b...
"We interview for culture/team fit" also typically signals a desire to avoid diversity.
It's preferable for both employee and employer have the right of free association. If it's not working for either side, just end it. See "‘Give Away Your Legos’ and Other Commandments for Scaling Startups" for a recent examination of this in startup hiring.
As organizations tend to grow larger, they tend to accumulate less effective people over time, since people tend to hire those who are less effective than themselves, rather than more effective. A counter-balance is necessary to preserve organizational effectiveness, which includes making it possible to fire genuinely ineffective people without a lot of hassle and drama. Some countries have truly ridiculous firing processes that involve a committee of one's peers, and the whole nearby office gets dragged into one person's poor performance.
Employers and employees don't owe each other an obligation to keep providing compensation or labor. If a company is unfair in its management practices, and undervalues effective workers, then that company will flounder in the market compared to companies that value them appropriately. The problem will fix itself over time, without simultaneously saddling down fair and appropriate companies with the baggage of making it hard for them to fire their bad people.
It has nothing to do with innovation and investment and everything to do with managers' desire to maintain their dominance over their employees.
>Meanwhile, poor performers stir dissatisfaction among other employees, especially effective ones. This makes it harder to start new companies and grow.
Not half as much as authoritarian managers do, and easy-to-fire policies guarantees authoritarian managers.
>It's preferable for both employee and employer have the right of free association.
Only if it were an equal relationship. Which it patently is not.
>As organizations tend to grow larger, they tend to accumulate less effective people over time
You know what kind of organizations do that the most? The ones that know that they can dispose of their employees at a moment's notice for any reason, without reason.
Organizations that can't fire indiscriminately tend to be a bit more careful about hiring. Which is good for job security, which in turn is actually good for efficiency and good for innovation.
Though I don't agree with everything in the Clef handbook, it was an extremely informative read. It's hard to spell out inclusion in words, but this seems like a solid start.
This article[1] has some good things to say around this.
[1] http://ideas.ted.com/the-secret-ingredient-that-makes-some-t...
My experience has been that most people are very empathetic to "their people" and much less empathetic to everyone else, so I suspect you'd end up with the same people you'd get if you took the "hire more people like us" default.
I think the point of that advice is to remind that for an astounding amount of people empathy is not at all a priority! It may be even seen as a weakness, in an unspoken way. Humanity and empathy should be a core value on a company's banner precisely because it's fairly explicitly discouraged by default in personal and work culture at large.
I certainly agree with that; I personally put effort into appearing less empathetic and less respectful than I normally am when I'm trying to get a job, just because I am more likely to get the job when I do that; my theory is that it matches most people's heuristics for "confidence"
(I mean, there is a cost... I'd prefer to work at a place that didn't value "confidence" - but not as strongly as I prefer to work.)
But yeah. I'm pretty sure people who are interviewing have no real interest in empathy or diversity. Hell, listen to just about anyone talk about "cultural fit" - everyone has an idea of what their new employee should look like, and there's not a lot of diversity (either in the 'inclusive of protected classes' sense or the "diversity of thought" sense) in that idea.
"Culture Fit" is a really problematic state of mind. I totally agree that it locks in on a 'type' and reduces diversity. It's a dangerous, ego-maniacal, and lazy way to hire.
It sounds like you make the same mistake as everyone else, thinking there is some connection between confidence and technical skill.
Appearing confident is completely unrelated to programming ability. confidence is a skill one needs to learn separately.
I'd argue that it's a lot harder than you think - you might be able to spot what you recognize as empathy, which is likely specific to a particular culture or personality type. Even at that, under the pressure and power imbalance of an interview, your hypothetical empathetic person might be trying their best to appear calm and focus on responding intelligently.
For instance: I'm on the autism spectrum. In an interview, my empathy might be masked by a general nervousness around newly met people, or by unintentional gaffes of body language. I could very easily see myself showing up as a false negative on your empathy test in an interview.
Another case: a highly qualified candidate from a high-context culture, who might be inclined to demonstrate deference or politeness as a form of building accord with their interviewer. If you're looking for a more effusive, gregarious "personableness", this might too show up as a false negative.
Me too. I find nervousness is generally a positive indicator for empathy.
> If you're looking for a more effusive, gregarious "personableness"
I'm generally not. In general I look less at how someone interviews and more at choices they've made. How people behave in an hour isn't as interesting to me as how they've behaved over the past years.
And go out of business.
http://www.dailymail.co.uk/femail/article-1168182/Catfights-...
2) Daily Mail, really?
Put your handbook out, watch your target end users learn who you are and check out your products.
The end users feel like they really know you and feel more positive towards your products when they come to choose a vendor.
Am I the only one who would rather work for an exclusive company than an inclusive one? Inclusive makes it sound like the company will hire anybody, regardless of the value they bring to the company.