12 ms·

Employee #1: Dropbox

332 points by craigcannon 10y ago

typetypetype 10y ago
> We were all using the product so when there was funny stuff we tended to catch it. I love this. There have been so many times I've run into a bug that makes me wonder if anyone on the engineering team actually used the product.
- gregmac 10y ago
  Also known as 'dogfooding' or 'eating your own dog food' [0], and yes, not enough companies/software teams do this. Developers that build software aimed at or naturally used by other software developers kind of have an unfair advantage here. https://en.wikipedia.org/wiki/Eating_your_own_dog_food https://en.wikipedia.org/wiki/Eating_your_own_dog_food
  - freehunter 10y ago
    The company I work for, and specifically the product I support, came out with modular "apps" that can be installed to enhance the functionality. This came out about a year ago, and while the number of apps is pretty impressive for the niche market the product falls into, none of the apps were terribly useful or complicated. There wasn't a huge incentive to actually care about the app market, let alone download and use any of them. So leadership made the decision to dogfood our own app environment. Any new features that are not part of the core experience or modifications to existing features are now apps. And guess what? We found some limitations to our app infrastructure, corrected them, and now we have a (again, relative) ton of high quality apps. Turns out no one was making apps because the experience sucked, until the developers found that out first hand and course-corrected.
  - walshemj 10y ago
    Back when I worked for a pre internet messaging company our terminals speed was slowed down to the same (1200 or 2400 baud) as a dial up user would see.
    - dasmoth 10y ago
      There was a story last year about Facebook having "2G Tuesdays" to give employees an idea of what life on a slow network is like. I wonder whether it caught on?
      - BinaryIdiot 10y ago
        Such a genius idea. I see far too many web applications not caring about latency. Forcing a developer to experience the same pain should help them. Unless that simply becomes the day everyone typically takes off, blames productivity on slow network connectivity, etc.
        nostrademons 10y ago
        Google had a latency proxy on the corp network that you could use to simulate dialup, 2G, DSL, etc (along with unreliable connections). It was a great tool, and you could learn a lot by doing all your normal searches through the latency proxy. Alas, not many developers knew about it, and even fewer were willing to take the convenience hit to use it as part of their normal experience.
        thedufer 10y ago
        OS X used to have a "Network Link Conditioner" that shipped with XCode, I believe. It did a lot of the things you're suggesting, but right at the network interface level. Unfortunately, it broke with the advent of Mavericks. No idea whether it works now, or even still exists. On the last web-app project I worked on, we had a middleware that activated automatically in dev mode and just inserted a delay in every request to bring a local delay up to our users' median delay. It was intentionally a bit of a pain to turn off, so almost everyone ran in that mode.
        ptomato 10y ago
        Still exists. https://developer.apple.com/download/more/?q=Hardware%20IO%20Tools https://developer.apple.com/download/more/?q=Hardware%20IO%2... is the link you're looking for.
- yeukhon 10y ago
  Dogfooding is quite important, yeah. Some products, hmm, maybe not. For example, if I work for a dating app, I may not feel comfortable actually using the app myself especially when I am committed to a relationship. I.e. I can't dogfood it because I have no use of the product. In the case of say Facebook, I believe employees use the site internally so dogfooding is possible, even if privately some employees don't actually have a Facebook account. Going extreme, people who are responsible for designing military jet or nuclear reactor, they can't dogfood any of that, only simulation and model testing are possible.
  - barkingcat 10y ago
    For low barrier to entry products like facebook, dating sites, etc, I think companies are smart enough to build internal facing development only environments - so as a developer you won't be "using" the dating site, just using/testing/dogfooding the internal "dev" dating site that has maybe a million robots and all the employees, contractors, partners of the company. If you haven't set down ground rules with a partner for working at a place like that, it's not a technical issue re: dogfooding, but a communication issue with your partner. For things like military jets, nuclear reactors and the like, many times companies hire ex-military jet pilots (test pilots like for example Chuck Yeager), and former nuclear power plant operators, or even university profs who developed/calculated the nuclear fission equations in the first place (ie Manhattan Projected hired basically all nuclear physicists in all universities in the US for the effort) - they also do "testing" - which could be a form of dogfooding.
    - _RPM 10y ago
      That isn't the same thing as Dog-fooding by the way.
    - yeukhon 10y ago
      Right, building a stage site internally or asking a pilot to test are basically user acceptance testing. Xeros builds a new printer model, replaces all the printing machines on the first floor that's dogfooding. But I get what you are trying to say.
- kasparsklavins 10y ago
  Half the [low priority] bugs I fix are because they get too annoying while developing.
- dasmoth 10y ago
  I somewhat blame this on the emphasis that now gets placed on automated testing (to the extent that nobody actually pronounces the "automated"). It's got some good points, but if it comes at the expense of manual testing I'm not convinced that's always a great trade-off, especially for interactive software.
  - jacalata 10y ago
    I don't think conflating dogfooding with manual testing really works - they are different actions and you can have a dogfood culture without manual testing, or vice versa.
    - dasmoth 10y ago
      If you're talking about manual testing in the sense of "run down a long checklist", yeah that's different and automated tests are a better (although still not perfect) substitute for that kind of thing. But definitely still consider dogfooding to fall under "manual testing."
      - jacalata 10y ago
        I don't think it fits under that at all, and I find that when people do see it that way it gets an entirely different treatment. "Manual testing" is an activity you do when you are thinking about how the product works. "Dogfooding" is a culture of using the product in order to achieve other tasks that you really wanted to get done.
- BinaryIdiot 10y ago
  In my experience dogfooding is the only way to build a great product. Without dogfooding features erode. The "oh I haven't tested that in 6 months" happens frequently. The UX never evolves. I have NEVER worked on a product that got worse when it was dogfooded and I have NEVER worked on a product that consistently got better without dogfooding (sometimes it'll get better but it's always in spurts before going back down again). Dogfooding is so under utilized especially in big companies.
  - city41 10y ago
    Dogfooding only helps here if the dev team's use cases match the users's. Just about every company I've worked at has "dogfooded" its products, but almost always a small subset or even a completely different configuration from a typical customer.
  - bshimmin 10y ago
    Dogfooding is difficult to achieve if you work in a niche industry which has no immediate relevance to your development team. Smart developers who care about what happens beyond the back of their monitor will, of course, quickly learn a lot about the sector, but they're never going to know or care as much as a real user of the product, and they're never really going to have the same interest as they would if they were building a text editor.
    - BinaryIdiot 10y ago
      Dogfooding does not require interest. Yes something niche that a developer on their own will never use is difficult (I think we had this as some of the previous companies I have worked at). Still, you should get the development team to use and demo the system on a semi regular basis. Make creating project ideas or something that they can use your product to make and play with. Tell them to take off every X hours a week or two weeks or something to ensure they are constantly using the product. It's harder but in my experience it's still necessary. At least I've never seen a good product come from a team that didn't also use the product. That I know of, anyway.
- idunno246 10y ago
  I worked at a iphone game company, where after about 6-9 months of of them being there we let a game designer go. Of course we recycle the ipads to the next person, at which point we realize, none of the hardware had been authorized to run our app so therefore could never have been played. Yea....dogfooding is important
huac 10y ago
"MIT is cheating. Going to MIT you end up getting to meet lots of people who are smart and fun to hang out with and you’ll get along with naturally. It’s much harder after school."
pg_is_a_butt 10y ago
Hacker News #1: Shills.
dude_abides 10y ago
> But I ended up picking Mercurial for the distributed version control system, which we were definitely wrong on that one–should have picked Git. I'm curious to know: is this sentiment widely shared? Is git really that much better than hg?
- diamondtrim 10y ago
  Never used mercurial. I suspect it's just as good, but the problem the author probably sees is, like me, most everyone is familiar with git and new hires need to be trained in something unfamiliar with less community around it.
  - bch 10y ago
    I wonder how large that friction is. I look at git, mercurial, etc as distributed version control first and foremost, and that they're more alike than different. It could be that I witnessed the popular adoption of all this via Linux going from tarballs/patches/mailing lists -> bitkeeper -> git, and have used and witnessed-the-evolution-of rcs, cvs, subversion, various DSCMs, and so my concepts of source control are stretched more broadly than people that are experiencing the dissonance between (e.g.) mercurial and git. Edit: clarifying words
    - marcosdumay 10y ago
      If you are used to an "always branch" workflow, mercurial can impose a lot of friction.
      - Bjartr 10y ago
        Do you have anything you can point to for that friction? I'm always looking to do better than I already am and would be interested in understanding the issues here.
  - frew 10y ago
    Used to work at Dropbox. Existing knowledge of new hires was 90% of the challenge with Mercurial with the other 10% being weird edge cases (e.g. very large/numerous repositories) that hadn't seen as much attention due to the smaller community.
keithwhor 10y ago
I was lucky enough to hear this story almost verbatim from Aston and it's so exhilarating to listen to how much fun everybody seemed to be having. He tells it with a lot of enthusiasm that you can feel just from the depth of his responses. I think the one thing that stuck with me, personally, is the issues Dropbox had in the early days (TC 50 tech issues) and that it took six months to get Aston on board. From what I understand, pre-YC was not easy for Drew either. As a stubbornly impatient person, this has to be hands-down the hardest part of building a startup. You're running an endless marathon as if your life depended on it, and you have to stop at the sidelines and calmly ask people if they'll run with you. And then be okay if they don't - because the course will change, and as it does it will become more attractive to different sets of people. You might see the finish line, but you have to understand that not everybody will see it the same way you do. The thing that I'd add here is that Aston kind of downplays how important having a business model is as an employee / founder (at least per Drew joking around about pricing). I don't think he did this intentionally, but generally we're over saturated with these ideas that you just need a product people love. These stories inspire technical founders, but having a defensible business is something you should think about sooner rather than later. Not everybody can be a Dropbox, so learn as much as possible about every aspect of what your company can and will be, learn how to communicate that, and stack the deck in your favor. It's an ongoing process and I certainly am not one to claim mastery (far from it), but as somebody who's in the weeds it's the perspective I have.
- ryandrake 10y ago
  What I don't get is why try to recruit the same person over and over for six months? I wonder what the outcome would have been had they just hired someone else equally as talented right away instead of going without an employee for all that time. You can't re-play these things so we'll never know, but it just seems odd to me.
  - nostrademons 10y ago
    They didn't have funding (other than YC, which at the time was $6k/founder, not nearly enough to support an employee) until right before they hired Aston. Drew had approached me about being employee #2 for DropBox, and I had lunch with him, Arash, and Aston in Feb 2008. They'd only closed the Sequoia seed round about a month before. IIUC, Aston had been officially hired the day before. I (stupidly in hindsight, but for good reasons at the time) ended up declining. I actually reconsidered about two months later and asked if the position was still open, but they had long since filled it - I think they got some very good MIT grads literally later the afternoon after I had declined. So they were hiring very aggressively, but they started recruiting before they were in a position to actually hire, to warm up potential employees.
_RPM 10y ago
Does Drew come from a privileged family?
- samfisher83 10y ago
  His dad went to harvard so I am guessing he grew up pretty well off.
  - _RPM 10y ago
    Yep. That explains how he was able to focus full time on Dropbox then. He must have always had a trampoline to bounce him back up should he fail. I know it was funded from the beginning most likely, but there had to have been a time before it was funded.
    - psyc 10y ago
      I know it's fun to be envious of rich people, but I grew up in poverty, and so far I've earned myself 5 years to focus full time on my stuff. I know it's a little harder, maybe, but all I had to do was go to work first. Most people go to work anyway.
      - _RPM 10y ago
        Maybe I did come off as envious, but I'm not angry, or sad, or feeling like I don't have opportunities to be a successful startup founder myself. It's just that you do often see a pattern among founders. It's so common that I've started noticing it. It's certainly not true that you have to come from a privileged family to be a successful entrepreneur. Look at examples like Larry Ellison.
        psyc 10y ago
        Yeah, it's probably statistically more likely for success to breed success. It's fine to know that as long as we don't let that alone stop us.
        10y ago
deleted 10y ago
[deleted]
vazamb 10y ago
A minor detail, but I am surprised about the whole "it was hard to figure out when someone moved a file" thing. I always assumed the actual file on disk was abstracted away into a database record, that specified the folder etc. Were they actually using S3 Bucket/Folders for file structure on Dropbox itself?
- hoov 10y ago
  It was more of a lack of abstraction than anything. The server reflected more or less what the OS presented -- an add and a delete rather than a move. Putting the pieces together later to present better information to the user was difficult. Not sure what they do today, but I remember many talks about ways to put that abstraction in place as close to the OS as possible. Reconstructing multiple, quick, renames/moves after the fact proved to be somewhat difficult from the frontend, which Aston worked on.
pensive_returns 10y ago
An interesting titbit Aston leaves out about his early days is that he was actually cofounder of AutoAdmit.com[0], a law school admissions forum, semi-notorious for its defamation lawsuits and being an incubator for troll, Michael O. Church[1] (banned on Quora, Wikipedia, and Hacker News for being a thorn in Paul Graham and Dan G, sides) that formed after the great Princeton Review Discussion Board exodus and has persisted with an active user base for almost 13 years now. I wonder if he's ashamed of that history since he fails to mention it (despite it being on his early resume!). [0] http://www.autoadmit.com/ http://www.autoadmit.com/ [1] https://michaelochurch.wordpress.com/ https://michaelochurch.wordpress.com/
- idlewords 10y ago
  What is the connection between AutoAdmit and Church? I don't understand how he's relevant here.
  - pensive_returns 10y ago
    Church is from autoadmit and probably well known to Aston (since they were both part of the PR community).
  - saintzozo 10y ago
    Yes, this is very puzzling.
  - hopethathelps 10y ago
    Church used to post obsessively on AutoAdmit under the name "pensive" and have lengthy conversations with sockpuppet accounts. Draw your own conclusions.
- ones_and_zeros 10y ago
  Michael O. Church a troll? Please. The guy had an odd view of himself but I always found he provided excellent well thought out analysis and arguments. I'm not saying he is always right, but he wasn't a troll.
psawaya 10y ago
What a great interview. There's so much under-appreciated advice here, particularly around founder/idea fit. I've been lucky enough to know Aston over the past two years, and have always been super impressed by his insight.
doktrin 10y ago
Aston is a class act. He volunteered to act as a mentor to students in a coding bootcamp I attended several years ago, and it was my privilege to meet him. He's the sort of person who is unequivocally a net positive in this world, and I wish him all manner of continued success.
webo 10y ago
Ironically, Drew's YC application is stored in Google Docs: https://dl.dropboxusercontent.com/u/27532820/app.html https://dl.dropboxusercontent.com/u/27532820/app.html
olantonan 10y ago
Awesome story
pw 10y ago
Anyone noticing from these interviews that a lot of first employees are kinda just randos that aren't very impressive in their own right and don't stay at the company very long?
- elgenie 10y ago
  Aston's tenure at Dropbox (four and half years) is "very long" in Silicon Valley terms in general and in early stage startup terms in particular. As for being "randos that aren't very impressive in their own right", you're zeroed in on a set of people who joined a startup before there was much traction, let alone profit, with almost the same risk as the founders but with less upside. That group is going to skew young and/or unsuccessful before they join and, since the interviews are conducted with #1 employees at successful companies, will skew towards having FU money for their post-exit careers.
  - pw 10y ago
    I realize first employees will tend to skew young and/or unsuccessful and, as a result of being first employees, these people have FU money, but my point is that their success seems to be kinda random. There's no sense of inevitability about their success like you see with really great founders. And it seems like they never go on to do anything amazing in their post-exit careers.
    - elgenie 10y ago
      How amazing is the post-exit career of the average great founder? What if the success of the "really great founders" similarly has quite a bit of randomness involved? The halo effect and associated myth-making doesn't get applied nearly as much to employee #1.
      - pw 10y ago
        I feel like I've struck a nerve in some way and would love to better understand what's fueling your response. Why do you feel like you have to defend first employees?
nasalgoat 10y ago
"In general, my thing is, again, in keeping with Dropbox’s conservative culture, if you can use languages and tools and databases and frameworks that are 10 years old or older, you’re probably doing pretty good." That's a level of understanding I have trouble getting from very experienced developers and system admins, let alone a fresh college grad. I wish more people would realize that.

332 points by craigcannon 10y ago

> We were all using the product so when there was funny stuff we tended to catch it. I love this. There have been so many times I've run into a bug that makes me wonder if anyone on the engineering team actually used the product.

gregmac 10y ago
Also known as 'dogfooding' or 'eating your own dog food' [0], and yes, not enough companies/software teams do this. Developers that build software aimed at or naturally used by other software developers kind of have an unfair advantage here. https://en.wikipedia.org/wiki/Eating_your_own_dog_food https://en.wikipedia.org/wiki/Eating_your_own_dog_food
- freehunter 10y ago
  The company I work for, and specifically the product I support, came out with modular "apps" that can be installed to enhance the functionality. This came out about a year ago, and while the number of apps is pretty impressive for the niche market the product falls into, none of the apps were terribly useful or complicated. There wasn't a huge incentive to actually care about the app market, let alone download and use any of them. So leadership made the decision to dogfood our own app environment. Any new features that are not part of the core experience or modifications to existing features are now apps. And guess what? We found some limitations to our app infrastructure, corrected them, and now we have a (again, relative) ton of high quality apps. Turns out no one was making apps because the experience sucked, until the developers found that out first hand and course-corrected.
- walshemj 10y ago
  Back when I worked for a pre internet messaging company our terminals speed was slowed down to the same (1200 or 2400 baud) as a dial up user would see.
  - dasmoth 10y ago
    There was a story last year about Facebook having "2G Tuesdays" to give employees an idea of what life on a slow network is like. I wonder whether it caught on?
    - BinaryIdiot 10y ago
      Such a genius idea. I see far too many web applications not caring about latency. Forcing a developer to experience the same pain should help them. Unless that simply becomes the day everyone typically takes off, blames productivity on slow network connectivity, etc.
      - nostrademons 10y ago
        Google had a latency proxy on the corp network that you could use to simulate dialup, 2G, DSL, etc (along with unreliable connections). It was a great tool, and you could learn a lot by doing all your normal searches through the latency proxy. Alas, not many developers knew about it, and even fewer were willing to take the convenience hit to use it as part of their normal experience.
        thedufer 10y ago
        OS X used to have a "Network Link Conditioner" that shipped with XCode, I believe. It did a lot of the things you're suggesting, but right at the network interface level. Unfortunately, it broke with the advent of Mavericks. No idea whether it works now, or even still exists. On the last web-app project I worked on, we had a middleware that activated automatically in dev mode and just inserted a delay in every request to bring a local delay up to our users' median delay. It was intentionally a bit of a pain to turn off, so almost everyone ran in that mode.
        ptomato 10y ago
        Still exists. https://developer.apple.com/download/more/?q=Hardware%20IO%20Tools https://developer.apple.com/download/more/?q=Hardware%20IO%2... is the link you're looking for.
yeukhon 10y ago
Dogfooding is quite important, yeah. Some products, hmm, maybe not. For example, if I work for a dating app, I may not feel comfortable actually using the app myself especially when I am committed to a relationship. I.e. I can't dogfood it because I have no use of the product. In the case of say Facebook, I believe employees use the site internally so dogfooding is possible, even if privately some employees don't actually have a Facebook account. Going extreme, people who are responsible for designing military jet or nuclear reactor, they can't dogfood any of that, only simulation and model testing are possible.
- barkingcat 10y ago
  For low barrier to entry products like facebook, dating sites, etc, I think companies are smart enough to build internal facing development only environments - so as a developer you won't be "using" the dating site, just using/testing/dogfooding the internal "dev" dating site that has maybe a million robots and all the employees, contractors, partners of the company. If you haven't set down ground rules with a partner for working at a place like that, it's not a technical issue re: dogfooding, but a communication issue with your partner. For things like military jets, nuclear reactors and the like, many times companies hire ex-military jet pilots (test pilots like for example Chuck Yeager), and former nuclear power plant operators, or even university profs who developed/calculated the nuclear fission equations in the first place (ie Manhattan Projected hired basically all nuclear physicists in all universities in the US for the effort) - they also do "testing" - which could be a form of dogfooding.
  - _RPM 10y ago
    That isn't the same thing as Dog-fooding by the way.
  - yeukhon 10y ago
    Right, building a stage site internally or asking a pilot to test are basically user acceptance testing. Xeros builds a new printer model, replaces all the printing machines on the first floor that's dogfooding. But I get what you are trying to say.
kasparsklavins 10y ago
Half the [low priority] bugs I fix are because they get too annoying while developing.
dasmoth 10y ago
I somewhat blame this on the emphasis that now gets placed on automated testing (to the extent that nobody actually pronounces the "automated"). It's got some good points, but if it comes at the expense of manual testing I'm not convinced that's always a great trade-off, especially for interactive software.
- jacalata 10y ago
  I don't think conflating dogfooding with manual testing really works - they are different actions and you can have a dogfood culture without manual testing, or vice versa.
  - dasmoth 10y ago
    If you're talking about manual testing in the sense of "run down a long checklist", yeah that's different and automated tests are a better (although still not perfect) substitute for that kind of thing. But definitely still consider dogfooding to fall under "manual testing."
    - jacalata 10y ago
      I don't think it fits under that at all, and I find that when people do see it that way it gets an entirely different treatment. "Manual testing" is an activity you do when you are thinking about how the product works. "Dogfooding" is a culture of using the product in order to achieve other tasks that you really wanted to get done.
BinaryIdiot 10y ago
In my experience dogfooding is the only way to build a great product. Without dogfooding features erode. The "oh I haven't tested that in 6 months" happens frequently. The UX never evolves. I have NEVER worked on a product that got worse when it was dogfooded and I have NEVER worked on a product that consistently got better without dogfooding (sometimes it'll get better but it's always in spurts before going back down again). Dogfooding is so under utilized especially in big companies.
- city41 10y ago
  Dogfooding only helps here if the dev team's use cases match the users's. Just about every company I've worked at has "dogfooded" its products, but almost always a small subset or even a completely different configuration from a typical customer.
- bshimmin 10y ago
  Dogfooding is difficult to achieve if you work in a niche industry which has no immediate relevance to your development team. Smart developers who care about what happens beyond the back of their monitor will, of course, quickly learn a lot about the sector, but they're never going to know or care as much as a real user of the product, and they're never really going to have the same interest as they would if they were building a text editor.
  - BinaryIdiot 10y ago
    Dogfooding does not require interest. Yes something niche that a developer on their own will never use is difficult (I think we had this as some of the previous companies I have worked at). Still, you should get the development team to use and demo the system on a semi regular basis. Make creating project ideas or something that they can use your product to make and play with. Tell them to take off every X hours a week or two weeks or something to ensure they are constantly using the product. It's harder but in my experience it's still necessary. At least I've never seen a good product come from a team that didn't also use the product. That I know of, anyway.
idunno246 10y ago
I worked at a iphone game company, where after about 6-9 months of of them being there we let a game designer go. Of course we recycle the ipads to the next person, at which point we realize, none of the hardware had been authorized to run our app so therefore could never have been played. Yea....dogfooding is important

huac 10y ago

"MIT is cheating. Going to MIT you end up getting to meet lots of people who are smart and fun to hang out with and you’ll get along with naturally. It’s much harder after school."

pg_is_a_butt 10y ago

Hacker News #1: Shills.

dude_abides 10y ago

> But I ended up picking Mercurial for the distributed version control system, which we were definitely wrong on that one–should have picked Git. I'm curious to know: is this sentiment widely shared? Is git really that much better than hg?

diamondtrim 10y ago
Never used mercurial. I suspect it's just as good, but the problem the author probably sees is, like me, most everyone is familiar with git and new hires need to be trained in something unfamiliar with less community around it.
- bch 10y ago
  I wonder how large that friction is. I look at git, mercurial, etc as distributed version control first and foremost, and that they're more alike than different. It could be that I witnessed the popular adoption of all this via Linux going from tarballs/patches/mailing lists -> bitkeeper -> git, and have used and witnessed-the-evolution-of rcs, cvs, subversion, various DSCMs, and so my concepts of source control are stretched more broadly than people that are experiencing the dissonance between (e.g.) mercurial and git. Edit: clarifying words
  - marcosdumay 10y ago
    If you are used to an "always branch" workflow, mercurial can impose a lot of friction.
    - Bjartr 10y ago
      Do you have anything you can point to for that friction? I'm always looking to do better than I already am and would be interested in understanding the issues here.
- frew 10y ago
  Used to work at Dropbox. Existing knowledge of new hires was 90% of the challenge with Mercurial with the other 10% being weird edge cases (e.g. very large/numerous repositories) that hadn't seen as much attention due to the smaller community.

keithwhor 10y ago

I was lucky enough to hear this story almost verbatim from Aston and it's so exhilarating to listen to how much fun everybody seemed to be having. He tells it with a lot of enthusiasm that you can feel just from the depth of his responses. I think the one thing that stuck with me, personally, is the issues Dropbox had in the early days (TC 50 tech issues) and that it took six months to get Aston on board. From what I understand, pre-YC was not easy for Drew either. As a stubbornly impatient person, this has to be hands-down the hardest part of building a startup. You're running an endless marathon as if your life depended on it, and you have to stop at the sidelines and calmly ask people if they'll run with you. And then be okay if they don't - because the course will change, and as it does it will become more attractive to different sets of people. You might see the finish line, but you have to understand that not everybody will see it the same way you do. The thing that I'd add here is that Aston kind of downplays how important having a business model is as an employee / founder (at least per Drew joking around about pricing). I don't think he did this intentionally, but generally we're over saturated with these ideas that you just need a product people love. These stories inspire technical founders, but having a defensible business is something you should think about sooner rather than later. Not everybody can be a Dropbox, so learn as much as possible about every aspect of what your company can and will be, learn how to communicate that, and stack the deck in your favor. It's an ongoing process and I certainly am not one to claim mastery (far from it), but as somebody who's in the weeds it's the perspective I have.

ryandrake 10y ago
What I don't get is why try to recruit the same person over and over for six months? I wonder what the outcome would have been had they just hired someone else equally as talented right away instead of going without an employee for all that time. You can't re-play these things so we'll never know, but it just seems odd to me.
- nostrademons 10y ago
  They didn't have funding (other than YC, which at the time was $6k/founder, not nearly enough to support an employee) until right before they hired Aston. Drew had approached me about being employee #2 for DropBox, and I had lunch with him, Arash, and Aston in Feb 2008. They'd only closed the Sequoia seed round about a month before. IIUC, Aston had been officially hired the day before. I (stupidly in hindsight, but for good reasons at the time) ended up declining. I actually reconsidered about two months later and asked if the position was still open, but they had long since filled it - I think they got some very good MIT grads literally later the afternoon after I had declined. So they were hiring very aggressively, but they started recruiting before they were in a position to actually hire, to warm up potential employees.

_RPM 10y ago

Does Drew come from a privileged family?

samfisher83 10y ago
His dad went to harvard so I am guessing he grew up pretty well off.
- _RPM 10y ago
  Yep. That explains how he was able to focus full time on Dropbox then. He must have always had a trampoline to bounce him back up should he fail. I know it was funded from the beginning most likely, but there had to have been a time before it was funded.
  - psyc 10y ago
    I know it's fun to be envious of rich people, but I grew up in poverty, and so far I've earned myself 5 years to focus full time on my stuff. I know it's a little harder, maybe, but all I had to do was go to work first. Most people go to work anyway.
    - _RPM 10y ago
      Maybe I did come off as envious, but I'm not angry, or sad, or feeling like I don't have opportunities to be a successful startup founder myself. It's just that you do often see a pattern among founders. It's so common that I've started noticing it. It's certainly not true that you have to come from a privileged family to be a successful entrepreneur. Look at examples like Larry Ellison.
      - psyc 10y ago
        Yeah, it's probably statistically more likely for success to breed success. It's fine to know that as long as we don't let that alone stop us.
      - 10y ago

deleted 10y ago

[deleted]

vazamb 10y ago

A minor detail, but I am surprised about the whole "it was hard to figure out when someone moved a file" thing. I always assumed the actual file on disk was abstracted away into a database record, that specified the folder etc. Were they actually using S3 Bucket/Folders for file structure on Dropbox itself?

hoov 10y ago
It was more of a lack of abstraction than anything. The server reflected more or less what the OS presented -- an add and a delete rather than a move. Putting the pieces together later to present better information to the user was difficult. Not sure what they do today, but I remember many talks about ways to put that abstraction in place as close to the OS as possible. Reconstructing multiple, quick, renames/moves after the fact proved to be somewhat difficult from the frontend, which Aston worked on.

pensive_returns 10y ago

An interesting titbit Aston leaves out about his early days is that he was actually cofounder of AutoAdmit.com[0], a law school admissions forum, semi-notorious for its defamation lawsuits and being an incubator for troll, Michael O. Church[1] (banned on Quora, Wikipedia, and Hacker News for being a thorn in Paul Graham and Dan G, sides) that formed after the great Princeton Review Discussion Board exodus and has persisted with an active user base for almost 13 years now. I wonder if he's ashamed of that history since he fails to mention it (despite it being on his early resume!). [0] http://www.autoadmit.com/ http://www.autoadmit.com/ [1] https://michaelochurch.wordpress.com/ https://michaelochurch.wordpress.com/

idlewords 10y ago
What is the connection between AutoAdmit and Church? I don't understand how he's relevant here.
- pensive_returns 10y ago
  Church is from autoadmit and probably well known to Aston (since they were both part of the PR community).
- saintzozo 10y ago
  Yes, this is very puzzling.
- hopethathelps 10y ago
  Church used to post obsessively on AutoAdmit under the name "pensive" and have lengthy conversations with sockpuppet accounts. Draw your own conclusions.
ones_and_zeros 10y ago
Michael O. Church a troll? Please. The guy had an odd view of himself but I always found he provided excellent well thought out analysis and arguments. I'm not saying he is always right, but he wasn't a troll.

psawaya 10y ago

What a great interview. There's so much under-appreciated advice here, particularly around founder/idea fit. I've been lucky enough to know Aston over the past two years, and have always been super impressed by his insight.

doktrin 10y ago

Aston is a class act. He volunteered to act as a mentor to students in a coding bootcamp I attended several years ago, and it was my privilege to meet him. He's the sort of person who is unequivocally a net positive in this world, and I wish him all manner of continued success.

webo 10y ago

Ironically, Drew's YC application is stored in Google Docs: https://dl.dropboxusercontent.com/u/27532820/app.html https://dl.dropboxusercontent.com/u/27532820/app.html

olantonan 10y ago

Awesome story

pw 10y ago

Anyone noticing from these interviews that a lot of first employees are kinda just randos that aren't very impressive in their own right and don't stay at the company very long?

elgenie 10y ago
Aston's tenure at Dropbox (four and half years) is "very long" in Silicon Valley terms in general and in early stage startup terms in particular. As for being "randos that aren't very impressive in their own right", you're zeroed in on a set of people who joined a startup before there was much traction, let alone profit, with almost the same risk as the founders but with less upside. That group is going to skew young and/or unsuccessful before they join and, since the interviews are conducted with #1 employees at successful companies, will skew towards having FU money for their post-exit careers.
- pw 10y ago
  I realize first employees will tend to skew young and/or unsuccessful and, as a result of being first employees, these people have FU money, but my point is that their success seems to be kinda random. There's no sense of inevitability about their success like you see with really great founders. And it seems like they never go on to do anything amazing in their post-exit careers.
  - elgenie 10y ago
    How amazing is the post-exit career of the average great founder? What if the success of the "really great founders" similarly has quite a bit of randomness involved? The halo effect and associated myth-making doesn't get applied nearly as much to employee #1.
    - pw 10y ago
      I feel like I've struck a nerve in some way and would love to better understand what's fueling your response. Why do you feel like you have to defend first employees?

nasalgoat 10y ago

"In general, my thing is, again, in keeping with Dropbox’s conservative culture, if you can use languages and tools and databases and frameworks that are 10 years old or older, you’re probably doing pretty good." That's a level of understanding I have trouble getting from very experienced developers and system admins, let alone a fresh college grad. I wish more people would realize that.