6 ms·

A quick skim of CB Insights' collection of 150+ startup post-mortems reveals that only ~5% of post-mortems referenced a lack of technical ability/execution. Mos

A quick skim of CB Insights' collection of 150+ startup post-mortems reveals that only ~5% of post-mortems referenced a lack of technical ability/execution. Most startup failures were caused by building the wrong product, or lacking sales skills, or not having a viable business model. The strong presence or absence of amazing engineers was rarely a factor. "Our biggest obstacle to growth, right now? We still can't seem to attract candidates with strong CS fundamentals. Maybe we should crank up HackerRank hazing process from 3 hour-long sessions, up to 5. Because I mean, just look around -- aren't we amazing? At this critical juncture for our venture, surely we can't afford to dilute our crack team with mediocre talent."

gedrap 10y ago
It probably counts as failure because of poor management, rather than absence of amazing engineers ;)
- delinka 10y ago
  That's obviously not the problem: "just look around -- aren't we amazing?"
50CNT 10y ago
I think that the fact that these are post-mortems (e.g., dead startups) skews things a little. Could be that the founders weren't technical enough to deliver something interesting, which then caused the issues of wrong product (e.g., there was a technologically more challenging solution that would have made sense as a product), being unable to sell the product (e.g, you're peddling crap, and you know it), and not having a viable business model (e.g., noone actually cares enough about what you build to pay you for it). That is total speculation though. Here's how we're looking at what we're doing though. It's viable with a fairly low tech approach, and that's a good start. But we can use technology to take something that "works" and turn it into something that purrs. It's like the phone switching terminals of old. You'd have an operator and you'd tell them who you want to speak to, and they'd plug the right wires in. It "works". Bell made money on that. They had the right product, strong sales people, and they had a business model. But to think even for a second that they could compete with that nowadays? There's some irony that VCs investing in the industry that owes its life to computing and telecommunications are saying "Eh, the technology you're using doesn't matter". But I do think that technology isn't the bottom layer of Maslov's hierarchy of startups. The existence of a market need is at the bottom, then whether your product is able to address this need, then whether you're able to reach that market, then whether you can get paid for doing so. These layers are filters. It's not surprising that most startups fail on the ones that come first. That doesn't mean if you're shooting to be Uber, or Dropbox, or Facebook, or Google, that you tech doesn't need to be on point. And the best point to start using sane tech practices is, well, as early as possible, preferably once you've validated your other assumptions.
- gedrap 10y ago
  > I think that the fact that these are post-mortems (e.g., dead startups) skews things a little. That's a very good! So it's 5% of startups that posted a post mortem (and it didn't disapear into ether), rather than 5% of all startups. These two things are very different things. > we can use technology to take something that "works" and turn it into something that purrs Well put. However, nowadays, the tech itself is often not the key bit in making the difference between 'works' and 'purrs'. Of course, there are exceptions, bigger and smaller ones. More often, it's understanding the problem, the users, and finding the fit. You can build a product with tons of technical debt and wtfs that gains some traction and then spend resources on improving it. However, it doesn't work the other way round. It often takes an experienced engineer to say 'right, let's start some cleaning up' at the right time. However, if your product doesn't solve any problems, no one is willing to pay for, etc, brilliant tech solutions are not going to help it. > start using sane tech practices is, well, as early as possible, preferably once you've validated your other assumptions Totally! It's just that it's often hard to tell when it's the right time.
- lpolovets 10y ago
  (I'm the author of the post.) There's definitely some sampling bias from the post-mortem article. Alas, this is the the most relevant public data that I could find. I do have a good (anecdotal) first-hand dataset: I've worked closely with about 50 portfolio companies at this point, and I've tracked a few dozen more that my fund didn't invest in. Maybe 5 out of the 50 had real technical risk, and 2 or 3 struggled and/or failed due to technical issues. For the remaining companies, the challenges have always been market-related, hiring-related, funding-related, and so on.
  - cs702 10y ago
    Isn't your tech background useful for smelling technical bull%&!t?
    - lpolovets 10y ago
      Yes. That's basically the only kind of tech diligence that I do at this point, and it's more conversational than diving into the tech. (And I only do this if someone is making very bold claims.)
vii 10y ago
These quotes really show the paradox: within the weird definition used in the article of "amazing engineers" which is not defined but seems to imply those who can talk a big game about architecture or score well on the HackerRank, the "quality" of the engineer has no relation to business success. That's because the engineer's quality is being assessed for being able to bullshit about architecture or score points for writing "clean code." The idea that "even great engineers" might take on technical debt is insane. In a startup situation, great engineers take on technical debt with the greatest of glee and at every opportunity, as the primary goal is to find product market fit. Bullshitting about scalability, maintainability and frameworks is counterproductive and maturely, one understands that any software will be almost totally rewritten whatever happens: take this example by John Carmack to start a prototype environment for rapid iteration, explicitly laying out ways in which it should be rewritten if successful https://groups.google.com/forum/#!msg/racket-users/RFlh0o6l3Ls/8InN7uz-Mv4J https://groups.google.com/forum/#!msg/racket-users/RFlh0o6l3... Many good engineers stay in their comfort zone of some part of the software lifecycle. Seems like the author was trying to assess people imagining their situation was that of big company software project going in for a third generation rewrite with little uncertainty about what it should do. This is not the situation startups are generally in, and great engineers in this situation adapt; they pivot without getting stuck on old conceits, and have a knack of understanding which signals to heed to get to that glorious market fit where suddenly reliability is valuable. Definitely they can be assessed on ability.

gedrap 10y ago

It probably counts as failure because of poor management, rather than absence of amazing engineers ;)

delinka 10y ago
That's obviously not the problem: "just look around -- aren't we amazing?"

50CNT 10y ago

I think that the fact that these are post-mortems (e.g., dead startups) skews things a little. Could be that the founders weren't technical enough to deliver something interesting, which then caused the issues of wrong product (e.g., there was a technologically more challenging solution that would have made sense as a product), being unable to sell the product (e.g, you're peddling crap, and you know it), and not having a viable business model (e.g., noone actually cares enough about what you build to pay you for it). That is total speculation though. Here's how we're looking at what we're doing though. It's viable with a fairly low tech approach, and that's a good start. But we can use technology to take something that "works" and turn it into something that purrs. It's like the phone switching terminals of old. You'd have an operator and you'd tell them who you want to speak to, and they'd plug the right wires in. It "works". Bell made money on that. They had the right product, strong sales people, and they had a business model. But to think even for a second that they could compete with that nowadays? There's some irony that VCs investing in the industry that owes its life to computing and telecommunications are saying "Eh, the technology you're using doesn't matter". But I do think that technology isn't the bottom layer of Maslov's hierarchy of startups. The existence of a market need is at the bottom, then whether your product is able to address this need, then whether you're able to reach that market, then whether you can get paid for doing so. These layers are filters. It's not surprising that most startups fail on the ones that come first. That doesn't mean if you're shooting to be Uber, or Dropbox, or Facebook, or Google, that you tech doesn't need to be on point. And the best point to start using sane tech practices is, well, as early as possible, preferably once you've validated your other assumptions.

gedrap 10y ago
> I think that the fact that these are post-mortems (e.g., dead startups) skews things a little. That's a very good! So it's 5% of startups that posted a post mortem (and it didn't disapear into ether), rather than 5% of all startups. These two things are very different things. > we can use technology to take something that "works" and turn it into something that purrs Well put. However, nowadays, the tech itself is often not the key bit in making the difference between 'works' and 'purrs'. Of course, there are exceptions, bigger and smaller ones. More often, it's understanding the problem, the users, and finding the fit. You can build a product with tons of technical debt and wtfs that gains some traction and then spend resources on improving it. However, it doesn't work the other way round. It often takes an experienced engineer to say 'right, let's start some cleaning up' at the right time. However, if your product doesn't solve any problems, no one is willing to pay for, etc, brilliant tech solutions are not going to help it. > start using sane tech practices is, well, as early as possible, preferably once you've validated your other assumptions Totally! It's just that it's often hard to tell when it's the right time.
lpolovets 10y ago
(I'm the author of the post.) There's definitely some sampling bias from the post-mortem article. Alas, this is the the most relevant public data that I could find. I do have a good (anecdotal) first-hand dataset: I've worked closely with about 50 portfolio companies at this point, and I've tracked a few dozen more that my fund didn't invest in. Maybe 5 out of the 50 had real technical risk, and 2 or 3 struggled and/or failed due to technical issues. For the remaining companies, the challenges have always been market-related, hiring-related, funding-related, and so on.
- cs702 10y ago
  Isn't your tech background useful for smelling technical bull%&!t?
  - lpolovets 10y ago
    Yes. That's basically the only kind of tech diligence that I do at this point, and it's more conversational than diving into the tech. (And I only do this if someone is making very bold claims.)

vii 10y ago

These quotes really show the paradox: within the weird definition used in the article of "amazing engineers" which is not defined but seems to imply those who can talk a big game about architecture or score well on the HackerRank, the "quality" of the engineer has no relation to business success. That's because the engineer's quality is being assessed for being able to bullshit about architecture or score points for writing "clean code." The idea that "even great engineers" might take on technical debt is insane. In a startup situation, great engineers take on technical debt with the greatest of glee and at every opportunity, as the primary goal is to find product market fit. Bullshitting about scalability, maintainability and frameworks is counterproductive and maturely, one understands that any software will be almost totally rewritten whatever happens: take this example by John Carmack to start a prototype environment for rapid iteration, explicitly laying out ways in which it should be rewritten if successful https://groups.google.com/forum/#!msg/racket-users/RFlh0o6l3Ls/8InN7uz-Mv4J https://groups.google.com/forum/#!msg/racket-users/RFlh0o6l3... Many good engineers stay in their comfort zone of some part of the software lifecycle. Seems like the author was trying to assess people imagining their situation was that of big company software project going in for a third generation rewrite with little uncertainty about what it should do. This is not the situation startups are generally in, and great engineers in this situation adapt; they pivot without getting stuck on old conceits, and have a knack of understanding which signals to heed to get to that glorious market fit where suddenly reliability is valuable. Definitely they can be assessed on ability.