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.
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.
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.
Interesting example. Genuine question, had it been the opposite, if you circle back in time, would you really take that job? (Trick question: Are you less happy than you think you would have been in other case?)
Complicated question. It certainly would've been better financially, though honestly, the difference is "set for life" vs. "set for a long time", so I'm not certain it would make a material difference in my life now. Besides, I think it's fairly likely that even if I were set for life, I'd be doing something fairly similar to what I'm doing now. I think that in terms of lifestyle & personal goals during the 4-5 years I would've been at DropBox, I actually did better (I ended up folding up the startup I was working on and working for Google, and I had a relatively stress-free, enjoyable, lucrative, and personally fulfilling time at Google where I grew a lot as a person).
I do think that my reasons for not taking the job have been invalidated by future experience. My top reason was "I'm not going to leave my cofounder", and then he ended up leaving me 2 months later. My second reason was "Well, you've got a startup, I've got a startup, it is unclear which of us is actually going to succeed," and of course my startup was dead in 6 months while DropBox is now a $10B company. (Interestingly, I had a gut feeling at the time that I was turning down something important - I could tell Drew/Arash/Aston were crazy smart, and I really liked their product concept video.) But Drew actually told me "Honestly, if I were in your position - and I have been in your position - I wouldn't take the job" and he was right. The bargain we make as entrepreneurs is getting to call the shots, and the consequence of this is that sometimes we make the wrong call, and in a way it's not wrong after all because the whole point was making the call in the first place.
There's also the issue of whether DropBox would be a billion-dollar company at all if they'd hired me. I think my skillset actually duplicated Aston's to a fairly large extent, and we would've argued over technology choices (I would've pushed for Django, JQuery, and git over Pylons, Prototype.js, and Hg - the fact that these won in the wider webdev world is immaterial, just arguing over them would've cost precious time that a startup can't afford). Instead they hired some very talented MIT grads instead, and my understanding is that these engineers were responsible for things like reverse-engineering the Finder and writing the syncing algorithm that were what really contributed to DropBox's success.
I appreciate your thoughtful responses so I was wondering what your thoughts are on importance and corresponding compensation of the 1st employee at a company.
If the first employee is important enough that in your mind, it's possible that with depending on the first employee they may or may not be a billion dollar company, do you think the first employee compensation is commensurate with that? Aston also mentions specifically the commitment he has as a first employee, and how he feels "you're basically a founder" in terms of responsibility.
In my opinion, he made off about as well as any first employee could reasonably expect (even unreasonably I'd argue).
I don't have the perspective of either a startup founder or the first employee anywhere so I'm not trying to slight the Dropbox founders in any way.
I guess my question boils down to two parts
1. What do you think a reasonable level of compensation is for a first employee
2. Given the success rates of startups (low), why would someone want to be the first employee somewhere versus either their own startup, or a later stage company that could pay them a much higher salary then the typical startup compensation. My unstated assumption here, which you might disagree with, is that someone who could have the impact of Aston, could become a staff engineer at somewhere like facebook/google/microsoft/etc and pull total compensation of 300/400k with a significantly higher chance.
I think the key difference between founders vs. early employees is in risk tolerance. An early employee should be able to go to work reasonably confident that he will get paid for his time and his efforts will not be completely futile. The job description for "founder", however, involves finding a reason for the company to exist, and that inherently involves the risk that you could put in a lot of work and it'll still count for nothing.
Aston (presumably) made out with a lot more than the $300/400K a year that a Google/Facebook engineer tops out at. He also took on more risk, but the risk was largely technical risk: the possibility that him and his teammates couldn't deliver what 65,000 people said they wanted. That risk is largely under their control, while as a founder, the primary risk is that nobody wants your product or it can't be built economically.
I do think that the large amount of money in the funding ecosystem lately has distorted this bargain somewhat. In boom times, you get cases where the founders get funded on hope & pedigree and draw a salary immediately (meaning that their financial risk is more akin to an early employee's), and then they go and hire a bunch of naive employees at below-market rates before getting any validation that people want their product (meaning that the employee now takes on market risk that was previously reserved for the founder). This doesn't do either the company or the employee any good; these companies are significantly more likely to fail than ones who stay founder-only while they prove out the market, and they ruin more peoples' lives when they do. If you look at employee #1's who have actually made out well - eg. those at Google, DropBox, Thumbtack, AirBnB, SnapChat, etc. - all of those companies had validated demand, had raised funding, and in many cases were already in use by thousands of people when they hired their first employee.
"It certainly would've been better financially, though honestly, the difference is "set for life" vs. "set for a long time", so I'm not certain it would make a material difference in my life now"
Let's not forget that DropBox hasn't exited yet, and in fact may be in a very tricky position. As much as it's fun to look at "I'd have had 0.75% of $10bn, that's $75m!", it's rather unlikely that you'd see that money. Maybe they can pull it off, but it's also possible that they are in a bit of a tight spot where they're over-valued, which can absolutely ruinous to employee options. They have to prove to the market that they're much more valuable than Box, which has a head start on them in that regard.
I'm not sure I'd view it as that clear-cut. If you walked away from your previous company with a life-changing amount of money, there's a very solid chance you were better off there than at DropBox, purely from a financial perspective. I'm not trying to be a jackass, I'm just trying to say that they haven't exited yet, and you can't really compare!
I assume there have been secondary stock sales. It's pretty common these days for relatively liquid secondary markets to spring up around tech unicorns. The fact that they aren't "public" doesn't mean that you can't sell; it just means you can't sell to ordinary people. Markets treat regulation as damage and route around it.
Because 1) for brand new startups, which all kind of seem like dumb ideas or impossible ideas at the beginning, only a very small fraction of very talented people are willing to join, and 2) at such a small team size, there's so much more than talent that matters. You'll end up working with that person so closely that they can't just be smart or talented -- you have to trust them to be a partner in helping steer your company towards what it's eventually going to be, in product, technology, culture, etc.
Chemistry and low risk. They knew what they were getting which is worth its weight in gold considering how hard it is to generally judge how well software engineers will perform once on the job.
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.
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.
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.
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?
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.
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.
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.
Dropbox is one of these - not necessarily latency but bandwidth. If LAN sync fails it quickly falls back on uploading/downloading files via Dropbox's servers, which can be expensive depending on what connection you're on. There's no way to debug why LAN sync isn't working and it doesn't seem to respect Windows 10's Metered Network settings.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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."
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.
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
"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."
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.
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.
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.
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.
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.
I have only a very tiny amount of experience with Hg, and it was my first experience with DVCS. I found the learning curve on it much smaller (which is mainly why I choose it over git at the time).
The reason I switched to git was mostly inertia. Many open source projects were going to git, Github was starting to really take off, and just generally there was a bigger community around git. This mean git got more (and likely better) choices for tooling, more help, and personally I would have to deal with fewer SCM's when working on open source/etc stuff.
I suspect the author was talking on those lines, and the other thing already pointed out in this thread: ability to find experienced people.
In my experience, yes. With SageMath we put a huge amount of work into switching from Mercurial to Git (I had originally chosen Darcs, then switched to Mercurial, then we switched to Git). In practice, the depth of functionality with Git can sometimes be an order of magnitude greater than that of Mercial, just do to git accumulating so much more developer momentum (see, e.g., the man pages for "git log" versus "hg log").
"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.
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.
I've been thinking about how to respond to this for a little while, because I'm a bit biased and I don't want to give away to much information about Drew's personal life.
I lived with Drew through college and a bit after. The thing that grew into Dropbox was started in an apartment that I lived in while Drew and I were working at a different startup.
While I would say that I regret not being in the financial position to quit my job and help Drew out early on, I don't think he was able to do it because of his privilege. I also want to call out that I'm struggling justifying that last statement, because I know what a privilege being white, straight, and upper-middle class in America is. That privilege totally helped getting into MIT (by virtue of going to a good high school and so many other things). But, I'm pretty sure he didn't rely on his parents for cash. He probably just stole my leftovers out of the fridge. :)
The fact of the matter is that he's scrappy and smart. During college, we were both presented with an opportunity to make some side cash. Drew took more advantage of it than I did, and it was smart of him. He banked his own cash and lived cheap. Maybe he graduated with less debt than I did, and maybe that helped, but I think that would be the only leg up that he had.
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.
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.
It seems like your question was set up to confirm your conclusion. If you had instead asked how Drew was able to support himself, you'd probably get a more accurate answer.
I feel like most all of us (and especially those of us in the USA) have a fairly decent "trampoline" to fall back on. Most of us have enough skills to go out and get a decent job whenever we need to. Most of us can trade Netflix for side projects and the costs of starting out are so low that there is virtually no risk.
Personally I would want to know because if came from a poor background his success story can potentially inspire many.
Privilege is a fuzzy term. A lot of people are born into good families but achieve way less than what he has achieved. So his background would not matter much for his achievements but it might matter a bit in giving other people hope just the way whether Tim Cook is gay matters very little for him but it matters a lot to little gay kids who want to be like Tim Cook.
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?
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.
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.
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.
I think you might have a point about the "post-exit career of the average great founder" in that it's usually not that impressive.
Larry and Sergey certainly would qualify as "great founders", given their level of success, and, while they continue to run Google competently, they really haven't done anything else (Google still really only has one line of business, after all).
Whereas on the other hand, we have someone like Bezos who, with AWS, has created not one, but two ten billion dollar plus businesses and whose ambition seems to be boundless. Or, of course, Elon.
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?
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?
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.
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!).
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.
Are we sure "pensive_returns" isn't Michael O. Church? Serious question: commenters on HN that write in an idiosyncratic fashion about Church have turned out to be him before.
Every time I read a comment about Church, I find myself asking, "is this how a normal person would write about someone best known for commenting on message boards?"
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.