Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's the sprint versus marathon mindset.

A small startup has a finite amount of time to either become a big company in their own right or do something so noteworthy that a big company sees the need to acquire them. Nothing else matters. There are minimal incentives to invest in the long-term welfare of your employees because in the long term, the company doesn't exist. You can't even guarantee that an acquisition will keep the employees you have invested in.

Large corporations like Google are incentivized to give their employees reasons to stick around. They can expect the company will be there in 30 years, and they can expect a good employee to put in a career's worth of work for them (and eventually have peer and mentorship contacts that encourage other good potential employees to join the company).

This is painting with a broad brush of how the incentives are structured... Not all big companies see it this way and not all small companies see it this way. But it's the behavior the marketplace appears to reward.



Re: It's the sprint versus marathon mindset.

As someone who did track in high school, the whole agile nomenclature around "sprint" continues to rub me the wrong way. If you aren't a startup facing a launch-or-fail moment, the approach should be much more that of a marathon.

I was joking with my wife that "sprint" to me implies that you go all out and then take a long break before you go again. We should be treating the longterm plan like a marathon and the intermediate steps like "splits".

If you are working on a product that's been around for years , the idea that you are an all-star for delivering your 5 points the day before your 2 weeks sprint ends and a lazy jerk if you deliver it the day after sprint ends just incentivizes a lot of shorterm-ism and corner cutting.

The model of working "all out" and your "break" for planning is a 2 hour meeting in between sprints where you get praised or scorned for a 10% difference in delivery speed is..


Splits works, but I tend to use iteration. There are benefits to breaking work into chunks and checking in how it's going every 2-4 weeks, but there's no reason to be in perpetual crunch time. There should also be free time at the end of every iteration to do some problem/design/idea exploration.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: