Successfully reported this slideshow.
Your SlideShare is downloading. ×

Dropbox startup lessons learned 2011


More Related Content


Dropbox startup lessons learned 2011

  1. Startup Lessons Learned 2011 Drew Houston Founder/CEO, Dropbox @drewhouston
  2. How things get built at Dropbox Challenges we face at scale How we decide what to build
  3. Dropbox by the numbers <ul><li>Just a year ago: </li></ul><ul><ul><li>20-ish people </li></ul></ul><ul><ul><li>5mm users </li></ul></ul><ul><li>Today: </li></ul><ul><ul><li>55-ish people </li></ul></ul><ul><ul><li>>25mm users </li></ul></ul><ul><ul><li>100+ billion files </li></ul></ul><ul><ul><li>300mm files saved daily (1mm every 5 min, more than tweets on Twitter) </li></ul></ul><ul><ul><li>Paying users in 175 countries </li></ul></ul>
  4. People > process <ul><li>Great engineers are dramatically more productive than average engineers </li></ul><ul><li>Hiring fewer but better people reduces need to be great at coordination, planning, etc. </li></ul><ul><li>Plan/design with Etherpad, track bugs with Trac </li></ul><ul><li>~25-person engineering team split up into smaller, loosely-coupled sub-teams </li></ul><ul><ul><li>Client, server, web, mobile, analytics/growth, API, etc. </li></ul></ul><ul><ul><li>Each with own roadmap, release cycle, process, team meetings, Etherpads, tests, continuous deployment, etc. </li></ul></ul><ul><ul><li>Core protocols & APIs reasonably frozen, enabling loose coupling (a la Amazon) </li></ul></ul>
  5. Find great people… <ul><li>… and get out of the way </li></ul><ul><ul><li>In general we don’t tell people how to work – no mandatory hours, etc. </li></ul></ul><ul><ul><li>Make the office somewhere people like to be </li></ul></ul><ul><ul><li>Pick whatever workstation, tools (no budget) </li></ul></ul><ul><li>Minimize overhead & decentralize day-to-day decisions through culture/values </li></ul><ul><li>Cofounder Arash maintains “soul” of the user experience; designer Jon keeper of look and feel </li></ul>
  6. Big results with small # of people <ul><li>One visual designer (formerly community manager!) </li></ul><ul><li>Server team of 3 manages 100+ billion files, 10+ petabytes of data, etc. </li></ul><ul><li>Strategy: divide & conquer, keep teams small (won’t scale forever but has for now) </li></ul><ul><li>As team grows, values/culture/mission made more explicit & deliberately taught to new people </li></ul>
  7. Planning <ul><li>We don’t do a lot of advance planning </li></ul><ul><li>But we need more than we used to </li></ul><ul><ul><li>More stuff going on </li></ul></ul><ul><ul><li>Functions outside engineering </li></ul></ul><ul><ul><li>People don’t know what other people are up to </li></ul></ul><ul><ul><li>Less information spreads by osmosis </li></ul></ul><ul><ul><li>As we grow more leaders internally, they need to stop and plan for their teams </li></ul></ul><ul><li>For a while we were doing too many things, and nothing would ship for months </li></ul>
  8. Dropbox company goals <ul><li>Modeled after Google’s OKR system </li></ul><ul><li>Yearly goals & quarterly goals </li></ul><ul><li>Forms a hierarchy that is shared publicly </li></ul><ul><ul><li>Overall company goals </li></ul></ul><ul><ul><li>Overall product goals </li></ul></ul><ul><ul><li>Team goals (e.g. client team) </li></ul></ul><ul><ul><li>Eventually per individual </li></ul></ul><ul><li>Perfect is the enemy of good enough here – your planning process needs iteration too! </li></ul>
  9. Study how other companies grew <ul><li>Challenge with scaling orgs is things that used to work start failing quietly </li></ul><ul><ul><li>“ What are we doing? Why?” </li></ul></ul><ul><ul><li>“ Why does what I’m doing matter?” </li></ul></ul><ul><ul><li>“ What is most important?” </li></ul></ul><ul><li>We try to learn from other companies growing pains; don’t reinvent the wheel </li></ul><ul><li>Take comfort in that all other high-growth companies were pretty #!$@ed up too in their own special ways </li></ul>
  10. Challenges we face at scale
  11. Launch fast and iterate quickly… <ul><li>… unless you’re making pacemakers </li></ul><ul><li>Different sub-teams need different engineering tradeoffs (e.g. server core team vs. web team) </li></ul><ul><li>Our most valuable asset: people’s trust. Years to build, seconds to lose if data is ever lost </li></ul><ul><li>Need big investments on e.g. client team to keep cycle times fast </li></ul><ul><ul><li>Google Chrome, others have set good examples here </li></ul></ul><ul><ul><li>But getting there takes a lot of work! (test coverage, continuous deployment, automatic updates, etc.) </li></ul></ul>
  12. The world is more complicated… <ul><li>… when you have lots of users </li></ul><ul><ul><li>More at stake: paying customers & public scrutiny </li></ul></ul><ul><ul><li>On the desktop, combinatorial explosion of different environments; impossible to test all </li></ul></ul><ul><ul><li>A problem affecting just 0.1% of user base is still 25,000 people when you have 25 million users </li></ul></ul><ul><li>… when the code has lots of moving parts </li></ul><ul><ul><li>Performance & memory footprint optimizations add lots of complexity to the code </li></ul></ul><ul><ul><li>Harder to add people, harder to add features </li></ul></ul>
  13. It’s not easy being lean <ul><li>Split testing & optimization is great, but you quickly run out of low hanging fruit </li></ul><ul><ul><li>Early wins on e.g. shared folder & referral flows </li></ul></ul><ul><ul><li>… remember A/B tests won’t get you an iPhone </li></ul></ul><ul><li>Analytics are essential but hard to maintain </li></ul><ul><ul><li>Our data volume increases 10x/year </li></ul></ul><ul><li>Most needle-moving projects don’t have MVPs that are easy to make </li></ul><ul><ul><li>Requires more coordination, effort to test ideas </li></ul></ul><ul><ul><li>Especially tests requiring UI on the desktop </li></ul></ul>
  14. Build the right thing & build things right <ul><li>But if you have to choose one, build the right thing </li></ul><ul><ul><li>No good to run fast in the wrong direction </li></ul></ul><ul><ul><li>No silver bullets in software methodologies; context matters </li></ul></ul><ul><li>We’re getting better </li></ul><ul><ul><li>Our chronic optimism is slowly getting cured </li></ul></ul><ul><ul><li>Company goal process helps predictability </li></ul></ul><ul><ul><li>Continued investments in core infrastructure & reducing cycle times </li></ul></ul>
  15. How we decide what to build
  16. Some design principles <ul><li>Everything should “just work” </li></ul><ul><ul><li>Don’t make users think </li></ul></ul><ul><ul><li>&quot;It's not just what it looks like and feels like. Design is how it works.&quot; – Steve Jobs </li></ul></ul><ul><ul><li>Usability, speed, reliability requires relentless, continuous improvement </li></ul></ul><ul><li>Don’t launch anything half-assed </li></ul><ul><ul><li>We usually launch “when it’s done”, but trying to get more predictable </li></ul></ul><ul><ul><li>“ Does less” is okay; flaky/ugly/confusing is not </li></ul></ul>
  17. Votebox: our tracker for user requests
  18. BUT…figuring out what your customers want is your job, not theirs
  19. Big problems hidden in plain sight
  20. Big problems hidden in plain sight <ul><li>For most people, technology fails the “Minority Report” test </li></ul><ul><ul><li>i.e. in “the future”, Tom Cruise would not be e.g. logging into his Gmail or carrying around USB drives </li></ul></ul><ul><li>Unsolved problems are all around us </li></ul><ul><ul><li>Seeing photos on your TV, listening to music in your car, sharing wedding pictures with family </li></ul></ul><ul><li>In the future, everything will “just work” but it definitely doesn’t today </li></ul>
  21. Wrapping up <ul><li>It’s worth the pain, though </li></ul><ul><li>Incredibly rewarding making things people actually use </li></ul><ul><li>A bigger audience means we can solve big problems for tens and soon hundreds of millions of people </li></ul><ul><li>Yet we all still fit in one room (for now!) </li></ul>
  22. Thank you! Questions? @drewhouston Slides:

Editor's Notes

  • (as I spent the bulk of my 20s discovering) This is not your typical rails app that you can bang out in a weekend.
  • Unusual aspects
  • A few examples/stories
  • A few examples/stories
  • A few examples/stories