Startup Lessons Learned 2011 Drew
Houston Founder/CEO, Dropbox @drewhouston

How things get built at
Dropbox Challenges we face at scale How we decide what to build

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>

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>

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>

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>

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>

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>

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>

Challenges we face at scale

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>

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>

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>

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>

How we decide what to
build

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>

Votebox: our tracker for user
requests

BUT…figuring out what your customers
want is your job, not theirs

Big problems hidden in plain
sight

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>

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>

Thank you! Questions? @drewhouston Slides:
bit.ly/dropboxSLL2011