Skip to Content

Who Discovers and Why

Peter Thiel’s Book

Wavefunction has a good look at Peter Thiel’s Zero to One. As he puts it, “Thiel has said some odd things about chemistry and biotech before, so I was bracing myself for encountering some naiveté in his book.” I don’t blame him; I’d be the same way. But it wasn’t quite as bad as he feared.

Nevertheless. . .there is a grain of truth in Thiel’s diagnosis of many biotech and pharma companies. For some reason the pharmaceutical industry has lost the kind of frontier spirit that once infused it and which is now largely the province of swashbuckling Silicon Valley inhabitants. Whatever the hurdles and naiveté intrinsic to this spirit, it doesn’t seem unreasonable to imagine that the industry could benefit from a bit more can-do, put-all-your-chips-on-the-table, entrepreneurial kind of spirit.

Still, you’ll need to be ready for the phrase “high-salaried, unaligned lab drones” – just warning you. Another part of the blog post mentions a good reason for the more cautious approach that you see in biopharma as opposed to software, though: higher chances of failure via factors outside of your control. That gets back to the humans-didn’t-make-this argument that I make in this situations – you really do have a better chance of bulling your way through in an IT startup by sheer skill and hard work. Whereas in drug discovery, skill and hard work are necessary, but nowhere near sufficient. We get our heads handed to us more often, and for reasons that couldn’t always be anticipated by a reasonable person.
That’s why the avoidable errors are so annoying in this business. Our failure rates are high enough already without own goals!

22 comments on “Peter Thiel’s Book”

  1. MLB pitcher and Medicinal Chemist says:

    “high-salaried, unaligned lab drones”
    Well, they could hire a guy who has been paid millions to throw a ball, such as Dr. Derek Lowe.

  2. Nekekami says:

    “Another part of the blog post mentions a good reason for the more cautious approach that you see in biopharma as opposed to software, though: higher chances of failure via factors outside of your control.”
    Please don’t make such blanket statements. Windows alone has many millions of factors outside the developers control every single minute, they are called humans(and that includes other developers), Linux has the same problems, as does any software above a certain complexity. Hell, besides humans, there’s the fact that different compilers can interpret a piece of code differently… Oh, wait, I should go down to an even lower level… Choosing different optimization levels in a compiler can make your code behave differently and introduce bugs and other unwanted behaviour. Now let’s go higher up in the stack again: Those compiler trained monkeys nowadays? I’ve been called in to help fix some projects, and you find that they’ve used code from 3 different frameworks, that each calls code from 3 or more libraries, and some of the function calls and data structures interfere with each other and….
    And that doesn’t even go into the potential complexity of the task you try to solve…. *sighs* Some people wonder why computer techs, programmers, sysadmins etc drink so much… After watching this clip you’ll understand why the temptation is so great…
    https://www.youtube.com/watch?v=-5wpm-gesOY

  3. Hap says:

    The costs of failure (or, worse, of apparent success that turns out to be failure) are a whole lot higher, too.
    Also, it is probably easier to be swashbuckling when you don’t have so much time invested in getting to a spot where you can be swashbuckling, and where the benefits for being so aren’t as great (because of the requirement for higher upfront investments and thus the dilution of equity). It doesn’t mean that it wouldn’t be good to be less risk-averse in some cases, but there are lots of reasons why people might be so.

  4. steve says:

    See Stuart Lyman’s critique (http://www.xconomy.com/seattle/2015/05/04/the-innovation-challenge-assessing-biopharma-startups/?single_page=true) for a different perspective. You go up orders of magnitude when you move from math (software/IT) to chemistry to biology. You can’t just apply what is true for IT to developing pharmaceuticals.

  5. steve says:

    Sorry – should have read “You go up orders of magnitude in complexity when you move from math….”

  6. Dr. Manhattan says:

    What really irks me when we get these kind of analyses from IT based entrepreneurs (Look at how successful we were in our startup!) is that they don’t have to deal with any equivalent of the FDA in releasing their products to the public. (Actually if there was such an agency, we’d have much better and reliable software, rather than the constantly patched Microsoft products…). Not saying there should be such an agency, but there needs to be a recognition that biotech/pharmaceuticals is highly regulated (as it should be when dealing with human health) and you’re not successful until the FDA is satisfied on safety and efficacy.

  7. Molecular Geek says:

    It’s also important not to neglect the effect of pharmaceuticals/biotech being a highly regulated industry. There are leaders in startups in biotech with the panache and bravado of Silicon Valley pirates, but once they have to start filing paperwork in White Oak, they either tend to tone it down or have a regulatory affiars staff to put a grey tone on the organization’s image.
    And as someone who’s been on the operational side of IT and also in pharmaceutical research, the two fields overlap more it might seem. To sound vaguely respectable, I’ll say they both deal heavily in applied chaos theory. In particular, the law of unintended consequences and Smith’s law* are near universals. IT is just fortunate that better hardware is arriving on a faster schedule than improved versions of humans are.
    * “Murphy was an optimist.”

  8. steve says:

    Look at one of the most successful IT companies of all times, Microsoft. Remember the old joke about what would happen if GE manufactured cars like Microsoft manufactured Windows? Every conceited IT guy should read it then think about what would happen if their engineering concepts weren’t just applied to cars but to biology.
    If GE manufactured cars like Microsoft Windows:
    1. For no reason at all, your car would crash twice a day.
    2. Every time they repainted the lines on the road, you would have to buy a new car.
    3. Occasionally, executing a maneuver such as a left-turn would cause your car to shut down and refuse to restart, and you would have to reinstall the engine.
    4. When your car died on the freeway for no reason, you would just accept this, restart and drive on.
    5. Only one person at a time could use the car, unless you bought ‘Car95’ or ‘CarNT’, and then added more seats.
    6. Apple would make a car powered by the sun, reliable, five times as fast, and twice as easy to drive, but would run on only five per cent of the roads.
    7. Oil, water temperature and alternator warning lights would be replaced by a single ‘general car default’ warning light.
    8. New seats would force every-one to have the same size butt.
    9. The airbag would say ‘Are you sure?’ before going off.
    10. Occasionally, for no reason, your car would lock you out and refuse to let you in until you simultaneously lifted the door handle, turned the key, and grabbed the radio antenna.
    11. GM would require all car buyers to also purchase a deluxe set of road maps from Rand-McNally (a subsidiary of GM), even though they neither need them nor want them. Trying to delete this option would immediately cause the car’s performance to diminish by 50 per cent or more. Moreover, GM would become a target for investigation by the Justice Department.
    12. Every time GM introduced a new model, car buyers would have to learn how to drive all over again because none of the controls would operate in the same manner as the old car.
    13. You would press the ‘start’ button to shut off the engine.

  9. Cassandra says:

    The irony is that a large fraction of the “high-salaried, unaligned lab drones” have been replaced in recent years by much lower-salaried, CRO-employed lab drones who are even less committed to whatever project they’re working on.

  10. John Wayne says:

    I’m not sure if we should be so proud about our complicated, highly regulated industry. While some of the criticisms of our industry are hilariously naive, I’ve certainly known a lot of high-salaried unaligned lab drones. We are all familiar with the reasons for this.
    As you move from a small to the big company, each person’s sphere of control gets smaller. As your job becomes less big picture, it is normal for people to default into process-like behavior (heck, most larger companies insist upon it.) Each day you don’t speak up about rebellious idea, you become more and more of a drone. If you have to be a drone, it better be worth the money … we can easily become a Dilbert cartoon with a series of hundreds of strategic retreats.
    Is they key to our troubles smaller companies? Maybe. They have their own set of problems. My hypothesis is the key to success is becoming (or working for) management that has the will and the power to stand up for science. You can’t get there unless you design experiments that ask the right questions.

  11. Nekekami says:

    @4
    First, you missed the point of my complaint, that Derek made a blanket statement, and two, you assume that his blanket statement is entirely true.
    Derek’s statement about software development true for some areas(that happen to be highly visible and profitable), but in other areas of real-world software development, it’s as far off the mark as someone stating that just because any rookie chemist can make salmiak by mixing HCl and Ammonia in their kitchen, all chemical reactions are trivial.
    As an example of one of the less visible areas is, and to highlight why the blanket statement is so horrible: Logistics planning software. There’s been 50+ years of work on such software, yet even today, such software consume massive amounts of resources(CPU, RAM, storage, manpower…), those systems are still clunky to use, they require frequent updating.
    Dissecting the above example, to highlight it:
    Core function issues(absolutely nowhere near a full list)
    Complication #1: Travelling Salesman Problem, made nastier by the fact that it can be assymetric.At least NP-Hard. Also see complication 7
    Complication #2: Multiple transport modes(see complication 1, 6, 7 and…)
    Complication #3: Laws and rules regarding transport and traffic, including multiple jurisdictions
    Complication #4: Energy requirements(see complication 1 and 6 and 7)
    Complication #5: Manpower scheduling
    Complication #6: Semi-permanent route info(such as max load, max width, max height, historical landmark etc
    Complication #7: Short-term route info(such as roadwork, natural disasters like flooding or storm damage etc)
    Complication #8: Vehicle scheduling(have to factor in maintenance etc)
    Complication #9: Timezones
    Complication #10: Special transports(Like, say, 70m long turbine blades)
    User Interface/data display issues:
    Complication #1: Languages/terminology
    Complication #2: Units(Implemented in SI. But someone from nonmetric-stan(one of the 3) want non-SI units….. 2 weeks later, the aero and maritime industries call and want their units too
    Complication #3: Timezones
    Complication #4: Data Input(How can data be fed to the program? How is data sanitized? How is it converted? To what accuracy?)
    Complication #5: Data output(how do you get the data out of it? What format(s)? what endpoints? Printers, tablets, websites?)
    Complication #6: Relates to #4 and #5, accessibility functions for various disabilities
    Practical implementation issues:
    Acceptable resource use(For example, if you want to cut down on compute time required, you may decide to implement an ultra-simplified TSP solver that instead requires a lot of human manpower)
    Implementation language(affects and is affected by the above)
    Operating system and hardware
    Ease-of-use&documentation
    Database software
    Implementing it according to spec
    Bugtesting it
    Bugtesting it
    Once again bugtesting it
    And last of this nowhere near exhaustive list is Recursion. Many of the above issues interact with each other, increasing complexity.
    As for the consequences, a badly implemented logistics or transport planning system can easily cause loss of life and destruction of property. Just look at accidents caused by Tom-Tom and similar GPS route planning software, routing people to cliffs, trucks getting routed into areas with narrow, twisty roads lined by hedges and children playing etc. Trucks regularly have to turn around, because a bridge can’t take their weight, or they get stuck under low bridges, because the route plan didn’t factor in max height etc.
    Some more advanced logistics planning software even tries to optimize cargo loading on vehicles, and issues with that includes very heavy containers ending up on top of container stacks, just because they were to be transported to the first port on the list, or planes being misbalanced for the same reason, a heavy container ending up nearest to the cargo door because it’s supposed to be offloaded at the first stop.

  12. Nekekami says:

    @6
    Excuse me? Do you think all of software development lives in a field of its own? Been neglecting the maintenance of your fume hood perhaps?
    Here’s a bit of enlighenment for you:
    If I write the code for a medical device, my code must conform to the regulations and standards set by any governing agency in the market I intend to sell it in(FDA in the US).
    If I write the code for a system on a plane, it must conform to the regulations and standards set by any governing agency in the market I intend it to be used in(FAA if it’s a US-only device)
    Software development is not one, single field happily living in their own area sniffing fumes.. ahem, flowers. Software development is heavily sectioned. Parts of the basic toolbox applies to all areas, but there are tools that only apply in a single area too. Hence why Software Engineers are usually appended with a field, such as software engineering(aviation) or software engineering(maritime) or software engineering(industrial automation) etc.

  13. ani says:

    @Nekekami, you preach in the wrong place. Some people here are the equivalent of the foodbabe fans, but for medicinal chemistry. “Everything is easy compare to medicinal chemistry and technology is evil”

  14. Dr. Manhattan says:

    #12. Yes, I am aware that there are software projects in certain fields are indeed critical and subjected to strict review. My apologies as I did not at all meant to denigrate software engineers, nor was that my intent. Certainly Paypal, Facebook, Snapchat, Microsoft Office etc. are not subject to the kinds of intensive reviews that are embedded in the projects you cite.
    My point was that CEOs such as Thiel (who is a lawyer by training, not a software engineer) offer somewhat facile solutions to very complex issues in fields other than their own. The point is that everything in biotech/pharma is regulated, and it is not a option to ignore the influence and role of Regulatory Agencies.

  15. AVS-600 says:

    @12 Last time I checked though, the software entrepreneurs criticizing the drug industry weren’t comparing it to the medical devices industry.

  16. Matt says:

    Outsider looking in here, but I think steve is right. Drug development is a lot harder than software development because biology is a lot less controllable/transparent than software. If drug development were still heavily regulated, but biology were as straightforward as software, then it would still cost a lot of money to get a drug approved but it wouldn’t be high-uncertainty. Instead we see large numbers of very costly late stage clinical failures. Pointing at the FDA to explain drug development failures is IMO akin to pointing at the FAA to explain plane crashes. If the FDA weren’t around then ineffective or hazardous drugs wouldn’t work any better, only some unscrupulous people might make more money by fooling the public. Like in the gloriously unregulated supplements industry.

  17. Dr. Manhattan says:

    @16 ” Pointing at the FDA to explain drug development failures is IMO akin to pointing at the FAA to explain plane crashes. If the FDA weren’t around then ineffective or hazardous drugs wouldn’t work any better, only some unscrupulous people might make more money by fooling the public.”
    I don’t think anyone here is pointing to the FDA as being responsible for failures in the industry. They are the gatekeepers and have high standards for safety & efficacy, as well they should have. The point being made overall is that biology/med chem/pharmacology is tough, and we have a lot of Ph. III failures. It’s the uncertain nature and complexity of the business, and certainly NOT the FDA’s fault.

  18. a. nonymaus says:

    Re: 6, 12, 14
    I think, to amplify on Dr. Manhattan’s point, that if Thiel were VC-ing flight-critical FAA-approved software instead of smartphone apps, he would have a very different view of how well it pays off to charge in whilst yelling “LEEEROY Jenkins!”
    But if he wants “swashbuckling frontier spirit”, there are several startups in the CNS field where he could put his money where his mouth is. Of course, that would involve his investing in manufacturing of “unregulated research chemicals” and “bath salts”…

  19. DCRogers says:

    Silly me, I expected to come here for comments on Peter Thiel’s book.
    Anyone read it and care to comment?

  20. matt says:

    @Nekekami #2,11,12: you are mistaken. This is not a pissing contest about who has the harder job. It’s true, writing software is hard work (part of my work history has included stints both in software and IT), and nobody is arguing that it doesn’t have difficulty. Workers in both fields will work about as hard each day, with all the intelligence they possess, and (I think at least) it’s a wash as to whether there any average intelligence differences between workers in each field. The question is whether a small team of workers with modest capital can achieve success more certainly in one field as opposed to the other, and I don’t think it’s close.
    Fundamentally, in software you are in control of the bugs in your product. If there’s a problem with the code, it’s because you didn’t think things through or you made an error. Where you are interacting with other people’s code, you have documented interfaces, and at any rate the library itself is probably less than a million lines of code, so learning about it is doable. While it becomes exponentially more complex to completely eliminate all bugs, individually nearly all bugs are recognizable. When problems arise due to interactions between libraries, for example, the software developer has easy ways to identify and predict such conflicts, or rule out having to do so. (This software only works on Windows 7 and newer…requires glibc version xxx or newer…only tested with Firefox and IE.)
    Consider what would happen if every customer had a unique set of >> 2^32 libraries and was modifying both the libraries and the processors they ran on, in real time, in ways neither they nor you understood. And “operating system” was simply a statistical description of having maybe any 30% of the libraries in common with other members of that group. And large numbers of those libraries had been written not by human hand but by an automated system of adapting to current conditions with random changes, and have never been analyzed or described so far. So you have only an opaque reference, which you only get by running years of stack traces on thousands and thousands of pieces of hardware.
    Your analogy of resource management software would be appropriate if 90% of the resource management software written utterly failed or was likely to kill people, with problems that only became apparent after hundreds of millions of dollars were spent testing it on customers. And it had to be tested on customers because every customer was unique and simpler testbeds didn’t produce accurate results.
    We both know that safety-critical software that absolutely must work or humans die is tiny in size and scope, specifically to limit the complexity required to test it. You can’t do that in biology; the minimum unit of complexity, one human being, far exceeds all human knowledge.
    Consider the difference between a software startup and pharmaceutical startup: let’s say the software startup decides to tackle resource management. There is no question that software can be written to manage resources, and there is no question that if you use a similar approach to existing software you will get similar results, the only questions are can the company do it more effectively than existing products and can they find a market niche.
    Now consider a pharma startup that decides to tackle, oh, Alzheimer’s Disease. There is no existing way to do that. Well, what’s the problem we are trying to solve in AD? Dementia, ultimately, but what is causing it? Nobody knows for sure, but the suspects are amyloid beta and tau. Or peroxynitrites, for some. Or maybe it’s aberrant amino acids found in some cycads. Or maybe it’s inflammation, “type III diabetes”. Well, okay, how do you tackle amyloid beta, if you pick that as a cause? Lots of possibilities, where no person on the planet can tell you (before clinical trials in people) whether an approach could work. Let’s see, an alpha secretase inhibitor doesn’t prove useful because alpha secretase cleaves amyloid precursor before amyloid beta. A gamma secretase inhibitor proves toxic because in addition to producing amyloid, it is involved in a lot of other important pathways, and as far as is known, there’s not a way to selectively inhibit just the one task. A beta secretase inhibitor may work* if you can deliver it to the brain, but it too has proven to have some severe side effects–maybe the right tweak will allow a dose that minimizes side effects and maximizes the intended result, or maybe those are unavoidable or maybe the trial and error required to find such a tweak cannot be completed with any available sum of money. Or maybe you can use the immune system, create antibodies that selectively bind to and remove amyloid. That gets rid of amyloid that is free enough to bind with the antibody, but what about the stuff left in clumps? Which is the problem? Nobody knows. If the stuff in clumps is in equilibrium with the free, will pulling it out to get bound cause problems? Nobody knows. The antibody approach has proven to also cause some problems, for unfortunately little effect. Maybe if it were tried earlier in the disease process it would slow things down? Nobody knows, we’ll see after it’s tried. And so on.
    When I say “has proven” or “has been found,” each of those statements represents hundreds of millions of dollars in research to uncover these little tidbits.
    *works as far as inhibiting classes of beta secretases, but whether that affects the clinical symptoms of AD is still unknown
    So, for the pharmaceutical startup, no “algorithm” exists to accomplish their task. It’s trial and error, but not a simple little testbed in your lab…lots of testing can be done but it mostly doesn’t give the same answers as rounding up customers, except to identify approaches that are really, really bad. Lots of customers need to be tested, because each will respond differently; even when it works, it won’t work for some, it will harm others, help others a little, and help some a lot. And all of that changes day by day, so you’ll need to run your test a few YEARS to form a trend strong enough to spot.
    Methodical approaches can be used, but the search space rapidly goes to the double digits and more in exponents, and narrowing down the search space requires knowledge that humanity does not possess yet.
    Well, okay, maybe Alzheimer’s was a bad example. What about just cleaning up aspirin? That’s been around a hundred years, let’s just make an aspirin that doesn’t upset your stomach. There’s a known approach, all we have to do is tweak it, like our resource management software is going to do. A google search of “selective COX 2 inhibitor” will tell the story: an apparently Sure Thing turned out to have a higher risk of heart attack and other cardiovascular events, and hundreds of millions of research dollars in, and already selling to customers, Vioxx got yanked from the shelves. Merck set aside something around $5 billion to cover its legal backside. And yet, my father swears by his COX 2 inhibitor for arthritis; he took aspirin (and all the other NSAIDS) for years and says nothing works for his pain like Celebrex. So there you have it: just tweaking an existing successful product produced simultaneously a $5 billion loser and a usable drug and a several-fold increase in risk of vascular events, after a decade or so of investment in design and testing.

  21. ChristianKl says:

    When Peter Thiel speaks about the drug industry he does identify regulation as a key problem that holds back innovation.
    It’s also not like Thiel is a complete outsider who doesn’t have any money in biotechnology.
    He’s the donor of the SENS Research Foundation.
    His venture capital firm Founders Fund has a large stake in http://www.stemcentrx.com/. His other fund Mithril Capital Management has stakes in medical device companies Fractyl Laboratories and Auris Surgical Robotics.

Comments are closed.