Diego Scataglini » Blog Archive » Start Lessons learned notes: Part#8

Start Lessons learned notes: Part#8

October13

3:50 pm dropbox case study

How we build things?
- We start with great people.
- Hiring fewer but better people reduces need for coordination. Less things to share among less people.
- Using etherpad to plan design with trac
  - Taken point, you don’t need an incredible infrastructure to coordinate. Simpler is better.
- small loosely-couple teams formed from a 25-person engineering team.
  - each team is locally organized
Find great people and get out of the way
- no mandatory hours
- make the office a nice place to work at
- very heterogeneous environment when it comes to people preferences to workstation.
Decentralize day-to day decisions through culture & values
Co-founders maintains the soul of the product & user experience
- Designer is the keeper of the look & feel
Big results with small # of people
- one visual designer (formerly community manager)
  - got lucky. He had no prior experience in design
- server team of 3 manages 100+ billion files …
- Strategy: divide & conquer, keep teams small
- as team grows, you need to institutionalize certain things like values, culture & mission
Planning
- we don’t do a lot of long term planning
- But we need more than we used to
  - things get more complicated over time
  - less information spreads by osmosis
Dropbox company goals
- modeled after Google’s OKR system
- yearly goals & quarterly goals
- forms a hierarchy that is shared publicly
  - overall company, product, team, individual goals
- Perfect is the enemy of good enough
  - your planning needs iterations too
Study how other companies grew
- Challenge with scaling orgs is what used to work start failing quietly
  - new engineer doesn’t really know how their stuff fits that big picture
  - where the company is going
  - creates malaise that flares up
- Try to learn from other companies growing pains
- Take comfort in that all other company had problems too.
  - We talked to our investors who invested in other companies for sanity check and discovered that every company is special in its own special way
Challenge we faced at scale
- launch fast and iterate quickly
- different sub-teams need different engineering tradeoffs
- our most valuable asset: people’s trust. Years to build seconds to lose if data is ever lost
The more users the more complicated your world becomes
- more at stake
- a problem that affects just 0.1% is still 25k when you have 25M
- when the code has lots of moving parts it’s harder to add people, harder to add features. Performance optimization adds complexity to the code
It’s not easy being lean
- split testing & optimization is great, but you quickly run out of low hanging fruit
  - early wins with shared folder & referral flos
  - but it’s not a substitute for a great product
- Analytics that scales with you is hard and needs dedicated engineering
- Most needle moving factors are new features
Build the right things and build things right
- but if you have to choose: build the right thing
Some design principles
- everything should “just work”
- don’t make users think
- Usability, speed, reliability requires
- don’t launch anything half-assed
  - it really going to violate the hard built trust
It’s your job to figure out what to build, not your customers
- Activating & retaining the users takes a lot of work
How do we decide what to build
- Big problems hidden in plain sight
  - For most people technolgy fails the ‘minority report’ test
    - ie: in the future Tome Cruise will not be carrying around USB drives
  - Look for unsolved problems
  - We ask ourselves how is this going to work in the future and that’s how we decide what to build
Wrapping up
- Building something that people love and use is rewarding. it’s worth the pain
- A bigger audience means we can solve big problems for lots of people