Interesting to see how this aged. By my reckoning:
1 (Single Founder) - people just ignore this one, more or less.
2 (Bad Location) - this one became a horrifying monster that devours everything it touches.
3 (Marginal Niche) - probably the biggest killer, then and now.
4 (Derivative Idea) - meh. People worry about this too much. Is there an unserved market?
5 (Obstinacy) - on point. Serve the market.
6 (Hiring Bad Programmers) - This one also became a horrifying monster. Graham says "In practice what happens is that the business guys choose people they think are good programmers (it says here on his resume that he's a Microsoft Certified Developer) but who aren't." Darkly hilarious in hindsight.
7 (Choosing the Wrong Platform) - meh. People use fucking backend Javascript now.
8 (Slowness in Launching) - Pretty valid.
9 (Launching Too Early) - maybe, I guess.
10 (Having No Specific User in Mind) - absolutely important. You have to be serving a market.
11 (Raising Too Little Money) - this pendulum has swung way over the other way now.
12 (Spending Too Much) - Yes. (Hiring too much. Stop trying to feel like an important funded company.)
13 (Raising Too Much Money) - Something of a subtle point, but still an important one - especially now that you can get too much money thrown at you more easily.
14 (Poor Investor Management) - of course.
15 (Sacrificing Users to (Supposed) Profit) - I'll just note that Graham writes that Google puts users first. Hindsight!
16 (Not Wanting to Get Your Hands Dirty) - Graham means with sales work. Very much true.
17 (Fights Between Founders) - This is why you vest, I guess. Graham was still down on founder vesting at the time.
18 (A Half-Hearted Effort) - I mean, why put in more of an effort if you have a route to fail upward?
> But there is a trick you could use if you're not a programmer: visit a top computer science department and see what they use in research projects
Please don't shoot yourself with this suggestion. From my personal experience Academia is so distant from what is relevant or practical to the industry.
Somewhat related, most academia is not focused on source code quality or its suitability for posterity. If you absolutely need to mime or plunder academia to succeed in your startup, pair that with a software industry veteran who can scale and secure your technology operation.
I have the opposite opinion. US funding sources for science and engineering tend to be very government-heavy rather than industry-based; but in my experience those government grants, particularly DoD, emphasize research with specific practical ends. The obvious exception is NSF, but Europe also has similar obvious exceptions at about the same rate.
The big difference between the US and Europe, however, is that universities in the US depend on grants to fund PhD students. Many (most?) European countries have national funding programs for their PhDs, which frees up both the students and their advisors to work on whatever fancies them regardless of practicality. France is particularly notorious for this. US academics do not have this luxury.
In my field, by far the lion's share of impractical (Fun! I love it! But impractical) work comes from Europe.
Yeah this is specific to Europe, in particular Germany, where companies such as BMW would send engineers to work on a defined research project at a university, and then adopt the research if it pans out. In the US there’s far more leeway, and part of being a good PI is stealthily inserting yourself own agenda into the DOT grant proposal, and those in the DOT will give you the leeway knowing that’s “how it works”
I guess this varies a lot. To my shame I don't have hard numbers (! I really should have.)
Personally I've worked on a half dozen global research network projects bringing together both public and private funding and 10-15 organisations, mixed universities, research institutes, and small to behemoth companies.
The target is always some wide ranging new radical technology platform and they spawn a bunch of startups and spin off projects.
Some targets can turn out to be too difficult, or simply wrong, but I've never seen a project that hasn't lead to at least one startup / product / new technology.
Eg: Start out looking at nanoparticle functionalisation, then stumble on a very useful sensor application or targeted molecular delivery.
Eg: Work on autonomous air sensor, then find simple off shoot application for tuberculosis using a completely different technology.
Eg: Build a medical laser for transdermal drug delivery then find applications in dental work and scar tissue removal.
Eg: Design a flexible heterogeneous compute cluster for hpc application, then get customers who want it for the low administration cost.
You start by bringing some very competent and diverse people together to tackle some tricky and new problem. Then after a while you'll have found a bunch of peripheral questions and applications for one thing or other you create in the project.
People talking and sharing experience and knowledge will almost always find new stuff out in the dark. If you're working on the edge of knowledge there is almost always interesting stuff hiding just outside the light of your personal flashlight. Bringing people together in multidisciplinary projects is amazing.
> 6 (Hiring Bad Programmers) - This one also became a horrifying monster. Graham says "In practice what happens is that the business guys choose people they think are good programmers (it says here on his resume that he's a Microsoft Certified Developer) but who aren't." Darkly hilarious in hindsight.
Anecdotally I see a variant on this a lot. Many times I've seen programmers get hired based on pedigree. "You worked at [xyz company or on abc project] you must be an amazing programmer!"
The amazing programmer at xyz company on abc project may have a lot of infrastructure and support teams boosting their stats. Start ups can't afford the overhead that makes a programmer amazing. Visa versa, a start up programmer may languish in xyz company.
On the contrary, the amazing programmer at xyz company may have a lot of skills that they developed from working on a large number of different projects, systems, teams and so on, because the large company has provided them with the chances to practice all those skills.
Roles at large established companies are not normally like those at startups. They tend to be on smaller areas of functionality, more specialized, and with little variety unless you swap teams (and that's almost like getting a new job).
Starting something new is quite rare, and if it's done, it needs to integrate into a whole bunch of existing stuff one way or another; whether it's builds, deployment, auth, database, payments, UI stack, whatever - large chunks of the design space have been explored before and are pretty much set in stone unless you have a lot of political capital to spike something new, or the company is dysfunctional and doesn't standardize on anything, so that it doesn't present consistently to its users and its developers are less swappable between projects.
In a startup, you have to make things quickly, and not necessarily well. What you are building today may need to be retired in 3 months, if not earlier.
In a startup, you usually don't have the time or resources to play with tech and learn cool new things. Instead, you're hastily producing another simplest thing that could possibly work, using predictable tools you already know in and out. You're lucky if it's RoR or Node; you could be stuck with Go or PHP.
In an early-stage startup you work long hours, and are preoccupied with two things: how to divinate what the users actually want (usually nebulous and contradictory), and how to quickly make it work this way. You can easily lose track of what's interesting in the broader landscape, instead of enjoying new hotness as it gets released.
If you want some leisure, join a large established company, work efficiently, and you'll have plenty of paid time to fiddle with the cool stuff developed inside it, and elsewhere. Or become so advanced that a large company will task you with solving something actually novel, not amenable to off-the-shelf solutions.
It's about using the simplest thing that could possibly work, not about excitement. PHP is pathologically uncool, but it does work and it is fast for building new stuff. (God forbid you get stuck maintaining it though...)
I'll have to disagree. Having worked at a "large established company" during my career, I'd say that I've been given the chance to experiment with plenty of new things and projects are also started more often than you'd think, even though not all of them make it to a release. I understand your point, that just because you've worked at a large company it doesn't mean you have the right skills for a startup, however I will still hold my point: it highly depends and I wouldn't discard the opposite situation.
I’ve never worked in a large company where I would be doing everything from front end, middle tier, databases, CI/CD design, creating cloud networking infrastructure, dealing with vendors, designing operations, and talking with customers in the course of a month. This was me last month. Admittedly front end design is a major weakness of mine even though I do know JS well.
Might or might not, in my experience in about any team it is usually some of the people really understand the system, can develop etc. Then there are couple ones that mostly just slack off and enjoy the salary and benefits. Maybe even smart but just not willing to put in the effort. For outside interviewer it might be very difficult to tell which one the interviewer is talking to, both might have very similar CV.
If one has business sense.
Understands that projects can't run forever and they have to be either completed or killed by a certain date.Has a concept of cashflow. Isn't arrogant with ' the customer should know better' or 'Why would anyone do that?'. Knows the balance between 'this needs to be improved long term' and 'we need sales today' and how to keep both running. Doesn't get involved in idiotic keyboard wars about spaces vs tabs,etc.
Agree, didn't think of a lot of the points you make. However from my experience, "this needs to be improved long term" will stay exactly as is, forever, in favor of business requirements and it will be improved only when the business absolutely demands it to be.
"this needs to be improved long term" isn't really something you can put on a quarterly roadmap though. I think a good startup engineer knows how to keep track of these things themselves, and knows when and how hard to push on project leaders to get something done about it. Imo, most of the "UGH why doesn't the business side care about this!?" is really a lot of engineers failing to properly communicate in business-speak with the rest of the company. If we can barely explain the bounds of what "technical debt" means and how we handle it to ourselves within our domain in software, how can we possibly expect people involved with business requirements and money numbers to ever meaningfully understand this concept?
I'd argue that not all experience is equal. Sometimes developers with deep big-company experience have a skillset and habits that is great for big-company but terrible for a startup environment. The opposite is also true.
Plus all the things @cosmodisk said on the sibling comment.
No. It depends on where their experience lies and the balance of their skills.
For a startup, you want wide and somewhat shallow experience. Since everything is an experiment, you want to crank out features and see what sticks.
I.e. you want a programmer that can do some UI / some app logic / some data science / some database / some infra/ops, (Not unlike a special forces person).
If you come from a big company, most roles are very specific / very deep - for example, a person works for 2 years on a file system kernel.
Except for UI - which I avoid like the plague - this describes me. UI is the easiest thing to outsource or get temporary contract labor or a boot camp grad to design to spec.
The problem with outsourcing in the early stages (MVP), is the speed of delivery. If you outsource it to a temp contract you are introducing a weak link in your delivery pipeline.
In addition, for your customers, the UI IS the product. Especially for the CxO level. So most of the "go/no go" decisions will be done based on the quality of the demo UI.
I’ve never worked at an early stage startup. For the last decade, I have been hired at four companies after they had found product/market fit, they “moved fast and broke things” and saw their velocity slow to a crawl because what got them here won’t get them there. (I never fault a company for having a horrible architecture if it got them off the ground, they got funding and survived to get to the point they are (see Twitter).
They needed to hire people to mentor and to help them implement better processes but at the same time being a hands on developer.
But, I have seen plenty of times where the company had an in house designer to design mockups of the UI and hire either a contractor that worked on site or a junior boot camp grad that knew $frontend_framework_of_the_week to save the heavy lifting for the senior devs/FTEs.
On one hand it seems like competent front end developers who can do “good enough” front end development and design are a dime a dozen and you can pay them peanuts. On the other hand, while I know HTML/CSS well enough to do some ugly internal site and I know JS well, I could never go from empty git repo to a well designed single page app on the front end. There is some type of mental barrier when it comes to me being a modern front end developer.
But if you give me a budget, time, and admin credentials to an AWS account, I can go from empty repo, no infrastructure to a fully baked backend solution with a full network infrastructure, database, cache, CI/CD solution easily (been there done that).
In a startup you need to wear many hats. At a large company you may have had a specific role ("front-end developer", "database administrator", etc). In a startup you don't have the luxury of not-my-jobism. Experience is of course great, so long as you have breadth.
If I were hiring for a startup. I would avoid someone who worked at Google. I would want someone who is wide not deep and could handle the stress and juggling that is part of a small company.
Google seems to have more “smart people” (tm) who don’t “get things done”.
> 2 (Bad Location) - this one became a horrifying monster that devours everything it touches.
I can't figure out whether you mean that location matters or that it doesn't.
And in the first case, whether you think SF Bay Area is devouring everything it touches due to insane living costs and salary expectations, or whether being elsewhere means losing out on certain perceived network / opportunities.
The original post makes it pretty clear that pg believes that, if you're not in a handful of locations, there's basically no point in doing a (presumably SV tech-style) startup.
> It probably means the founder couldn't talk any of his friends into starting the company with him.
re. 1), fun, since very young I was always told to never ever ever make a company with a friend or any kind of associate as all the experiences in/around my family of people making companies as associates failed spectacularly, while all the 1-person things worked out fine. Wonder if it's a cultural thing.
The best startups I've worked for have had multiple founders. It gives you multiple points of view. The company is less likely to make a mistake. And when it does, it's less likely to stay with it.
With a single founder, it's very easy to go in the wrong direction. Because the person is stubborn, won't consider the alternatives, and has no "equals" to confer with, it often stays that way...
Guilty of number 18, guess why it took two years between wanting to found and actually doing it.
Also guilty of number one, kind of. But that is more due to family /economic situation than a lack of a co-founder.
Regarding programmer and platform. There are so many cloud solutions out thereby now, unless softwareis your product, there is no need to develop it in-house. Take warehouse management and transportation management. Unless you want to built a new WMS or TMS, but build a service, just use the stuff that exists. Which make the programmer a guy able to appraise and implement said software. And like the programmer, one of the founders should be good at doing that.
Valid point. Depends on what solution you are looking at, so. One extreme would Office, nobody would develop word, excel or outlook by themselves if that wasn't the product to be sold.
I wouldn't draw the line of writing software at "is software the product to be sold?", but rather at "does writing software gives us a true competitive advantage?".
An example: I once worked for a company that was successful in the translation space. Most freelance translators were using Word with some expensive plugins, but the company made the choice to use an app made in-house tailored to translation and that gave them a competitive advantage (faster iteration, less mistakes), so they basically replaced Word with an in-house solution. And their "product" was still the translations, not their hidden software (Of course this was back when Translation Management SaaS weren't popular).
Of course I've seen the opposite happen as well: I know a SaaS company that were in the business of selling blogs and CMS software. They had built their own blogging/CMS from scratch in the span of two years, but after six months launching, they pivoted to be a Wordpress host. Whoops, looks like customers just wanted a Wordpress anyway. They're doing ok now btw. (btw: I know that's a terrible example, since they turned out to be a service company rather than a software company).
Point is, writing a WMS or TMS would make sense for a non-software company if (and only if) it had completely novel ideas that would put them ahead of the competition. Of course that's a rare thing but still a good space to be explored!
Nobody in my story was in the business of writing a word processor.
Interestingly, that's probably another lesson on mistakes that kills startups: thinking that the only thing able to replace X is an exact replica of X.
yeah, the bias towards San Francisco got so strong that companies fight over every single college graduate that gets near there, inflating salaries to incredible levels, while tens of thousands of experienced engineers are underemployed in other cities. And the glut of overpaid 23-year-olds hasn’t exactly been good for making SF be a nice place to live
Bootstrapped, launched and sold two startups as a single founder. Launched a third one with academic cofounder . Was asked by VC "how much of a Prof is your Prof". Spot on as it turns out too much. Just saying...
> Not leveraging / building upon an unfair advantage — Network, Contacts, Insider information, Access.
Lol. Pretty much by your definition all advantages are "unfair", but absolutely, yes, if you don't leverage your network and contacts you'll likely fail. But more importantly, I think if you think of "network and contacts" as some sort of shady underworld, you're already screwed.
Your network is mostly people you want to work with, and more importantly people who want to work with you. Heck, one major purpose of YC is to give the benefit of an amazing network to folks that otherwise wouldn't have access.
1 (Single Founder) - people just ignore this one, more or less.
2 (Bad Location) - this one became a horrifying monster that devours everything it touches.
3 (Marginal Niche) - probably the biggest killer, then and now.
4 (Derivative Idea) - meh. People worry about this too much. Is there an unserved market?
5 (Obstinacy) - on point. Serve the market.
6 (Hiring Bad Programmers) - This one also became a horrifying monster. Graham says "In practice what happens is that the business guys choose people they think are good programmers (it says here on his resume that he's a Microsoft Certified Developer) but who aren't." Darkly hilarious in hindsight.
7 (Choosing the Wrong Platform) - meh. People use fucking backend Javascript now.
8 (Slowness in Launching) - Pretty valid.
9 (Launching Too Early) - maybe, I guess.
10 (Having No Specific User in Mind) - absolutely important. You have to be serving a market.
11 (Raising Too Little Money) - this pendulum has swung way over the other way now.
12 (Spending Too Much) - Yes. (Hiring too much. Stop trying to feel like an important funded company.)
13 (Raising Too Much Money) - Something of a subtle point, but still an important one - especially now that you can get too much money thrown at you more easily.
14 (Poor Investor Management) - of course.
15 (Sacrificing Users to (Supposed) Profit) - I'll just note that Graham writes that Google puts users first. Hindsight!
16 (Not Wanting to Get Your Hands Dirty) - Graham means with sales work. Very much true.
17 (Fights Between Founders) - This is why you vest, I guess. Graham was still down on founder vesting at the time.
18 (A Half-Hearted Effort) - I mean, why put in more of an effort if you have a route to fail upward?