Muji - A hhhypergrowth Discussion
This episode is brought to you by Stream by Mosaic, a product that is integral to any fundamental research process. Stream has developed an extensive library of expert interviews that cover a variety of industries. https://streamrg.co/BB features over 300 expert interviews per week. 70% of Stream's experts are found exclusively on https://streamrg.co/BB. Visit https://streamrg.co/BB today for a 14 day trial.
Album art photo taken by Mike Ando.
Thank you to Mathew Passy for the podcast production. You can find Mathew at @MathewPassy on Twitter or at thepodcastconsultant.com
Please leave us a rating in your favorite app store!
+ Transcript
Bill: This episode features Muji from hhhypergrowth.com, that's three H's, where he writes about tech. Muji has extensive technical knowledge about internet infrastructure, network security, and high growth companies such as Snowflake, each is unique. He shares his knowledge via paid newsletter, which I subbed to and I enjoy very much. I would not have been able to get through this conversation without Stream's library. To the extent, I sound like I am a noob, I somewhat apologize but also somewhat cop to being a noob to some of this. But Stream got me a lot of the background knowledge that I needed to be able to ask some of the questions as did Muji's website. I hope you all enjoy this episode. It's a topic that I find absolutely fascinating. As always, none of this is financial advice. All of the information contained in this program is for entertainment purposes only. Please consult your financial advisor before making investment decisions and do your own due diligence.
Thrilled to be joined by Muji from Hhhypergrowth, I think I said that correctly, writes the Hhhypergrowth Blog referral to the show by Shomik, and I have really enjoyed subbing to your stuff, and reading through the backlog, I have a ton left to go Muji. You pen deep technical explanations of trends and I have really enjoyed reading it. So, thank you for doing it.
Muji: Yeah, thanks for having me on. Yes, I go rather deeply, more in piece length into some of these technical platforms. So, it's not for the light of heart. So, kudos for jumping in.
Bill: Yeah, it's been fun, man. The one I haven't been able to get to is the piece on Snowflake, and everybody tells me that I have to, but I have my own little obsession with internet infrastructure and how it works and CDNs, and I don't fully understand what makes Cloudflare different from Fastly, and both of them different from Akamai. So, I'm working on getting competent in that language and you write a lot about it. So, that's where I've started.
Muji: Yeah. So, I wrote that what is Edge Network's piece? Well over a year ago now discussing the architecture that they've adopted. So, yeah, happy to talk any level of depth in there.
Bill: Yeah. So, I think what would be helpful because not everybody knows what even an Edge Network is but if you don't mind, maybe, taking a brief walk-through memory lane of how we got here, and why as a society we're using Edge Networks today maybe try to help people piece together, the backbone of how they get their content looks. That might be a good place to start and then we'll see where it goes.
Muji: Yeah, sure. So, there're these services called 'The Cloud' that exist out there that I like to call core centralized cloud.
Bill: I've heard about those. They're big these days.
Muji: Some called the Hyperscalers because what it allows for is centralizing all your infrastructure using infrastructure as a service IAAS capabilities, which is the raw compute, memory, storage, networking that these clouds provide in a centralized place. So, you can create that raw level core VMs and really just move your infrastructure as is from your bare metal systems that you might have in on-premise centers into the cloud. Where CDNs came about is that, once you have all of these centralized services, it really behooves you to cache that content around the globe in order to make it faster and more responsive to the end users as well as greatly reducing the amount of the hit, what's called the origin server, the underlying web server service that's delivering that content.
Bill: All right. I'm going to make this even a little more basic just for people that really don't understand. If back in the day maybe, you had to send the outbound signal from your device would have to travel over fiber, it would ping something miles, miles, miles, miles away, sometimes across the ocean, whatever, come back, takes forever, there's a delay. CDNs push the distance that the signal has to travel much closer to your device and caching the information close to where you are means that the signal doesn't have to travel all the way back to, let's say, Netflix is a good example. I'm sure it's probably on AWS, but it doesn't have to go all the way to AWS. It goes to a point in between where you are and AWS is and the information is cached, which means stored, so, you can get the video much quicker than you otherwise could. Is that a fair characterization of what's going on?
Muji: That is. They serve a content delivery network serve as a middleman, a proxy for your content. So, as Netflix is streaming a video, it's a little lumpy with Netflix because that's a massive amount of content. So, I like to use something like New York Times, publishes an article, much more smaller piece of content but millions of readers are going to read that content or view that video that's going to hit the underlying web server delivering that content over and over and over again, greatly increasing the amount of costs in core cloud. So, if I have a million hits hitting my web server to deliver this article, that means I need a lot more resources in the cloud, I have to put a load balancer in front of it, so that I can distribute that load across many servers that can deliver that content in order to even keep up with demand at that point.
Even before we get to the latency, it's just about handling demand. I'm publishing something in one place, there's a lot of consumers, millions and millions of them, they are hitting that content at once, that's going to create a massive spike in the load that the underlying infrastructure has to handle. So, caching moves that into a distributed architecture, where they have what are known as points of presence, P-O-P-s or PoPs that are their edge servers distributed in data centers around the globe, so that I, a user in San Francisco let's say, would be hitting content server in San Francisco, that's caching that content, instead of going all the way back to wherever New York Times has its data center, let's say New York, but expand that out further, a user in Hong Kong is trying to reach that same content at the same time, they can hit the cached content in Hong Kong instead of traversing the globe. So, absolutely it minimizes the number of network hops that has to occur, which greatly improves the latency of that and the round trip time, so that instead of it taking several seconds for me to circumvent the globe with my network request and then get content and circumvent the globe back with the response, it's much more instantaneous with having that locality of infrastructure.
So, Akamai was the stalwart here. It has hundreds of thousands of PoPs distributed around the world that are very low power and really just ideally situated for serving content from a cache. If that content doesn't exist at the cache, the cache will go back and then make the request to the origin server and say, "Give me the content, it will then cache it for a certain amount of time from that location." So, instead of one web server or a host of web servers in one location serving up that New York Times content, you can have in Akamai's case, hundreds of thousands of servers distributed around the globe serving up that content instead. So, Akamai was the first mover here, but then Cloudflare and Fastly came about as the upstarts to have a more programmable way of controlling your cache content. That's really the architectures the day then created is what's spawned what I'm interested in this new paradigm called Edge Networks.
Bill: So, first of all, the other thing that is really cool if you're not familiar with how all this works, but before all this existed, the cloud and whatnot, The New York Times would have to have their servers on premises and they would have to build the capacity such that they could handle the highest potential peak that so things wouldn't go down. Now, you can share the infrastructure via the cloud. So, it's just like much more efficient because everybody's not planning for their individual peaks and building out too much aggregate capacity, it's shared throughout the system. Is that a fair characterization of what meaningfully changed?
Muji: Yeah. There are a lot of transitions in the underlying technologies. Absolutely, the core of what you said is true that you have to handle peak load. So, for a live event that's being streamed, that's all in the moment millions of users at once. For content from New York Times, it might have its ebbs and flows, where it's some kind of topical piece for a local market that is an event coming up that weekend, it's going to get a lot of traffic or however the readership ebbs and flows any given moment, maybe there's more nighttime traffic with say, Netflix than daytime traffic. We always have to have the capacity to handle that real time load. A couple of shifts occurred, one was the virtualization of things. So, instead of bare metal servers hosting a web server, you can have VMs and have many web servers with a load balancer in front of them handling that load and that is what initially started to even the load and usage of bare metal systems, so, you could really maximize resources. From there, the migration to the cloud is enabling a lot of different directions.
Certainly, on the virtualization front, you can not only have VMs now in the cloud, but you can have containers that are a little more minified VMs and more specific to purpose and more programmable in particular. Then as you migrate to the cloud, then other shifts are occurring such as the distributed nature of application architectures. So, containers and microservices are starting to enable more distributed application architectures much less you can tie into platform as a service capabilities within these cloud vendors such as database services, like, you were mentioning, Snowflake can deliver or MongoDB can deliver those services for you on that raw cloud infrastructure, and then serverless functions are the next wave of further dividing your application into these inner working pieces, and in that case, erasing the concerns for what the underlying infrastructure that it runs upon, which is the serverless movement.
So, a lot of different waves of technology virtualization, the cloud, container-ism, distributed architectures with microservices, and now, serverless functions, so, you've got a wide range of ways you can architect an application that is housing your content. Now, that further wave we were just discussing out, which is outside of your immediate zone of control, outside of your infrastructure, which is that CDN network can be hosting your content outside of your control, but delivering it more rapidly and reducing the amount of hits on your underlying infrastructure a thousand fold or more by hosting that content on these remote servers instead of every request hitting your server.
Bill: Is it fair to say that the way that I'm going to call this all-internet infrastructure for lack of a better term, and please feel free to correct me if I'm wrong on that. But is it fair to say that the way that this is all developed has enabled the application on our phones or our computers to have less demand on-- the application puts less demand on the device that we're using it on and it's pushing the demand out towards the CDNs or the backend infrastructure, and that has something to do with why there's such advances and what our devices can do, is that fair to say or did I mess that up?
Muji: Yes, you haven't. I guess that's skipping ahead a little bit into where these Edge Networks can go from here in that they can basically provide compute directly away from your device in a very near location. So, that's a little bit the end of the story or where we can lead into--
Bill: Well, let's go to where we should go in the story.
Muji: It is [crosstalk] structure.
Bill: I don't want to skip to the end because I like this stuff. I want to help people figure out why.
Muji: Yeah, exactly. We should take a measured approach here-
Bill: Yeah.
Muji: -as we walk through these things. Yes, It's all internet infrastructure. I tend to call that raw IaaS portion of cloud services and platform as service capabilities built on top of it and SaaS services that are then built on top of that same raw infrastructure such as MongoDB, Elastic, Cloud, Confluent, Snowflake or Building. Building a service that you can tie into that's built upon raw cloud infrastructure across clouds. I consider all that cloud infrastructure. CDNs exist apart from that. They're their own thing built outside of the core cloud. Everything else I just mentioned is in core cloud, where Edge Networks are going is outside of it.
Bill: So, do you mind explaining why there's a distinction there?
Muji: So, what the CDNs have done, certain ones have started to build compute capabilities over those dumb cash servers that they've been distributing around the globe. This was all built to handle content delivery. In Cloudflare's case, it was a little bit different and they were trying to build a security product, and they have a core product that sits over websites in order to protect them. So, they serve as a middleman proxy over any website and content is one of the things they deliver. So, Fastly was a direct competitor to Akamai and that they wanted to build a more programmable content delivery network, so that developers could use APIs to control the CDN content in order to refresh it as quickly as possible and to basically manage what we'll call this distributed cloud that they've been building across these kind of smarter distributed cache systems.
Bill: Okay.
Muji: [crosstalk] Edge servers that they're distributing around the globe. They're building programmability into it.
Bill: Okay and Akamai is it fair to say it's like a little bit dumber for lack of a better term, like, you can't program it. It just there to cache information and get it to quickly whereas Fastly, you can customize it a little bit better. Is that a fair way to think about this?
Muji: Yes. So, Akamai as the leader in this invented this technology as websites and mobiles started taking off, you know that you had to cache this content elsewhere, especially, in this publish and subscribe model of the internet, which is I'm publishing content, a video, a blog post somewhere and people are consuming it from there. CDNs really power that portion of the web. They took the tactic of more is better. So, less powerful servers, hundreds of thousands of them distributed around the globe to be as near as possible to the internet populace.
The approach that Fastly and Cloudflare took is that they wanted smarter Edge servers. So, they have much fewer. Fastly has under a hundred in comparison to probably 300,000 by Akamai. I haven't looked at them within the last year but they had over 250,000 when I first investigated them. So, it has more compute capabilities, it has more memory, and that allows them to then build in those programmability into their cloud and basically interconnect all of those distributed servers and have it serve as one large distributed cloud. In Fastly's case very devoted to content delivery and in Cloudflare's case starting to then pivot from there into other adjacencies.
Bill: Interesting. So, how do you have latency that is low enough to compete with Akamai if you're Fastly, when you have so many-- few is the word I'm thinking of, servers or CDNs rather I'm sorry.
Muji: There's more to content delivery than speed. So, if you're going to solely focus on speed and have a dumb cache delivering that that's distributed everywhere, Akamai is a choice. But if you want more programmability into it to tie your developers and better tie your application stack into that content delivery network, you're going to go with something that's more programmable. So, you can have the best of both worlds in these new emerging content networks.
Bill: That's interesting. It sounds to me like the more programmable network should in theory be quite a bit more capital efficient since you need a lot fewer access points or is-- [crosstalk]
Muji: Absolutely. Yes, because it's not just the servers that are hosting it. It's all the networking infrastructure, which is I haven't really discussed yet but that's what's powered these smarter networks to appear is the rise of software defined networking. So, instead of having to maintain a stack of network appliances with your firewall, your routers, your switches, your load balancers, your DDoS protection, a host of any cybersecurity need used to have a separate appliance that all had to tie together in a giant rack.
Now, with software defined networking, you've basically taken that concept of virtual machines in application stacks and applied it to networking. You can have a core machine have all the networking ports, but use software to drive the behavior of that any particular application needs to have over that network can all be programmatic now, instead of having to tie together these legacy network boxes. So, that's really what has allowed these upstarts, let's say, to create a better network. In their case, a programmable network with many distribution points around the globe that they can now start taking advantage of in new ways.
Bill: Interesting. Is it possible for someone like Akamai to pivot the way that they do things or is the legacy, I guess, tech stack for-- Does it preclude that change within them or you know what I mean?
Muji: Oh, yeah.
Bill: Are the entrants just attacking an incumbent that can't do much?
Muji: Pretty much. [laughs] Sorry, Akamai, but we've seen the story play out a number of times of a company that has a cash cow, in Akamai's case it was these arrangements they had with the stalwarts of the web to deliver their content, as companies are becoming more, I'd say next gen in terms of technology adoption, companies emerging like Shopify, let's say, that have an entirely programmable app stack, they want to tie into a more programmable network and distribution capabilities. So, you're going to find the future forward companies really starting to adopt with these new content delivery networks, not Akamai. So, they had the cash cow and they weren't even slow to pivot or they weren't slow to see it, let me put it that way. They were experimenting with Edge Networks with serverless compute at their distribution points very early from what I understand. Just the market wasn't ready, they shelved it, and then were slow to pivot and once it actually became a thing.
We've seen this with Splunk, who was very slow to adopt from licensing to recurring revenue for one move as well as from on-prem to Cloud. You saw Palo Alto slow to pivot from its firewall into other new modern cybersecurity techniques that are enabled by these more software defined networking programmable network capabilities. So, companies have to adapt on an ongoing basis because they didn't allow some other solutions to emerge that have become their own thing.
Bill: Interesting. So, I'm just trying to make sure that people don't get lost here and maybe I'm just talking to myself. So, please, pardon me, fully programmable app stack is something that you said. I think you said that. I maybe mis-repeating. What exactly does that mean and what was the old world like? In other words, what can we do now with this technology that couldn't be done before?
Muji: Yeah. I've written about this in my premium service actually quite a lot. The old method is what are called monolithic app stacks, which is that you're building all your features into one giant application, you're having set releases of that application, takes several months to tie all these changes together, and you go through a formal QA process, and it all gets released at once, every several months if not every year. But in the early days of the cloud and on-prem, it's all about building all these capabilities into one giant system.
Having not even using distributed systems, it's typically like one giant API built on one VM or one bare metal system. As I mentioned before, one of the application architecture trends that have emerged with the cloud and become a lot easier in the cloud is distributed application architectures. So, that's what I mean by modern app architectures is the move towards away from monolithic applications and towards microservices and distributed application architectures as well as serverless functions like AWS Lambda allows which is really breaking your application into-- Your application might do thousand functions and you've combined them all into a monolith, you're breaking those thousand functions up into pockets of related activities in the case of microservices or in the case of serverless functions breaking them down to very specific functions that do one thing only. That was very difficult in the days of old I'll say because it just magnified the number of applications you had to deploy, you had to test, you had to manage all of those things manually. Now, there're tools emerging that are allowing better management over those things, better observability over them. So, that's what I mean by these, I guess, it's a future forward tech companies, is that they've adopted microservices, they're a lot more nimble, individual teams are responsible for specific portions of their application and the inner work together instead of one giant team trying to cobble together all these changes into one release cycle.
Now, it's all split. Not only do you have different ownership, you've got different release cycles and it can be daily and even hourly with some of these companies with modern app developer workflow tools, you can be releasing as you make changes that can be automatically tested and released in today's world.
Bill: That makes sense. I'm thinking of Microsoft and I realized that this is software, but it's the difference between I have Windows 95, and then they're working on the next Windows forever, and then I get 98 to Office 365, where it's continual iteration, and I just get pushed out maybe there's one thing that needs to be tweaked, but the whole operating system maybe doesn't get redone every single time. It's just like one piece. Is that a fair-- something that rhymes with what you're saying obviously at a different level, this is the software you're talking about, more infrastructure?
Muji: Yeah.
Bill: Yeah.
Muji: I mean, certainly, it applies to that monolithic approach. An operating system has to do thousand different operations. It's all combined into one giant hole and released on a set schedule. So, exactly what you said, Microsoft had to collect all those things, test them together, and have a release cycle every several years in that case. That's the way licensed software has worked that you had to install an HR package, you would install it once and then you get annual updates, let's say from there. Under SaaS, your SaaS service that handles HR software could be being updated hourly behind the scenes and you have no idea. Why? Because behind the scenes, all those thousand things have now been broken up into separate pieces that all intertwine and intercommunicate with each other.
That's what's that distributed application architecture. It's entirely invisible to the user but in turn it's made it so much easier to manage software, because every team is now responsible for their separate piece. They can develop it, build it, test it, deploy it at their own pace as long as they maintain a contract with their company about how microservices have to intercommunicate and work together, company needs to find a common platform for that and then once that's in place, those pieces, I feel it becomes the better way to deploy application architectures.
Bill: Yeah, that makes sense to me. Something that I had heard you say in a previous interview, I think it was Brandon Beylo's was that you're from the software world and for a while you were hesitant to invest in software, is that what you said? I'm not putting words in your mouth, right?
Muji: You're not. Yes, I was a very passive investor for the first several decades of investing. As a software developer, I was very hesitant to invest in software companies because I knew what a house of cards they could be behind the scenes. How hard it is in that monolithic architecture to piece together all these changes, test what's called the integration test, test all the various changes together as a whole, not separately, you need to do both, you need to test every change you commit. But then once they all come together in a greater whole, you have to do an integration test over the entirety. Make sure one fix didn't break another for instance. So, I felt like those concerns, those early concerns I had in software in the early aughts, let's say, or the early teens of this century have been eradicated because of these new application architectures. Making the application so much more resilient in particular. There're high availability concerns where you can now live deploy application changes even in a complex multi-container system through a variety of deployment strategies and never have downtime basically. So, there're better testing capabilities, there're better workflow tools, all of this is now automated in most modern software companies.
Bill: I'd imagine that the customer of any given company in that environment is potentially less likely to get frustrated with the product that's coming out because if there's continuous improvement, I used to hate Windows, hate Windows. Now, it's actually pretty nice to use. I think some of that's just specific but I think some of it too is that the improvement is continuous. So, I wonder if it's reduced. Often part of why I have stayed away from software as an investment is, I've never really understood. When I look at the valuation and I look at the current business, I'm morphing a little on this. So, pardon any dumb thinking. But I've just never understood the duration argument. I've been like, "Man, this has to stick for so long in order for me to get paid back if I truly want to own the business in perpetuity." Now, I think that the way that things are being developed, it's potentially a stickier relationship once you're in it. But I don't know how do you feel about that? Is that flawed thinking?
Muji: Well, to step back just a little bit, I completely agree with where you're going in that. These updates in today's app stacks are mostly entirely invisible to the end consumer. What the consumer sees is way better uptime, way more resilience of the software. It's just up all the time ending major outages at AWS, just last week.
Bill: [laughs]
Muji: These applications are more resilient than they used to be and so they're more dependable. So, I tend to live in enterprise SaaS, which I see to the latter part of your point there as enterprise SaaS tools, and especially infrastructural tools are becoming the underlying building blocks that other customers are building upon. So, an operational tool-- consumer, I tend to stay away from in general. It's just a lot more fickle of consumer sentiment. With enterprise, you get a lot of usage and a lot of users with a single sale. You're selling to a company then the thousand users have to use your software. That's a massive sale in one. So, I tend to like that, go to market a lot more but I'm finding that these are becoming really deeply sticky services, especially infrastructural. If I'm using some kind of database service such as Snowflake or MongoDB and I've built my stack on top of it, I'm not going to easily rip that out and replace it. So, it's guaranteed amount of usage from that point going forward and then hopefully as other companies succeed and grow the service that's providing these underlying infrastructural capabilities is also succeeding and growing.
Bill: I like MongoDB as an example because so, what MongoDB does is, it's basically a database company for lack of a-- I'm maybe not saying it the right way but DB makes me think I am. But it's like data entry and you can be not quite as rigid as you might have had to been an Excel can be a little bit more free flowing or it's easier to customize. But once you have your data entry into a program, what's the probability that you're going to recreate all your data entry as a business?
Muji: Yeah. There're certainly competitors to MongoDB and there're other documents stores that you can morph your data into. So, it's not like they're competitor free. It's just that once a software stack has been built upon it, it becomes an arduous process to, it's like lifting up your house, scraping out your basement, relaying a foundation, and putting your house back down. It absolutely can be done. It's just a major ordeal [crosstalk] it's not a quick change.
Bill: That's what I meant. Why would you port your data over as long as you're getting some minimal viable output from the company you chose upfront. I would think it would be very competitive upfront and then once that sales process is over, the probability of switching is quite low I would think.
Muji: Yeah. So, that's one of many, many things that I find attractive about software in general and enterprise SaaS in particular, and especially enterprise infrastructural SaaS is that it's all forming building blocks that other companies are building upon and doing it in a way that they have extremely high gross margins, there're very low capital costs, really it's just paying what I call the infrastructural tax, which is what they have to pay to the underlying cloud providers in order to provide the service on top of AWS, and Azure, and Google. Some of them live across all three such as MongoDB, Elastic, Confluent, and Snowflake. Then they provide an extremely sticky service.
In those cases, a very vendor agnostic way in that if I'm an AWS shop and I have to set up all my infrastructure in AWS, well, now, we've acquired a company that's all an Azure shop. But these tools are allowing that cross cloud inner communication that I also find very appealing in today's stance.
Bill: Yeah. That makes a ton of sense because you wouldn't want to have-- well, as an acquirer, the least amount of friction when you buy somebody is a good thing. So, it stinks to really want to be able to purchase a target company and then all of a sudden, they're an Azure shop and you're like, "Well, it's going to be terrible to migrate everything over." If I understand it correctly, if both of you use Snowflake, it doesn't really matter what the backend of Azure versus AWS is you can integrate your data, and share it, and it's just seamless. Is that fair?
Muji: Yeah. This is what Oracle has proved over the past several decades is that, once you've locked in a customer into whatever your specific solution is, you can continue to milk that. I think where they failed is maybe keeping up to date with cloud trends as those got adopted. But finding a lot of these companies are now extremely nimble and can adapt very quickly. Especially having that distributed application architecture really allows for-- The underlying architecture is very modular. So, they can adapt very quickly with new solutions, especially, like Edge Networks that are starting to appear.
Bill: It sounds like as you're talking about this to me, like, the key if you're thinking like me, I'm trying to learn about this stuff. Please pardon me if anything's really dumb. But it seems to me that you want to drill down to the part of the stack that is not going to be that easy to displace. So, if you think about it like, I don't know, a solar system, find the sun, the sun's not going anywhere but don't think that every star is going to be the sun if that makes sense.
Muji: Yes. [crosstalk]
Bill: I think I read that which is why I thought this [crosstalk].
Muji: [laughs] Actually, find the shining stars in here that have an extremely sticky service that aren't likely to go anywhere.
Bill: So, how do you go about finding these stars? I'm curious what your research process looks like and how you find new ideas and stuff like that?
Muji: Well, so, I'm a hhhypergrowth investor. I did have a detailed post called what is hhhypergrowth that goes through my investment process. There are some secular trends. I'm mostly watching right now, Edge Networks being one of them. Developer tooling, again, those core services that companies are building into their application stacks like an example might be Twilio or Stripe providing communication or payment infrastructure into your application very easily. Okta for no identity management, that sort of thing. cybersecurity with the trends towards zero trust, and SASE networks, which is relying on experts to run your networking infrastructure and security, instead of you running it yourself, and data and analytics is a massive trend right now. Everyone keeps saying, "Data is the new oil at this point" and it's about making better use of it.
We're seeing a lot of disruptive AI based companies starting to emerge in specific verticals. So, it's all encompassing within these trends where I tend to live but then I look for hhhypergrowth companies, which in turn tells me a lot of things. Obviously, it tells me that they have a lot of current success, but behind the scenes, it also tells you that they have created a product successfully, are finding a lot of market fit that customers are flocking to it and spending more, the land and expand motion is all visible to me in the hhhypergrowth. They've had an initial success. It might be outside of their control like the pandemic proved that a lot of companies saw an uptick in usage just with stay at home. So, I'm trying to find the durable secular trends in hhhypergrowth. Adopting better security, adopting better networking, adopting better data tooling, adopting better dev tooling for application stacks, those aren't going to go away. Those are not one-time trends, they're long-term trends over the next several years.
So, I tend to stay in those industries and then try to find the better companies looking at the fundamentals in terms of the explosion of profitability that inevitably should occur. So, I do look at underlying margins and see gross margin going up, which shows that they're making better use of the underlying platform that they're built upon, the underlying cloud service, or IaaS infrastructure and then, better operating margins that the company itself, it's salesforce and R&D is able to do more and more with less. But really, where I tend to then live on top of all that, that's all in the financials in the KPIs that the company reports, I then look for how are these platforms built, what are they built upon, what are the adjacencies I can see them entering, what are their product releases telling me, what are their customer conferences telling me, what is management telling me in earnings calls in terms of where the product is morphing, how does that then turn into adjacent markets that they can enter and increasing TAM? So, it's finding solid companies that are doing extremely well now and that I expected to continue to do extremely well in the future.
Bill: Okay. So, if I can say that back to you, it sounds to me that you're top of the funnel idea generation is looking at the financials for hhhypergrowth, which you define as north of 40%, right?
Muji: Yeah. It varies but it's about 50% at this [crosstalk] as the minimum.
Bill: Okay. All right.
Muji: [crosstalk] the quality of companies I'm finding where that line is drawn.
Bill: Okay.
Muji: Generally, companies with revenue growth of over 50% and in turn ARR growth over 50%, and then, high gross margins for over 70% and growing, ever increasing towards the positive operational and cashflow margins, and then, if they are cashflow positive, fantastic. An NRR, net retention rate over 120%, which tells me that the companies that are currently used to product last year are spending 20% more this year. So, usage is increasing. So, that with the customer growth metrics show me the land and expand motion within these companies, want to see lots of lands, new customers entering, the ecosystem, and spending more and more time.
Bill: That makes sense to me. Then, so, do you tend to try to, let's say, you find this company, Snowflake for lack of a better example, will you exit then once it exits the hhhypergrowth stage or are you okay owning it forever?
Muji: I don't own forever. I am okay with exiting or keeping it after it exits hhhypergrowth. I actually held Okta quite a long time. Because it was such a well-positioned company in so many different trends at once, until I started seeing operational issues or product issues, where I don't feel that they're not growing to the best of their potential. So, I ultimately will exit when I see faults but certain companies do have a lot of long tail, so I tend to hold them for quite a while.
Bill: Why are you willing to exit when you see faults?
Muji: I run a very concentrated portfolio under 10, sometimes as low as six but typically eight to 10 that I have better ideas. So, companies will fall out of my top 10 and I'll just move on.
Bill: It's interesting. It's like I'm thinking of your portfolio like a baseball team. It's like you've got a bunch of five tool players and then the valuations that you pay make me a little queasy. I don't know everything that you do, but I do know that where you play and optically that makes me queasy but I think that your strategy makes sense in that pond because if I understand you correctly, you're probably out before there's like a real problem, and there's multiple compression, and you're trading for another young player, that's a five-tool player, and refilling the baseball team.
Muji: Yeah. I'm not always out before drastic events. There's always surprises from companies that report issues. I was in a company called Zscaler that end of 2019 was showing a lot of issues in their sales and the customer growth was drastically falling, which to me affects the land and expand. You can't have all the success and expand if you're not landing the customers in the first place. So, I exited at that time. So, the faults vary, whether it's newly spotted competition, the trend isn't as durable as I thought it was, or the company showing faults in management or execution tends to be the primary reasons not so much price driven.
Bill: No, that makes sense to me. You're looking at the fundamental outcomes of the company and you're not looking at stocks as your stock prices. It's not like technical crutch. [crosstalk]
Muji: Yeah. It's all about the fundamentals but it's about writing companies that are executing well and I expect to execute well in the future, and letting them do the work, and then constantly watching them to make sure they do the work. Let's be clear [laughs] watching them continuously. But recognizing companies that have some kind of special sauce for executing well in the past and I expect to execute on the future. But sometimes, I'm late to the game because I'm so stringent in my requirements that a lot of companies-- I could have entered earlier but they weren't showing, let's say, operational leverage that I like to see. We weren't seeing underlying margins constantly trending positive. I wait for them to write and show better execution and then we'll join in.
Bill: So, what does this look like in between quarters? I know you're doing stuff in between quarters but I'm just trying to figure out, like, are you doing scuttlebutt? I mean, you've got a big following on Twitter. I've got to imagine that you've got a bunch of tech friends. Are you pinging people asking them, what are you hearing on the ground, or how are you using this product, or is it mostly that you're assessing the competitive landscape, and then watching for the financials, and listening to what management says, or is it a combo? I'm just curious.
Muji: Yes. So, constantly watching what management is saying through earnings is important, much less keeping track of the fundamentals. But constantly I like to see what they're talking about in terms of product line and adjacencies that are possible. But really, it's not talking so much to tech friends. Most of my research is all me. And then I started the blog and now have a premium service on top of it and the Twitter, but it's all revolving around these companies. I tend to watch not only the earnings but other investment conferences can sometimes have interesting tidbits emerge from the CFO was talking to at some related industry conference. But it's the product announcements that is probably where I tend to live most. I like to watch the product cadence, how quickly they introduce new products, how they go through beta, and then into final release. I like to look at their customer conferences, which provide a surprising amount of insight for investors.
Companies are learning this and starting to attach investor days to their customer conferences, like, Datadog's, Dash conference that just occurred in October, they had an associated investor day to talk about, "Hey, first off, customer conference, we released a huge host of new products. Annual event where they dump several new products and there were 10 odd new ones on the horizon, either being released or in beta at the moment." But then they had an investor day that kind of weaved through it and talk about how this all combines into the greater story of where the company is going. I really like that stance by companies. It makes them so much more transparent. That's where I like to live, not just on the fundamentals and the numbers and I don't tend to go over those extensively in my service. I'm talking more about the product lines, and how we can read the tea leaves, and look through the lines in the product releases to see where companies are going next.
Bill: Yeah, that makes sense to me. I think I've noticed and I may be incorrect when I say this, but it seems as though your more recent posts have been more about zero trust and security generally. Is there a reason? If that is a correct statement, is there a reason that that has captured you recently or that's just a function?
Muji: Oh, that's not the reason at all [crosstalk].
Bill: Okay.
Muji: I first wrote on in October 2019. I wrote a series called Flavors of Security. You can see zero trust approaching from mile away. There had to be a better way. Once we no longer have a perimeter, which was a company would have a headquarters, create telco lines that interconnected all the branch locations, or retail locations, or whatever various spots their employees might be working in factories, warehouses, distribution centers, whatever, all interconnected through telco leased lines, you'd have to draw a perimeter around that company. So, you could have a moat and a firewall could control the entry and exit into the company network. But once you're on the company network, everything was trusted. Back in the late teens, but really for me, culminating in October of 2019 in general, you could really see it starting to be adopted. So, you can talk about it for years and years. IoT, we've been talking about for years and years, and has that really, truly exploded? Not yet. We can talk about that if we circle back to Edge Networks.
But it's recognizing that security is at the forefront of management and even Board of Directors minds at this point. You can see it in the number of breaches that we have monthly and even weekly into these systems that are stealing data, releasing it to the public, holding these companies for ransom has been a huge trend over the past few years. So, it was just recognizing the need pretty early there. But yes, I've continued to talk about it quite extensively over the past few years.
Bill: Yeah. I didn't know if there was a reason that-- it seems very prevalent versus maybe I see a lot of other people write about SaaS and things like that. It seems like you tend to be from I'm a sub for two weeks. So, if I say this incorrectly, I apologize, but I do really like reading what you write. It seems like you have more of a security focus than some of the other people that I've followed. So, I just didn't know if there was a particular reason for that.
Muji: I wouldn't say I have a security focus. I have been for decades in software. I have been a database developer, lead application architect for years and years and years, even as a hired gun consultant for most of that time. So, I've just been around app stacks as the cloud became adopted, as these new modern application architectures have started to emerge, as data services have started to emerge, and machine learning and AI have started to take hold big data. So, I've watched it all firsthand. I have an understanding over all of that. What it is developers look for, what kind of security tools companies need in their infrastructure, how infrastructure works, how application stacks are installed upon this infrastructure, and then how application architectures are built on those application stacks? I have got a knowledge over all of those directions. So, all of those kind of swirl around, security is but one focus. It's not a primary one.
Bill: Okay.
Muji: It's anywhere into data, infrastructure, application architectures, dev tooling, which is the underlying workflow of how you build and deploy your applications and/or the SaaS services that you embed within your applications, and now, data and analytics, and machine learning and AI is also starting to consume me. So, all of the above please.
Bill: Yeah. No, that makes sense to me. You sent me down a zero-trust rabbit hole. I liked it a lot. Do you want to explain to people what zero trust is and why it's so important relative to the old way of doing things?
Muji: Yeah. Sorry, I started on that route. So, as headquarters enterprise networks used to be very tightly controlled. It was all under the enterprise's control, I should say. You have your headquarters attached to your remote locations, attached to your branch locations, attached to your retail, or warehouse, or other facilities that you've got as a company. You would draw a network perimeter around all of it and keep that moat with a firewall. With the emergence of cloud services, you don't own that infrastructure. You can control it. Some of them are programmable via API but it's not within the boundary of your enterprise network. So, there really is no perimeter at this point. There is, people call it a software defined perimeter now with the emergence of software defined networking that we're talking about earlier.
So, you need better tooling as an enterprise to secure your assets now that they can be on-prem, it can be users that are on-premise and networks and systems that are in your data center, its remote users, which we just saw completely explode with the pandemic last year, so now users can be anywhere. But from your on-premise data centers, you're starting to move into cloud infrastructure, and then reliance on SaaS services such as Microsoft Teams or Zoom for intercommunication, Office 365 for email, you've got HR packages, you've got financial packages, travel imbursement packages, whatever else you need to run your enterprise. You can't draw a perimeter around cloud infrastructure must less those SaaS services you're using.
Zero trust is the emergence of networking and security in one. You combine them all together in order to have a service provide that for you. So, you're relying on the experts to handle your network traffic in a secure way across all these separate environments.
Bill: This may be stupid. So, again I apologize, but the way that I log in to your site, is that a zero trust? No? Okay, it's stupid. I can edit that.
[laughter]
Muji: There are no stupid questions.
Bill: There are plenty. [laughs]
Muji: No, no. See, I'm used to talking to generalists. I always love breaking this down and making it explainable is my forte. That's what I did as a lead developer. I constantly boiled down really complex architectures of distributed networks and distributed applications and servers in an understandable way for management's consumption and then for my clients' consumption. So, I'm used to boiling things down. Zero trust it started as a way to manage how your users talk to applications. The infancy of zero trust was that I have all these applications I run internally. They may be on-premise, they may be in the cloud, zero trust provided a common interface that users can all go through and instead of being a firewall into a network that the user can then move around in, which is what a VPN does. Log into your company's VPN in order to get into the trusted network of your company, and then you can access the HR package, the database, the development stack, etc. That's a trusted network. We're moving away from a trusted network to everything being untrusted.
Now, the user has to establish who they are through a variety of techniques, either coming from an identity management system and SSO like Okta, having hardware keys, there're lots of ways now to prove you are who you are. I'm this user I could even be tracked down to that. I'm on this device, a laptop or mobile device. I request a service from this gateway and I ask for access to the service. Let's say, I need to access the HR package. It establishes who I am and makes a femoral network connection to the HR package. It doesn't directly connect me to it. It serves as a proxy between those two things, so that it can completely control security in real time over that connection. Once that is severed, I have no longer had access to the underlying HR package or anything else within the enterprise. So, this is a one-off femoral network connection is handled by the zero trust systems for every user request into an application.
So, that's expanded further from there into what's called SASE networks, which are zero trust plus networking. Now, I've got all these interconnected spots. Let's say, I have a headquarters and I have 500 retail locations across the US that all have a point-of-sale system, and employee tracking systems, and inventory tracking systems, and whatever else exists within a specific retail location. I want to interconnect a network between those things. I can now use a zero-trust method where I can have a common networking backbone hosted in the cloud that handles that for me. All of those retail locations make a specific connection to the centralized service and a centralized control plane, and then can all intercommunicate from there. So, you've layered that kind of networking and then put zero trust over it, which is that I'm a user and I still have to establish who I am before I can talk to any service across that network.
Bill: I want to defend myself real quick because if I want to log into your website, I have to have you send me a code each and every time and then so that's what I was thinking.
Muji: Yes.
Bill: But I recognize--
Muji: Caution.
Bill: Yeah.
Muji: Yes. It's related. It's establishing who you are through one technique. Email is not a very secure-- [crosstalk]
Bill: Yeah. That's what I thought. I was like somebody could just-- [crosstalk]
Muji: So, you are not going to use that for logging into your financial system.
Bill: Right.
Muji: So, or let's say you're Twitter employees and you have to log into the control plane to delete someone's tweet or something, you've got to go through a sequence of events in order to get into those internal systems now, zero trust is helping solve that.
Bill: Yeah. All right. That's cool. Can we move just--? I'm sorry. What?
Muji: I was going to say this all is actually circling back to Edge Networks, which we left sitting there as I started to explore the app stacks.
Bill: Well, where do you want to go with this? Let's go somewhere.
Muji: That's what's appealing to me is that, what we were talking about at the beginning is circling back now into the rest of the story, which is that these companies have built, the CDN companies have built a distributed programmable network spanning the globe, and then have computers that are serving as those cache servers, smart caches in whatever select cities in order to reach as much of the internet populace as much as possible. So, that was great for application stacks and delivering content. It was crucial and really greatly reduced company's costs with hosting in the cloud. You're only hitting your server a 1,000th of the time, if you have a cache server over it. But not only that, Cloudflare in particular provided other things like application reliability, application performance, and that they started building their own private internet over that programmable network, so that they could start routing traffic around problematic areas of the internet if they see like ISP has gone down in Atlanta, they can route around it for instance.
So, they served as a layer over your application stack. What they and Fastly started to do and why both companies were really in the limelight in 2020 is that the market got a lot more clear about what Edge Networks are, which is they could start building compute capabilities like a core cloud provides centrally at those Edge servers. So, core cloud, I'm going to start infrastructure. When you start with a company like AWS, you have to pick the location, the centralized cloud location that you want to put your information all in. So, you'll pick one region in the US East or [crosstalk].
Bill: Like Texas or something.
Muji: Exactly.
Bill: Yeah.
Muji: Like East Coast, West Coast, somewhere in the middle in terms of the United States. You'll pick one location, put all your resources there. Maybe you'll spread out from there into other regions or availability zones just for high availability, if one goes down as we just mentioned. What Edge Networks are starting to allow is building compute capabilities for serverless functions that are distributed to all PoPs at once. So, now I can have my application, I can deploy it instead of into one location, US West, East, and AWS, I can say in Cloudflare, if I'm using workers, I can deploy it and it will deploy to all 250 locations at once. Meaning, I have an app that now is not in situated in one place. I have an app that is spanning the globe in one deployment. So, when you're dealing with consumer apps, that's greatly putting the back end of an application that might be on your mobile device within a single hopper to, so, incredibly low latency of most of the internet using globe.
It's becoming a new infrastructural play, where they've got the programmable network that interconnects all these spots spanning the globe, and then they're creating a developer ecosystem over this compute capability, so that customers can deploy applications to control the flow of traffic across that programmable network. So, it's all circling back to where we just landed in that zero trust and security is one of the use cases of a programmable network in that you can control, where traffic flows, so you can control the security of that traffic. So, I'm finding that Edge Networks provide an ideal architecture for zero trust, regardless of where the user is, me the enterprise user used to be in headquarters in Chicago, now it's dispersed around the globe logging into the enterprise network. How about using that distributed server architecture with a programmable network in order to handle the networking and security traffic as I traverse the enterprise network and use the SaaS services that the enterprise signs up for?
Bill: They're able to do all this with far fewer actual locations, then someone like Akamai, it was or is. I mean, Akamai can't do it. I understand that's probably the answer. But how are they able to do it in such an efficient manner? Is it because their software defined networks? Is that the core-
Muji: Bingo [crosstalk].
Bill: -Yeah, technology breakthrough?
Muji: Software-defined networks. That's the answer. Because they can basically create this globe spanning cloud, because it's all software driven under the hood, they control the networking, they control all of the infrastructure via software and they have leverage that architecture that they built for CDN for content delivery in order to help distribute the application across the globe.
Bill: That is some wild shit, man.
Muji: Now, it's not just that. It's a mesh. It's not just 250 separate application development points. They can talk to each other. You can route traffic between them. That's where the security features have also emerged in these platforms is that, I, a user, if I'm anywhere near Chicago and I need to enter the network, I log in through the PoP in Chicago. I establish secure connection with that PoP or if I'm in Hong Kong, I'm talking to the Hong Kong one, or if I'm in Indonesia, I'm talking to the Jakarta one. Once you've established your identity and your zero trust security credentials with that network, now it's Cloudflare in that case is in charge of the global network from there. They can handle all the security within their walls of their private network as it spans the globe, instead of you traversing the public internet. So, there's really now a division between private and public internet, and as well as that they're creating this globe spanning cloud capability.
Bill: Okay. So, if they're able to control, so, if Cloudflare is able to do that for you that seems to me like what they would market is they can control the level of security within, it's almost like a private internet that they've created or is that really dumb to say?
Muji: No, that's exactly correct. Cloudflare and then Zscaler is another company that's architected around this Edge Network capability where they've got these PoPs distributed around the globe. Those PoPs have become basically gateways into their network. It becomes the entry and exit point for their network. So, just to walkthrough a typical user request, I'm a user currently situated in North Carolina. I establish a connection to the nearest PoP, which might be Atlanta. From there, I'm entirely within Cloudflare or Zscaler's network until I get close to where the application is hosted. It will then exit the PoP and enter the cloud service of where that SaaS service is located, let's say Microsoft Office. I, then basically securely created an entire network connection between me and a SaaS service at that point and then back for the response. So, these networks are starting to interconnect with the clouds to even remove the exposure to the public Internet once you have to exit their network and talk to whatever the services or they have tunneling capabilities that I can create a secure tunnel between an on-premise data center and their Edge cloud.
Bill: They're not-- They couldn't possibly be laying there on fiber. So, they've got to have some wholesale agreement. Is that a potential security breach or no?
Muji: Oh, for sure. Yes. They have infrastructure they have to rely upon. They're not laying their own cable. They're renting fiber, they are utilizing data centers like Equinix to create these data center and locations around the globe for their Edge servers. So, those are the gateways. But they have to rely on other people's networking and infrastructure in order to build that out. But this goes back to the core of these companies being so security focused and having a software defined network is that they can guarantee that their stuff is entirely encrypted and not visible by the underlying infrastructure. Actually, touches on another infrastructural play I've been seeing lately is, as companies are starting to rely on the cloud more, they want to start encrypting their information more just to not have that exposure you're talking about.
Bill: Yeah. That makes sense.
Muji: AWS can see your stuff unless you encrypted at rest and in transit. So, you're starting to see security plays around that as well.
Bill: Okay. So, if I am using Fastly or Cloudflare to get my content close to my customers, I also have an agreement with AWS, AWS is going to share my core information with Fastly and Cloudflare or can I completely cut-- I wouldn’t cut AWS out right or [crosstalk]?
Muji: Well, that's a very interesting question about where this all goes going forward.
Bill: Yeah, that is where I'm trying to go.
Muji: For now, what you say is true that you're always going to have your core infrastructure somewhere. The CDN networks were a layer over that but not eliminating the underlying origin servers that they talk to. I'd say the same is true for Edge Networks but ultimately as Edge Networks become more utilized going forward, they should absolutely eliminate certain use cases of why you would host in core cloud. So, there's always going to be the need for centralization of data, you want to run machine learning with a high amount of memory and compute, and over a vast history of all your data over several years, let's say, that's always going to happen in core cloud. But anything dealing with network transmission is highly programmable now in these new clouds.
You're starting to see services emerge on Edge Networks, where again it gets back to that middleman nature of CDNs. The same architecture is in place for Edge Networks. It serves as a middleman. You can have now a programmable middleman. You can have these applications controlling how traffic flows across the globe in easy use cases, just controlling, I want it to go to this data center versus this data center. But you can start stitching responses together. They've mentioned like last mile ad insertion instead of having a request that goes all the way to the cloud, and things get assembled from various services there, it can be doing the assembling at the Edge now. So, it's just starting to open up a whole lot of new use cases that I think will take business from core cloud.
Bill: So, my gut like visceral reaction, when this conversation started was core cloud is still got most of the bargaining power over the long term. This recent part of my conversation has me thinking that I have a lower confidence interval now than I used to in that statement. Does a company and I'm not asking to do this Snowflake deep dive? I don't even know that my brain can handle it right now. But the Snowflake is able to be used across cloud providers, if it is also able to be used among Edge Network providers, does that sort of commoditize or level some of the playing field or am I not thinking about that correctly?
Muji: Well, that was the one of the use cases I just mentioned, where-
Bill: Okay. I just want to make sure because-- [crosstalk]
Muji: [crosstalk] all about centralization of data. So, to use AI and machine learning properly, you need more and more data to train it on. Now, some of that is going to move to Edge for sure, where you might have real time analytics running over the data. This is where a company like Confluent has a lot of power as a data messaging platform that lives across clouds. That's what's going to be interesting from here is seeing what the use cases are that split. But I don't see Snowflake moving into the cloud, sorry, into the Edge. It does live right now above the three major clouds in the US. You can seamlessly as a turnkey service, transfer data across those clouds, so that you can have users in Azure and users in AWS or users in two different AWS regions for instance, all operating on the same set of data. Same with MongoDB. They're all starting to become distributed data stores across clouds.
That's a unique differentiator than comparing them to the same related services like data warehousing or document stores in that the core clouds provide themselves as a service, where Edge is going to come into play as the transmission side, I feel like. So, you still have to get the data from somewhere and you still have to transfer it to that centralized location and then from any insights that you extract in that centralized location might need to be distributed outward from there. This is getting into how the nature of what is the internet is changing for me, which is that the internet thus far what crypto people are going to call Web 2 is that I'm producing content, I'm centralizing that content somewhere and distributing it outward. It's the pub/sub model, [crosstalk] publishing something, a YouTube video that gets placed in a centralized server somewhere and distributed out to millions of people.
What's changing now with the rise of IoT, with the rise of 5G really enabling much faster speeds at the last mile is that data collection is going to come from all the endpoints that exist out in the globe. All the IoT devices, all the OT devices, all of the user devices, the connected cars, the connected buildings, the connected cities are all creating a vast amount of data that's now flowing inward. That's the paradigm shift that I'm seeing emerge that I think Edge Networks are going to have an extreme amount of power for is that they are the programmable network in between all of these things. They're that kind of the interconnective glue and can help transmit data wherever it's created to wherever it needs to go regardless of if I'm that pub/sub model, and all data is going outward, or if I'm collecting data from remote locations, and it's all coming inward.
Bill: So, is this circling back to a comment that you said like IoT hasn't really taken off yet? But we can come back to that or have we come back to that comment and is this the technological advancement that may enable IoT to take off like people said it would?
Muji: Yes. Certainly, one of the big unlockings for IoT, I feel like is 5G that you've got better remote networks that IoT doesn't have to be wired. You'd have to connect all these sensors into a local network in order to make use from them, and there's just a lot of friction in adopting devices or sensors across your business. But it's so helpful because those devices give you observability into all the things within your business. Let's say, a factory or a smart tractor, so that you can monitor how things are happening on your agricultural business or whatever. So, it's 5G is the first unlock for sure and that's still just emerging. Edge Networks, I feel like are the next unlock which is, now that we have all this capability in the last mile, we can start leveraging it in better ways by having compute capabilities in Edge cloud, where we can be performing actions where the data is being collected, instead of in a centralized cloud location.
Bill: This makes sense to me. So, 5G enables these devices to communicate with the Edge Network and a low latency like very, very fast, very seamless communication, and then Edge Networks enables the company or whoever is trying to perform analytics on it or whatever they're trying to accomplish. That's the new technological advancement that allows the vision to come to fruition. Did I just say something that makes sense?
Muji: Yes. Those two things combined, so, this is all on the transmission side, yes. 5G is going to explode the amount of bandwidth capability and the number of concurrent connections that can occur from a single tower. So, the amount of data is going to explode and you can start making better use of that data in Edge compute absolutely. But there's another use case I see emerge from this combination, which is, you've got a lot of dumb devices. I could be reading temperature pressures, air humidity, if I'm monitoring something environmental. From dumb devices, you could be having smart compute at the Edge, a single network hop away. So, that low latency really starts to come into play. Again, it's not the most important feature, but you can basically start enabling things like AI and make dumb devices smarter through this combination, that I have the fast networking that gets this data into an Edge Network.
First off, the 5G gets to the tower, the tower has a hop to whatever the ISP is, from there it's a hop to the Edge Network. So, instead of going through multiple hops in order to get to a core cloud to make a decision, the decision can be being made very locationally adjacent to the dumb devices collecting that data and/or can be collecting data from many devices making a decision and then giving its results back to all the devices. So, I do see a pretty positive future trend where all these things are swirling.
Bill: That's super interesting, man. I want to keep going but I'm tired because this stretches my brain so much.
Muji: [laughs]
Bill: I put out a tweet the other day and it was a little while ago, but I said for the longest time I was so stupid that I would look at some valuations and I wouldn't even get curious about some of the stuff, right? The amount that that cost me in curiosity, potential career decisions that could have been different, I just hope that no one else does that because this stuff's so fascinating for me. Even if I can't predict where it goes like you do or whatever, it's just such a fun conversation to have. But it tires me out because it requires a lot of hard thinking the whole time for me, it probably comes second nature to you.
Muji: Well, so, I'm a combination of technologist software developer for decades and a hhhypergrowth investor. But there's one word in there that I would disagree with, which is predict. I'm not predicting anything. The key to my investment thesis is that I wait for companies to prove to me that they can execute and then I can see where they can go from there. That's where we start exploring these interesting technology combinations. But I'm already starting with the basis where these companies are excelling at what they do now and then I see where they can go going forward.
Bill: You may have said it before but in case you did not, the other thing that I know that you like to see is, you like to see that they're releasing other products that are demonstrating people using them, right?
Muji: Yes, absolutely. So, certainly, I have the financial metrics I look for and hhhypergrowth signs of operating leverage, a fantastic gross margin, the land and expand you can see in customer cohorts, and NRR. But absolutely this is why I like to watch the product cadence as I call it, the cycle of how they release products, how they're entering adjacent markets. I'd like to see a harmony between sales and product. That's proven to me in product cycles and NRR is that, I'd like to see companies that are ever expanding the menu of options of what it is they provide and then selling it to existing users. But that in turn is what proves to me that they can start entering these adjacent fields that I kind of spot that they're starting to move towards.
Bill: That makes sense.
Muji: They have enough success at what they do now. They continue to iterate on product releases, and sales can sell it, and then as I like to say is, it creates the hurricane of growth, which to me is all about scale. I can see signs that the company can continue to scale its sales, continue to scale its operations, its profitability, its product line, and then adjacent markets.
Bill: All right, so, the one thing I do want to touch on, since it is an investment program. Snowflake, let's not get into the deep dive of it. I think everybody if I haven't plugged your blog enough, I think people should sub and they can read what you've written on Snowflake because it's very extensive. But when you look at these-- [crosstalk]
Muji: That's the half of it. [laughs] I've talked about four more times.
Bill: Yeah. Well, I really encourage people especially if you're a generalist like me and you're interested in this stuff. I find Muji to be a very good resource. But when you look at something that has $100 billion valuation, how does that or I don't know what it is today? Is it 80 or whatever? At what point does valuation come into your process and do you ever look at something on a market cap basis and say, "Eww, that's a little too big of either a multiple or a gross valuation."
Muji: Yeah. I can't say I ignore it. It's just not a factor in my conviction, I guess, I should say. Now, Snowflake is a little bit of a special case in that I was mad at them because I saw them coming from a mile away and I really wish they would have gone public sooner. These companies today are now finding so many funding rounds that they can stay private longer and someone else is gaining the benefit of that not me as a public market investor. So, I had expectations at IPO that they would explode. So, when you have a company that everyone and their mother is all watching, obviously, the interest level is too high and I stayed away at IPO. It was just too much. So, I guess, I do have my limits. It just doesn't generally enter the equation so much as I evaluate new companies, especially, ones growing over 100% and I think that they can sustain that really has a way of making the valuation metric not matter over time and so a lot of compression can occur when a company is growing 100%.
So, somewhere in between there is where I live as an investor. It doesn't always enter the equation. It's obviously, a frothy market and got taken to the woodshed here a little bit over the past few months. But that occurs, especially, when it occurs so in tandem across all of tech and all of hhhypergrowth, it's just market moves. It's not indicative of any one company and I'm hyper focused on individual companies and their performance. So, if this company is $60 billion of market cap, the question I ask myself is, "Could it be $100 billion? Could it grow from here?" If I see those adjacent markets, then yes, especially, if they're growing 70%, 80%, 90% year over year, and are doing so in a sustained way, and showing signs of extreme profitability that once they land and expand starts to wane, they can have those levers to turn up the profitability strongly or even better, those levers have already been achieved just through simple scale of their business, it's ultimately a very successful business at the end of the day.
Bill: Do you think in some of these companies, is there a risk that as they mature their best people leave and go to the next startup or have they already hit such escape velocity that it doesn't really matter? That's something that I wonder about, are these companies able to run it steady state and keep their culture?
Muji: Well, that gets back to my house of cards [laughs] comment a little bit in that. As these companies are scaling up so much, let's say monday.com, just it was growing 94% and just put in 97%, it's accelerating. What does that do to company culture when you have to onboard 100% new employees in a year, let's say, and especially when things may have been on-premise and are now entirely remote, certainly culture might be affected. It's also becoming the era of where developers are a currency. I's developers are in control of their destiny and can pick the career path that they want or industry that they want to be in.
Every company is a software company at this point just to some degree. Either it's stitching together the existing SaaS tools that they've got with their existing legacy tools at a bare minimum or they're creating software on their own that they have applications in an app economy or API economy direction. So, I don't see these trends ending and developers are becoming harder and harder to get. So, I think there's going to be more use of the SaaS platforms, more use of the companies that have proven that they've become an expert in security in data, in analytics, and relying on their expertise more instead of hiring staff to do it for you. So, I'm still incredibly bullish on software in general because developers are hard to come by and yeah you do see that as these companies grow, this is why I'm constantly looking for signs of operational faults and issues with their product release cycle and customer growth is, I want to monitor this massive swelling of successful execution isn't causing any issues in my long-term thesis.
Bill: Yeah, that makes sense to me. That's what I would watch, too. So, that makes sense. Well, man, I thank you for joining the program and sharing your knowledge. I will remain a sub and just thanks in general for writing what you write. I'm going to pop into more of your Twitter Spaces, because I really enjoy listening to you talk. I like how you come from a tech focused, there's so much discussion that I think-- I think there's a lot of flat discussion out there and I find what you write to be very high signal. So, to the extent I'm a good judge on that, thank you.
Muji: I'll take the compliment. I appreciate that. Thank you. Yeah, Twitter has been fun. I've been around bulletin boards and investor forums for decades now and it's always been high noise to signal through a lot of it. Everybody clearly pitches their own book and hypes up whatever they own. So, you've always had to separate that. Yeah, I feel like I've got a little bit of a unique perspective here between the technology and the investment focus. So, I'm glad I can help folks. Yeah, I created that. I've been writing for years but created that blog when things went haywire in the pandemic, and then decided to leave development behind earlier this year and start a premium service. So, thank you to all the folks who pay me to opine about these things and it's been super fun.
Bill: All right, cool. Well, I look forward to future conversations and thanks again.
Muji: Great. Thanks for having me on.
[music]