Having said that, what I don’t buy is the premise that you as a professional must be given free range to do whatever you want, on company time - just because. We don’t let policemen indulge in random acts of vigilante justice, just because they wanted to try it. Yet, often times, that’s where our industry ends up and hence the startup roadkill all over the roads.

I’m coming at this from a business perspective: first of all, if you are honestly finding the daily work of a startup you’re involved in as mind-numbing work, do everyone a favor and quit now. I don’t mean this as a judgment, I just think that you should find another startup where your personal interests coincide with the product being built. If you love what you do, and you get to do it on a daily basis, how can it be a drudgery?

Last but not least, most companies are more than happy to see their people grow - courses, conferences, team lunches. The key point being: it betters the person, and the business. What I’m trying to caution against is random acts of shoot from the hip: “hey, that new app-server looks nice, let’s port all of our stable infrastructure to it!”

On the one hand, I believe we need technological indulgences to keep our creative spark alive and to be able to bring new ways of thinking, tools and practices to our work - all good.

On the other hand I now find that the striving to improve my craftsmanship at software development is often sufficient indulgence for me. I mention this because I now take pride in effectively refactoring crappy legacy code, automating builds, applying TDD etc. The indulgence has shifted from the tools I use to the way I use them.

In the end, I think we need to get buy-in from stakeholders that technological (or other) indulgences are ultimately beneficial to the organization. This provides a focus and context to the indulgence and allows for a win-win.

If organizations do not see the value in the indulgence or the work remains “mind-numbingly boring” then perhaps it’s time to indulge in a career move instead.

I guess I’m saying that I don’t have the answer, though I’ve looked quite extensively. The Fifth Discipline by Peter Senge would second your question. So would a lot of other books that discuss creativity and productivity. Peter Drucker was probably the first to come out and start thinking about knowledge workers, handling them differently, giving them leeway for curiosities. John Seeley Brown, a former head scientist at Xerox’s PARC, defends the need for curiosity with a need for delivering the goods in some of his writings, lamenting how they dropped the ball on some of the major technological breakthroughs of the last couple decades. Gerald Weinberger, the guy who ran the Mercury project (first man in space from the US) deals with this in at least two of his books. If all these heavy hitters are this concerned about this issue, maybe it’s right at the heart of all of our careers.

I do think, however, that the reminder to keep things lean comes at a very good time for me. If we all got into technology from curiosity, then the parts we need to be sure we can do well are relax and keeping it lean.

Felipe, 37Signals had an insightful view on this (I think): you obviously need vision of what you are building, but also don’t worry about satisfying and logging every user request. Your users won’t let you forget about the features that really matter.

Re: unique feed. Awesome, and thanks!

David, the only cautionary note I would add around it: you see a lot of startups fizzle after they get their funding. Sometimes, that cash creates a false sense of security - as if, you’ve already got it made. Wrong.

Declan, those are great tips. We’ve been using sprint burndowns, but I like the idea of a release (or even further) burndown chart - definitely something I’ll try in the future.

It’s also interesting that you’ve brought up the stifiling angle, because that’s the most common response from the developers: “but where’s the fun in that?” Somehow we equate product focus to rote execution, which is obviously not the case.

I agree with Elise that a clear vision is critical. What is helpful for team alignment on this is to have a product/project charter that clearly spells out the vision and SMART objectives for the team. Print this out in a really big font (or just hand print it) and put it somewhere visible. Then when you are questioning what you are doing you can quickly check it against the vision and objectives.

If you can foster a strong commitment to agility on the team then this issue becomes less of a problem. In each planning session the product owner should be clearly deciding what is valuable in terms of stories before the gear heads start thinking about the high gloss technology. To encourage this business line of thinking use another big visible chart, a burn-down or burn-up chart. If people start to stray they will quickly notice the trend and can reset back. Keep reminding developers that their role is deliver business value and that successfully doing that will reap much greater personal and team rewards than the quick technology fix.

Now all of this may appear stifling to developers who love to live on the cutting edge. So allot time for research, book clubs, lunch and learns to fill that technology craving. Use time-boxed spike tasks within iterations to test how new technology could be used to further the product.

As the world moves toward more open and free markets, competition is the driving force that will mandate more effective methods for solving problems. The analogy between Darwinian variation-and-selection and free-market dynamics is apt. Those entities that fail to acquire the necessary resources will go bankrupt, the economic equivalent of death and survival of the fittest.

I think your comments on time and strategy are exactly the issue here: we have so many resources, we can stretch them, waste them, master them, or whatever. Bringing that perspective to the keyboard seems to be the best place to have it.

Choose which feature to implement now? That’s the big question. Another thing that can make this even harder is another question: “What users want in my product?” specially in Web startups.

One more thing: your blog feed is unique and highly recommend for anyone who wants to develop or create a startup. And you’ve made me start playing around with machine learning, SVM… (my professor can’t hear that, since I’m working almost full time with a XML research project) :P

Just wanted to give congratulations =)