Back

• Business Models
• Investment Approach

Deep dive: DevOps | EP109

May 25, 2022 Print

---

---

Your Host

Rob CampbellCFA

Institutional Portfolio Manager

Rob joined Mawer in 2016 and brought with him a near-obsessive passion for nicely formatted spreadsheets. He is fervent about the importance of taking the long-term view in investing; living a life of “non sibi,” Latin for “not oneself”; and putting clients’ interests first.

When not at the office, Rob is binge listening to all kinds of podcasts—investing and otherwise—and sharing in the interests of his three young children, which include trucks, trains, and reading the same stories over and over. Good thing he is curious.

Transcript

Download pdf copy

Disclaimer:	00:22	This podcast is for informational purposes only. Information relating to investment approaches or individual investments should not be construed as advice or endorsement. Any views expressed in this podcast are based upon the information available at the time and are subject to change.
Rob Campbell:	00:39	Justin Anderson is here. Justin, welcome.
Justin Anderson:	00:41	Hey Rob! Fantastic to be back with you.
Rob Campbell:	00:44	Yes! And hey, I got to say I'm really excited for this one. I mean, I'm always excited when you come on the podcast, but we tend to geek out and get into the weeds on some fascinating topics that are often at the forefront of changes happening in the tech space and this podcast is no different. You're here to share some of your recent learnings that you had on a DevOps-focused reverse roadshow. So, to set the stage and get started, (and we'll get into this in a lot more detail), but for those of us who are perhaps less well-versed in the vernacular of IT departments, what is DevOps and what drove your recent interest in that subject?
Justin Anderson:	01:21	Okay, so you're starting off with a pretty big question there [laughs] and we'll see where we can take it. I'll answer your second question first: Why did we get into this? First of all, I mean, it's core to who we are at Mawer—we're really curious, and this is a theme that's out there in the world. And when there's a theme that people are chatting about, we get curious and try to find out more about it. We've done that with Bitcoin in the past, we've done it with payments, with video games. We've got lots of these kind of thematic stories that we really dug into when we want to learn more. So, it's playing to our curious nature. Then the other reason, if you remember, today's podcast could in some ways be a continuation from our last podcast that we had together when we talked about the compounders, the holy compounders. Part of that process of looking for the holy compounders is looking for companies that have sustainable growth. That's the first step in the process.
	02:08	Sustainable growth are companies that typically are in structural[ly] changing industries; things that are happening that are thematic and important in the world. So, for us to find companies that have that sustainable growth, we look for these themes, these changing industry themes. Examples of those would be the cloud migration changes, the e-commerce changes, cryptocurrency…
	02:30	And some of these themes are overblown and they turn out to be much smaller things in the long term than maybe people talked about, and then others are very big. So, if you can find the ones that are going to go very far, then that can become a key component of finding that sustainable growth company.
	02:46	It doesn't mean you're going to invest in the company. It has to check the box on having good returns relative to the cost of capital. It needs to have a strong moat, so it can sustain the returns and penetrate deeply into its addressable markets. So anyway, coming back to why we're looking at this—we feel that DevOps is one of those important structural changes that are happening in the world today. So we got curious, we wanted to find out more. That's why we're digging into it.
	03:10	Now to your second question of, what is DevOps? That's complicated [laughs] and it's very technical. So, hopefully by the end of this discussion we'll have a bit of a sense of it. At the highest level, it's a way of running an IT department. It's a process of how you structure your people and how you set up your factory to run your IT. So, that's a very high-level description, but we'll get a lot more into it, I'm sure, as we go forward here.
Rob Campbell:	03:35	Yeah. Well, maybe let's step back then. So, let's step away from DevOps for a second and just—IT departments more generally—paint us that picture. How has that kind of evolved? What are some of the problems and where does DevOps then come in?
Justin Anderson:	03:47	Yeah, let's start with just, what is IT? So, “information technology” is what it stands for, and it's typically a department in a company. You might have a marketing department and you might have a research department and then you might have—most companies—will have an information technology department. What are they doing? So, the example I like to use with [the question] "what is IT?" is Google Maps. Everyone knows what Google Maps is. What is it? It's an application. It's something that helps you find things. Now, there was an old way before we had IT departments and applications, people printed maps, and you would go out and you might have a trip to Mexico, and you arrive, and you buy some maps, and you start touring the country with your maps. And you get lost pretty quickly because the map's five years out of date, and oh, it turned out you bought the wrong map. You needed the map of this area, not that area.
	04:36	And, oh my goodness, the roads have all been changed, because some construction happened.
	04:39	So, there's a lot of inefficiencies with that old model of using maps, of physical maps. And so, in comes an idea to say, "Hey, what if we just had the map in your hand and you could zoom in, zoom out, and it kept everything up to date in terms of where the roads are and it even had traffic overlays, and you could see all sorts of different features that are helping you to get to where you want to go?" That's an application. It's a clean purpose of an application to take an old way of doing things and to make it much more efficient for humans. And IT is all about supporting, building, deploying those applications. That's what it's about. Now, the application just like Google Maps helps us get to where we want to go, in the enterprise (a typical company) will have dozens of applications that are helping us so that we don't have to use the old maps so that we can do much more efficient kind of workflows to get the job done, to get what we want to get done. So IT is really about supporting that.
Rob Campbell:	05:32	Okay, and you mentioned a couple of the constituents—so users, the application itself, but there are other things involved in that IT stack, right?
Justin Anderson:	05:40	Right. So, if we break down the IT stack (so, what's behind the curtain) let's say, on Google Maps, what's back there for the user? It looks great. Just this nice little application you can use, but there's a lot that goes into building and maintaining that. First part of the factory floor is the developers. These are the folks who are writing the code. Maybe they're assessing other applications, maybe they're testing applications, and eventually they're handing off their application to the next subgroup within IT, which would be the operations team. So that's ops. And ops, once they take the code and the program from development, it's their job to deploy it.
	06:17	What that means is, essentially to install it in different types of environments around the enterprise. So, “put that on your operating system, put that on the hardware.” In the case of our Google Maps example, the operating system might be Android versus iOS. The hardware would be one of hundreds of different types of phones that are out there. So there's a lot of permutations that go into that and different phones might react differently to the application in different environments. So, managing all that complexity of how it gets deployed and how it gets maintained and supported, that's all around the operations team.
	06:49	Then finally there's the security team, which is really making sure that, hey, you're not getting hacked. The application is being used by the proper people, the people who have authority to use that application. You also typically, at least historically, have had an infrastructure group, which would be much more involved in buying the hardware, the servers, all that physical hardware on which the applications would be installed and be running.
	07:11	So that's, in a nutshell, let's call it the four pillars of the IT department. Development, operations, security, and infrastructure. All four of them are kind of working together in order to build support, secure these applications that help us do our jobs better.
Rob Campbell:	07:28	Great. Then, so within a company's IT department, I mean just the way that you describe that, those seem like different skill sets. So it might take a certain person with a certain background to be a developer, which might be different than the kind of folks that you'd have within your security department. Is that the right way of thinking to those different buckets?
Justin Anderson:	07:46	That's right. So, developers are your sort of typical coders. They're the ones that are using a programming language to write logic and to solve problems, build algorithms, that sort of thing. They're very much in the weeds of the coding. Whereas your operations folks are going to be more of a wider range of folks; people who are used to working with servers and maybe there's more data scientists monitoring things. They're going to be more of that database-type expertise, making sure that systems are talking to each other smoothly. Monitoring, making sure that applications aren't coming down. We call that in general, “observability processes.” Then security are also going to be looking at dashboards, running penetration tests. So, that's where you try to see if you can hack the system in a friendly way to double-check that the right security systems are working. So it's going to be a wide range of skill sets across those teams.
Rob Campbell:	08:35	Okay. And when you look at IT departments and whether that's for IT companies or pretty much any company, I guess, the way you've described that, I mean, it sounds quite siloed—just the need for specialization in these different groups. What is the communication like across these platforms? I suppose that's a way of asking where does “DevOps” come in?
Justin Anderson:	08:53	One of the questions behind your question is, why is it set up this way, right? Why do we have these kind of four different groups and they're sort of moving these applications through it? And a lot of that—there's good reasons for that. So, one of them is historically, companies tended to buy and manage their own infrastructure. So what that means is they would buy their own servers. They would install the server operating systems onto those servers. They would maintain those servers. That required a lot of complexity to do. A lot of effort. Also, the applications themselves were monolithic for the most part. What that means... if we come back, I want to explain what monolithic is versus microservices. So, monolithic is a way of developing an application and the new architecture is going more towards this microservices concept.
	09:39	If you think back to our Google Maps example, what's the difference between monolithic and microservices? So, in a microservices architecture, these are the newer architectures, you might have an authentication service. That would be a subset team that is focused on say, user authentication, for when you're trying to get into your Google Maps. Maybe there's a separate map service and this would be all about making sure those maps are kept up to date. Maybe there's a separate GPS service that is focused on communicating with the satellites and making sure that you're getting the right positioning. Maybe there's a timeline service. So these separate services in the new models are designed to be very separate from each other and talking through standardized interfaces called programming interfaces. The reason for that is you can break down the application to much smaller, easier to manage chunks. Whereas in the past, all of those services that we would call separate services today would all be intermingled together.
	10:32	So the code would have the authentication, and the map, and the GPS, and it all be kind of in the same code and the same database in the same backend. What that led to is much more complicated applications that required a lot more people and complexity to manage. So historically, because of the monolithic architectures that tended to be the primary way that applications were developed, that was one of the contributing factors to the organization the way it is. I already mentioned the infrastructure being more on-premise as opposed to cloud infrastructure. So that's another reason why—because you need people to manage that. You need hundreds and hundreds of people to manage a number of complex enterprise applications.
	11:10	That's partly why you saw this specialization. I guess the final point I would say on this is, and we'll get more into this, but just 20 years ago, 30 years ago when the IT department, let's say, was born or was evolving in how it was structured, it was a lot less memory efficient world.
	11:24	In 1970, if we go back 50 years, you could fit about a thousand transistors onto a microchip. Today that number is closer to 50 billion. It's approaching 50 billion. So [laughs] for anyone that's counting, that's a 50 million times increase in the number of transistors. That's well-known as Moore's Law in terms of how quickly that memory efficiency has gone up. But in the past when memory was a bigger constraint, when we didn't have that, when Moore's Law was earlier in its infancy, IT departments had to optimize around that constraint, around the limited memory capability that they had. So that required more specialization, departmental-type specialization, to really focus on that constraint. So those are a couple really high level reasons. The on premise, the monolithic application design, the memory-efficient approach to optimizing the IT department of why the IT department was kind of structured in that way.
Rob Campbell:	12:13	Yeah, if I'm understanding that right, it's almost as if the need for a maximum efficiency has been relaxed just given the development of Moore's Law, which actually allows the whole system to get more efficient [laughs] in a weird way. Is that the right way of thinking about that?
Justin Anderson:	12:26	Yeah, I think it's a really important point because what's happened is those constraints that we talked about in the past, especially around memory efficiency, has been relaxed. Monolithic architectures have evolved into microservices architectures which allows for smaller services to be maintained and on-premise has shifted to cloud. And so the infrastructure management has been simplified. You can now outsource a little bit like using Uber instead of buying and maintaining all the complexity of your own car. It's become a lot simpler to just pull out your credit card and use that. So those three factors together, all three of them are shifting. There's cloud, there's microservices architectures.
	13:03	And with Moore's Law, we're seeing memory efficiency is less of a constraint for the IT department and that leads to optimizing around different constraints. So, the new constraint I would argue—and this is where you're getting a bit into our opinion—is around process efficiency. It's saying, "Hey, you don't need to be as memory efficient as you were in the past."
	13:22	Because of that, efficiency's still important, now we're really focused on how do we get that application out faster? How do we make it more reliable? How do we release more improvements more quickly? Those kinds of key user factors become more in focus than saying, "Hey, we got to really optimize the memory here because the servers cost so much money." So that's causing these shifts. Now, these shifts don't happen overnight because people are creatures of habit. And we're used to doing things under this old regime of on-premise, of monolithic, of memory-focused efficiency. So to shift takes time.
	13:56	That's partly why we're so interested in this DevOps theme because we think it's a shift that has the weight of physics, let's say, behind it. It's going to continue to build momentum, but because of humans and their habitual nature, it's not going to happen overnight. It's going to be this sort of long-term trend.
Rob Campbell:	14:11	I want to go back to some of those challenges in a minute, but we've talked a lot about where things were and where they're moving, but can you describe for us just…in an IT department that has moved to this DevOps state, it sounds like the key benefit to the IT department's clients is just that increased focus on the user. The ability to deploy updates faster, have a greater focus on them… What does that department look like? We've talked about silos, I presume those are broken down. What are some other features of that type of organizational structure?
Justin Anderson:	14:40	Yeah Rob, I think we're in a better place to answer your original question of, "What is DevOps?" And that's kind of answering this question that you ask now. When we first asked, it's sort of like, "Look, we don't have the scaffolding yet to kind of go there." But now I think we have a bit of it. So okay, you kind of understand the shifts that are happening and what does that lead to? What is this new arrangement of the IT department that things are potentially moving towards? What is DevOps? So, I have one line for it: it's end-to-end product-oriented IT. So in the past, as we've discussed, you had your development group, your ops group, they each have their own head. They each have their own budget. They're managed independently. These teams do these handoffs. So there's a lot of friction between the teams.
	15:18	Whereas DevOps says, "No, no don't have separate development ops, security teams—put it all together and orient your teams not around these functional groups, but around the products themselves, the applications, the Google Maps."
	15:33	For example, you would have a Google Maps team that would have developers, it would have ops people, it would have potentially infrastructure and security people on it. And that entire team would work together under a single leadership to build, manage, support, deliver the Google Maps experience. I think it's extremely likely that Google is using that already and I think a lot of the leading tech companies have already adopted these more advanced architectures. But yeah, in a nutshell, that's what it is. It's combining everything together end to end. One of the reasons it's now possible—like if you tried to do this 20 years ago, you'd have 4,000 people on the team. It's like, good luck with that [laughs].
	16:06	But because of the microservices—for example, let's take a highly complicated application that still exists today—well, Google Maps might still have thousands of people on it, but if you break it down into those microservices that we talked about, they might start to have more manageable teams on each of the microservices. So you might have a team of 20 people that are focused on the GPS component and that's all they do. That's 100% of their focus. The great thing about this architecture is you can always break it down if you're doing your microservices architecture efficiently.
Rob Campbell:	16:34	Within the IT department, what kind of obstacles has this caused? In other words, from moving from a more siloed structure to one that's more integrated, are certain legacy folks more or less useful in that environment? Do you require a new type of IT personnel, developers, ops folks? Who's best suited to move into that new structure?
Justin Anderson:	16:54	Yeah, I was on a call with a ops engineer out of—it was actually out of Japan—and when I was talking to him about these transitions from on-premise to cloud and other types of changes, he said, "Look, you got to wait until this generation retires before you're going to see a lot of change." I think that's the age-old human story. I mean, it's certainly not specific to IT. When there's change, we resist it and we say, "Nope, I like doing things the way I do them. I'm going to stick to my routine." So I think there's this natural hesitancy. I remember hearing for many years, I don't think you hear it as much now, but when we talked about moving from on-premise infrastructure to cloud, the pushback often was security.
	17:30	It's like, okay, if we're going to deploy to the cloud, then it's going to be less secure. And I actually think that the story around that has almost flipped where people increasingly are seeing the cloud as more secure than hosting and maintaining your own infrastructure. There are individual cases; you can never have a blanket rule for all situations—like a bank or something like that. There may be a certain case where you may not want to go down that path. But yeah, I think in general, it's like we said: when things were being optimized around other constraints, that created a generation of people who were focused on that kind of architecture for the IT department and there's just natural hesitation to shift away from that. So, yeah, that's a challenge for DevOps.
	18:10	The other challenge I would say, this is critical, is that a lot of the vendors—so the people supporting development team that we talked about and the operations team—these people, the vendors that are supporting these, they're selling solutions to help those departments. They tend to focus on selling either to development or selling to ops, because they're solving very different problems. Development might be looking for automated testing for their code, or they might be looking for different things that are helping them make sure they don't make errors when they write their code. Whereas ops might be focused on observability monitoring and availability monitoring-type tools like Splunk and those types of tools that helps the ops team monitor the applications and make sure they're up and running well.
	18:53	So, because they tend to align very much along the existing structure, it makes it very hard to collapse them together and to unify dev and ops because there isn't really a lot of vendors out there that are kind of selling to both. So that's another challenge that faces it. Because it's kind of a chicken-and-the-egg problem. You can't really go into DevOps until you have a vendor that can sell you a DevOps type solution.
Rob Campbell:	19:14	So you might be a relatively new company, you don't have this legacy structure, you want to start off with a DevOps focus, but you might not be able to do that just given the people that you need to work with aren't necessarily set up that way too.
Justin Anderson:	19:25	Yeah, and I like what you said there—a relatively new company. It kind of triggered a thought, which is, a lot of times a good place to look for change is on how do the startup companies architect their IT departments?
	19:37	That's a good place to look because startup companies typically have very little money, and they're very sensitive to cost, and they're going to be working to make a IT structure that is very efficient and delivering a lot of value. Whereas large companies tend to face a lot of other challenges, such as complexity, and habits, and the way things are set up, and making those shifts can be a lot more costly. So look to the startups often in the IT world to see where the industry's going. The startups are uniformly going cloud, they're going microservices, they're going DevOps.
Rob Campbell:	20:06	I have no idea whether this has anything to do with DevOps, but I'm reminded through this discussion of your comments just about the way Adyen, the payments processor, developed their platform. They were new, they didn't have to deal with the legacy issues affecting other incumbents. So they were able to set up this platform that didn't have any of the baggage that some of their peers might have had.
Justin Anderson:	20:24	Yeah, exactly the way they—the actual word Adyen (don't quote me on this as I'm publicly stating it on a podcast [laughs]), I think it's Swahili for "do over" or something along those lines, because that team had actually built a product and sold it to a bank in Europe, I think in the UK—a [Scottish] bank or something—and they subsequently said, "Hey, we're going to take everything we learned and we're going to build this thing from scratch using a much more kind of end-to-end seamless tool platform." And that's what they did. And they've had a lot of success by going down this path of end-to-end connectivity.
Rob Campbell:	20:57	It's funny, actually, I listened to that Business Breakdowns podcast this morning on Adyen and they did have that background on the Swahili origins. I want to move on to just investment implications. I mean, this has been fascinating so far, but I want to draw some conclusions to more of our day-to-day work beyond just the curiosity in it. Is there anything that you think that we need just from a background information that we haven't gotten to before we move on to some of your investment learnings looking at this?
Justin Anderson:	21:22	No, I think we've set the stage for talking about takeaways and I'm glad you bring up takeaways. It's funny, you can't have... One of our tensions with our curiosity at Mawer is every time we express our curiosity at the end of the meeting, you start getting the takeaway police start[ing] to step in and they say, "Hey, what does this mean for investing?"
Rob Campbell:	21:38	“So what?”
Justin Anderson:	21:38	So some of us are really curious. Yeah, what's the “so what?” So I appreciate you bringing that cultural norm into play here.
Rob Campbell:	21:46	Well, let's go back to one of my initial questions, which was the interest in the reversed roadshow. So I take it that you and some others—which I think is really interesting—you pulled in some non-investment folks into some of these meetings. Can you talk a little bit about that and just the types of companies that you were speaking to and the types of individuals that you were speaking to?
Justin Anderson:	22:03	Yeah. I mean, take a step back for our process—we have the Research Lab, which is something I'm a part of. The Lab is focused on building products using these DevOps techniques for our Research department, but we also leverage the Lab team to talk to potential investment companies that we potentially are going to invest into to understand where they are, how sophisticated their technology practices are, those sorts of questions. A particular individual in our team who leads our development group, a gentleman by the name of Wilson Chen, put his hand up and said, "Yeah, I'd be happy to help out with this." He's helped us out many times in the past looking at companies and doing some assessments. So I reached out to him. He was happy to join the calls on the reverse roadshow, which is where we go and we talk to a number of companies in this industry. So we did that. We spoke with over a dozen companies kind of in or around the DevOps space. Wilson joined our calls and we grilled them on where they were on the DevOps journey.
Rob Campbell:	22:56	Cool. Were you speaking to folks in IT departments? Were these IT-focused companies? Or were you speaking to management teams more broadly? What was that focus?
Justin Anderson:	23:04	Good question. So, remember we talked about the vendors who are selling to development, selling to ops, and one of the challenges of making DevOps happen, I call it “crossing the chasm,” which is, how do you find a vendor who can both sell to development and to ops? There's not very many of those, and that's one of the constraints to DevOps rolling out more quickly. So the focus of this reverse roadshow was talking to management teams that were running companies that are selling technology to dev and selling technology to ops.
Rob Campbell:	23:32	Got it, okay. In talking to those companies, I presume you're speaking to CTOs, CEOs, CFOs, those types of individuals. How do you assess where they are on the transition and how prepared they are, as you said to cross the chasm?
Justin Anderson:	23:47	It's very company specific and there's a couple techniques that you can use. I think for these ones, because we're talking to the vendors, these are very technically savvy individuals. I think the primary thing we’re focused on are which companies are really positioned to cross the chasm, which they kind of have a foot in both worlds. One company that came to mind that we own some of is Elastic, which is a business that historically has focused on the development side of the house. They built libraries that help developers put search capabilities into their applications. That's historically been their focus, their bread and butter. They've taken that technology and they've kind of rolled it into much more ops-focused applications, such as monitoring, observability, availability-type applications. Where the ops people are now starting to buy more and they're monetizing a lot of that fantastic technology in the ops side.
	24:36	So for us, the revenue is coming from the ops for Elastic (most of it—maybe two thirds of it), but there's still a major presence, and certainly the historical roots of the company are on the dev side of the house. So we quite like that company because it's well positioned. They see the vision of DevOps. They're already penetrated into both of the departments. They're one of the few companies that are in a position to enable the transition. Another company that comes to mind that we don't own historically for valuation reasons—and this is a lot of companies in this space that are great companies but the valuations were crazy—was GitLab. GitLab historically was very development focused, very focused on helping the developers, but they also see the DevOps vision and they're trying to shift more into the ops side.
	25:16	I think the challenge that GitLab has is they really are development focused and they don't quite have that same cross-the-chasm strength. But what we like about that company is they do have the vision behind the DevOps future. I am noticing that the stock is getting a lot cheaper lately, so we're starting to poke around to see if that one could be of interest.
Rob Campbell:	25:35	What about some other things that we own, like Microsoft, for example, how are they positioned?
Justin Anderson:	25:38	The two that I talked about [are] kind of smaller companies, sub 10 billion market caps. But yeah, on the high end, two of the best-positioned companies would be Microsoft and Amazon. Microsoft, because first of all, they see this vision, that DevOps vision, they're very developer focused. If you go to their conferences and understand their technology, for the last half a decade or more, they've really made this pivot to going from this out-of-the-box Windows/Office producer. I mean, those are still major products for them, applications, but they've shifted to really the ethos of the company is, how do we make developer's job easier, faster, smoother, all that? So that's made the company's moat a lot stronger. They give away a lot of products to developers, but it means that developers get onto their tools and they leverage platforms like Azure—their public cloud—to deploy their applications and that sort of thing.
	26:28	Amazon similarly can benefit because of their dominance within public cloud. DevOps links up very nicely with public cloud. They synergize together because public cloud takes away a lot of the complexity and is becoming increasingly sophisticated to support the DevOps transition. So I think DevOps, those two companies, should really benefit from this transition long term.
Rob Campbell:	26:48	Going back to the compounder discussion and just this idea of sustainable growth—your comments on Amazon, I mean, that's been a massive tailwind for their business; just their position in the cloud. This may be an impossible question, but when you think of DevOps as a theme versus the transition to the cloud, I know they're interlinked, but how do you size them with respect to an opportunity? Is this on a par or are they different?
Justin Anderson:	27:12	I think they're highly integrated. They're different components of a similar theme. What's the theme? The theme is globally, we spend $4.5 trillion roughly on IT. So, what is that $4.5 trillion? That's being spent on consultants, it's being spent on internal IT people, people salaries, that sort of thing. It's a huge amount of money. It's kind of off-the-charts in terms of industry size. And the main idea for why these are tailwind businesses with, let's call it “sustainable growth potential,” is because as companies adopt DevOps and public cloud, they can deliver that same IT experience or even better IT experience with fewer people. That's the reality. It's more productivity.
	27:54	Or they might be able to have a higher weight of developers relative to say, other IT professionals. Doesn't mean you don't need other IT professionals, it just means the productivity that the IT department—what is productivity?
	28:05	It's a function of how much output you have relative to how much input you put in. That productivity is improving a lot with the adoption of public cloud, of DevOps architectures. And the thesis is that you can chip away and you can capture some percentage of the billion dollar question, or I guess the trillion dollar question [laughs] is how much of that $4.5 trillion you can capture. But almost certainly as you add more value to the IT department, leveraging these technologies, you're going to capture a slice of that. So the TAMs, if you will, that might have been historically defined by much smaller market sizes—say the server market size, how many servers are out there—and you just think of public cloud as replacing the servers. It's like, no, it's not just replacing the servers. It's making the entire IT department much more productive.
	28:50	It still leads to another question which is, okay, how much of the value that they create can they actually capture? And that depends on moat features and that sort of thing. But certainly the thesis that they're going to create a lot more value and capture more of that global IT spend, I think, is highly probable.
Rob Campbell:	29:05	Can I ask about another sort of category of folks who, short term, this seems to be a benefit from? At least in my basic understanding [laughs] and that's IT consultants, but maybe long term, this theme doesn't play it as well for them if indeed IT departments are getting more efficient, more productive. How do you think about that? I mean, we own a few within our portfolios, Accenture being one of them. How do they either benefit or see risks given this theme?
Justin Anderson:	29:28	It's one of these things where I agree with you on the short term, they certainly can benefit from the transitions and helping companies make those transitions. Longer term, I think it's kind of unknown because maybe in five years or 10 years, the constraint dynamic shifts again and now you need to bring in more consultants to go with the new transition. Now it's very dependent on the specific consulting company. I think some of them are a lot more sophisticated than others in delivering more value and selling to the right clients. So yeah, I would say that's a very company-specific situation. But yeah, I think I tend to agree with your overall statement there that [in] the short term probably positive for them, long term, big unknown. Because yeah, it may be that some of that $4.5 trillion that was going to consultants, maybe it goes to the vendors instead as they're making the department more efficient.
Rob Campbell:	30:12	Okay, fair enough. At least in my lifetime, IT projects are the gift that keeps on giving [laughter]. There's always something to consult on.
Justin Anderson:	30:20	Absolutely.
Rob Campbell:	30:21	Another sort of related business model that we tend to own across a lot of our portfolios—I don't know if it's relevant here— [are] the VARs, the value added resellers. Where do they come in?
Justin Anderson:	30:30	VARs are handling a lot of the complexity that happens when you have non-technical people interfacing with technology. So you need companies to support that interface. I don't see this transition as particularly impactful to that interface. It probably will have some impact on the margins, particularly around deployment of applications. But I believe overall, this trend is more about internal IT and about the transition between some components of IT, say more leadership from development, more money available potentially to capture for the vendors that are enabling the architectural changes happening within IT, as opposed to the interface between IT and non-IT.
Rob Campbell:	31:10	Okay. And then you mentioned it before, but price. So from an investment perspective, you said that a lot of these companies just given the theme that presumably is reasonably well known, you get that reflected in the price. Some of these have sold off so far this year or the last four or five months. Are you seeing these being more attractive? And given our investment philosophy, what do we need to see before we'll make more investments in this space?
Justin Anderson:	31:33	We've spent quite a bit of time on these companies and what we did over the last couple years is built out some inventory (we call it inventory the stocks that we've researched, but we haven't bought yet). There's a number of stocks that we looked at and have different levels of comfort with: the Snowflakes of the world; Atlassian comes to mind; Splunk; Elastic we own a little bit of; Mongo DB is another one that's kind of nearby. So we looked at a lot of these companies, a lot of them we were ready to execute on, but the valuation over the last couple years has been the struggle.
	32:05	I think what's happened over the last, let's say six months, has really piqued our interest.
	32:11	So, partly why we wanted to do the deep dive was just like, "Hey, these things are getting a lot more attractively priced and we need to get more comfort around the business model." I think that's what we're doing. We're getting well positioned. We're not necessarily ready to execute tomorrow on a lot of this stuff, but we're definitely a lot more interested today than we were six months ago based on how the valuation has shifted and our comfort level with the business model.
Rob Campbell:	32:31	Justin, in the past, when you've come onto the podcast, I've usually given you a new job. I think I've made you the Chair of The Fed, I made you head of the Accounting Standards Board. I'm going to give you a new title today. I'm going to make you an IT consultant to us at Mawer. How are we doing internally with this? What does our IT team look like? I know you mentioned Wilson, but how important is this to our business?
Justin Anderson:	32:52	First of all, it's critical in my opinion to the business and I think we're doing pretty good overall. We're not that big of an organization with that much complexity. We certainly have our fair share, but our complexity level is, I think, manageable. And as your complexity level comes down, the ability to make these kinds of transitions goes up, because the cost of shifting isn't as bad. I think we are doing it in pockets for sure. I think for example, our Lab team, we run exclusively our infrastructure on the cloud. We architect some of our major products using [a] microservices-type approach, very focused on process efficiency. Alex Lam, who's one of the leaders on our Lab team comes to mind as somebody who's extremely devoted to that process efficiency approach. But we've got others on the team, Chintan Sharma who exhibits a huge degree of excellence, Aaron Guo as well. So I think the quality of the team is there within the Lab, they're really following this process.
	33:44	Then outside, I think we're also making good improvements. They're dealing with a lot more complexity, so it's not as easy to be nimble when you're running some of the core applications that they are. We certainly are shifting more towards cloud and seeing more of this kind of product orientation in our team makeup. So I think, yeah, the direction is definitely there.
Rob Campbell:	34:01	Yeah, and for what it's worth, I'll give you this feedback live here on the podcast, I mean, as a user of many of the Lab tools, I certainly feel the focus on the user that's maybe facilitated by that approach.
Justin Anderson:	34:11	Oh great. Well I'll relate that feedback back to the team.
Rob Campbell:	34:14	Yeah [laughs]. Last question from me, unless you got more you want to talk about is just, where are the risks in this? I think you mentioned one of them, which is just structurally it takes time for people to change. This is a big transition. What are some other risks that may keep you on the sidelines with respect to some of these businesses?
Justin Anderson:	34:31	I think it's kind of around the key issues of change. There's a lot of talk of DevOps and you'll notice a lot of companies advertise that they do DevOps, but they don't really do DevOps [laughs]. It's sort of a buzzy word. It's a little bit like, "Oh we do artificial intelligence." And you find out they're just running some standard machine learning in the background and that lets them claim to have this artificial intelligence capability. It's a classic problem like that where people get interested in this topic, companies start to try to put on a good face. So I think the risk is one, is that you get sucked into an investment that they're not as advertised. They've kind of made the case that they're a really [a] cloud-native dynamic sort of DevOps oriented shop, and it's not the case at all. So, assessing that technically I think is one of the reasons I think our Lab group has got a real nice advantage because we can leverage our internal capability to make those assessments.
	35:25	I think another one is just the trend playing out more slowly, kind of to the point about the vendors selling to different groups. I mean, inertia is a powerful force in the universe. It's very hard to change things, especially when there's multiple levels of siloing happening that kind of rigidify everything. So that's a factor. I think the complexity level of organizations, as you get more complex, the rate of change is going to be less. So the way you get around that is disruption. Companies come from below, they get architected more efficiently and they disrupt the companies above. That's probably the mechanism there. But yeah, that could slow for whatever reason. If people got risk-averse all of a sudden markets went down a bunch and people stopped opening new companies, then maybe what would happen is that the transition would happen very slowly because you would just have that kind of status quo continue.
	36:10	So I think those are some of the risks to the trend. Then individual companies—I think it's so company specific that it's kind of hard to get into. But you'd be worried about the things like them not doing true DevOps, cultural risks, the kind of typical stuff that we look at in our risk process.
Rob Campbell:	36:25	Well hey, I found this absolutely fascinating. Really appreciate you taking the time to educate me and our listeners on what sounds like a really exciting topic. Justin, thanks so much as always for coming on the podcast.
Justin Anderson:	36:36	You like to challenge me on these tough topics, Rob. Once again, hopefully we haven't tortured too many of our listeners, but it was great being here. I found the discussion really exciting.
Rob Campbell:	36:46	Awesome. Thanks Justin.

---

Related Reads

• Why investors really need to understand the mechanics of Bitcoin | EP87
• The quest for “holy compounders” | EP101

---

How to subscribe

The podcast is available to listen and subscribe through any of the following platforms:

• 
• 
• 
• 
• 
• 
• 

Subscribe to Art of Boring to receive email notifications when a new episode is available, as well as other insights through our blog and quarterly updates.

---

Have feedback?

If you enjoyed this episode, feel free to leave a review on iTunes, which will help more people discover the Be Boring. Make Money.™ philosophy. 

If you have any questions, comments, or suggestions about the podcast, please email podcast@mawer.com.

---