This looks like the work of a bit of a control freak. It seems odd to codify so many things in so much detail. It seems they are a pretty small and young company (the handbook has multiple references to being less than 10 employees, their Twitter account joined in 2012), 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?
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.
While I commend Clef for releasing this publicly, I do agree that many of these policies are pointlessly rigid for a small company. In particular, the vacation and sick leave accrual seems unnecessarily draconian.
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.
> 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.
> 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.
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 liked your reply so much I had to do more than just upvote. :) Policies get a bad rap because there are so many bad policies, and so many incompetent leaders who hold them sacred. That doesn't mean policies shouldn't exist.
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.
Absolutely zero remote work, yet I built Stack Overflow with a team of entirely remote developers, and do the same with Discourse today.
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.
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.)
His comment was accurate in that you are constraining many vectors of diversity by only hiring from a specific location, even if gender likely isn't one of those vectors.
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.
I just think it is super weird to be completely, categorically opposed to remote work when a primary goal is diversity. It is a severe constraint on hiring, and you want super flexible hiring to maximize diversity.
Its not weird to be completely, categorically opposed to remote work when you've found, e.g., that remote work usually doesn't work well in your environment and that, even where it does, allowing some people to work remotely and not others impacts overall morale in a way which offsets the advantages from the limited circumstances where remote work is useful.
Wanting diversity doesn't mean having unlimited willingess to sacrifice quality of work to get it.
Completely irrelevant, baiting non-sequitur. Your perception of his company's diversity does not change the validity of his point about having a less diverse pool to hire from.
> Your perception of his company's diversity does not change the validity of his point about having a less diverse pool to hire from.
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.
Yeah, at our current size + team composition we don't feel like we have the knowledge/experience to do remote work well. With that informing our decision making, we've decided to prioritize other things (that have different tradeoffs).
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 :)
My $.02 is that being successful with remote workers is a management problem. If you're a good manager and you hire well, you'll have few problems.
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.
Also not sure I agree with the rationale they provide for remote not working for their needs.
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.
Jeff, I didn't know this about SO or Discourse! I follow coding horror, is this something you've written about extensively? We need more voices. The value-leverage remote work has is so huge. Makes it really frustrating that there aren't more people really talking about it (slash doing it).
I recently noticed that Slack also doesn't appear to support remote work. Kind of an ultimate irony :(
Stack Overflow HQ is in NYC, one of the most diverse population centres in the USA and the world.
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.
I do basically all my work as a remote consultant, so I applaud your commitment to remote work, but I want to play devil's advocate.
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).
+1. Unless you're a believer in affirmative action, which I'm not, the ultimate way to work for diversity is to not even know what races, colors, or sexes your employees are.
- 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?
Not sure what the downvotes are about. The documents mention elsewhere that 45-50 hours are the norm. Mentioning it again on the "no remote work" page gives the impression that the authors view remote is unworkable due to hours or that remote workers need to be reminded of expected hours. You can dislike that and downvote it if you want, but it doesn't change that it is.
I'm sorry, but I think these recurring "we do everything remote" are cheap shots from the outliers that produce software that, with all due respect, is relatively simple, usually the "for developers, by developers" kind of stuff.
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.)
I was involved with the setup of a new department in a mega-corp that went from 10 people to 464 people in 1.5 years.
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.
Unfortunately not. The internal classification is 'confidential'. I'm not much a believer of security by obscurity, but that's the company decision and I respect that. When I say refer to (since I left this organisation), I mean mentally. Putting all that in place established some solid structured thinking which I'm looking to share, but that's not ready yet - when it is I will post a link on HN :)
I think it's great to see increased transparency in company procedures, and I will probably steal some aspects of it. OTOH, the implementation is slightly disappointing. No remote work plus "we expect full-time employees to be at the Clef office between 45 and 50 hours a week" is definitely decreasing the pool of potential employees. As a parent there is NFW I would sign up to 10 hour days, but I'm glad the company is open about it's expectations, and they have the right to create the kind of company they want (within the limits of the law).
Perhaps I've just been lucky, but I've been working in the US for the last 15 years, and the policy at all 4 of the companies I've worked for has been: "if you're sick, don't come in".
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.
Came here to say the same. 9-10 hour work days I think shows that the company is too young that they aren't able to invest in a work-life balance. I hope that commitment comes with early employee equity, because time in someone else's payoff is something you don't get back.
Putting it in writing up front for employees is crucial and good.
Man, no kidding. Why would anyone want to sign up for that? 45-50 hours codified face time in your open office cattle farm. Get permission from a founder at least a day in advance if god forbid you need to be out of the office for something. Not only do I not want to work there, but I'll think twice before signing up with them as my 2FA provider.
Permission from one of several founders at a 10 person company is proportionally equivalent to letting your team lead know you'll be absent. That's not exactly an excessive standard, is it?
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.
An expectation of 45-50 hours work is illegal in most of the developed world. This company is legally free to require that, and prospective employees are free to work somewhere else, that treats their staff like normal human beings.
It's the implication of what the rule means. There's a huge difference between "let someone know you're going to be absent" and "ask a founder for permission to not have to come to the office."
> Permission from one of several founders at a 10 person company is proportionally equivalent to letting your team lead know you'll be absent. That's not exactly an excessive standard, is it?
Requesting is different from informing. "May I work from home tomorrow?" is not the same as "I am going to work from home tomorrow."
If you tell your boss "I am going to take tomorrow off", and they say, "Actually, you're scheduled for an interview, can you please come in? But take Thursday or Friday off by all means", you're going to still go to work, right? Informing, in practice, is identical to requesting, and this is really just a language thing that makes it clear that you (a) should inform somebody you'll be gone and (b) you can take any day off except maybe 5% of days have critical meetings or whatever.
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.
> If you tell your boss "I am going to take tomorrow off", and they say, "Actually, you're scheduled for an interview, can you please come in? But take Thursday or Friday off by all means", you're going to still go to work, right? Informing, in practice, is identical to requesting ...
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.
Early phase startups are not known for emphasizing work-life balance. Clef offers 50hrs weeks, 3 weeks vacation, which seems pretty standard to me for this kind of job.
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 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.
I work at Pivotal Labs also. I don't even find it that disruptive to interview candidates on our projects bc I'm still working on what I'd be doing that day. It's certainly less disruptive than marching our entire team one after another into a conference room where they grill the candidate for an hour at a time, which is what most employers do.
One recommendation would be to title each section based on number so that it doesn't default to alphabetical order, which presents things out of the order in which you would want employees to read them. For example, the Onboarding Documents section currently looks like this:
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
IMO a real commitment to equal opportunity would mean no at-will employment (i.e. no firing for undisclosed reasons) and only blind interviews (e.g. online pair programming without speech/video):
Making it difficult to fire ineffective people, or doing so slowly, is one of the best ways to ruin an organization. The friction that exists around firing in many countries seems to be part of why they have less effective business innovation and investment. Companies can't hire someone without significant risk, because firing them will be difficult if they don't work out, and so they're averse to hiring. Meanwhile, poor performers stir dissatisfaction among other employees, especially effective ones. This makes it harder to start new companies and grow.
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.
>Making it difficult to fire ineffective people, or doing so slowly, is one of the best ways to ruin an organization. The friction that exists around firing in many countries seems to be part of why they have less effective business innovation and investment.
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.
I've been spending a ton of time researching how startups build a diverse team with an inclusive culture and honestly have struggled to find much literature on it.
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.
I'm being totally literal. Prioritize empathy for others as a quality you look for in candidates/colleagues. It's not all that hard to spot and interview for, and I think it's crazy valuable in teams. Particularly (this is relevant to my work) when you're not your own user (because you build for a market of users that you aren't.. like tools for doctors or journalists, or I dunno).
This article[1] has some good things to say around this.
> It's not all that hard to spot and interview for
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.
> Prioritize empathy for others as a quality you look for in candidates/colleagues.
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.
That's definitely a danger, and it's not an either-or thing, of course, as well.
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 think the point of that advice is to remind that for an astounding amount of people empathy is not at all a priority!
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.
There are super good points here. WAY too much value is put on "confidence". I imagine because really talented folks are tend to be confident confidence is preferred because talent is harder to gauge. That's a shame.
"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.
Fantastic idea, I'd love to see more of this. Not only does it promote transparency and positive change but it also gives people a leg to stand on if the company doesn't do what they public say they do.
At Clef we’re working to build an inclusive company with a value-driven culture.
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.
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.