I’m at the (horrible) Javits Center in NYC for Web 2.0’s first day. The whole thing seems a bit empty, ill-attended, so far. Maybe more people will show up as the day progresses.
Bottoms Up and End to End: Apply the Wisdom of Crowds to Businesses
Ramez Naam, Microsoft
Session I was most interested in for this time-slot. Might be lame. Generally this room seems pretty empty, and the whole thing seems a little ill-attended?
This talk is about how to organize your biz t make it work better.
Starting with the old chestnut: OSS Field Manual on how to sabotage organizations. Including:
- Insist on doing everything “channels”. Never shortcuts to expedite decisions.
- Refer all matters to committees for further study and consideration. At least 5 people on a committee.
- Advocate caution. Be reasonable and urge conferees to avoid haste.
- Be worried about the propriety of any decision. Should things be pushed upstairs?
So, how do we structure an org to encourage and take advantage of innovation, change?
Hmm, he’s hitting Darwin. I hope we’re not getting to social darwinism here.
And so: Wisdom of crowds beats the wisdom of king, bosses, etc. Okay, sure. Bunch slides about how flat is good, top-down is bad, etc.
Okay, but how does bottoms-up work:
- Clearly articulate a direction, and provide reasoning. (That way, all the rowers know what direction to row)
Eh. My time: wasted. Hopefully the next session (after lunch) will be better.
Lessons Learned in Scaling and Building Social Systems
Joshua Schachter – schachter.org. This guy is one of the founders of del.icio.us i guess.
He build del.icio.us from very small to 4 million users and millions and millions of users.
I’m not Mr. Smart Guy. I’ve screwed up everything you could possibly screwed up so I can share some of that with you.
Three kinds of scale
- Partition systems into multiple users. Sharding, clustering, etc. I build del.icio.us as one big database. It’s a huge painin the ass. don’t do that.
- Caching. Meta caching. Dn’t go to the database if you can help it.
- Replicas. Must have multiple copies of data. Fastest performance having data on disk in the order that you made it. Having your primary keys int he exact format you needed will really help you. 60x performance on the same hardware.
- Proxy: put a proxy in front. Helps out enormously in terms of performance. Guy on a modem in Romania: it takes four mintues for hinm to fetch an item. He;’s occupying an entire slot on the server for tht whole time.
- Slopiness: support the innate slopiness of how people use things. Decouple interactive performance form the rest of the system.
- Different features at different scales. Set of features will be different at different levels, different scales
Small system: push everyone together actively. Larger systems, features around mitigation of traffic, like people not finding each other (like tags, etc. on delicious)
- Coping: AT start of system: minimize barriers to entry and activity. Later on when traffic ramps. you want to increase transaction cost to increase quality of the system.
- Utility, network effect, revenue. Structure things in this order. Make it useful, then get a network effect, and then figure out how to make money on it. For example: you get an evite invite, and it has no info on the event. Annoying. Evite wants the traffic, but it pisses off the users. Too many barriers to entry in terms of utility and network effect, you’ll get spanked. (Hmmm, lessons for SM?)
- Product is self-marketing. Don’t make people log in to see anything at all.
- initial marketing vs. actual functionality. del.icio.us was marketed as online bookmarks for those with more than one comptuer, but in reality it’s a bookmark search appliction.
- identity & reputation: provide ways for people to be continually drawn into the system. let people market themselves using your product as a vehicle. Make people feel good about themsleves by exposing stats on who’s looking, using, etc. They’ll come back.
- RSS!!!!! Badly named, hard to use, power user thing. BUT: half the traffic comes from this. (He also recommends full feeds, not clips. Hmmmm.)
- Infection: Firefox plug-ins was a huge ramp-up for del.icio.us
- Language: consistency. When we added privacy to del.icio.us, button first said “private”. Then we changed to “do not share”. spent a whole week getting it right.
- Fidelity: Ensure that your system will not get users angry at each other. Like: revealing specifically who’s following you. This spelled trouble on del.icio.us (“my former boyfriend is stalking me” etc)
- lengthen or destroy feedback loops: don’t ban users. maybe abusive users get slower responses from server, or aren’t seen by others in the system, etc.
- Pretty URLs! (Yay SelectMinds and URIs in Zev)
- API. Bring developers’ natural enthusiasm for solving problems into your system.
- be lazy: reduce. when you build stuff, you’ll do it wrong. You’ll need to learn from your users, and change things. So don’t spend a lot of time building: it’s wrong. You’ll change it. Build fast, iterate quickly.
- Ideas: write your ideas down. Keep extensive notes, go back and look at them.
- Listen to your users: I used to read every single incoming and outgoing customer support message. (Damn). I spent time reading these things and learned a lot. Tally up requests, and figure out what you can build now to deal with those complaints.
- motivations: what are the users’ motivations for using the system? find out.
- user testing: do it.
- measure and record: everything. what are your success metrics?
Good talk. Keynotes next, in half an hour.
New York’s Web Industry From 1995 to 2008: From Nascent to Ascendent
Kind of a rambling review of internet media history in nyc. but, here ya go.
1995: bay area had 8 times the early-stage venture investments as new york. 2008: just 2 times. so the valley still in front, but nyc growing fast.
Why did this happen? I’ll discuss. Oh, by the way: Death to Silicon Alley! Let’s just call ourselves New York.
1979: Interactive Telecommunications Program starts at NYU. Tisch school.
1989: Connect Times: leads to Jupiter research.
1991: Ziff Davis starts ZD Net.
95: Interactive agencies like Razorfish and Agenc.com
96: Flatiron partners. Got sued for that.
97: Silicon Alley Reporter Radio SHow
97: Razorfish bought a ton of agencies. “This ended badly.”
97: Doubleclick goes public. Yo yo dine gets bought by Yahoo.
98: Kozmo. (Yeah!) WHich was awesome, and which failed.
98: “The last year of sanity in the first internet wave.”
99: Offlin companies want to go online, fueled the agencies. Generally all hell broke loose.
2000: The crash.
2002: Rock bottom.
2003: Renewal. And so on.
The Death of the Grand Gesture
Meandering presentation that didn’t really say anything. I guess the point is that social software isn’t really about a grand event, more about an ongoing series of interactions. Fascinating.
High Order Bit
Jason Fried – 37 Signals
How many of your are in the software industry. (People raise hands.) You guys are really fucking lucky! You don’t have to worry about physics, or anything. You can build it anywhere, inside, outside, hot cold. You’re very very very lucky.
You have to worry about things others don’t. Like, you have to worry about feedback. Software is more difficult to gauge reaction. Software is there, and expands, and expands, and that’s one of the things that makes it bad.
So, what would your software be like, if it was physical? WOuld it be spikey? Comfortable? Fit in your hand nicely?
Ooooh, i feel guilty now. You need to be a curator of your software. Where you can say “no”. Think of your product a a museum, and your features as art. Will you hang that feature on a wall?
The other trick: Listen to your customers, but innovate for your entire customer base.
Finally: Eventually you’ll hit bloat. And it’ll be really hard to go back. Don’t do it.
In closing: Curate your software. Don’t say yes to everything.
Growing Company DIY
Maria Thomas – New CEO of Etsy