3 ms·

I think everyone in the company, at an early stage, should have a mindset of ensuring things are getting done, rather then working X number of hours. It should

I think everyone in the company, at an early stage, should have a mindset of ensuring things are getting done, rather then working X number of hours. It should never be about the number of hours your working - some weeks it may be 100 hours, then some weeks it may be 30 hours. It should always be about building a great company and finding those people that are passionate about the same, family or not. Also, it is discrimination to actually not accept candidates based on whether they have kids or not. We never ask family/personal related questions in our interviews, as it is against the law to do so.

oppositelock 13y ago
As one of those older, experienced coders with a family, I'll tell you right now that statements like "it should never be about the number of hours your [sic] working" immediately sets off my skepticism. Part of having a family is that you have responsibilities outside of work, and these are not responsibilities you can change easily like a job. You can't honestly commit to a job with open ended hours requirements. You can occasionally do long work weeks and sacrifice your family, but that builds a relationship debt you must pay back in the future, so it'll happen very sporadically. I've been around silicon valley for two decades. I know how fast I work, how startups work, and how to contribute to a team. I know that if you hire me as an individual contributor, I will be ahead of you in line for equity losses and behind you in line for financial rewards, which affects my motivation. If I'm doing my own startup, then the situation is entirely different and I will move heaven and earth to get the job done, and try to make it work with my family, but this isn't something that can be carried on too long without burning out. One day, you will find that even when people pull 100 hour weeks willingly, they stop being effective at half that load, and end up making mistakes from exhaustion. They slowly burn out, quit, get cranky, and you have big emotional explosions at work about the workload. If you want your company to succeed, and retain good people, you have to find a way not to burn out your people, and this applies to any age. Crunches shouldn't last more than a couple weeks and should be an exception to the norm.

oppositelock 13y ago

As one of those older, experienced coders with a family, I'll tell you right now that statements like "it should never be about the number of hours your [sic] working" immediately sets off my skepticism. Part of having a family is that you have responsibilities outside of work, and these are not responsibilities you can change easily like a job. You can't honestly commit to a job with open ended hours requirements. You can occasionally do long work weeks and sacrifice your family, but that builds a relationship debt you must pay back in the future, so it'll happen very sporadically. I've been around silicon valley for two decades. I know how fast I work, how startups work, and how to contribute to a team. I know that if you hire me as an individual contributor, I will be ahead of you in line for equity losses and behind you in line for financial rewards, which affects my motivation. If I'm doing my own startup, then the situation is entirely different and I will move heaven and earth to get the job done, and try to make it work with my family, but this isn't something that can be carried on too long without burning out. One day, you will find that even when people pull 100 hour weeks willingly, they stop being effective at half that load, and end up making mistakes from exhaustion. They slowly burn out, quit, get cranky, and you have big emotional explosions at work about the workload. If you want your company to succeed, and retain good people, you have to find a way not to burn out your people, and this applies to any age. Crunches shouldn't last more than a couple weeks and should be an exception to the norm.