Thursday, April 23, 2009

Pick Teams, Place Bets

I posted this first on iAccelerator.org

“If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea.” Antoine de Saint-ExupĂ©ry via Marc Hedlund

That has been a favorite quote of mine since I read it on Marc’s blog a couple of years ago. I’ve known Marc since his days with Popular Power. When he and my college friend Jason Knight founded WeSabe I came in as a small angel investor.

Marc has also been a guest speaker at the YCombinator weekly meetings, and as I’m preparing for the teams coming in to the iAccelerator, I called him this morning to ask for some advice on how he has dealt with startups, and his recommendations for me.

Some VC running a venture training program at Stanford said that most of what he does is pick teams and place bets. They add value by making connections, and getting involved a bit. But, they’re very explicitly not trying to run the companies. Marc told me this when I asked how to train teams to run board meetings. Marc’s main point was that the information founders share with investors at a board meeting should be the same information they already collect just to run their company. “What do we really need to know about our business to know if we’re succeeding or failing”

Much of Marc’s advice felt like this. When I asked whether he recommended having teams give tech talks he said that he had tried it a couple of times at different startups with varying results. The first time an engineer suggested it and the culture embraced it. Another time he mandated it, and the team rejected it. Asked whether I should train people in a specific development methodology such as Agile, he recommended that instead I bring people in to talk about their experience with different development practices and help teams evolve one that fits them. On whether there were standard tools all teams should use he mentioned that at WeSabe they use CampFire extensively for company collaboration, but they’ve tried BaseCamp a few times and hadn’t really got traction with it until recently.

Ultimately, Marc’s advice comes down to ‘listen’ understand whats actually happening, collect and present information. Advocate rather than mandate the changes you want to see.

Sometimes I describe my vision for the iAccelerator as a ‘Startup Factory’ where all the companies coming thru abide by ’standard’ processes and use common tools. I imagine multi-colored story cards marching accross Kanban boards behind each of our teams. And that we’re all using Salesforce, Basecamp, Trac, Git / SVN, etc. which allows teams to track their own progress, and us as external stakeholders to quickly and uniformly monitor the different companies we’re engaged with. The combination of all these things gives us a consistent brand of what it means to be an iAccelerator team.

And honestly, I feel there maybe times when this is appropriate. But, Marc and the VC seem to argue heavily in the direction of picking really great people and then giving them the latitude to express their brilliance in the ways which are comfortable for them.

From this quote on the YCombinator ‘about‘ page, it seems Paul Graham takes this position too.

We try to interfere as little as possible in the startups we fund. We don’t want board seats, rights to participate in future rounds, vetoes over strategic decisions, or any of the other powers investors sometimes require. We offer lots of advice, but we can’t force anyone to take it. We realize that independence is one of the reasons people want to start startups in the first place. And frankly, it’s also one of the reasons startups succeed. Investors who try to control the companies they fund often end up destroying them.

2 comments:

Parag Shah said...

Hi Freeman,

I agree with the "no interference" policy. However, would it be also incorrect to mandate that the teams use some project management tool, some vcs, some code reviews, some continuous build system, and then let them decide which one and how to deploy it.

I know it is not strictly hands of, but I think most teams would want to use these anyways. Teams that do not want to use these systems, might have decided so due to lack of experience.

If mandating that a team uses some system seems a bit strong, then an effort must definitely be made to educate the team about the implications of their decision

My 2 paise.

--
Parag

Anonymous said...

Awesome post!

Couldn't agree more. I am a founder of a startup which got destroyed by our over zealous investor. He would meet with us every week and almost try to delegate work to us. In the end we founders simply quit and left the company to him.