Hacker News Reader

Comment by wccrawford | Hacker News Reader

I can't help but think this requires that only 'rock star' programmers be on the team. 1 bad apple would start to throw everything off, and a few could derail it.

It also requires that everyone have the same vision, or you end up with a very fragmented product, see as how you allow each developer to decide what to work on.

Don't get me wrong, I would love to work at a company that is succeeding at this... I just can't imagine how to keep it succeeding.

Seeing as how it requires the developers to act like they have a stake in the company, perhaps a better title would have been: Driven Developer-Driven Development

View on HN

I dunno about 'rock star' (although I'm a pretty amazing drummmer…) but yes, the talk centers around hiring the most driven people possible. I don't think any of us act like we have a stake in the company — we do.

I'd highly suggest reading Drive by Daniel Pink. The entire book is about how people are motivated. It would definitely answer almost all the points listed.

looks interesting, thanks for the tip

> I'd highly suggest reading Drive by Daniel Pink.

This video shows Daniel Pink delivering an 18-minute presentation at TED on the same topic: http://www.ted.com/talks/dan_pink_on_motivation.html

> I can't help but think this requires that only 'rock star' programmers be on the team.

"Rock star" developer can mean a lot of things.

What's required here (aside from everything listed in the prerequisite section of the slides) is that developers have a sense of ownership of the product. That's it.

You can foster this by literally giving them percentage shares of ownership. Some developers naturally feel this way about everything they ship. Some developers will never feel this way unless they own a majority interest in the software.

+1 for Driven Developer-Driven Development. This works with small teams where each contributor has a solid track record, or with a group that has worked well together in the past. Open source projects can get by with a few bad apples as long as the core contributors are solid. I think you can use this model within small companies, but only if you are confident in the reliability and talent of each team member.

If some percentage of your team is unreliable, requires training, or likes to do their own thing (unavoidable at larger companies) - this can backfire.

If the team has signed up for a goal or deadline, the vision bit is important - it can be difficult to keep a loose team of rock stars on target without some structure.

Using "rockstar" reminds me of awful job advertisements for awful companies.

Reply on news.ycombinator.com