SPEAKER_00 0:00

Imagine you held an auction and nobody came. Imagine you spent millions of dollars and months of time preparing for this auction and nobody did. Imagine that this was supposed to be the start of a brand new business model that had never been seen before and was going to change the economy in terms of billions of dollars and it failed. I was part of that project. I have some stories to tell. I've seen this movie before because history doesn't repeat, but it rhymes. And so it's important to learn from the past to do better in the future. I've seen people make lots of money through good decisions and lose lots of money through bad decisions. I've seen people make lots of money through bad decisions and lose lots of money through good decisions. I've seen irrational exuberance, I've seen overhype, and I've seen the crash. I lived through the dot-com bubble. And a lot of what happened then is happening again. And there are lessons to be learned and there are opportunities to be had. So stay with me on the qualified answer to understand why some decisions do better than others and what we can learn from the past. So let me take you back to the turn of the century or around the year 2000. It was a time of e-commerce, of the dot-com boom, of what was called the new economy. And part of the new economy was that the rules no longer applied. The most important thing was first mover advantage and eyeballs. The balance sheet didn't matter. Spoiler alert, it did matter, but we'll get to that. But this story about an auction is of a company that I was consulting with at the time I was working for Pricewaterhouse Cooper's, which was a big, big firm at the time. And we were helping them build this online reverse auction system. And the concept here was that large companies buy lots of things that aren't direct purchases. So things that aren't required for the production of their products, but that they need to do business. So a great example at the time was toilet paper, tissues, printer paper, coffee, drinks, etc. And the concept here that the whole business was built upon was that these companies were going to come together and pull their purchasing power. So this was something like eight to ten of some of Australia's largest corporates who came together to create this sort of separate entity. And it was going to filter all this aggregate buying power, and then they were going to run what was called a Dutch auction or a reverse auction. And a reverse auction is where the person doing the buying sets the maximum price they will pay, and then they expect the suppliers, the bidders, to bid a lower price to win the business. So, for example, let's say I'm selling reams of paper and I'm willing to pay $10 for a ream. And I'd like a cheaper price if possible. So I'll come onto the platform and I'll say, hey, I'm going to buy 10,000 reams of paper and I want it done at $10 per ream. So I put that up on the auction site. And then the suppliers will then say, okay, um, I'll do it for $9.75. And then someone else will say, well, I'll do it for $9.50, et cetera. That's kind of the idea that they're trying to get to there. Now it sounds completely logical when you think about the benefits for the corporates. Hey, I can pull my spend, get better value, people will be desperate for my business. How hard could it be? Well, the day came that we had our first auction. And if I remember correctly, it was for paper, but I could be wrong. And we all got together, we had press there, it was a big, big event for the project team. And we sat there, the auction went up, and there were the buyers, or the bidders, I should say, it's probably the suppliers were there as well online. And we all sat there waiting for the bids to come in. And absolutely nothing happened. Nothing. Not a cracker. Why? Because it didn't make sense for the bidders to bid because they were doing themselves out of business. And yes, you could say there's a prisoner's dilemma where everyone has to bid because if they don't bid the other person will bid, etc. But what we hadn't guessed at the time was that the price we picked made no sense. And so there was no point in them bidding at all. Now, you may also suspect there may have been some behind-the-scenes conversations where the supplier said, Well, we're not playing this game. It makes no sense for us. I don't know if that took place. That's not cool if that took place, but who's to say one way or the other? But what was important here was that the fundamental question of who is the customer and what do the customer needs was not answered. And we did a whole lot of stuff on that project to make it happen. This was a crazy time. I'll give you for instance. This was a time where we would put people on plane business class with hard drives in their carry-on to add it to the SAN server in Singapore that was in the only data center space we could get. And we were happy to pay that. There was not even questioned that we would pay that. It was a time in the industry where pay rises were going crazy. I remember clearly that when I was at PWC, they were getting poached. People were getting poached to go to dot-com startups and the like because it was lots of money to be made. And I remember the partners came down one day. I was a principal consultant at the time. They came and they said, we're giving everyone pay rises, no one will be disappointed. And so my natural reaction was, I really want to be disappointed. Like, you know, try me. Show me if you can't be disappointed. Well, they came in with 30% plus pay rises for everyone. I was not disappointed. I was shocked and amazed. So that's what was going on at the time economically. And this auction site came about because of a lot of people doing a lot of hard work and making some calls, making some tough calls. So, for example, we had to make some choices about where we would get the infrastructure. This was obviously pre-cloud, and we're working with a partner which was Compaq at the time, and they were providing all our hardware. And I was designing the system, we needed certain amounts of hardware, et cetera, but we couldn't get it. So we had a chat with our distributor who was providing the hardware. And this is where you start to understand that business is not just done academically, it's also people and relationships and opportunities. And so what this particular vendor did is they would maintain what was called buffer stock for another large customer. Um, this large customer also was a partner in the entity that we were building. And so they said, you know what we could do? We could use their buffer stock, ship it to you straight away, and refill the buffer stock off your POs. We were cool with that. That's okay. You can do that. Um, and it worked. It meant we got up and running quickly, but there were second-order effects of well, which projects didn't get done at that original customer because we made this trade-off. But again, at the time there was a rational exuberance. They wanted to be first, they wanted to be there, they needed to be seen to be successful. Now, we weren't the only ones who were trying to build this online marketplace. There was another company doing exactly the same thing with their own set of big Australian customers as well, who were aggregating together because there's no idea that's only ever done by one person. I'll talk a bit about that shortly. But they played a really interesting game where at the time, first mover advantage was really important. And I remember clearly the day that this person turned up at the reception of this really sort of makeshift office we had, it was kind of cobbled together. In fact, it was in the old uh children's family court building of all places. So it had really weird day call, let me tell you. And someone turns up, and it turns out the receptionist rings our CEO and goes, Um, I've got the CEO of our major competitor here. And he turned up to just, you know, say good day, see how everyone's going. So, you know, it was clearly something was up. They launched the next day. They were no more successful than we ended up being, but they launched before us, and he came because he wanted to see that they were going to be first. And in a way to kind of rub our noses in it, not cool. Not cool at all. But what happens in marketplaces that are going through this kind of transformation? Well, Jeffrey Moore did some fantastic work back in the 90s. You may have heard of his book Crossing the Chasm. There was a follow-up called Inside the Tornado. Lots of important points there. Add it to your reading list if you're looking for stuff to add to your reading list. But one of the things he talks about is something called the Gorilla Game. And I'm going to quote a little bit uh and take some license as well. But the gorilla game is a theory that really talks about how companies will self-organize into a rigid hierarchy during this tornado phase. Now, the tornado phase is the hyper-growth phase when the mainstream market adopts new technology. AKA, Gen AI. Mainstream market, something that was very new, and you know, even two years ago, people didn't quite understand. It's a barbecue topic now, isn't it? Everyone's talking about AI, how do I use it, what have you. So this is how it typically gets distributed. And you'll see this in other markets if you think about it. So, firstly, there are three roles. Firstly, there's the gorilla. This is the dominant market leader and establishes the de facto standard and architecture for the industry. And gorillas normally capture more than 50% of the market, even up to 70%, and the vast majority of the industry's profits and valuation. And because they set the standard, they become the safe choice for your pragmatic type buyer. So at the moment, you could argue anthropic might be that gorilla at the moment, or at least they're trying to be, they're shaping up to be, they're they're putting in the plays that you would put in play to be the gorilla. They're setting the standards, things like MCP, etc. Um, I'd argue that uh Google's trying to do the same thing. Obviously, OpenAI is trying to do the same thing, but I think they've slipped a little bit in terms of their gameplay in this area. But this is the gorilla. If you think about the smartphone market, though the gorilla became Apple, didn't it? Bulk of the profits, bulk of the reputation. After the gorilla, you've got the chimps. The chimps are the runner-up challengers. They offer a different proprietary approach to address the same customers, but they didn't become the gorilla. And so they'll typically get 10 to 20% of the market share and they've got to fight hard and they might not have the normal profit margins, et cetera. You can self-select who you think is falling into that category at the moment. And then there are the monkeys. These are smaller niche players or clone companies, and they don't try and create their own standard. They offer 100% compatible alternatives to the gorilla's architecture. And they typically compete on either lower price or particular niche edge cases. And they really are in a read and react type scrambling approach, and they go for single-digit market share, but you can make a good business out of that. Back in the storage days, for example, I worked in storage for a long time. EMC was the gorilla. Uh, you had players like Hitachi or HDS and NetApp, who are probably the monkeys uh or the the chimps, I should say, in that stage. So we had lesser percentages. And then you had the monkeys who were scrabbling around for specific things that worked for them. So Data Direct Networks is a great example with super successful in telco, did really great in certain niche areas, but they were never going to be EMC. And this just talks about the mental models around how a market shapes out. And what that can help you do is lay a few bets, bets of the mind. So, where am I going to put my time, what skills are going to work on, where do I think things are moving to, on particular players as it shakes out. Now, I do not think that this particular model has played out yet. I don't think the guerrilla game has nearly played out yet, but it's in play at the moment. And when you start to see that it's in play, you can start to make better decisions around what it is you're using, why you're using it, et cetera. Now, one of the ways you can do this is using what's called the OOTA loop. Now, the OODA loop is probably one of the best known and overused models in business, but it is relevant. It was created by a US Air Force colonel back in the day to help fighter pilots figure out what was going on and win battles. Essentially, it stands for observe, orient, decide, and act. And I want to unpack that because it is actually a process you need to consciously go through. And when you talk to people, particularly in the military who've been very successful, particularly in combat roles, they do this. I don't want to say naturally, they do it habitually. They do it all the time. So observe is about gathering real-time information about your environment. What's going on? What are your senses telling you? What are the market trends telling you? What's happening out there? Then orienting, giving meaning to the data that you observed. Like what is it actually telling you? Now, this is the most critical step because orienting requires a lot of judgment. And you ain't getting judgment from an AI LLM, let me tell you that. That's where judgment starts to come into play. And that's where you add value because you start to assign what the importance is to the data you just observed. And the key is not to come up with a concept that you then force the data to prove. You're trying to help the data tell you the story. You want it to talk to you in a way that gives you good information, good insight. Then you need to decide. So, based upon your orientation, you need to decide a best course of action. You've got to form a hypothesis, and you're going to have multiple hypotheses to test. There's no one answer. It depends. You get to decide. That's the whole premise of the qualified answer. You know, there's no just it's obvious, do this. It's not a decision if it's obvious. It's just a thing that you do. And then we need to act. You need to execute on the decision. But immediately after executing, you start the loop again. This is where there's a lot of failure I see in business. Is you need to take the results of the action and feed it into your observe cycle and see is the thing that I'm seeing happening what I thought was going to happen? Doesn't my hypothesis hold true? Or did I get it wrong? Spoiler alert, you're allowed to get it wrong if you make it better. A lot of people will not accept that they're wrong. They'll always say, I'm never wrong. We had a leadership principle at Amazon, are right a lot, which was trying to capture the fact that, yeah, we want people to be right a lot of the time, exercise good judgment, you normally get it right, but you don't have to get it right all the time because no one does. If Bezos didn't get it right all the time, everyone gets it wrong sometimes. And so you've got to give yourself permission to get it wrong because then you can take action by saying, I didn't get this decision right at this point, I need to make a change, away you go. Let's go back to my online marketplace example. Um, we had we were an all Windows NT environment, um, Windows 2K as well. Uh that wasn't one of my choices at the time. I wouldn't have gone for that. In those days, the safe choice was uh to go with Solaris and Oracle and that sort of stuff. We went for a full Microsoft stack because one of our partners was a vendor that was very aligned with that, and so that's what we were gonna use. Um, and so I made a decision to use a particular clustering software, and the clustering software had support on NT and was planned for Windows Server 2000 as well. And I took a punt and said, Yep, I'm going with that server software, we're gonna use NT for now, we're gonna move to 2000, it'll be okay. She'll be right. Um I was wrong. And in a funny way, I was so wrong in that I ended up working for the company that sold the cluster software. And even my entire time when I was there, they still didn't release the software. And unfortunately, it was a bad decision. And uh what I learned out of that, and it didn't matter for the company that I bought the software for and on behalf of anyway, because they went out of business, whole other story. But the lesson that I learned there was buy what's on the truck, don't buy the futures because the futures are by nature unpredictable. And people will tell you, yeah, it's just around the corner, it's coming out, we'll have it soon, I'll give you a discount, all that sort of stuff.

unknown 16:58

No.

SPEAKER_00 16:59

Just buy what's on the truck, and life will be a lot better because you're not leaving yourself open to chance. So the ooter loop helps us be quicker and be first if we can use it effectively. But as I mentioned earlier, just being first doesn't mean you're right, but it can help with a lot of other things. So there's first mover advantage that comes into play in the way we think about things. But then we also need to think about the gorilla game. And the gorilla game is fascinating because it's built upon the concept of opening up yourself to some degree to allow others to interact with you in a way that leverages the network effect, which means that more people will use the thing. When fax machines first came out, you didn't get much value from having a fax machine if no one else had a fax machine. So the fax machine market was actually sprinkled with free fax machines. That meant that people would say, Hey, I'll send you a fax. And some would say, Well, what's a fax? Oh, it's this machine. You plug it in, you can send paper to other people. I don't know, arcane concept, but there you go, it had to start somewhere. And because everyone wanted this sort of concept, uh, it became popular in the way that communication was done for a very long time. So network effects are very, very important. If we think about the cloud times, one of the big things about AWS was that it was all API driven and those APIs were public. And one of the social and commercial contracts that took place was that we weren't going to change those APIs in the long term, would give you, I think it was 12 months warning, 24 months before we turned it off, type stuff. Um, if a new version of the uh the um the API was to come out, would maintain the old one. It was all really well done from that perspective. And that's a classic network effect play because we said, well, if you are building something as a third party, the safest choice for you was to use the AWS API, particularly the S3 API, became almost a virtual industry standard. And I remember at the time, industry bodies wanted to create a standard that subsumed that particular way, but the market gets to decide. And so what happens is that the adoption rates and the network effect will overcome, in most cases, any organized effort to create a standard to some degree. Now, we're seeing again that play out at the moment with MCP. It was proposed by Anthropic as an open standard for people to use to have their LLMs interact with other systems. Now, there's lots of arguments about the efficacy of that particular technology, whether it's good or not good, whether we should just use CLIs instead. That's probably a whole different episode and a different podcast. But I think what it does represent was a really interesting move into the space of saying, well, how do we create this broad network effect where our large language model can access any system that someone might want to give it access to, knowing that if I do, I give it deep efficacy and deep utility to my customer. So again, back to that fundamental question: who is my customer and what do they want and what do they need? They don't necessarily need at that time a faster, better model, because the model was good enough, but they needed the model to do more things. Because if the model did more things, it became more important to them and more useful to them, which meant they would use it more, which meant that someone like Anthropic could invest more money in building a better model, which was then more useful, and so on and so forth. And we get into Jevon's paradox. But just understanding the dynamics at play in any of these kinds of market forces and the decisions we make individually and what happens with them is really, really important. And that's really the premise of this show. On this show, I plan to have some really cool interviews with really interesting folks from the IT and business world, where they talk quite candidly and openly and honestly about one or more key decisions that they made and how they came to make those decisions and why they made those decisions and what the ramifications and lessons learned were of those decisions. And I'm doing this because I think it's important. I think as we move into a world where a lot of the classic technical technology skills are maybe not as important anymore. Again, you can argue the toss on that, but certainly I have not written many lines of code in the last year or two compared to the many years before that, where I wrote lots of lines of code. But what I think is never going to go away is the need to exercise good judgment and make good decisions with the best possible data available. Now that sounds like a logical, simple thing. And I think what you'll see over the coming episodes that it's not. In fact, it's anything but for a whole variety. Of interesting human factors and organizational reasons. An experience is a great teacher, but the cheapest lessons to learn are the lessons of others. And the most expensive lessons are the ones that we learn ourselves. Now, the ones we learn ourselves, we typically hold dear and we really feel it. Others maybe we observe and it's interesting, but I still think it's very important to take it on board and understand it. But the the analogy I'll give you is I can tell you that you shouldn't touch the hot stove because it's going to burn your hand. And I can tell you that because I've burnt my hand and let me tell you, it really hurt. And you'll go, yeah, that's great, Simon. Um, I'll bear that in mind. And you'll have that in your mental model. But, and we all go through this as children, the day that you touch the hot stove and feel the pain, the lesson is learnt in a completely different way. And the meta lesson of that is don't touch the hot stove. Talk to people who touch the stove. That's kind of what we're doing here. So that's one kind of episode. The other kind of episode is just me talking, somewhat like today, on different topics of how to make decisions, how to think about technology, some of the challenges I see out there, some of the opportunities I see out there as well. And things that can help you in your career, either as a technology person or a business person, or increasingly both, be successful and help others to be successful. The purpose of the podcast is to help folks make decisions and to understand that you have the flexibility to make good decisions that change over time and that will be evaluated differently over time. And that no decision is easy, everything has a qualification. And that's why I say the phrase, yes with an if, no with a but. Now there's always that variation to be brought in mind there. But what's important to remember is we can make better decisions and we never stop learning. And so I'd love you to come on that journey with me. I have two asks. The first is tell someone else about the qualified answer podcast. It's brand new. I want people to know about it, to hear about it. So if there's folks you know that might be interested in this, please send them the website, send them a link, just give them a hey, go listen. The second is that in the show notes, there's a link. So wherever you are, you can click on the show notes and it actually allows you to send me either a text message or a voice message. So you can give me feedback straight away. It's really cool because it means while you're on the go, you don't have to send me an email. You can just click the button, give me the information. And that may be a suggestion for a future show, topics you want me to cover, a guest you'd love me to have on, etc. I'd love to get your feedback. OODA loop, I need the feedback. I need to understand what's good and what you'd like to see. So if you could help me with those two things, I'd really appreciate it. I hope you've enjoyed the first episode. Lots more to come. Some great guests on the way, believe me. And until next time, keep on building.