00:00:00 Chapter five: decisions require informed bets
00:04:48 Shannon theory: information as computable quantity
00:09:36 Data equals bits; verbosity hides nothing
00:14:24 Knowledge converts information into profitable actions
00:19:12 Immutable past principle, ERP designs violate it
00:24:00 Stockout zeros rewritten, forecasts become biased
00:28:48 Economic pain: misallocated capital, lower returns
00:33:36 Bad data scapegoat masks architectural confusion
00:38:24 Historian analogy: fixed records, endless semantics
00:43:12 Systems split: records, reports, intelligence
00:48:00 Reports enforce compliance, not forward decisions
00:52:48 Intelligence generates allocations under uncertainty
00:57:36 Excel proves decision layers already hybrid
01:02:24 Records sold as magic, vendors profit
01:07:12 Litmus test: does software mutate past
01:12:00 Too-good-to-true claims, M5 reality check goodbye
Summary
Supply chain decisions are bets on an uncertain future, so clear thinking matters. The discussion draws hard lines between data, information, and knowledge, then argues that most supply chain software blurs them badly. Its sharpest point is that the past must remain immutable: once firms rewrite history to suit weak models, they corrupt the basis for good decisions. From there comes the practical distinction between systems of record, systems of report, and systems of intelligence. Companies overspend on glorified ledgers, underinvest in real decision engines, and then wonder why performance disappoints. Clear categories, not vendor mystique, are the beginning of competence.
Extended Summary
This discussion centers on a simple but far-reaching idea: supply chain decisions are bets under uncertainty, and therefore whatever informs those decisions matters enormously. The central complaint is that most supply chain thinking has failed to make clear distinctions among data, information, and knowledge. Data are merely recorded symbols. Information is what reduces uncertainty. Knowledge is the causal understanding that allows a decision-maker, human or machine, to turn information into actions that improve economic returns.
From this foundation comes a second major point: the past must be treated as immutable. A firm’s historical records should reflect what actually happened, not what planners wish had happened. Yet many systems, especially standard enterprise software, are built in ways that allow the past to be rewritten. This becomes especially tempting when bad models collide with inconvenient facts. For example, if a stockout leads to zero recorded sales, a simplistic forecasting system may misread those zeros as evidence of weak demand. Instead of fixing the model, practitioners often “correct” the historical record. In other words, they falsify the past to accommodate the limitations of the present. That is not merely a technical mistake. It is a conceptual one, and it leads to bad capital allocation and lower returns.
A third distinction follows: firms need to separate systems of record, systems of report, and systems of intelligence. Systems of record are glorified ledgers. Their job is not to think, but to store reliable accounts of the past. Systems of report summarize past activity and help management enforce compliance with existing processes. They are backward-looking instruments of oversight. Systems of intelligence are something else entirely: they face the future and generate decisions about how resources should be allocated.
The argument is that companies routinely overspend on systems of record because vendors mystify what are, in essence, expensive bookkeeping tools. Meanwhile, the real source of superior performance, systems of intelligence, is underappreciated because it is harder to build, harder to explain, and harder to sell with glossy promises.
The practical advice is disarmingly simple. When evaluating software, ask whether it mutates the past. Ask whether it cleanly separates record-keeping from decision-making. If the vendor cannot answer plainly, that alone is an answer. Much disappointment in enterprise software begins when firms ask ledgers to think, reports to decide, and salesmen to tell the truth about either.
Full Transcript
Conor Doherty: Welcome back. In this special series, Joannes and I take his new book, Introduction to Supply Chain, and we go chapter by chapter and go back and forth discussing the merits, the challenges, the problems, the practical tips.
For this series, I assume the posture of somebody who does not know Lokad, does not know Joannes, and is completely unfamiliar with the quantitative supply chain perspective. In fact, I assume the position of one of the 10 million or so practitioners in the supply chain landscape, someone who might see this book on a shelf, perhaps in a bookstore, perhaps on Amazon, maybe pick it up, start reading, and have questions. And my role in this series is to be your voice. I pose those questions to Joannes and try to get you clarification on anything that you might think is unclear.
Now, this is episode five. If you have not seen the previous four, I do suggest watching them, because things we say today will certainly echo back to previous discussions.
And with that, Joannes, good to see you again. So, chapter 5: information. I think in order to frame it, I will actually read to you the opening line of chapter 5, because I think it really does provide a nice lens for the discussion. Chapter 5 begins: “Every supply chain decision is a bet under uncertainty. To be any good, it must be informed.” What do you mean by that, and what is the practical message of chapter 5?
Joannes Vermorel: So, the first is I am pointing out something that should be kind of self-evident. Self-evident is that your supply chain is complex. It is made of many people, many machines, many locations, many inventories.
If you are completely ignorant about all of that, I think we can reasonably assume that it is self-evident that your decisions are going to be very bad. We can go into the philosophical debate of whether you have some kind of prescience or some magic skill that would let you take correct decisions in absence of information, but that sounds very quickly like not realistic at all.
So now, a good manager has to be informed, decisions have to be informed. Okay, that is kind of directionally what interests us. But what does that mean specifically? What does that mean?
And the short answer is information has been entirely codified at a mathematical level through the course of the 20th century. Thus, we do not have to guess. This is an area where we have actually extremely high-quality scientific knowledge that is extremely dependable.
This knowledge is not theoretical. It is literally, every single piece of software nowadays uses this knowledge in dozens of ways, even in supply chain. Even in supply chain. So any software that you use is using this theory of information knowledge in dozens of ways.
Yeah, your browser, your phone, the system that you use to do video conferencing, anything, and your supply chain software also.
Conor Doherty: So my proposition, ERPs, is that what you mean?
Joannes Vermorel: Yeah. ERP, any… Again, this theory of information, the Shannon theory, is so foundational that it is a little bit like basic arithmetic. It is absolutely everywhere, and that is the point.
What I am saying is that we have something that is absolutely massive, that is absolutely everywhere, that is… if you remove that, there is not a single piece of software in existence that keeps working, almost. Trivial stuff maybe, but anything that has even a modicum of complexity just stops working. And yet, that is my point: how come that I have never seen this theory ever even be mentioned in any supply chain textbook? We have a problem.
Conor Doherty: When you talk about… Sorry, thank you. When you talk about information in this, again, specifically in the supply chain context, you mean data, right? Or what do you mean specifically?
Joannes Vermorel: No, that is the point, is that this term that was used in a very directional fashion, like information… what is information? “Oh, that is what I listen… what is being said on the news. Those are information.” Okay, this is directionally correct.
But what about a super precise, mathematically correct… I would say a definition that has mathematical clarity, not validity, a mathematical clarity to it? Something that is absolutely pure, something that is so pure that you can actually process this thing with equations. And that is the point that I am making. We do not have such incredible theories on everything.
There are plenty of things where it is… For example, for intelligence, we do not have a crystal pure, a high-grade purity theory of intelligence. No, no, no. We have things that are extremely muddy, extremely confused. So it is not always available.
But it turned out that for information, Shannon, one of the most brilliant minds of the 20th century, cracked the problem and gave us a theory, the Shannon theory of information, that is extremely beautiful, simple, and efficient.
Conor Doherty: And what is that?
Joannes Vermorel: So, what is that? It is literally something that codifies at a mathematical level what information is. And this is not mathematical speculation.
It turned out that this mathematical codification is incredibly efficient. It makes software work better. In fact, there is almost nothing that we can do with modern computers that we would be able to do without resorting to this theory. So I know it is a little bit strange to have that and people have never heard of it. But for the audience that has ever done any bits of computer science, it is as obvious as arithmetic. It is foundational. It is very hard to imagine a world without this theory of information.
Conor Doherty: Okay. Well, let me read you some quotes, because again I think the book is 500 pages, so I am just going to give you a little bit more context here, and that way you can respond a little bit more concretely perhaps.
So again, the idea that every supply chain decision is a bet under uncertainty, to be any good it must be informed. You also write, “Mainstream supply chain theory routinely collapses data into information. It treats the quantities it aims to decide upon, that being demand, lead times, service levels, as directly observable.” Now, to the 10 million practitioners who read the book and all the followers who are listening, who all have a supply chain background, what are you saying to them there, and what changes when I take that information?
Joannes Vermorel: First, we need to clarify, that is what I do in this chapter, we need to clarify the difference between data, information, knowledge. And people, again, they have kind of a directional intuition, but if you press, usually what comes out is extremely muddy. And again, if I look at the average supply chain textbook, it is very clear that the author has no freaking clue about what is the difference between those three things.
Again, when I say a difference, I mean do you have mathematical-level clarity about it? Because it is very important, because if you do not have clarity in your mind about those concepts that is of mathematical grade, that means that you cannot use equations. If you cannot use equations, that means that you cannot translate that into software.
So again, it is very important because ultimately what we are describing is that this clarity is not nice to have. It is literally the very ingredient, it is a very quality that makes this thing translatable into software terms. We need… because ultimately software is only basic arithmetic. Software is just that.
So if you cannot translate your ideas into staged arithmetic, in effect you cannot even put that into software.
Conor Doherty: So, back to data, information, knowledge, data specifically as it pertains to the examples you give: demand, lead time, service levels. How does this theory fit onto this?
Joannes Vermorel: So first, data, what is the difference? We need to first approach data. Yes, data is just the capacity to store zeros and ones. If you go down, data is just a representation where you have zeros and ones. That is it. That is data.
Now, the problem is that data, again, if you count in terms of zeros and ones, it does not really tell you about anything, about something that would be like information. We have to get rid… Why? Because let us say, for example, the number one. I can write it just “1,” or I can write it with one comma and a million zeros.
Conor Doherty: It is the same number.
Joannes Vermorel: It is the same number.
Conor Doherty: In French, in English… or a dot.
Joannes Vermorel: Yeah.
Conor Doherty: Just in case anyone was thinking a decimal separator would be a dot in English.
Joannes Vermorel: Exactly. And you can pad with one million zeros. In terms of data, if you add those one million zeros, you will have a megabyte of data. But do you have more information? It is still a number that is like one. What it represents is still the same thing.
And so here we are saying that anything can be represented in many, many ways, and some ways are more verbose than others. And so the problem with data is that data does not tell you whether what you are doing is verbose or not. When you say, “I have one megabyte of data,” if it is only zeros, you do not have any data, you just have zeros.
So then the question, and that was the question being asked by Shannon, was, “Well, okay, what is the something that would be representation-independent?” We are interested in something that would be the essence of what is in the data, and this essence should be representation-independent.
And now Shannon was actually thinking about, “Okay, what are we exactly trying to solve?” That is a big question, because okay, we have all those representations, but what is the finality, what is the endgame of having stuff represented different ways? And Shannon came with an absolutely stunning, brilliant, and simple answer: it is ultimately the capacity to resolve uncertainty.
So information is, in the purest sense, your capacity to resolve uncertainty. And that is why I say, if you quote from the book as well, that is why you can see that this number that I can represent either as just one character or a million, that is why it is doing the same thing. It will let me resolve the uncertainty the exact same way. Thus it carries the exact same information.
And then Shannon goes much further. Once you have this understanding, capacity to resolve information, it gives a mathematical framework to actually understand what is going on. It gives you tools like informational entropy so that you can actually measure the quantity of information. And that is the thing, that information can be quantified. We can know, just like you can quantify kilograms or liters, you can quantify information in shannons.
So it is literally something that is very interesting, and it proves that it is a fundamental unit. It is a fundamental unit of information.
Okay. And it turned out that, because it is so foundational, every single software is built around those ideas. And now the thing is that, if we are getting back to supply chain being informed, that is very interesting, because suddenly we have something extremely fundamental. We have clarified, again with mathematical-grade clarity, what informed actually means.
And that is so important, because now we are not having something merely directionally correct. We have something that is very, very precise in correctness. And that is an instrument that is extremely useful. And again, the criticism that I do implicitly in this chapter is this is an instrument, this theory of information, that is so important that it cannot be treated as a cosmetic detail. It is not like a nice to have. It is something that is foundational, and supply chain practitioners should at least understand what is at stake with this theory.
Conor Doherty: Well, that is actually the perfect transition to this question, because again I was rereading the chapter, as I do in preparation for these discussions. I was mindful that this might get too abstract, because again, data versus information versus knowledge can seem quite abstract, and I do not want to lose people because there are concrete quotes and I want to read them to you and then I will pose you a concrete question so that it becomes a little clearer.
So, just to summarize in your own words, literally your own words: “Data are recorded symbols. Information is the capacity of those symbols to resolve uncertainty.” As you said, “Knowledge is the causal structure that lets a mind, human or machine,” and I know you prefer machine, “turn information into decisions that improve the firm’s returns.”
You then add, that is page 133: “Treating raw records, that being data, as if they already resolve uncertainty is the root cause of dashboards that never decide and planning modules that never plan.” So my question is, how can a practitioner know what mode of thinking they are in? Are they just playing around with data? Are they playing around with knowledge? Or are they playing around with information? Because in your view, only knowledge is what makes the difference.
Joannes Vermorel: Yes. So here, how do you avoid the confusion? Yes, it is very simple. You cannot change the past. Okay.
Conor Doherty: So what does that mean?
Joannes Vermorel: That is literally… so you need to think, am I projecting in my mind something where the past is mutable? If you do, you are in big trouble, because the past cannot be changed. Again, it is kind of self-evident, but very frequently what I see in supply chains is mental models where the past is very mutable.
Conor Doherty: You are talking about just taking past data and making your future decisions based purely on the…
Joannes Vermorel: The past is literally, conceptually, at a philosophical level, something that can be changed. And that is a problem. That is a problem, again, because it cannot be changed.
Conor Doherty: You are saying the past can be changed?
Joannes Vermorel: So according to the mainstream theory, yes. Okay? And I say it is very, very weird, and when you think about it, it is very, very wrong. Okay? Because the past cannot be changed, obviously.
So again, the point is that you have some… that is a sort of first-principle reasoning. So we take something that we take as self-evidence. I need to make assumptions, so I do not want to make massive assumptions. So I need to make my assumptions as small as possible.
So here I am just saying, first principle: the past cannot be changed. That is it. Okay, I am making an assumption, but I am not making an extravagant assumption.
Conor Doherty: But in what way do people act as if they think the past can be changed? That is a better way, maybe.
Joannes Vermorel: Because the way they engineer their software, the past is absolutely mutable. Okay? The past, for example… again, every single ERP on the market, the past is mutable. It is by design, the relational design. So if you engineer an app following the CRUD — create, read, update, delete — it is absolutely mutable. The past can be changed. It is conceptually a problem.
Conor Doherty: And because, for practitioners…
Joannes Vermorel: For practitioners, yes. Because that means, again, you have to think that if the past can be changed, then you are heading for trouble. You can think, “Oh, maybe not,” but I would say no, you are going to have problems down the road, because what you are doing is something that is so brutally inconsistent with something that is self-evident, like the past cannot be changed.
From a supply chain perspective, what does that mean? It means, do your equations treat the past as immutable, or do your equations mutate the past? So if you compute something, you are going to compute numbers, so you are going to have many numbers as input and many numbers as output. Question: do you have a clear boundary between the inputs and the outputs?
If the outputs… you see, if you have the numbers that represent the past, like raw transactional history, and you say, “You know what? It is frozen. I cannot touch them ever because it has happened.”
Conor Doherty: Because it has happened.
Joannes Vermorel: Exactly. And thus I cannot touch those things because they are past. They are immutable. But now let us imagine — and in software it is very easy — that I build whatever, some sort of logic that has a feedback loop that goes logically into the past.
Conor Doherty: That goes into the past. Okay. Why would it do that? Because for what purpose?
Joannes Vermorel: First, it does not need a purpose, because software is very complex, so you can do a lot of things very accidentally. So you see, if you do not enforce a clean environment to say, “My past is immutable,” what you will get is a mutable past by… again, it is just a law of software. Software is complex. The fact that the past is immutable has to be enforced. If it is not enforced, you will accidentally modify it.
So now let us say a practical example where the past… because again, the past is… I know this is very philosophical.
Conor Doherty: I know, but this is very philosophical, I feel.
Joannes Vermorel: But the problem is that, again, the problems of supply chains are things that are so massively wrong that people cannot wrap their head around, because the nonsense has been going on for so long that they are lost.
Conor Doherty: They are lost, and that is why we are here.
Joannes Vermorel: So how do you mutate the past? Well, you have a stockout. Okay, so you have your records and they say what you sold. Okay. So I sold one unit this day, three units this day, four units there, and zeros for this day, this day, this day. Okay.
The problem is that the zeros that I observed in the past, well, we had a stockout.
Conor Doherty: So the fact that you sold zero is the past. This is the truth. You sold zeros.
Joannes Vermorel: Yes.
Conor Doherty: Fine. I do not think anyone will contest this so far. How do you make the past mutable?
Joannes Vermorel: Now you have a problem because your time series forecasting algorithm, the time series forecasting that you use, does not behave correctly. It misbehaves when you feed zeros as inputs because, in fact, you have an impedance mismatch between the past, the semantic of the thing in the past, and the semantic of the past in the future.
The past, what you have are the observed sales.
Conor Doherty: Yes.
Joannes Vermorel: So this is the semantic of what you have observed and recorded in the past. You have… the semantic is the observed sales. But for the future, this is not the semantic that you are interested in. The semantic that you are interested in is future demand. That is the mainstream supply chain theory perspective.
Okay, so the problem is that if I extrapolate time-series-forecasting style my past sales, those zeros are going to create a massive downward bias.
So, in a way… sorry, I know, but it is very simple. Again, if you observe tons of zeros, your model, which is a variant of a moving average of some kind — it is just a glorified moving average with a few cyclicities on top, but it is a glorified moving average — so your forecast, time series forecasting model, a glorified moving average, will take those zeros and it will underestimate the demand because it will take your zero units sold, but it was because of the stockout, as inputs.
That is the problem that people face. And how do you solve that in a very bad way? Because you forgot that you had this “the past is immutable” invariant, you know. So how can you solve that in a way that is profoundly misguided? You make the past mutable.
What do you do? You rewrite the units that you sold to have something that would be the plausible demand for this day. So you modified your past data, and you replace your zeros, that were what you effectively observed, by plausible demand for the day. What you have done is that you have changed the past. Okay? And it is very inconsistent.
And guess what? You will end up in a world of pain, because what you have done is so logically wrong that it cannot be any other way. It will cascade into all sorts of problems.
Conor Doherty: And again, people might think… I will let you finish the point, but there is a key detail there that I think you need to unpack, which is you have described the mechanism of being wrong, but you have not explained the pain of being wrong. So, you have said it is logically wrong. That is the mechanism. What do you feel as a consequence of being wrong? That is the consequence.
Joannes Vermorel: The consequence is your allocations. We are back to economic problems. Your allocations will be out of whack. So that means that you will effectively misallocate your capital, and thus you will have a rate of return that is much lower than the one you should have.
You see, the thing is that any allocation, good or bad, gives you a rate of return. And if you are lucky and you are in a very nice sector, even bad allocations can sometimes yield a positive rate of return. But again, the game is you want to have the maximum rate of return.
So fundamentally, the pain will be diminished rates of return for all the allocations.
Conor Doherty: Less money, essentially.
Joannes Vermorel: Yes. Less money. Yes. And that is always a problem. If you manage your company improperly, the sanction is that it is less profitable. Yes. That is it.
And here you have to understand that this invariant — you should not be modifying the past — is extremely important, and you cannot play with this invariant because it is so logically inconsistent that no matter how clever you think you are, it is going to have very bad consequences for your supply chain. You cannot defy this sort of principle.
Again, it is like if you read causality the wrong way for a business thing. If you think that A causes B, but in fact the reality is that B causes A, if you misread the situation that way, it will cause economic damage. It is a sort of deep misunderstanding that will echo and create all sorts of problems along the road because fundamentally you are doing something that is so wrong that, yeah, it will have negative consequences.
And those negative consequences will be incredibly varied. They will be incredibly diffused. And because it is supply chain, it is complex, et cetera, it will be all over the place, and then it will be very difficult for you to diagnose what is the root cause.
I tell you, you can go back to the root cause. The root cause is you cannot make the past mutable with impunity. That is just as simple as that. And when I say impunity, do not think of it as a moral judgment. It is an economic judgment. This impunity will be paid in dollars.
Conor Doherty: Okay. I am going to push forward a bit on this point because there are at least two other core pillars in the chapter, but between them is another issue about data.
In the chapter you talk about… So you mentioned earlier data are just recorded symbols. They represent something, you interpret them as you will. Now, you push back on the idea that data is often scapegoated as the cause of financial losses and failed programs. You make the claim that — and you have said it actually publicly, we have done live events before where you have said, “Your data is not bad. If you have transactional data, basically depending on what software you have, you are good to go.”
So this is again another example of where your perspective and, let us say, the mainstream perspective will be at odds, because you and I have both heard, I do not know, let us say a hundred to a thousand times — that is the order of magnitude — “My master data is not good enough to start a new project,” whatever. You clearly disagree with that idea. Why?
Joannes Vermorel: So, if we go back to the fact that the past should not be mutable, yes… but the reality is that the way supply chain, in practice — and again, it is practiced with software, it has been practiced with software for the last three decades, so I do not know any supply chain of any scale that does not have software right, left, and center. Software is all over the place.
But if you do not have a very clear boundary between the stuff that represents the past and the stuff that speculates about the future, it is going to be a massive mess. Again, software is complicated, software is complex, supply chain is complicated, and supply chain is complex. So complexity is all the way down.
So if you do not enforce… you must enforce this invariant that you have a class of software that deals with the past, and that is going to be called systems of record. And then you have a class of software that deals with the future, and that will be called systems of intelligence.
If you do not segregate those two, and you maintain this segregation, guess what? You are going to have a hodgepodge mix that is going to be so confused that nobody understands anymore what is going on. And thus you will ultimately blame the data, because you would say, “Oh, obviously we had so many problems, it must have been bad data.”
And bad data is a scapegoat that is very convenient because data, not being a person, means you do not blame anybody. It is when people blame data, it is as if they were blaming the universe. And you see, it is okay.
If you go back in antiquity, that would be just like primitive tribes that were blaming some kind of gods for their problems. Obviously we are too modern to blame a god, so we are not going to blame a god. We are just going to blame a modern construct so that it feels so much more modern. So we are going to blame data, instead of blaming the god of supply chain. But from a rational perspective, this is exactly the same thing. When people say, “Oh, my data is a problem,” what I hear is, “I am blaming the god of supply chain,” or the god of IT, something like that.
Conor Doherty: Well, to be fair — and now I will draw on my previous knowledge, because I do know that your position is a little bit more charitable than that sounds. That sounds very absolute.
Joannes Vermorel: No, no, but…
Conor Doherty: Just to be fair, I am pressing the point.
Joannes Vermorel: Yeah, you are pressing the point.
Conor Doherty: But to be fair, you have previously said — and I am paraphrasing you — but in effect, data is not bad. And your point being that, look, transactional data is what it is.
Joannes Vermorel: Yes.
Conor Doherty: But you have made the point that it can be tricky because there are semantics. And I do not think you mention it in this book. I believe, if I am recalling correctly, it is actually in your first book, the Quantitative Supply Chain Manifesto, the big red book.
Joannes Vermorel: Yes. Yes.
Conor Doherty: And you gave the example — it is one of my favorite examples, and I have pitched it to you before — like, what does sales mean, like on a day? If you open a ledger, is that the sales that happened on Monday? Is it when the warranty period expired from sales two weeks ago? There are about 10 or 12 or 15 or a thousand ways you can slice sales units per day.
Joannes Vermorel: Yes. And that is… you see here, to understand that is that the data about the past is immutable. Think of it like the documents of a historian. The documents are just the documents.
So when a historian is working, the documents are immutable. If there was, for example, a treaty signed between two countries at a certain date, this treaty is perfectly recorded. This treaty does not change.
Conor Doherty: Yes.
Joannes Vermorel: But there might be so many subtleties that are lost in truly understanding what was going on. So the work of the historian is to actually revisit those facts, those records, and build a new understanding of what happened.
Conor Doherty: I like this metaphor.
Joannes Vermorel: You see, and what I am saying is the work of a historian is extremely difficult. Yes. Because in fact, yes, the records are non-ambiguous, but the interpretations that we can have of those records are infinite. And that is the same for software.
So your software — let us assume for the moment that your software is properly designed, in practice usually it is not — and that it is really a software that is mindful of making the past immutable. Fine. So now you have clean software where the past is immutable. You have clean records that are not constantly moving under your feet. That is good.
But I am not saying that understanding those records is easy. Understanding those records can be extremely complicated. And that is why you do not want to make the situation worse by having some kind of feedback loops that reinject stuff into your past.
Just think of it as a historian who would be working with historical documents, but imagine he has a library that says, “Oh, here, it is my collection of documents about what happened in France in the 17th century, and that is the list of documents that I have, there they are, the references, from my understanding.”
And now imagine that in this library you have people who insert forgeries all the time. So they insert fake 17th-century documents in this library all the time. Then the historian would be completely lost. He would say, “Now I had one problem, which was already very difficult, which was making sense of this time period, and now I have another problem, which is getting rid of all the forgeries that were actually created after the time period I am interested in.”
You see, that would be such a nightmare. So obviously historians are extremely, extremely precise in making sure that all the documents that they have are actually of the right period and they are not forgeries that were made after the fact.
And that is what I am saying. So that is why what I am saying is that we need to make the past immutable. But making the past immutable, which is the first step, that system of record, it does not make the past easy to apprehend. It remains extremely difficult.
Conor Doherty: Which is why you talk about you need specialists, supply chain specialists, who can parse the semantics.
Joannes Vermorel: Exactly. And it is difficult, but not because those observations are garbage. They have not been polluted with forgeries made after the fact. They just have some kind of intrinsic difficulty, which is it is very difficult to interpret. When I say “the past sales,” it is a very ambiguous statement. It is a very ambiguous statement.
And that is ultimately where knowledge comes into place. Knowledge is being able to resolve this ambiguity so that you can turn this information into something actionable. You need to resolve all those uncertainties — or all those ambiguities, I would say, not uncertainties, ambiguities.
Conor Doherty: Okay. Well, I do think it is time to address what I would say is the central pillar of the chapter, and certainly something that speaks even beyond the book itself because it is aimed at practitioners. But this gets into just the entire concept of where does a company allocate its money. And that is, yes, systems of record, systems of report, and systems of intelligence.
So systems of record: your ERP, whatever, the historian of the company, to use your own analogy, like what happened when, that is in the past.
Joannes Vermorel: It is not the historian. The system of record is literally the clerk, the clerk, the clerk. It is just the guy who writes.
Conor Doherty: The digital version.
Joannes Vermorel: Exactly, the digital version of the clerk, someone who is just keeping the records. He is not trying to have any intelligence. He is just recording as it is — the good, the bad, the mistakes, and the greatness — everything as it is. That is it.
Conor Doherty: Okay. Systems of report, that is the business intelligence tools, representations of that.
Joannes Vermorel: So systems of report are used for something very different. They are used for compliance. Yes. You see, so what does that mean? That you are going to say we have processes, we have rules, we have best practices, and the management just needs an instrument to enforce that.
So the systems of report, they are not about gaining intelligence, understanding the future, or anything. They are essentially an instrument for a large company, yes, to maintain compliance with its own processes. And that is it.
Conor Doherty: They want insight, they want a visualization of what is happening.
Joannes Vermorel: That is what vendors who are selling business intelligence say. In practice, I have never seen those tools used that way. They are only used… Nobody is really earning any insight. I mean, yes, occasionally, very occasionally, someone will have an insight looking at a business intelligence report, but that is not the purpose of that brand, of that category of technology. It is so infrequent.
For me, it is again a weak analogy, but it is so infrequent that it is very, very secondary. It would be saying like alcohol is something that you can use to make scientific discoveries. Yes, occasionally there will be a scientist that will drink a lot of alcohol, and in this altered mind state they will make a discovery. But saying that alcohol is an instrument of science is a little bit pushing.
Conor Doherty: Now you are making a teleological argument. And actually, allow me just to set the table a little bit more, because I think then we can take the idea a little bit more universally.
So again, you have explained at length systems of record — that is the clerk, it is just the records of what happened. Your systems of report, that is visualization tools like business intelligence. It is not for decision-making. You have sold for decision-making in practice companies who operate supply chains are extremely large, complex, and thus staying consistent with their own proclaimed processes is very difficult. So systems of report are very good at letting managers check if their underlings are sticking to whatever compliance means in the company.
Well, you have actually said… my own microphone is in the way. Hang on a second. “Most corporate disappointments come from conflating these different systems, expecting ledgers to think or analytics layers to serve as sources of truth.”
Now that sets up the category that you have yet to expand upon, which is systems of intelligence. And I, again, having read the chapter, realize that that is where you believe decisions and better performance actually lie. So please explain, I would say somewhat tersely, what a system of intelligence is, and fundamentally why you should not treat the other two classes of systems as if they were a system of intelligence.
Joannes Vermorel: So, that is core, by the way. That is a core point.
So the first one, system of record, is the past. It is a record of the past. It is the best thing that you have about the past. Now the system of report is also about the past. It just tells you if you were compliant in the past with your own processes. So it is very much backward-looking.
So you see, this system of report just tells you a story about the past. It is a way to build a narrative about the past, if you want. It is not very elaborate. It is just again, that would be just like economic history, where French people richer or poorer a century ago? That is just what the system of report would give you. Instead of having millions of records about earning statements of French people, you would have aggregated statistics. That is what you have.
Conor Doherty: We have covered these two, though. So let us get to the intelligence.
Joannes Vermorel: And the third one, it is something very, very different. It is the only one that is actually looking at the future.
Conor Doherty: Okay. And in what ways?
Joannes Vermorel: By design looking at the future. It is by design, because what it is trying to achieve is to generate decisions. So this decision is always forward-looking. You decide something because you think that you will have some kind of payback. That is why you make this decision.
And I have clarified that in the specific case of supply chain, a decision is an allocation of resources. So an allocation of resources, you are essentially allocating a resource because you expect a return on investment of some kind at some point. And your system of intelligence is just a machine to generate those allocations for you. That is it.
Conor Doherty: Not to cut you, but even still, just to underline the point, even if you make your decisions based on things that you have criticized in the past, like “I want to maintain high service levels,” even if that is the case and that is your guiding star, it is still because you want a desirable return on investment.
Joannes Vermorel: Absolutely. So that is the overarching goal, yes. And again, you can have adequately designed systems of intelligence or inappropriately designed systems of intelligence. The only difference will be the rate of return that you get out of your decisions.
But first, you see, you cannot bypass the fact that a system of decisions exists. Why? Because resources are allocated. That is it. Resources are allocated. So the decision is being made. You cannot bypass that. The resources will be allocated.
You are, as a company, spending your dollars all the time to buy raw materials, to buy inventories that you replenish. You are giving tasks to your own employees to do something. That is an allocation of resources. Those things happen all the time. They cannot be evaded.
And what I am saying is that a century ago we had a very clean situation. Systems of intelligence were exclusively human. So the records were already part machine, because the records, even a century ago, were written down in books.
Conor Doherty: So in a way the storage was already something that was inhuman. It was not in the mind of a person.
Joannes Vermorel: They were not carrying this information in their heads. They were carrying it through devices already. Obviously they were not sophisticated, but they were devices, and they could store already, through books, quite a lot of information. So we were already having for the records essentially artifacts. Computers are better artifacts, but we already had artifacts.
When it came to decisions, it was just purely human. Purely human. But now, for the last three decades, what we have is a mix. Nobody has a purely human decision layer anymore. It does not exist. It does not exist.
Even when people say, “Oh, we do everything manually.”
Conor Doherty: “Do you?”
Joannes Vermorel: Oh yes. “Everything is done manually. We are just using Excel.”
I say, “Oh, okay.” So, you know, Excel is very much software. Excel is software. Excel is like an extension of your mind to do tons of basic arithmetic. So we already have some kind of a hybrid system that is human mind plus machines. As soon as you have an Excel spreadsheet, it is a hybrid system. It is software plus human mind, both.
And over time, what I am saying, what I have seen, is that the software portion has just grown bigger and bigger and bigger. And even if it was nothing more than Excel spreadsheets, because guess what? Excel is not itself a moving target. Excel, if we go back 20 years ago, was max 65,000 lines. Now it is a million lines.
Thus Excel, over the last 20 years, expanded in capabilities, and now you can even have Python scripts in your Excel spreadsheet. So Excel itself became more powerful. And there are plenty of things that became more powerful, because for example, people say, “I am just using Excel.” But are they just using Excel? No. They are also using the capabilities of their systems of record and report to generate extracts that are used as inputs for their spreadsheets.
So effectively, it is not just pure Excel. It is a mix of the applicative landscape that is generating inputs that you are putting, et cetera, et cetera. And what I am saying is that overall, year after year, the portion that is delegated to the machine is growing bigger and bigger and bigger. That is what I am saying, and thus we need to put that under control.
Conor Doherty: Yeah. You have also, again in the chapter, advanced the argument that real scalable profitability is to be found by investing more in systems of intelligence rather than systems of record.
Now, we previously discussed on other episodes that the spending tends to be very asymmetrical. So, for example, the majority of spending might be on systems of record, even though you make the argument they do not generate decisions. Like, I have got the most sophisticated accountant or ledger ever. That does not get you to a better decision. So why is the spending so asymmetrical?
Joannes Vermorel: Because again, software is a big complicated thing, and people treat software as if it was some voodoo magic that happens within the offices of the vendors. This is not… software is surely basic. It is certainly not voodoo magic.
Conor Doherty: It is portrayed by some vendors.
Joannes Vermorel: Yes. Because for vendors, they say, “I have a secret recipe. I have a magical ingredient that you cannot replicate,” or something. And that is just essentially talk to promote your products. But it is not rational.
Now, back to the software, what I am saying is that if you maintain your very clean environment, like you have a class of software that is only dealing with the past, that is system of record, if you maintain, you enforce this invariant, then suddenly you realize, “Oh, this piece of software that is only dealing with the past, it is just a glorified version of my accounting books.” There is nothing to it. It is just a long series of records.
And guess what? Hard drives are cheap. So I can have my billions of records and it will be cheap. And thus, should I pay top money for that? No. It is simple. Thus it must be cheap.
Do you think that, as a software vendor, you want your client to realize that what you have in your hands is something that should be super cheap? No. So you are going to mystify the client. You are going to mystify the client, and you are going to create a whole layer of confusion so that people are lost and they do not realize that at the core what you have is something extremely simple.
A system of record is extremely simple. This is just a glorified ledger. Nothing else, nothing less, nothing more. It is super straightforward.
Conor Doherty: People will spend — companies, not people — companies will spend half a billion on a system of record.
Joannes Vermorel: Yes. And why? Because enterprise software vendors are extremely good at making their products desirable. So they will create an enormous amount of confusion so that people think, “Oh, this software, it is so much more.”
And I say no. What you are buying is an illusion. It is not more. If you are buying an ERP, you are buying a system of record, and thus this thing should be very cheap, lean, and that is it. And if you are facing a software vendor that is starting to mystify you by explaining, “Oh no, no, no, my ERP, it does everything, it has AI, it has this and that, et cetera,” you are being mystified. That is my message. You are being mystified.
It is as if an accountant was telling you, “I am a rockstar accountant. I do magic. Profit comes the way I count the numbers. You make more profit.”
Conor Doherty: Actually, just pause for us. Imagine that. That is actually a better line right there. An accountant that would tell you, “Thanks to my great accounting, I can generate so much money for you. We are going to create money out of thin air.”
Joannes Vermorel: It sounds like fraud.
Conor Doherty: Sounds like fraud.
Joannes Vermorel: I mean, an accountant is not supposed to be able to create money out of thin air. The accountants that are capable of doing that are usually doing things Enron-style. They work for the syndicates, or Enron. They had accounting shenanigans that were extremely creative. I give them that. Enron had extremely, extremely creative accounting.
Conor Doherty: Admire the moxie.
Joannes Vermorel: Yes. They were like pioneers of avant-garde accounting techniques, and it is really not good. It is really, really not good.
So again, you do not want your ledger to be the place where you have innovation. This is the wrong intellectual framework. You do not want an inventive accountant. You do not want a creative accountant. You want a diligent accountant. You want a reliable accountant, and you want a cost-efficient accountant. That is what you want.
And by the way, all those qualities translate to your system of record. They are exactly the same.
Conor Doherty: Yep. So this is, again, a key point. You touch on it in the book. I know you have also talked about it in other videos. We do not need to get into the heavy software architecture — we have already been going for almost an hour — but what you just said there, like you want your records to be diligent, you want your records to be snappy…
Again, key difference here: just to compare these two, because I think they are the two most often confused classes in this designation, you have systems of record and you have systems of intelligence. In the book you describe decisions as laborious decisions, because to make a good decision takes time. Now, the software architecture required to support that is the opposite of the software architecture to make a record accurate and fast.
So again, to be very concrete, you are in a warehouse, or in a store, and you are selling things. You want to know how many units are there. You want to know how many units are in the warehouse. You want to know that as accurately and quickly as possible.
Joannes Vermorel: Yes.
Conor Doherty: Now, that is what a system of record is for. Now, you know better the design, but you have made the analogy before, the sports analogy, that basically you can be very, very fast at running like a marathon runner, the best in the world, or you can be a powerlifting champion. It is very difficult to do both because the better you get at one, it comes at the cost of the other. So please expand on that in better words than I just did.
Joannes Vermorel: So again, the accountant analogy is… how many rockstars are in their pastime accountants? None. None. Because if you have the temperament to be a good accountant, you do not have the temperament to be a rockstar. And vice versa.
You would never trust your accounting to someone who is taking drugs, who is doing wild things.
Conor Doherty: So decisions are rockstars in this analogy.
Joannes Vermorel: Decisions are, yes, a little bit. There is a little bit, because they are innovative, they are creative. Fundamentally, what you are trying to do is achieve greatness.
Conor Doherty: There you go.
Joannes Vermorel: And accounting is not there to achieve greatness, because greatness, accuracy in accounting means Enron. You do not want greatness. You do not want innovation in precision. You want something that is always the same, reliable, boring.
Conor Doherty: Boring.
Joannes Vermorel: Yeah. There you go. Yeah. Boring is an incredible quality for an accountant. I would even say, if your accountant is a very interesting guy, I would maybe not trust this accountant. Again, it is a matter of personality. The great accountant is someone who is so reliable that he is boring. That is what you expect from an accountant.
And from a rockstar, this guy can be completely unreliable. But guess what? Sometimes he has a strike of genius, and boom, greatness. That is a great decision. That is the sort of thing that you expect at the decision level.
Because again, the future is uncertain, so it will always be a gamble. That is why I say, at the decision level, you are always speculating. There is no other way. You do not know the future. Thus there is an element of risk. And that is why you can have an element of greatness, that if you are very, very good at the way you see the future, then you can achieve something that is incredible, which is a very, very high rate of return.
Conor Doherty: I certainly like the accountant element of that analogy. I just want to pitch to you, and you can tell me how you feel about it.
To use the musical analogy, how I perceived it was accountant is your system of record. We want it to be sort of mundane, reliable, dependable. The system of intelligence is like Bach or Mozart. They will compose. It will be laborious. It is intensive. It is creative. It is enigmatic. A really good allocation or replenishment, that is like I am taking symbols from all over. It takes time. It is effort. The system recomputes and computes. And at the end, you have Für Elise. You have one of the greatest pieces of music of all time.
The rockstar can make it sound chaotic, but to me the way I perceived it was like classical music. It is precise. There is science to it. The beats, you want everything to fit within parameters.
Joannes Vermorel: But also, if you have true greatness in classic music, which is indeed a better analogy, you cannot enforce boundaries. Genius, even if it is extremely codified and strict, is never within the boundaries, because true genius is redefining what music should be. Redefining the boundaries, pushing those boundaries not randomly, but with purpose.
And that is kind of the opposite of the accountant, that is not supposed to push the boundaries. The accountant, a good accountant, is by definition… again, you do not want any situation… yes, it must be boring. It must be constrained.
If you are in decisions, yes, it is Mozart. You have to push the boundaries of what music can be. Yes. And that is how you have this true greatness. And yes, the analogy really works on this stage.
Conor Doherty: Okay. Well, again, then we come back to… is there… why is there, overall in the industry, a seemingly systematic — pardon the pun — systematic underappreciation for classical music, systems of intelligence?
Joannes Vermorel: So now we need to have a look at the incentives of the software vendors. So what is your incentive? You want to sell at the highest possible price the thing that costs you the least to produce. That is… I am a software vendor. I need to make money. So I have the monies that I earn, that is the price that people pay, and what does it cost me is the price I pay as a software vendor to have the software produced.
So far, software industry is just like production. You want to essentially buy low, sell high.
Conor Doherty: That is it.
Joannes Vermorel: That is it. Now, a system of record, as I said, is very simple and thus very cheap to produce. Great for me as a software vendor. Great. Why? Cheap. Low cost of production. Excellent.
Now the problem is… now the willingness of the client is not that good. You see, yes, my costs are low, but the willingness of the clients to pay is low as well. Not such a great place.
But imagine that if I mystify the client about exactly what my software does, I can inflate its willingness to pay enormously. There will be a problem, which is that if I want to do that magic trick, I will need magicians to do that, because it is kind of a magic trick. So I will need to have those magicians. Who are going to be those magicians? That is going to be the enterprise software vendor guy.
And guess what? Those enterprise software vendors, if you look at their workforce, up to two-thirds of their workforce are actually vendors. They are salespeople. So the cost of an enterprise software vendor… the typical enterprise software vendor, two-thirds, you are not paying for the software being produced. You are paying for the cost structure of selling the software.
So essentially you are paying a vendor for the magicians that they have, that are creating the illusion that the software is so much more than what it is, and thus they are inflating your willingness to pay. You would say, “It is so simple,” but guess what? It is simple, and it works.
Thus tons of enterprise software vendors are doing exactly that. You take a piece of software that is cheap to produce. Then on top of that, you take people that are enterprise salespeople, and then those people will do the voodoo. That is their professional competency. They will inflate the willingness to pay of the clients. And at the end, what you have is companies who are paying extravagant prices based on extravagant expectations that are going to be disappointed every single time, because ultimately what they are buying is something that cannot deliver ever on its promise. That is it.
And this story, unfortunately, has been repeating over and over for the last four decades.
Conor Doherty: Let us be honest, we have been going for an hour, and I think it is about time that I ask the closing question. But it builds on not only what we have discussed today, but honestly the previous four chapters, which is, and I think it is probably one of the most consequential questions, again not only just for practitioners, but for the companies in which they work.
You have outlined systems of record, systems of report, systems of intelligence, the functions of each, where the value lies in each. Okay. How can practitioners who may not have your level of expertise in software design and architecture and whatnot, how can they tomorrow, if they enter a conversation with a vendor to buy an ERP, a system of record, how can they know, “Am I about to get ripped off here? Am I being sold snake oil?”
Joannes Vermorel: You need to ask the basic question: “Is your software mutating the past?” I know it is a strange question.
Conor Doherty: Because you want them to ask that to the vendor.
Joannes Vermorel: Yes. Yes, just ask the question: “Do you mutate the past?” That is it. It is a very simple question. “Do you mutate the past?”
And where it ties to information is that when we finally understand how information works, et cetera, et cetera, what you are doing is that you are asking a simple question that is a litmus test on whether the software is enforcing a fundamental invariant or not.
If the guy, if the vendor, is baffled by the question, then it is a terrible answer, because it means that the vendor has no clue about what it is doing. If the vendor has no clue about what it is doing, you probably should not buy it.
Conor Doherty: You should not buy it.
Joannes Vermorel: You should not buy it. Imagine, again, I know software is so abstract people tend to lose their mind, but let us go back to a question for a car. If you ask a question for a car, it would be, “Is this car safe?” And if the vendor was saying, “What do you mean, safe? I do not understand your question,” then you would be, “I guess I will take another car. I would prefer to buy a car from guys that tell you, ‘Oh yes, our car is very safe. It has safety belts. It has airbags. It has a design where, if you collide with something, the engine will go under you instead of crushing your legs.’”
That is a good answer. That is the vendor that you want. The vendor that you want is saying, “Oh, mutability of the past. Oh yes, that is such an important concern. We have paid a lot of attention to it.”
That is a simple thing. It is just if you are buying a car and you ask, “Is it safe?” and the vendor tells you, “Is it safe? I have never really thought about it.” That is just not a good answer. That should be a terrifyingly bad answer.
And I am just saying, again, software is easier and simpler than you think. You should just ask your software, “Are you selling me a software that is dealing with the past or dealing with the future?” If it deals with the past, do you do it in a way that is clean, so you do not mutate the past? And if you are dealing with software that is about the future, then do you have something that is like a clean separation, and you are not trying to mix everything together?
So you need to ask those basic questions. And then this sort of information is just a way to kind of understand why we need this clean separation between past and future, because ultimately it is about this information. What counts as information only comes from the past, your knowledge on top to generate the decisions.
Knowledge is not looking toward the past. It is fundamentally something that is looking toward the future. But again, you need to have those building blocks, integral building blocks, so that you can challenge your software vendor in very simple ways.
And again, when you ask the question, “Does your software mutate the past?” if the vendor is baffled, you need to run. This is bad. This is really critically bad. This is just as bad as an automotive vendor that says, “Safety? I have no clue what you are talking about.” Again, you should run if you have… you see, these are important simple questions that you can use, and that is what I would suggest. That is why I suggest you read this chapter. You need to be able to ask those painfully simple questions. They will be excellent litmus tests to detect dangerously incompetent vendors. That is all that I am saying.
Conor Doherty: Yes. Another potential way to frame that, and you can let me know what you think, is… so you gave the example of a car.
Joannes Vermorel: Yes.
Conor Doherty: And what I thought while I was listening was, okay, it is like if you were buying a sedan, just a regular family car, and you say, “All right, can I drive up hills? Can I drive up mountains in this? Will it be fine?” And if they say yes, somewhat skeptical.
Now, to map that on to the software analogy would be: you are buying an ERP and you ask, “Can this make better decisions for me?” and they say yes. To me, a question might be something like, “Well, I am a novice, but my understanding is computations required to make decisions are incredibly intensive, and in a single piece of software that will impede the low latency of a system of record. How do you mitigate that?” Just explain to me how you mitigate that. And if they have no answer to that, I would be skeptical, because again the better the requirements to be good at computation comes at the risk of records.
Joannes Vermorel: I would say yes, but the problem is that… I have been thinking… you see, this is a good question, this is a good test. The problem that I see is that your typical enterprise software vendor is going to give you an answer that you will not understand, and it will look smart and coherent. That is why I prefer to ask for facts.
Conor Doherty: But those are facts too.
Joannes Vermorel: No, it is not a fact, because the problem is they can lie. I am not denying them. The problem is that there are ways to make it work. Okay? You see, you can mix systems of record and systems of intelligence. But there is a catch: it becomes exponentially costly.
That is why, for example, you can mix, and you have a very simple example, Google is doing that. So they have a clean record of all the web, plus a system of intelligence that can decide in real time, all together, mixed together. So they have both the system of record and the system of intelligence all together to give you brilliant answers. So it is possible to mix the two.
But it is possible, but it costs a lot of money, really. It is exponentially more costly for the vendor, and it also costs incredible talent. So bottom line, can you have something that is good at both system of record and system of intelligence? The answer is not no. The answer is yes, with tons of money and tons of talent.
And guess what the vendor is going to tell you? “Oh, that is me.”
Conor Doherty: “That is me. That is exactly me.”
Joannes Vermorel: “That is exactly me, and much less than you think.”
Conor Doherty: Exactly.
Joannes Vermorel: Exactly. And so here, what I am just saying is that it is too good to be true. It is too good to be true. There you go. If it sounds too good to be true, it is probably too good to be true.
And it is so difficult to compete with Google. It is so difficult to do those sorts of things together, and the costs are so staggering that the likelihood that you are actually facing someone honest is… again, I would say you have to be skeptical.
So I think it is a good question, but the problem is that the vendor… it will be so easy to lie to you, because they would say, “AI, we are so good.” Yes, normally it should not be possible at this price point, but we are so good that it is possible.
And then you have to call… you are bluffing. You are just bluffing, sorry. Because you see, the problem is that then you have another sort of test, which is that if you had people that were that good to do something that is that grand, you would not be doing supply chain software. You would be doing something that would make you even more money.
Just imagine, if you have teams that are as good as Google’s, even better, and can do things even more incredible, then why do you not compete with Google to just crush them? Maybe you do not do that because, in fact, you do not have those teams.
And if we are back to “it is too good to be true,” let us go back to the M5 competition. The M5 competition — it was a competition about forecasting. Okay? Forecasting.
Every single one of my peers, my competitors at Lokad, if you go on their website, they will tell you “state-of-the-art forecasting. We are the best.” They all tell you, “We have the best forecast.” Sometimes it is not that blunt, but if it is not stated bluntly, it is so strongly implied that it is really in your face.
So the situation is we have a hundred enterprise software vendors who are all saying, “We have state-of-the-art forecasting models,” and that they are really, really pushing the boundary of what is possible accuracy-wise. Excellent. Excellent. Okay. Why not? Why not?
Now the M5 was a thousand teams competing worldwide. If you look at the top hundred people — and again, people can verify, it is a Kaggle competition, so the records are in the public. Anybody in the audience can verify what I am saying. You can go and look at the Kaggle records, and you look at the top hundred people for this worldwide competition, who was part of the top hundred. The answer is: there was not a single enterprise vendor.
Oh wait, there was just one enterprise software vendor in the top hundred. It was Lokad, and all the others were absent.
Conor Doherty: Number one at the SKU level, if I recall.
Joannes Vermorel: Yes, we were number one at the SKU level and number five at the aggregated level. Initially number six, but then someone was disqualified because they actually just cheated, and so after the fact we were reranked as number five.
Okay. But you see, that is why I say too good to be true. If people are so good, there must be some side effect of greatness.
Companies like Facebook are, for example, pushing the state of the art in AI. They do. How do you see that? Well, they have invented many of the technologies that are used by everybody. For example, PyTorch, which is used by like two-thirds of the deep learning community, is a product that came out from the Facebook labs — I mean Meta nowadays.
So you see, if you have great engineering, and Meta has great engineers, one of the accidental byproducts is that you have great technological pieces that come out of your labs, or achievements of some kind. Again, Google, same thing. Google, for example, invented transformers. The GenAI revolution was essentially started at Google. So again, that is a sign that they had truly great engineers.
If we go back to people who claim that they can do system of record plus system of intelligence, and because they have people that are so great, I say, “Okay, but where is the proof of this greatness? What have you achieved that would kind of tangentially prove that you have such an incredible workforce?”
And very frequently the answer is there is none, because in fact, again, you are in the business of doing system of record, which is boring, which is not interesting, which is not technically challenging. And guess what? You are not going to even need the very best engineers, because if you are doing systems of record, why would you want to pay top money for top-notch engineers that you are never going to even need, because what you are designing is actually fairly simple? You do not need those people. So why would you hire them in the first place? The short answer: you do not.
Conor Doherty: All right. Well, you have been going for quite a while. I do not have any further questions. Thank you very much, as always, for expanding and indulging me as I push back on you. I hope I was not too firm today, but again, you are fired.
Joannes Vermorel: Fired. Exactly.
Conor Doherty: Exactly. This is… yeah, this is my last stand. This is Custer you are looking at.
But yeah, as always, I am just trying to get to the heart of what I think is a great book with some really, really, really good ideas, and I am just trying to push you to make it clearer to people who do not already know you, because obviously when I read…
Joannes Vermorel: And who have no reason to agree with me.
Conor Doherty: And who have no reason to agree with you. Exactly. So I am trying to push back. I am playing the devil’s advocate, which I know you have asked me to do.
Joannes Vermorel: Yes.
Conor Doherty: And to you watching at home, thank you for your questions. Many of the questions actually I posed to you today, Joannes, actually came from the audience. And reading more quotes to contextualize, also feedback from the audience.
So if you have any other feedback, or you just want to reach out and continue with the conversation with Joannes and me, you can connect with us on LinkedIn or send us an email at contact@lokad.com.
And with that, we will see you next time for chapter 6. And yeah, get back to work.
