David Williams, VP Product Strategy at Quali - Tame Your Complex Infrastructure

(Joel Beasley at 00:00:03) Hello, my friends. Today we're talking to David, the VP of Product Strategy at Quali, and we discuss what it looks like to have strategy as a business function, how Quali is able to automate your tech infrastructure, and why it's beneficial to trust your teams with a higher degree of autonomy and accountability. All of this right here, right now on the Modern CTO Podcast.

(David at 00:00:30) Here we go.

(Joel Beasley at 00:00:31) This is the Modern CTO podcast.

(Joel Beasley at 00:00:43) So how did you first get into tech, man?

(David at 00:00:45) Completely by accident, to be honest with you. I was studying to be a mechanical engineer, making washes for someone. But no, I did an internship when I was a kid and ended up being the lackey for one of—another term for a computer department—and carrying tapes and stuff that you don't even see today. But it was an entry point that I didn't expect. So getting into IT and technology was a complete fluke. It was thanks to a summer job and someone giving me a break. And I think that's what a lot of this—you know, IT is around—is, you know, with things like LinkedIn and other stuff, which wasn't around at the time, just enables that to be expedited so much better. So me getting into this world, I say it wasn't by design. It was not something I left school thinking about—completely different trajectory. So, you know, getting into it was—and at the time, not to age myself, but when I was a computer operator, it was ranked up there with astronaut.

(Joel Beasley at 00:01:48) That's awesome. So what was your first major job in the industry?

(David at 00:01:53) My first major job, I think, was working for a company called Digital Equipment. And like yourself, I was pretty young, and they gave me the opportunity. Digital Equipment—I got into it, again, I won't bore you with the route to it—but Digital Equipment at the time was one of the biggest hardware manufacturers. It was up there with HP and IBM, and it was really shaking the tree with IBM. And I joined them because of the disruptive nature of the company, and it was a very big company at the time. It was only second to IBM. And they gave me the opportunity over a very short period of time—and I was very young—to head up the European software portfolio group. So that was what got me into working, you know, with people in the United States. And I spent a lot of time in Boston, going backwards and forwards, which to me in my mid twenties—I'd never been to the United States before—so I probably spent the first week with my mouth open. So it was a pretty cool environment. But that was the first real responsible job where I was looking after a lot of the company's revenue objectives, articulating as clearly as I could how this technology would work, how it's different from everybody else. And it made you step up, you know. Sometimes you're thrust into jobs where you aren't quite there, but it certainly motivates you to do better when you're challenged that way. So I've always managed to find jobs where I'm challenged. So that's a good thing. Never stop learning. You know, that's the way it is in IT.

(Joel Beasley at 00:03:17) Yeah, absolutely. So earlier you mentioned that you spent some time at Gartner. What were you doing there?

(David at 00:03:23) I joined Gartner really to take a completely different avenue to IT. So with IT generally, I started off—my background was very much in the operation side. So I started off, you know, computer operations, network operations. I went into software development. I did product management for a long part of my career. In fact, it's still pretty much core to what I do. And Gartner just gave me an opportunity to take everything I'd learned over a prior—it was actually only a decade of experience—and apply it in a way that said, this is what I've learned. And it's the same way that we're having this conversation. It's sometimes—if you focus on a very specific area of technology as it started to fragment and get very complex, people were just needing to understand, if I'm doing this, what's the ramifications? So I like this sort of conversation with clients. I really enjoy working with end user customers, even to this day, because there's nothing that motivates me more—getting back to my roots of what I used to do—and nothing has changed that much, which is really heartwarming to me. It keeps me relevant. But even when I was a computer operator many years ago, today, a lot of the aspects are slightly different, obviously, but the behavior and the objectives are the same. It's, you know, delivering IT. And I think at Gartner it enabled me to become—it was like going to university, really. It was really getting submerged into a set of subjects, becoming competent on it more than just hands-on, but really understanding the market, all the vendors, how the technology worked. You know, you really get really deep into it, and then you extract it up to the business level as well. So it taught me—in the seven years I was at Gartner, I covered a number of subjects—IT operations and network management. I did release automation, the ability to do software into the production environments. And then I did some AI. I worked on AI, early AI and operations, which was, to this day, still in its infancy. But the last gig I did at Gartner was I did a lot of work around the DevOps practice. So I was talking to a lot of software developers and people doing more agile practice around development of software and actually helping their leaders understand the ramifications of going down that path, the success factors, you know, the failures that happen and why. And that was just pretty interesting. It gives you that sort of color. So when you actually go back into the doing side of the equation, if you like, the software side, whether it's from an end user or from a vendor, you come away with that sort of ability to be able to identify things a little bit quicker. And you know what level you can talk to when you talk to a prospect or a customer, and you can adjust your level of conversation accordingly. Because before I was an analyst, technology was king, no matter who I was talking to. I was going to blitz them with technology. And so, you know, volume was my weapon.

(Joel Beasley at 00:06:17) I like that you mentioned that it was kind of basically like going to university for you being at Gartner. Because that's kind of how I feel about doing this podcast. I don't know. I've been producing it for like a year and a half and hosting for a couple months now. And I feel like I don't have any training in cybersecurity or digital transformation or whatever, but I mean, I'm pretty good at talking about all those things now. And it's—yeah, it's so much fun being able to learn so much on the job. And I'm just glad that that's still out there, like, opportunities to do that.

(David at 00:06:59) Yeah, it is. As I've gone through my career, I've gone through—and I don't think anybody really controls their career in this world anymore. You are swept along with the tide, and you spot opportunities on your path. And I think that as I've gone through, working for a lot of small companies—I've worked for five startups that were almost, you know, one or two people all the way to less than 50. Three of them were acquired, which is good because that's typically an objective of being in a startup. You want to be something bigger and to get there quicker. Someone comes along, thinks you've got a great idea and obviously, you know, pays money to actually have you as part of their portfolio. One company I actually went through and watched the IPO in front of my eyes, which was a really fantastic thing to escape the velocity of getting acquired to suddenly get to such a success where, you know, you're IPO-ing and suddenly, you know, you've got a ticker and all that sort of stuff going. And then I worked with a company that hit the wall with no skid marks. So it's not all been fantastic. So it's like you learn from your mistakes, and you basically course correct to make sure it doesn't ever happen again. So it really is—you know, that's the small companies and the big companies I've worked for. You know, like, I've done Digital Equipment, was a very large company. To this day, I remember my employee number, and it was six digits long. So I wasn't exactly the first on board. But working for companies—I was a senior exec at Tivoli, which was what brought me to the United States, which was a fairly—it was a startup at the time in '96. And I came to Austin, and I don't think my yearbook at school said live and die in Texas, to be honest. So I came here and the reason I'm still here is I got married to a Texan, and that pretty much solves that problem. And so I didn't want to drag her back to the beautiful climate of the UK. So it was really, you know, moving that way to large companies and it became part of IBM. And I looked after the products and strategy for the enterprise business unit, which is a very cool job over a period of time, but the amount of money made was significant. And then I was a CTO at BMC Software in Houston. So that was an extremely good opportunity to learn even more about the industry and broaden it with its portfolio. I also, you know, worked for a company called CA Technologies, which was acquired only a few years ago by—I was there when Broadcom acquired it—and I was the head of product strategy there. So that was a pretty cool job. I lived in San Jose. My family still lived in Austin, but I was commuting backwards and forwards to San Jose. I came back to Austin to beat the tide of people in California just behind me. And then, more recently, I was at a company called Digital.ai, which is a portfolio company that did slightly different things. A lot of security stuff I'd never done. And constantly understanding not only from the types of companies I've been in, which is always an education. And I always find surrounding yourself with smarter people is the secret of success, to be honest with you. You can learn. You want to come away from a room smarter, not duller. And so you really want to surround—my teams that I've always built, I've always been people that I've had mutual respect for that always knew something that I didn't, and it was always sort of like a Fantastic Four type of thing that you all had to bring together with your secret source that you can bring into any game, and you could always answer a question with a wave in the room. And so it was a pretty cool way. So to your point, it's—there's no stopping the learning. And the company I'm with now, Quali, is a—it was purely one meeting with the CEO. He had me at hello, basically, on the value prop. And what this company solves is, ironically, what I struggled solving at previous companies, because it did something that basically cut to the nub of the problem. And other companies are spending lots of time trying to work out what the problem is because they don't have the technology. And as soon as he showed me what it did, I was like, that's it. I really want to get back into that level of technology. And so that's why I am where I am now.

(Joel Beasley at 00:11:29) Yeah. So tell me about the group of smart people you're surrounded with now. What are you doing at Quali?

(David at 00:11:36) So at Quali, I look after the product strategy. What that really amounts to—product strategy is a fairly new evolving title. I've had it all the way through my recent career. Strategy is always something that is seen as being everybody's job because no one owns strategy. You can build the direction. You could construct the idea around where you're going to go. You put the vision in front of everybody. You make sure that the product roadmaps and everything are aligned with your strategy. But at the end of the day, once you've articulated it and you're executing the strategy, then it really is a team effort. And I mean across the company. And so I did that when I was at CA. Similar idea. Very big company where you're trying to coordinate, you know, eight business units. Whereas the company I'm with is just one—a much smaller company—but it takes the same amount of effort and work to be able to orchestrate things and get things working. And I think strategy's become much more of a function purely because the industry moves so fast, and you've got to go to where the puck is going. I know that's an old clichéd statement, but I think if you really wait to put things to get stable and then develop to it, you're going to be years late. So you've really got to look at where things are going, and a strategy team's job is really to understand with a level of confidence that where the objectives are is where you should be directing the company. So maybe there isn't all the money that you would like to make from it, or maybe the user base isn't ready for it, whatever the maturity of that is. But you've still got to assess where the applications are being developed, what the digital infrastructure really means, what businesses are trying to achieve, and how they perceive IT's value. And then you work out, okay, well, what are the problems that they are going to be solving in the very near future, in the next six months? And how does that extrapolate out? And of course, today, it's not just technology. Skills are pretty rare. People are very transient. You know, today, I mean, people have jobs—if you're there for three years, it's almost like you get some sort of reward. And so you get—the idea is that the strategy team really has much more hands on the wheel than it used to have. And you really are driving not only the go-to-market—you know, how do you sell, how do you price and license going forward—and you think accordingly, as well as where do you put the investment around embracing the new technology. And, you know, as Quali, we're an infrastructure automation company. So infrastructure is everything cloud, everything containers, everything virtual, and it's the whole stack. It's a big thing. And so how do you—in the future, what does that stack look like, and how do people use it? And that's what Quali's objective is, is to ensure that as people add more pieces of their infrastructure together, create environments, focus on a very specific output, you can basically be prepared for it. So we can keep up with them. Companies can innovate and do what they need, and Quali as a company can make sure that not only do the practitioners get the value, but also the business gets the value. Because at the end of the day, if you add 10 more developers doing infrastructure, what is the bottom line impact of that happening? And that's a very difficult thing to equate, period. So value stream is the current term that people—value streams. And a value stream basically ties what you do to a business outcome. So infrastructure has always been taken for granted. It's just there. You know, it's always been there ever since compute met storage. It's been that way. And now it's obviously extrapolated to such a degree that infrastructure changes through a software delivery pipeline constantly, and yet everybody's building these things one at a time. So they'll build it for one area, then they build it again for another area using a complete set of tools, different people, different things in the stack. How do you keep context? And what I mean by context is how do you make sure that what is being designed and developed actually is being tested against and is being released as the operations people understand what's going on? And that's a, again, it's a hard problem to solve, but that's exactly what I think companies really want to achieve today. And I think that's what, you know, in the future, that's going to be almost—we want to see what the business value of this technology is, even if it's free. Nothing is free. It always costs you money.

(Joel Beasley at 00:16:06) So I wanna just make sure I have a good baseline understanding of infrastructure in general before we get into talking about it more. So I'll paint a picture for you of my understanding of infrastructure, and then you can tell me if I'm way off or just how much that relates to what you're doing at Quali. So the way I'm familiar with it is from talking to companies on the podcast that are making an infrastructure play as their business model. So we had a company called WePay on, and they set out to make an app that was like Venmo, like a person to person payment app. But what they ended up doing was making the underlying infrastructure so that other payment apps could take the technology they built and build a payment service on top of it.

(Joel Beasley at 00:17:01) Or we had a private space exploration company come on called Firefly. And yeah, they're trying to have a business of launching rockets and stuff. But the long term goal of theirs is to create an OEM marketplace for rocket parts. So anyone can design a rocket for a specific niche and spin up a space company.

(David at 00:17:24) And in—

(Joel Beasley at 00:17:24) that case, Firefly would be the infrastructure. Is that kind of on the line of the context of your company?

(David at 00:17:34) Yeah. I mean, infrastructure is a very interesting term. When you describe it to someone that doesn't have anything about technology—so when I describe it to my parents, for example, I have to sort of describe in a way that they can take something from it because a lot of what I do has always been a mystery to them. So I've always made sure that whenever I articulated to them, I don't take anything for granted. And I think in technology today, you shouldn't just assume that just because you had infrastructure, it means different things to different people. And, traditionally, what infrastructure looks like from an IT perspective, it's the stack of things that you need to have to support an application or an outcome based technology. So typically applications, and it will include everything from the network layer all the way through the compute and storage. But then it includes all the other stuff. It includes all the software, the middleware, the applications layer, obviously, as well, but also the tools that you're using.

(David at 00:18:31) So if you're a developer, you'd have your IDE in there, and you'd have your development toolkit in there. But you'd also have things like your database and your security technology also in that stack. So it becomes quite a diverse set of things, and it's very user based. So if you said to me, okay, my job is I'm a software developer and I'm looking at the application stack, the stack of things that you would use as infrastructure would be very much the common foundational pieces—that'd be compute, storage, et cetera. But the tools that you use may be very unique to you. So you'll find that the stack that you look at may have a foundational infrastructure that's very similar to how the tester would look at it. But the things that you've layered upon are very specific to your role to enable you to build the application using the technology. And I think that to make it maybe, I would argue, easier—or maybe I always—I've had to explain this very slowly in the past because infrastructure is what most people have been dealing with forever. What people are trying to get to is environments. And there's a subtle difference in infrastructure and environment.

(David at 00:19:45) Infrastructure are all the things—you get a menu. You say, I want one of those and some of those and this size of that and that sort of configuration, and I'll build it to do my job. And that thing that you're doing will be built from all your ability to identify all the things that you would need to build that thing. So like Legos. Environments are very specific to your objective. So you could say, I'm building an application, and you go and say, I'm gonna click on the application button, and it would come with all those things. It would say, I know what you need. So it becomes aware. So once you've built from an infrastructure an environment that supports yourself, then it's captured. And it says, this is what you do when you're building—when you're doing your job in this way. And so you add it as a menu item or something that way. That's an environment. Environment's very specific. It takes very specific pieces of an infrastructure in a very specific construct with the configuration settings, et cetera, already built in. And you just have to hit that one button. I'm doing this job now. And automatically, it would automatically provision and label those infrastructure pieces in support of the environment you're building. So you're no longer building it again and again and again.

(David at 00:20:45) When you get to the environments, when people start thinking, I know what I'm doing and I'm basically just making a few tweaks here and there to do my job, your life could become so much easier because now when you've got the environment, you can tune it, you can optimize it. You can make sure that it's better, more efficient. You can go, when I use these things, when I built my stack, this cloud provider's tooling, and I use this cloud provider's tooling, this one was so much better. It was easier for people to use. It had more features and functions. It was higher performing, whatever the aspects are. Suddenly when you've got environments, you can start applying the intelligence that you would like, which is help me make the decision on what I wanna use. So infrastructure in its heart is something that's a good thing and also a problem because it's lots of bits like Legos in a box. Environments are like Legos, but you can only make that plane or you can only make that car. You know, I want that one and you get the lid and it goes, oh, with these bricks, you can't make a plane from the car one. But with a box of bits, you can make whatever you like. But unfortunately, most people want that thing. Look at Lego. It is actually selling you environments, not infrastructure.

(Joel Beasley at 00:22:09) Got it. Got it. Yeah. Lego is not selling a huge bin of random Legos.

(David at 00:22:15) Not anymore. It's a shame.

(Joel Beasley at 00:22:18) Okay. Okay. So a lot of the time people are spinning up new applications and they're using a lot of the same pieces that they have to use on everything they build. And so instead of putting those pieces together every time, you have those pieces already set up and ready to use for someone else to take and just get going on the thing that actually differentiates them on their application?

(David at 00:22:47) Yeah. There's two ways that Quali—we look at this in two ways. We've got two technologies that we apply. They both are infrastructure or another term—technologies. They automate the infrastructure. One is very much focused on spinning things up very, very quickly. A lot of companies, especially large enterprises, they need to get control over getting services up and no rogue cloud environments appearing, things that are provisioned but then forgotten that end up being charged to you or things misconfigured with people that didn't have the skills or the resources to be able to make sure that happens. So we got a technology that enables companies that like to look at themselves as service providers to their own business where you make a request. It's a self-service portal. You can click on the environment, so you can even build your own if you want to get into the weeds. But it enables you to quickly bring that up. But the whole point is that we provide the full life cycle.

(David at 00:23:39) So it will ask things like, how long is this gonna be using this for? What is it being used for? It asks you some very basic questions that gives accountability and ownership to the things that you're building, that enables you to understand what the costs are associated with that because we capture cost, especially if it's in the cloud, and we can say that's what it costs. But we also spin it back down. So nothing's left rogue out there. So finance is a happier person because they're no longer getting these unexpected bills. And we also enable the skills to be optimized. So anybody should be able to provision a quick environment to support their application if they don't have the networking skills, the database skills, and the system skills that you need or the cloud skills. We can spin that up. So your skill set may be pure one area, and enable you to build the other stuff in advance. So that's one thing that we do. We do that for a lot of companies today, and they build these environments up, bring them back down. It could be for demos, prototyping, applications, whatever you want to use it for.

(David at 00:24:47) The other technology we have is much more development focused. So that builds the things that we're just talking about, which is—it takes developers. Developers like to use their own technology, you know, whether it's infrastructure as code type of capability, and they build up their infrastructures. And they feel very happy about doing that because they can build the configurations and the infrastructure stack within their application code and build things up very quickly. And, you know, but it's very unique to them. And, arguably, if you get two developers, they might be doing it slightly different. So as you move down the agile processes, when we've got these modern software delivery activities going on, there might be more people doing different things to the infrastructure. They may not have the skills to do what the developer did. So you wanna be able to enable them to actually leverage what the developer built and then add their own stuff so they can do the testing. But you should also be able to say to the development team, they can subsume what they're using. So what we're not doing is just saying, oh, to get the value from Quali, you've gotta completely forget what you've done. You know? You can—there's no way, having been a developer, you're ever gonna rip what I need out of my hands because I need to innovate, and I don't wanna be told. You know? The worst word in the world for me when I was a developer was abstraction. I don't want abstraction. I can't work with abstraction. I can only work with detail.

(David at 00:26:03) So I should be allowed to use my tools, and I should be able to subsume those into the Quali technology, which keeps them as a blueprint. And suddenly, that piece of scripting that I'm using or that piece of code that I've built is now got governance attached to it because the blueprint applies that. It gives you a versioning of the product because I know what blueprint I'm associated with. And so it actually gives that ability for my blueprint to be able to pass down the line, modified, or multiple blueprints grouped as a deliverable, you know, for that software delivery. So it enables me to have all the flexibility that I want. It gives me the ability to not have to worry about risk and governance because the technology is about that. And it gives companies the ability to understand when they do all this work, what's the cost, the effort, the speed of doing it with all the things that we talked about in regards to optimization.

(David at 00:26:36) So it's a really cool technology area that today has only started to come because DevOps, which is a term that a lot of people are using, has got to a level of maturity where the management and the executives in companies are saying, well, everybody's been going and doing their own thing, but now we haven't got visibility into all the infrastructure pieces you're using, all the skills that are applied. So they're looking for a little bit of understanding. And I think the term is, you know, they wanna observe what is going on so they can plan. Because if you don't know what you're using and you don't have any control over how things are being used, then how do you plan infrastructure going forward if it's not all in the old days where you could just look through the computer room door, count all the pieces you got? That's where our budget is, and we're gonna add more of these. You can't do that anymore. Everything is disposable. You know, that virtual environment goes up and down. And now you've got serverless within each cloud provider, which is fairly proprietary. Who knows where your workloads are going and what's happening. So you really just need to have that ability to plan your spend and understand where your skills and resources are being allocated. And that's what Quali is aiming to solve.

(Joel Beasley at 00:28:09) So it sounds like with your position in the development process, it kind of makes you a tastemaker of tool chains and what people are using. So how do you keep up with all the new products that are coming out and make sure that you are offering the absolute best solution at each layer in the stack?

(David at 00:28:32) You know, this has been a challenge for every company for a long time because, you know, you can go for today's shiny object, and it'll be replaced by tomorrow is really interesting. That's what I'm talking about, the strategy in regards to where do you prioritize. So I think a lot of the things, to be really serious, is that there are certain things that we won't be doing. So as a strategy, there might be—you might have 10 integrations, and we would have to decide which are the most strategic ones that meet our audience, our target audience. We focus on large enterprises. That's where the complexity is. That's where the scale is having challenges. And I would say that most enterprises use an awful lot of similar type technologies. The Gits that are used, there's not more than three or four that are commonly used across the infrastructure. Even though there are hundreds, there are three or four main ones in there. The cloud providers obviously make it a little bit easier because, you know, people wanna use the cloud tools. And of course, with virtualization and other things is a fairly established space.

(David at 00:29:19) So even though there might be literally thousands of options on what developers could use in the whole scheme of things, we actually break it down to a very specific amount. So I would say we have the optimum amount, and it depends upon, one, what they're trying to do. Is it a build engine, an IDE, a Git? What sort of repository is it? And we'll make a decision around that. But we typically support all the top five technologies that are used across most of these areas, and it gets more expansive. Obviously, as you get into operations because, boy, what you thought you had in development is just exponentially more in operations. So you just gotta work out what is the most valuable to the types of companies that you have and you're aiming at. And, again, will we support everything within the company? We'll support the main things.

(David at 00:30:13) The one thing that we're doing to support a lot more things is we do have a freemium technology from our product. So if you do wanna develop something on the platform that isn't—so you wanna manage your Coke machine, then we give you the ability to integrate your Coke machine into our system. So you've got the ability to bring in new software, new applications, pieces, new tools, new components in using the community version that we have. And we just give the tools with which you can build those things out. And then we will provide with the enterprise version the ability to be able to manage all the main components that are out there. So between the two, we'll find water. We'll find its level. But we will continue to look at the new technology emerging, and we'll continue to look at how technology gets abandoned because this is a very disposable world today, and things get abandoned almost overnight. It's quite shocking how people do that. So but when you work out where the infrastructure is going, then you can work out what type of technologies are being applied to solve that problem. And that helps you at least get your target within a reachable way. You're not trying to basically go, we'll integrate with anything with a pulse. It's just not feasible.

(David at 00:31:31) But let's say working with our customers is awesome. They keep us — you know, we have customer advisory boards being delivered and that sort of thing will provide us with the input we need, as well as the communities. Communities aren't known for their shyness, so communities, there are always one or two people who are very vocal that'll bring the whole herd together and say, "This sucks," or "This is great." And they will be at that.

(David at 00:31:58) There's no gray area typically. It's on or off. So you really have to be very attentive, basically, to make sure that you're giving the customers and the prospects, as well as the people that are just doing it for the freemium version, the things that they need based upon what they're telling you they need.

(Joel Beasley at 00:32:17) So it sounds like a major benefit of this is obviously cost savings with — I guess we'll call it the old way of doing things. Developers would kind of get their budgets from the company to just do whatever they say is best for their project, and then the developer next to them is building a completely different stack when they may not have to do that for their project. And so if they come and use a service like yours, then they can find a lot of synergy between the stacks and not purchase things twice. So do you have a customer success team or something that will go in and measure all of the unnecessary expenditures that were going on before and calculate the ROI and cost savings of moving to your service?

(David at 00:33:12) Yeah. Quali as a company, when it was first doing the technology — it was CloudShell, and what it did was that first solution, the service enablement technology. To get that up and running ten years ago when it first came around was really to make sure that customers were getting what they needed. And so the customer success team is very much how you described. It is going in there, making sure that the success starts at the day, the minute that either the order is placed or the product is being adopted.

(David at 00:33:46) So don't forget, some of these things that we're doing aren't — you know, we've got a freemium version, but we've got the ability to be able to help customers get value out of the technology as fast as possible. That's our objective: to make sure that the thing that they bought it to do gets there as fast as it possibly can. And so some companies have the ability, by the way, to do this. They've got a lot of very smart people who understand and have brought technology into, you know, to a bank, for example, and they know how to work there. And we work with them, and we're pretty much guiding as opposed to having our hands in the pie.

(David at 00:34:23) In others, much more hands-on, working out where the low-hanging fruit is. A lot of this stuff, by the way, is done in some of the testing and some of the beta testing that can happen. I know, as well, if they can adopt something and get an early version of something and test it that way. So a lot of that's done ahead of time. So presale sometimes gets that.

(David at 00:34:48) So we identify, obviously, what the value is, because they've got to justify the cost if it's an expenditure, and we want to make sure they achieve that. So that ROI is based upon that. So the customer success team, which is quite a big team within our company, is really focused on making sure that what we deliver: one, is relevant; two, meets what they expected; and three, provides them with a strategic capability going forward. And it's not just a tactical tuck-in.

(Joel Beasley at 00:35:13) That's very cool. Yeah. That makes a lot of sense that it needs to be a really big team, because it sounds like a big job given the level of complexity that you can get to with all the thousands of different options that developers have to choose from in their stacks.

(David at 00:35:28) Yeah. I would add to that, saying that even though there are lots of options, our job is really to construct these environments and these places where you can actually bring them in without having to have a lot of hands-on. So we don't want people doing all the wiring. You know, we want to make sure that if there is technology out there that has a default set of capabilities that we can integrate automatically out of the box, then we will do that.

(David at 00:35:42) Only when you get to very much a company's requirements specific to their very unique application do you have to go in there and maybe help a little bit. But otherwise, the vanilla is pretty much something that we would expect to get out of the box. So a lot of the things that our customer success team may have done in the past, my expectation is that we embed them into our technology going forward, so no one has to do it, and it becomes a much more out-of-the-box experience. So single-click is always an ideal thing, but getting to a point where they're not having to go head-hunting at NASA is our objective.

(Joel Beasley at 00:36:27) Yeah. That makes a lot of sense. So earlier I made a note when you were talking about strategy as a function. I wanted to dig into that a little bit more.

(Joel Beasley at 00:36:36) It makes a lot of sense to me that having strategy as a function helps a lot with being nimble and able to adapt quickly and keep a finger on the pulse of what's going on so that you can steer the company in the right direction. But I also feel like placing that level of authority of the strategy on a small group has the danger of creating blind spots, where strategy is being decided by the whole organization, you have a more diverse set of thoughts going into it, which, of course, slows it down. Like, these are competing ideas that are both important. So how do you remedy that?

(David at 00:37:18) So the strategy team is very much tied into the product team. So product marketing within Quali, product management, and strategy — that's a trifecta, and they work very closely together. So one is really looking at we're getting the product to market, making sure that it meets the requirements, has the roadmap planning, et cetera, in place. The product marketing job is really to take the technology and apply it to solving the problems, making sure that companies, that whoever you're talking to, understands the value of doing it.

(David at 00:37:50) The strategy person is really looking a little bit further in advance in regards to the whole strategy in regards to the market. So, for example, if you and I were building a company and we said we're going to be the number one company in doing application performance monitoring, and we said, "Well, that's all you and I are going to be doing as a strategy team." What that means for you and I is that we're no longer looking at continually looking at one product to do it. We may be looking at what partners do we need, what technology do we need to add into it. Do we need to morph this and migrate it to a more effective technology? So really, you're really looking at solving the market problem and solving the problem for the client. You're not trying to make a technology relevant all the time, because everything has a wave. And when I worked at the big portfolio companies, you've got to assume that what you're developing today is not going to be relevant forever. And so, to continually — you're always going to have a legacy and install base that is slower to adopt, but you've got to make sure today, especially in today's environment, where you've got to have the agility built within your roadmap.

(David at 00:38:55) Roadmaps are continuous. It's not like you do a six-month release anymore. Releases happen every day. So as you're doing that, you're tweaking it, and you're making sure that the strategic direction, the overall vision of where the market's going, is injected into the product roadmaps, which is then injected into the messaging and the value props that come out of the marketing organization. So the strategy team is really looking through the windshield. Others are looking at the dials. Others are sort of, you know, telling you how fast you're going and advertising it to the world. So it really is, everyone's got their courses. So the strategic function really has become much more of a function within most companies. But I've had that job title for probably over fifteen years, but as part of product management. So whenever I'm in product management teams, we had strategy.

(David at 00:39:41) The trouble with product management teams only having strategy is they only look at the product, and they move the product forward. And I'm saying it's the market. Make sure that what you are is relevant and how it moves forward. It just makes you a bit smarter in regards to how you position your own products. And it also keeps you a little bit more aware of the threats that occur, because who knows what Amazon is going to be building tomorrow? Who knows what these guys sitting in a garage somewhere, building that's going to completely disrupt the container market? So you've got to make sure that you're really looking at some of the very small pieces of information that are coming out, the edge of the radar. But as you get closer to it, you can see what the volume is, and you can measure it. And that's something that is, again, unique to this world today. You've really got to understand that and just be effective ongoing. So I've got to be able to say to my CEO, who's got to explain to the board where we're going as a company, we can have the vision. We'll adjust, adapt accordingly. But to your point, do I own strategy?

(David at 00:40:41) No. I'm the custodian. I say this is where it's going, and we do that thing. The strategy is meaningless if it's an ivory tower function. Absolutely meaningless. You can't be the only people that get it. So everybody has to understand what we're doing. So no surprises is what I promise my boss. And that's exactly what the strategy team is doing. It's making sure that whatever happens in the market, we have a position against it, or we understand what's going on, that we can address it and then adjust our products accordingly.

(Joel Beasley at 00:41:12) Yeah. I like how I feel like that's a level of maturity in a company, to have a strategy person — or sorry, strategy function — that's separate from just like, "Oh, that, of course, that's the CEO's job is top-down. Like, that's how that works."

(Joel Beasley at 00:41:28) It's kind of like a little while ago, we had a string of interviews with enterprise architects that are all about deciding the way the hierarchy in the organization works. And I think that's kind of a similar thing where it used to be like, "Oh, of course, that's just the CEO's job. CEO runs the company." But the CEO might not be the best person at doing that. They might not be the best person — but similarly, they might not be the best person to steer the strategy when their focus is all over the place with the company.

(Joel Beasley at 00:42:03) So I think that's really smart to have the level of maturity to not necessarily take that away from the CEO completely, obviously, but to spread out that responsibility away from necessarily just the C-suite.

(David at 00:42:19) Yeah. I mean, the company strategy, which obviously is a much bigger thing, that includes M&A and many other things. And so, even though the strategy team will work with the business development organization — and we have a very close relationship in Quali between myself and our BD leader — because obviously we're not going to be able to solve this all on our own. Sometimes we need partners, whether it's a set of channel partners that we can say, "We really need to hit that geography harder because the market requirements of what we deliver is so much more applicable to what they're experiencing." So it's not just the market, again, as just a North America thing. It needs to be looked at as a global essence, and that's something that the CEO would have. How do I need to allocate resources? My job is to make sure that the CEO is aware and gets the information with which to make a lot of the decisions. But at the end of the day, I'll be honest with you, our CEO is extremely strategic and visionary.

(Joel Beasley at 00:43:16) Oh, right.

(David at 00:43:17) And so, as far as I'm concerned, he's part of the team, and every decision we make and everything that we're observing, he's aware of, because again, no surprises is my promise to him. And so I want to make sure that as we move forward, that the overall company strategy is influenced by some of the products. Because my role is really the product and the market that our product addresses. His job is more expansive than that. It's around the whole organization, the teams, how we build them up.

(David at 00:43:50) And so that's how we work together, is saying this is the thing, and then he goes away, works out how much the investment is required to meet a certain objective. And that's all him. I don't — I can't go ahead and hire another fifty people to do something or move people from one country to another, but I can definitely give the reason why we should be doing that, or the business reason why we should be doing that. And that's how he and I work closely together.

(Joel Beasley at 00:44:13) Cool. Okay. Yeah. That gives me a much clearer idea. Thank you for that. I want to talk a little bit about your overall kind of leadership strategy, leading your teams and whatnot at the company. Is that cool?

(David at 00:44:26) Sure. Yeah.

(Joel Beasley at 00:44:27) So how would you describe the culture of your area of the company and of the company in general?

(David at 00:44:35) I think that most companies, because things are moving so fast, a lot of decisions are made in little silos or in closets or, you know, over lunch or whatever. And I think that the challenge today, especially with what we've just — what we're going through still with COVID and everybody working from home and doing whatever they need to do — I think the culture needs to be much more of an open-door one. So with my team, I don't have any secrets. I mean, really, everything, to be honest with you — I don't make decisions all on my own, for starters. That's the first thing.

(David at 00:45:09) I've got a small team of people who will work very closely with their own team. My philosophy is, if you hire the right smart people and they can do something that stops you having to be involved in it — so I will work as a collaboration person. So I stop being an owner of something, and my team member becomes the owner, and I will work as part of the collaboration team. So I now work for that person.

(David at 00:45:34) So it's — and I think that's how we scale up. If I get lots of the smarter people, and I've been privileged, I think, in my career to work with people that are very smart, who I would work for now, ironically. I mean, I'd have no problem in working for a lot of people that worked for me in the past, purely because I know that there's going to be a lot of opportunity to work together in a collaboration way. But that's my philosophy: we can hire the right smart people, get them to own something. It's really good when you're accountable and you can walk away from your job every day knowing you've accomplished something that you can be proud of.

(David at 00:46:09) So accountability and ownership is very keen in my eyes. I want to make sure that people are given the opportunity to succeed, and any training they require can be added in. This is not just motherhood applied. This is an actual real thing that I strongly believe in. And I think the team that I've got at the moment has different skills. They are different. I have, luckily, within the strategy — you can have a mix of skills. You've got someone that can do market research really well and understands the competitive landscape, someone that knows channels and the technology much better. You know, you can mix those skills up. And as a team, you make that wonderful team, but they still have accountability to their own portfolios and market focus.

(David at 00:46:49) So that's how we build up this team, and I think that basically filters through to the teams that we work with. Same goes. I look at product management. They don't report to me, nor does product marketing going forward. So I regard them as my team. I include them in my meetings. They come in. We discuss it that way, and so they're part of the virtual team that I have. So I don't let all the reporting stuff get in my way anymore. I mean, it used to, many years ago when I was early in computing.

(David at 00:47:15) Your organization defines how much visibility you had on what's going on. Like I mentioned, two of the acquisitions that I was involved in were complete surprises. Well, one of them was a very big company, so I wouldn't know. That wasn't. And it did surprise me, and it was done in a very small way. And I think I don't want that to happen with my team because we're involved in a lot of things. So openness with a level of professionalism attached associated with it as well, because there are confidential things that my team will understand that they can't spread to everyone else. That's the role of strategy. It has certain things that you can't tell everybody.

(David at 00:47:49) But mainly, our main role is to make the product successful, make the company successful, and anything that's associated with that gets diluted through the team. So, again, collaboration has been a struggle because I think people are a bit Zoomed out. But so meetings—I mean, this is the longest meeting I'll have today. So it really is keep the meetings short, keep them peppy, be available on the phone. I mean, I spend more time keeping my Fitbit up to date and purely talking to people, making sure that happens. So again, communication—no mystery in it at all. But I do not like siloed organizations. And I was working for CA Technologies and they broke that down incredibly well, right until the very point where they got acquired by Broadcom.

(Joel Beasley at 00:48:38) That's awesome. Yeah. It sounds like you're doing a good job with a challenging idea of reconciling, giving autonomy to your employees to make decisions on their own and own their projects, because obviously they're going to be working harder when they're proud of their work and when they own it and they can make decisions faster when they are empowered to do so. But then they also need to simultaneously, while they're owning their projects like that, be able to come together and share often about what they're doing, to be open about it. Like I said, it sounds like those are kind of somewhat competing ideas. But by the way you describe pulling in all these people from different parts of the organization to your virtual team, it sounds like you're doing a good job keeping that communication open. That's really cool.

(David at 00:49:34) I'll be really honest with you. I mean, not only is it a good thing to happen, I need it to happen.

(Joel Beasley at 00:49:39) Yeah.

(David at 00:49:39) Yeah. If I didn't do that, I couldn't do my job. I cannot just make a decision, turn left. I mean, it's just—I have to have, within the team that we have, you've got to be part of the fabric, and it's got to be more dispersed. And as a company, as we've grown, this is, by the way, a behavior that takes a bit of time to put into a culture. But it's very effective from the get go. So openness and the ability to do all the things, say what you need to say. Don't worry about upsetting me because we have no time for you to beat around the bush. And I'm a Brit, so I know how to beat around the bush. So it's really you've got to get to the point of scrutiny quickly, explain your rationale, and then we'll make a decision.

(David at 00:50:20) So I've always found that, you know, I've been in this industry quite a long time, and I've managed very large teams and very small teams. And I think that there are subtle differences, but the main thing is to make sure that you listen more than talk, which for me has been a lifelong ambition. And basically get the information in and make sure that you get the temperature on everybody. I think it's really important to talk to people as often as you can because things happen so fast. We're as a company, we're growing. We're moving—we are twice as big as we were a year ago organizationally. So as you move with that serious amount of growth, you've got to make sure that transparency and that organizational roles and functions and contributions are understood. So that enables you to execute more efficiently. So I may be saying again, I'm sure that people go, "Well, that's a bit of motherhood and apple pie." Sure it is. But it's a balancing act. Nothing's perfect in this one, and it really depends from company to company. But any company that still works in the silo where decisions are only made by one or two people, you know, things happen, will struggle going forward because that's not how the world works today.

(Joel Beasley at 00:51:29) So I think it was like a month ago, I was talking to this guy, Ryan Westwood. He's the CEO of a company called Simplus, and they're a Salesforce partner and they help companies out a lot with digital transformation. But anyway, this guy was just an excellent leadership guru kind of guy. He said it's like one of his life goals to inspire a thousand future leaders. And so like you were talking about scaling up this communication as your company has doubled in the past year, he was the founder of this company and they've scaled significantly. And so as the founder, he set values at the beginning, and he just had to do his best to propagate those out through the culture. And the way he evaluates the health of the culture as the company grows is when he sees the values being practiced by employees without any involvement from him. Right? And I just thought that was a really cool way to think about it. And I was just curious, how do you kind of evaluate the health of the culture in your teams? And when have you seen times of those values being practiced without your intervention?

(David at 00:52:46) I think when I first came to the company, I've been with this company for nearly a year now. So when I came in, the strategy position was a fairly new one, a product marketing and a few other dysfunctional areas. But where I'm going with this is that everything came to my door, and you become a bottleneck when you're doing those things. So when you start removing the bottlenecks, that's when you know. Have we removed them all yet? Not yet. I mean, we're still growing. We're still doing that. There are certain people that are always nice to have in the room. But when you see when I'm no longer—when I'm invited to a meeting as an option that I used to be compulsory and one of my team members is now running this thing, that to me is success, especially if I've already spoken to them, and that's what they want to do. They want to own something.

(David at 00:53:35) I think, again, I really think that people will really like the jobs when they're accountable, when they own something and can show what their contribution is. And that's when I can see that happening in front of my eyes. When I see my team, they may not contact me for two days, and I don't freak out about it because I know that if they're not talking to me, everything's really good. You know? And that I learned many years ago by someone that when I was at IBM, someone told me that. And I was like, "Really? I'd like to talk to you every day because I like it." And it's like, "Yeah. But if you don't, I'm not going to get upset." And I think that that sort of thing is an indicator of it. Plus, if what they're doing is successful and other people have said that person's contributing, they take an ownership, it's really moving on that path. So you can judge two things. One, the person that's doing it, their overall persona and how they're working that day. And I always have said, you know, talk to me if you have any challenges. But the second thing is what they're doing is being successful, and other people talk about them.

(David at 00:54:37) And I get that a lot more now. It's "Thanks to these people," you know, "that contributed to the overall success of that quarter." And it's nice when you see your team being singled out to do that. Again, not everything's rosy, but pretty much that's a really good benchmark to have. And I think, by the way, you know, when you're on LinkedIn, everybody claims to have solved world hunger. It's really nice when you can say, "Hey. I did this." And then, "Oh, by the way, I've got two dozen witnesses that can you can call anytime to show you that I did this." So it's really nice when you can actually—again, accountability as opposed to being a contributor. So that's, you know, that's where I really want to go with this team is to make sure that my team is accountable for certain outcomes and that they get rewarded accordingly, which again is another thing. Rewards in regards to whatever it is, promotions, bonuses, whatever. It's so much easier to do when you can latch it to someone that says that's what they did this quarter, and there's no way that you can refute it. So it's pretty cool. You know, it's a magic thing for me, and it's a good thing for them too.

(Joel Beasley at 00:55:40) That's awesome, man. Well, we're almost coming up on time. I want to ask you one more question. What are you learning right now? What's challenging you?

(David at 00:55:50) I think what's challenging me at the moment is that the—I mean, I don't want to get down into the technical reasons, but the market has dramatically changed over the last, I'd say, two or three years. The maturity of the market has grown. I think COVID accelerated a whole bunch of innovation. It just drove it. And I think that the challenges to me is to be much more alert. So I found that when I'm reading research and, you know, the thousand opinions that are out there, you've got to get to a point where you can take the magic touch points and actually become—get a hardened set of actions that you can go with that gives you enough understanding that you're going in the right direction, because people can get analysis paralysis where they're looking at so many analyst opinions. And I can say that with honesty, every analyst's opinion and every pundit has an opinion, everybody on a community side has an opinion—you can get drowned in it. And so just having the ability to be able to articulate that in a level that says, "This is where we need to go and why," by using the most important ones, identifying the major reasons, that's a challenge today because they say everybody's got an opinion. It's like going to an Amazon site and asking, you know, the feedback process. Is that a good product? And one star, five stars. It's like, what the heck? It's all around.

(David at 00:57:04) I need to understand a little bit more about the market. So, again, the speed of the market is my challenge and keeping up with the rate of change. But it doesn't keep me awake at night. I just need to make sure that we execute, you know, in line with it, keep and keep ahead of it in some ways.

(Joel Beasley at 00:57:26) All right. Well, before we wrap up, is there anything that we didn't get to touch on today that you want to make sure we get out to the world? Like it sounds like you guys are growing pretty fast. Are you hiring? What do you want to plug?

(David at 00:57:38) Yeah. We are. We are actually, yes. So, actually, we are hiring. We're hiring across the board at the moment. We're hiring developers. We're hiring salespeople, we're hiring marketing people. So we've got people coming in, product marketing people. So we are growing at a rate. And the good news is for us is that we're not looking at—we're in Austin. It'd be great to have people in Austin because half the planet seems to be coming here now anyway. So, but we're not tied to that. And I think that the freedom of being where you are is something that, as a company, we embrace. So we're very supportive of that, and we're just looking to get the right people in the company. It's a great place to learn, and it's a really hot space. So you talk about the Gartner thing, about me learning. I'm learning here a lot every day. I get a little bit, hopefully, smarter every day, and the people that we have hired are awesome. So I'm very happy with the team. And, again, that's what I'd like to say. If anybody's really interested in Quali, please look us up. And if they're interested in more of a career in Quali, again, drop us a line.

(Joel Beasley at 00:58:49) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.