Invest Like the Best with Patrick O'Shaughnessy
· Shyam Sankar, Patrick O'Shaughnessy
[00:00:00] S1: All value creation is downstream of the culture. Continuing to be an environment where a new person can come in and just have huge responsibility, be in charge of people who've been here 10 years or not. It's like that org structure, I call it a quantum org structure. I don't think a flat org structure is optimal. That doesn't actually work. I think what you want is an org structure that can crystallize, is the right structure to solve the problem as it exists today and is able to reform as the problem manipulates tomorrow. And you can see the pathology of big companies as they go through some sort of big reorg every five years, even if you just steel man it. Probably most of them are wrong, even at inception. But if you just steel man it and say, "Hey, they just reorged. This is the right org structure for this company today." Every day, the entropy is against them. And every day, it's slightly more wrong than it was before. If you're so ossified and committed to your structure that you have to wait until it's totally broken before you reorganize it again, that's a fundamental weakness. So that plasticity and how your commitment to working backwards from the problems, that is how we generate value. And that has to be consistent. And I think if we can protect that and promote that, promulgate that culture in the future generations, we're gonna keep winning. [00:00:00] S0: What critique of Palantir do you take the most seriously?
· Patrick O'Shaughnessy, Shyam Sankar
[00:00:00] S0: What critique of Palantir do you take the most seriously? [00:00:00] S1: When you have a structure like this, you don't get to spend nearly as much time with people as you'd want. The rate of irradiation is very heterogeneous. There's some sort of bimodal distribution for how long people stay at Palantir. The probability that you'll stay for a decade plus if you've stayed three years is incredibly high. But roughly around the three-year mark, everyone faces this crucible where they look around and they say, "This place is so fucked up and crazy." And they have to understand, oh, but that's the feature of it, and then they'll stay. [00:00:00] S0: Sign up for it or not, right. [00:00:00] S1: Or they'll say, this is the bug of it and I gotta get out of here and it's not gonna work. The critique I take most seriously, because I think with a little bit of help, a lot more people can make that hump. And that's the future of the business. It’s in those people. [00:00:00] S0: We have you to blame for how many freaking pitches we have to take that involve some forward deployed something or other in a company these days. You were the one that really pioneered the success of this model at Palantir. Everyone is saying it now, that every company has to have forward deployed engineers or forward deployed so-and-sos to be successful. Obviously, I think that's not true for every company. It's true in Palantir's case for sure. Can you tell us the story of what this term means, where it came from and why it's powerful?
· Shyam Sankar
[00:00:00] S1: We could start by maybe thinking about my critique of the conventional software industrial complex, which is that you're sitting, let's just say in Palo Alto and you're building this piece of software and your essential feedback loop on "Is this software valuable" is, "Can I sell it?" And if someone's willing to pay for it, it must be valuable. That's an okay feedback loop. There's a stronger feedback loop, which is "Is the software valuable? Did it deliver the outcome?" The only way you can assess that is actually in the field with the end user, on the factory floor, in the foxhole. So in our case, it wasn't gonna be enough. You have this weird division between the IT buyer and the operator. The validation is going to come from the operator. The idea was really almost to build software through backpropagation. Hey, how do you go to the person who has the problem? You're showing up with your best thesis of what you've built in the metaphorical Palo Alto, but then you are not just sending a sales engineer out there whose job is to try to ring up the sale. You're sending someone out there who is obsessed with whether it's going to generate an impact in the world or not, and is willing to continuously solve backward and is technical enough to understand the full stack. How would we take the specific and learn how to generalize it over time, in terms of the product? One way of thinking about this is, there really are two types of engineers. There are people who know how to build the right thing, and there are people who know how to build it the right way. And their dopamine hits come out of different things. The people who know how to build the right thing, they're more like MacGyver. Their high in life is, "I solved the problem." In their minds, solving the right problem is 80% of the work. On the other end, you have engineers who are more like artists in the traditional sense. "Don't you see how beautiful the thing I built is?" The architectural elegance, the scalability of it, that's what gives them the high. Nevermind that it doesn't solve a problem anyone cares about. It's art on its own. It should be appreciated. And I think about this like vector math. So the forward deployed engineers skew towards this hacker mentality. The product engineers skew towards this artist mentality.
· Shyam Sankar
And you have an unstable equilibrium where you're trying to align these vectors in a way that you're gonna go upwind. If either side dominates, you don't really have a business. And that's why that seam between them, you actually need a dictator-like figure to manage and decide. And many of the outcomes, particularly – I think this model is super valuable when you think about your customers as existing of some sort of power law in terms of how useful the next marketing thing they're gonna be asking for is in terms of the overall development of the product. If it's a Gaussian, you should just survey all your customers and average it out and figure out what to build. That's like a traditional product development process. If on the other hand, you think some percentage of my customers are living in the future. Yes, only they or only a handful of people have this problem today, but I can assess that this is actually a really valuable thing to solve that no one else has solved. We should solve it now and effectively have a monopoly on the capability to do that. We'll be five years ahead of everyone else if we lean into this problem. You can only surface that in this sort of forward deployed engineering way. The other thing about forward deployed engineers that's worth saying, in the Thielian sense, is the importance of secrets. Peter talks about the importance of secrets. If you're gonna do something really impactful, there has to be something true about the world that you believe other people disagree with you on. Warp Speed is born out of one of those secrets. For the better part of 15 years, our software has been used to make things in the world. The one thing you could not tell anyone before COVID is that their manufacturing software doesn't work. People would point at their ERP system and be like, "Look how great it is. I spent $5 billion, $10 billion doing it." But as a forward deployed engineer, when I would go to the final assembly line on the factory floor, everyone's using Excel. There's a contradiction here that no one is somehow forced to reconcile with, which is really what they're saying is this software is so ill fit for what I'm trying to do, I hit the eject button, I pull the data out to Excel and I'm like hand rolling my own solution. That should be an obvious sign that something's not working.
· Patrick O'Shaughnessy
[00:00:00] S0: What are the limitations of it, in the sense of if you have X Y or Z, you shouldn't try this model or you need this to try this model. One thought would be the product needs to be expensive because it sounds like an expensive process to deploy people on site, highly trained, expensive people and so on. So you need to be selling a very expensive product. But if you were giving advice about use or don't use this concept of forward deployed engineering in your software business, how would you frame it up to other entrepreneurs?
· Shyam Sankar
[00:00:00] S1: I would say this, you have to believe that you're gonna be able to capture meaningful value for the problems you're solving. So your problems you're solving are really big and therefore imply there's a lot of value behind them. And if you can solve them in a deep way, you'll be able to capture that. A lot of the problems we're solving, like to get at bat, you weren't gonna get paid a lot up front. You're actually gonna invest a huge amount into the customer to go do that. But you would do that because you believe that actually in the end, we'll be able to capture the value, a portion of the value we're creating. Our economics will be downstream of our customers' economics. The other part is that your ambition extends beyond a linear box. We always struggled when we came into the commercial world where you had the Gartners of the world and they have this sort of box. This is my enterprise architecture. I've broken it up into all these boxes. What box do you fit in? The answer for us is, well, we don't fit in any box. We fit in all the boxes. It's some sort of heterodox thing. You're solving for all the problems in the seams. Like, you're basically solving for the fact – that architecture diagram was made by some mid-level product marketing manager. It's never been used or validated in anger. It's never actually solved a problem in the real world, but the cargo cult of the IT buyer just keeps believing they should buy it. I think if you fit into that, doing forward deployment engineering would be crazy. Why would you do that? But if you're like us and you don't fit into it, you need some way of just scraping and clawing, to deliver enough value that the institution has to confront. But even though it's heterodox, even though it's heresy to my enterprise architecture, it works.