This post boils down to one statement: "every 100 days we have a 20-day-long crunch time". I'm all for getting things done, but scheduling arbitrary crunch times is a great way to wear the team down until people quit.
This system works for us, but may not work for others. Either way, I don't think it produces burnout. Empirically, this hasn't been the case. We're 2 years in and I've never had burnout been an issue. For a few reasons:
The people on our team like work to have an ebb and flow. There are times when we're pushing 100% and times we're reflecting. The 100 day horizon is actually quite long so there's time to refactor, vacation, and reflect.
We do our goal planning bottoms up. Almost every one of our goals has originated from the engineering team. 100 Day planning sessions are an opportunity for individuals to lobby for their project. It feels great to push your own project and it feels great to pitch in on someone else's.
We do unlimited vacations (which everyone says) but our team actually takes advantage. We don't have a culture of martyrdom, so people don't feel bad. I've found more people take time off in the beginning of 100 day segments than the end.
Agreed. This sort of advice is great if you're the founder/owner, because you're the one standing to get rich when somebody comes in with a buyout offer.
If you're an employee at such a shop, though, this is a sucker's bet. Most likely your hard work is paid off with a bunch of feel-good bullshit about how you're changing the world, and the expectations that you'll do it all again in three months.
Having a crunch time (especially scheduled) is a tacit admission that you are not, in fact, reducing scope properly.
Startups are machines for learning. This isn't limited to learning the market and finding business fit and reproducibility, it also applies to all the participants, whether they are founders or employees. No corporate job is going to let you become a DBA and a Frontend Developer and a Backend Developer and a Product Manager all at once, in a production environment, with no safety net. There is no other place where you can learn at that depth, and there is no other place you can learn at that rate.
There is also something to be said for the experience of personally identifying with a goal, no matter what that goal is. The other people at your startup will quickly become your best friends (sure, maybe that's because you are spending all your time with them at the expense of your other friends). You work together, eat together, play together. The level of camaraderie and sense of membership that develops can only be compared to military service (I've done both, and it is very similar).
If you are lazy, or you don't want to sacrifice in exchange for an amazing experience where you will learn and grow more than you ever could anywhere else, then you shouldn't be working for a startup. There are plenty of big companies that will pay you a decent salary and let you stagnate, work 10-4, never expect or require of you any growth, and let you phone it in until you eventually die. Good luck whichever way you decide to go!
All I can say is, good luck with that attitude when you get married and have a family. Your perspective on what is important in life will completely change.
Believe it or not, you can be serious about your career without sacrificing your personal life.
You both seem to be guilty of universalising your own work values and denigrating the choices of others as either "lazy and don't want to learn and grow" or "too immaturely self-oriented!"
Take it from the Bard: "There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy"
> No corporate job is going to let you become a DBA and a Frontend Developer and a Backend Developer and a Product Manager all at once, in a production environment, with no safety net. There is no other place where you can learn at that depth, and there is no other place you can learn at that rate.
You mean breadth, not depth.
> Good luck whichever way you decide to go!
Wow that was disingenuous. There are non-startup jobs that do not suck, and at any rate, the goal of a startup is to become a big company. You just have a personal preference for working at early-stage, high-growth companies, which is fine.
Specifically, the definition is: "pervasive pattern of negativistic attitudes and passive resistance to demands for adequate performance in social and occupational situations"
Example: Letting the air out of someone's tires. This is an aggressive act. It's not passive aggressive, because it's not passive. It is sneaky and cowardly, which has nothing to do with being passive.
Example: Your manager is on the hook to have feature X ready on Monday. He has annoyed you by buying the wrong brand of coffee, so you read HN all day on Friday and avoid working on the feature. On Monday your manager looks bad for not delivering the feature on time. This is passive aggressive, because it was via withholding of sufficient effort that you managed to harm someone.
That's only the DSM-IV definition. Psychology is a lot bigger than that, and the English language is bigger still. The difference between passive aggression and aggression boils down to whether the anger is being expressed directly or indirectly. It isn't solely determined by inaction, and there's a spectrum in-between the extremes. Letting air out of someone's tires is passive aggressive because it avoids confrontation while causing harm, whereas going up to the driver and punching them in the face is aggressive and does not avoid confrontation.
Faking niceness is similarly passive aggressive because it avoids confrontation while causing harm. Adding sarcasm into the mix, admittedly, makes it more aggressive, but it's still more passive aggressive than being straightforwardly aggressive in the first place.
Regardless of whether or not I'm right, regardless of whether your comment was disingenuous, passive aggressive, aggressive, or sarcastic, I'm unhappy that you're openly and unapologetically being uncivil on Hacker News, it's against the guidelines, and I'd like it to stop.
So you are upset because I am breaking the rules, and not because we are arguing in this thread?
Now who is being disingenuous?
As for your "definition", passive means a lack of action. No amount of arguing will make you right.
The convincing argument you might have given, except you are clearly not able to admit even slightly you were ever not perfectly correct about something:
Language is defined by usage, not definitions in books. People can't use a phrase wrongly, it means what they meant it to mean, the only question is whether it is an effective way to communicate when other people will interpret it differently. In this case, the dictionary definition is never meant, what people really mean when they say passive aggressive is "weak, not physically aggressive hostility".
Incivility is against the guidelines. Civil arguments and debate are fine. Normally I'd be happy to discuss the nuances of aggression and passive aggression, but the tone of this conversation has become overly hostile and I don't want to participate any more.
I disagree with you as to what passive aggression means, in that you have a narrow view and I have a broad view, but there's likely many mental health professionals who actively rely on the DSM in their work that would agree with you. I will certainly keep that in mind when I use the term in the future, so thanks for pointing it out.
I have decided to follow your lead and take a 'broad view' of what 'incivility' means, which is to say the real definition and it's direct opposite.
Good luck on taking the high road, or whatever it is your posturing is meant to convey!
Oh, and if you are going to pretend my definition is just the dsm 4 super narrow version (as if you had any idea of that before you looked it up on Wikipedia to try to debunk what I said), try googling 'passive aggressive definition'.
Not true at all. I work for a 107 year old family owned printing company. I get to be the DBA, Frontend Developer, Backend Developer, and Product Manager (our LOB applications). And it all leads from test to production. So you are just plain wrong. And there are LOTS of companies out there that have people doing what I'm doing. Lots of manufacturing businesses in the $50-$400 million dollar a year range have small in house programming staffs that have to be jacks of all trades. Doesn't always work out so well when people expand knowledge begrudgingly, but those who really have a passion for learning can have a long interesting career solving all kinds of problems that truly make a difference to the company bottom line.
There are also companies that give you room to learn and to grow, help you advance your career in the direction you want, and also let you work reasonable hours.
What? I'm doing it wrong because I work 40 hours a week at a job I love, then go home in time to go for a walk in the park, read a book and watch the sunset, play a sport, and see friends?
I'm glad whatever you're doing works for you, but don't assume everyone else has similar needs.
This is startup management 101. As a startup, you don't have a large HR team, so you need to engage in practices with strong selection bias.
In other words, "we run 100 day dev cycles with 20 days of an intense crunch" will cause people who thrive in a fast paced, results-oriented startup environment to self select.
It'll also eliminate people who don't like this environment.
The practice of 100 day cycles with 20 day crunches is tangible, real, and allows people to make a good decision about whether or not this company is a good fit.
It's much more effective that asking, "do you work hard", "do you work long hours", "do you enjoy a fast paced environment"...
"wear the team down until people quit" should be refined to: wear down people who should not be a part of our team until they quit, thus opening a spot for a someone who's a better fit for our fast, paced, result-oriented, win-at-all-cost environment.
I'm sure the length of the crunch varies. And in a startup situation having a crunch every 100 days doesn't seem totally unreasonable to me. Also, people's versions of "crunch" differ... one person might picture 60-hour weeks and another might picture JWZ taking catnaps under his desk every 48 hours.
I recently did a challenge of 100 days of commits to side projects and I'm now at day 96. I think this was awesome for me, as it kept me really focused on my projects, even if some days I had only small commits.
I think my next challenge might be even more focused and look to launch one of my prototype projects in a specific amount of time. This will force me to focus and launch something, even if it isn't perfect.
My constraint is a bit different. All I have to do is work more than last week's day. For example, if I achieve for Monday 3.01 hours. All I have to do for this week Monday is to achieve 3.02 hours. It has gradually pushed me from 6 weeks ago of 23 hours to 30 hours this week.
Once I reach my goal of 30 hours a work week, my goal is to merely maintain the momentum and shift most of my workload 2-3 days so I am not working all week all the time. (Although, some activities must be done everday, such as studying)
A 100 day challenge doesn't make sense for an established company (why would you do that to yourself?)
But for a startup, it makes total sense. You're moving quickly, and 100 days is enough time to make substantial progress while keeping yourself accountable to actually shipping. I think it sounds like a perfectly viable strategy. Definitely not for everyone.
There seems to be something deeply effective about setting arbitrary constraints. Obvious examples abound: haiku, twitter, 80-char code, screenplays in fixed-width Courier, 25-minute pomodoro, text-only man pages. Also, the metronome of practicing music (cadenzas don't count), the fixed 8 hour workday, the 12-tone music temperament..
I've wondered what a piece of software could look like with each function/codeblock written on 1 index card each. Linus seems to prefer one-page functions for C, but I like the extreme of the index card.
My first CS teacher in high school required index-card size functions (actually procedures because it was Pascal). It's helped me immensely over the year, because those 5-10 line functions end up growing into 100 line behemoths as features get added.
Starting with smaller bits gives you a longer mean-time between refactorings.
This is how I've gotten around my own productivity faults: not with a particular arbitrary date, but by publicly promising to a point of no return. It's incredible how much I've been able to do by setting expectations without too much estimation. By promising what I want to accomplish rather than what I think I am capable of accomplishing, it tends to push me to be more productive than I thought possible.
On one hand, making deadlines as short as possible is a great idea. It's too easy with one-year or two-year projects to six months arguing about infrastructure, requirements, and standards and end up delivering late or not at all. Every project should be required to deliver some value in the first couple months.
On the other hand, three or four twenty-day crunch times every year is not sustainable. Unless they're planning a Logan's Run-style turnover of their current team.
I think it will cost about $7 to print it and $5 to ship it (free shipping is included, internationally as well I believe) so this is about what I expect my cost to be.
I've spent a lot more than 100 days listlessly wandering around with no direction, and I think 10 instances of 100 days aiming in deliberately wrong directions would've been more interesting, and I'd have learned more.
(Exception is if I got into horrible debt or did/received some sort of lasting damage).
