Using No-Code Right with Vaughn Thurman, Founder & Chief Evangelist at HighGear

(Joel Beasley at 00:00:03) Hello, my friends. Today we're talking to Vaughn, founder and chief evangelist at HighGear. And we discuss the difference between low-code development, no-code development, and no-code configurable software, how to get the lowest time to value out of a no-code solution, and why no-code configurable software is often better equipped to empower non-engineers than no-code development solutions.

(Joel Beasley at 00:00:29) All of this right here, right now on the Modern CTO podcast. Here we go. This is the Modern CTO podcast. I want to get into the meat of the episode today. Your company, HighGear. Can you tell me a little bit about what HighGear does? We'll start there.

(Vaughn at 00:00:54) Yeah, you bet. Thanks for asking. So HighGear is a software application that is clearly in the workflow space for medium to large size enterprises. And what differentiates us is not necessarily what we do, but who we empower to do it. We have a significant stack of completed technology that handles things like assuring security, determining the pathway that work will take in best practices, assuring that the capture and presentation of information for decision support is handled in an organized way. And what we deliver is a no-code set of capabilities that allow ordinary people who are not programmers—they may think in systematic ways, but they're not coders—to deliver an entirely enterprise-grade solution in really short order, completely through configuration, kind of a tailoring. So if you could think of it as we're delivering completed suits, and we're just asking them to decide what pocket square and tie should go with it, but we're doing that with no-code tools.

(Vaughn at 00:02:03) And so to take the example a little bit farther, if you think about finance systems, it's very common for people to expect that if they buy an enterprise-grade finance system that, while it's going to take care of the transactional routing of income, expenses—maybe it's got an approval process, maybe a CFO has got to sign off on an expense larger than X—the general journal entries that go behind taking that expense and spreading it across five years, you expect the engine, the platform, to do those things. But you would also expect that you're going to have to configure the invoices to look the way your company wants them to look, and you're going to have to get the reports to display the data that your CFO wants to see and that people in various parts of the organization—like accounts payable, accounts receivable—need to see in order to be able to do their jobs. And you would also expect, in the vast majority of those systems, that a business analyst, somebody who's not a programmer but is close to the business people, understands the complexity and nuance of their processes.

(Vaughn at 00:03:06) You would expect that a person of that talent set would be able to go interview the business stakeholders, figure out what it is they want and need, and stand it up. And IT is going to be responsible for standing the platform up, or if it's in the cloud, making sure it's secure, and they're going to integrate it with other applications. Maybe you're going to say, "Hey, we've got this thing where people can order online, and we want it to automatically go in and create an invoice in our system." You're not expecting the business analyst to do that, but you do expect that business analyst to be able to stand the system up, get the general journal entry automated transactions happening, get the invoices configured the way you want, get the dashboards looking the way the CFO wants, and get the interfaces set up so that the people can do their jobs.

(Vaughn at 00:03:47) Well, HighGear has really taken that same model and translated it over to work at scale. And so we come into organizations—traditionally, financial services, energy companies, government agencies—that have work that needs to be meticulously tracked, perhaps audited, typically audited, and they need to be able to prove that things were done a certain way within a certain time frame and who approved this, who made this change, who handled that payment, who sent this shipment. And we bring the transactional engine that delivers the expected best practices, the transactional integrity, but each of our customers configures it uniquely to their environment. And likewise, a business analyst who's close to what the business problem is or what the business stakeholders want and understands that intuitively is able to go in and use completely visual tools to draw out or map out those workflows. But unlike solutions where you're just drawing a picture, it's alive.

(Vaughn at 00:04:45) It's going to work. Records requests can begin to move through those workflows. They can be escalated based on time, based on rules. "Hey, if it's more than $100,000 and it's been in here more than three days, send it to this team and notify this team." Those are the kinds of things that people configure in our tool using no-code visual tools. They configure the forms that someone might use on one of our customers' websites to request maybe an update to their account or to kick off an investigation in a logistics organization. And then that record comes in and begins to move through the organization. Perhaps it first goes to customer service and then goes to somebody else. Well, our business analysts are able to configure all of those things—the forms, the fields, the flows, the sophisticated flows that make sure things move through the organization according to policy and procedure.

(Vaughn at 00:05:39) And ultimately, the dashboards that present all of that information, like the stakeholder who says, "What are the 18 things I need to do today?" all the way up to that VP of operations who says, "What are the 73,000 things my team got done yesterday? And I want to aggregate it by location and type of work and customer." And that's really what our system has done. Like I said in the beginning, it's not what we do, but who we empower to do it. With code, people could do the same thing eventually, but we're bringing, you know, 15-plus years of best practices from organizations all over the world in a container that's done, where our business customers can then just empower their business analyst to configure that last 10 to 15%, sometimes even doing 80% of that with a template, to tailor it to the unique way that they want to do business, to their unique policies, and to unique requirements of their industry.

(Joel Beasley at 00:06:33) Very cool.

(Vaughn at 00:06:34) That was a little bit long, but I get excited. You can probably tell.

(Joel Beasley at 00:06:37) Oh, I can tell. So is HighGear shipping a no-code configurable software, or is it like a no-code app development solution?

(Vaughn at 00:06:46) I'm really glad you asked the difference there because I think it's important, and I think there's a lot of confusion in the marketplace between low-code and no-code vendors and no-code configurable applications. And so would you mind if I kind of zoom out a little bit and give my perspective on this?

(Joel Beasley at 00:07:04) Let's zoom out. Let's see it.

(Vaughn at 00:07:06) So, you know, I think what you've got to do is sort of first examine what's happening in large enterprises. And there's a tremendous press for digital transformation. Quite frankly, the birth rate for developers is too low. It can't keep up with the great ideas that business people are having. The line is really long. And so IT people and business people alike, for different reasons, sometimes the same reasons, are trying to find ways to shorten that line at the door without creating new risk. And so one of the things that they can do is to go look at a low-code solution. And so if I write code from scratch—just to kind of define these things as we go along—I've got maximum power and maximum flexibility, but I'm probably going to have the longest timeline to first delivery and the longest timeline to any incremental changes.

(Vaughn at 00:07:58) So if I take that second step to low-code, it's not necessarily going to fit all the requirements that were at my door, but it might fit a lot of them because a lot of them might fit kind of within the box of what low-code solutions are going to do. Now the low-code vendors, I think, would argue that they can do everything that a straight code deployment would deliver, and I think that's disputable. And in fact, I think it's very disputable. I think there are scenarios where it's true, but you would be paying a price it's not worth it, that because you would work around the limitations of a low-code platform, you'd end up slowing yourself down later in some way.

(Vaughn at 00:08:34) So I think it's wise—and by the way, I'm not negative on them. I'm actually very positive on them. I think it's just wise for a technical leader to understand what that tool is intended to do. It's intended to take more junior programmers and allow them to develop simple to mid-grade or more sophisticated requirements that actually do fit that low-code model in less time. So they're going to sacrifice some flexibility for some speed.

(Joel Beasley at 00:09:02) So I noticed you said that it allows junior developers to do these things, but I see a lot of low-code stuff positioned for non-developers.

(Vaughn at 00:09:11) That's right. That's right. And that's where I'm going to be controversial. I see the same thing in the marketing claims, and I even see the same things with a lot of CIOs who spent a lot of money on it, saying, "We're getting this to happen. We're empowering citizen development." Now, you know, I've been to some presentations for some of the folks who lead in that space, like Mendix and OutSystems, and they've certainly got some great deployments out there where people are getting things done that are quite impressive and very useful to the organization. Again, I'm very positive on that sector. But the reality is that the people that they bring up and put on stage and talk about—not them specifically. I don't want to sound like I'm shooting at a particular vendor—are often, whether they realize it or not, becoming IT people. They're people who already think systematically, and they begin building centers of excellence where what I would call para-programmers are learning how to use these tools.

(Vaughn at 00:10:05) And the low-code environments often require you to drop down into code to get some capabilities done. Quite frankly, it was the same thing Cisco, when it was the dominant force in the marketplace, began facing competitive pressures from smaller router companies that had web interfaces. And so, you know, you'd have this sort of geeky-looking guy in the back room in IT who could go into a command line that looked dark and forbidding, or there was a sexy new router that had a web interface that looked light and easy. And Cisco, being very afraid of that, came out with web interfaces for all of their routers. But the reality was that Cisco had much more advanced capabilities than the majority of those baby competitors.

(Vaughn at 00:10:47) And so what you would find out is the web interface would only do the same things that you could do in the web interface of the competitor. And if you wanted to get into the advanced capabilities, suddenly the web interface would say, "You have an advanced configuration. If you save any more in the web interface, you're going to break it." So you would end up having to go get that guy out of the back room and send him back into the command line, the black foreboding window. Right? So, you know, look, the tools are continuously advancing, and they really address a significant portion of what the requirements set are in a lot of organizations. There's a lot of great stuff. But you've got to realize that you're either taking people who've already been trained as a classic developer and giving them a faster way to deploy, or you're going to be taking business people and really turning them into full, if not nearly full-time, para-programmers who will have to partner with developers to ultimately deploy and support their applications. And that's where I kind of get into one of the dirty little secrets of low-code and the promise of citizen development.

(Vaughn at 00:11:51) I've seen a lot of organizations—and I won't name them. There's some that we've come in who have had those expectations, have been disappointed by them, and are on round two or three trying to figure out how to address the need—where they've said it's been a boomerang. "We got this big license. We threw it out. We did training. We thought everybody was going to become a developer. And what we found is there were people who could do it. They were the people who had the capacity to become that para-programmer. But if they ever left, nobody else in their team could figure it out, and it boomeranged back to the IT department." So just as we were bragging about having empowered the organization to do it, here comes a manager back and says, "We lost Susie, and we need two more changes, and the only people who could quickly figure it out were developers."

(Vaughn at 00:12:30) And so it's not that the concept doesn't work at all. It's that if you look at it across time—18 to 36 months in the majority of these deployments—and we're a frog in the well. We only see a little bit of the sky from where we are, so we may be missing somebody out there that's been wildly successful at it. But in a lot of these scenarios, they're still happy with the application because they're still getting apps done faster than they were before, and the line is flowing faster at their door. But often they're disappointed with the concept that it was going to go out there and everybody in the building was going to become an app developer. And I think that's where no-code came along.

(Joel Beasley at 00:13:12) I want to ask you, though: Do you think the promise of everyone being able to be a developer with a low-code tool—do you think that promise is impossible, or do you think that with more improvements to the low-code platforms that are out there and the deployment strategies that are being used, that we could get there?

(Vaughn at 00:13:33) I think it's more of an expectations management problem than a technology problem. And what I mean by that is, I think that if people were sold that you're not going to become a citizen developer, but that we're going to make you a citizen collaborator in some of these scenarios—we're going to let you build interfaces very quickly the way you want them—I think that's realistic and true today. If we say we're going to let you create high-level data structures and, you know, snap out some very quick and simple mobile applications, I think that's actually true today. I think if you start looking at the idea that we're going to automate things that are going to move all over the building—that work, for instance, and that's my area of expertise, right? That's what we focus on at HighGear. But if we say, "Hey, we're going to take these things that are going to move all over the building, and we're going to let everybody create their own piece of it," the fact that you're in the low-code domain—you're still nearly as flexible as code—

(Vaughn at 00:14:29) and so that means that what somebody does in stage one, unconnected with what's going to happen in stage two, can't cross the gap. What I mean by that is, let's say you were trying to solve a problem for our customers, or a bank, and you want to let our customers make a request to move their funds from one account type to another. And so you're able to get to the data sources for our account types. You display them out there, but then you build something custom to allow them to determine what amounts they want changed. And so you get that request and you say, you know, "Victory. I've done digital transformation. They used to have to do a paper request or email us or call into our call center. Now they can go onto this form and do it."

(Vaughn at 00:15:01) But I'm in the next department, and I'm actually going to do those moves. And I've also created something so that you can request it from me internal to our big company. And while you called it "amount to be transferred one," "amount to be transferred two," I said "fund one change request." Now we might be able to map those things together, but this starts to get into the domain of needing that IT person, that data manager, to get in and say, "Okay, hold on. You called it this. He called it that. And by the way, you don't even have a match. You've got five fields over here. He's got a field that creates multiple instances, and we're going to have to figure out how to tie those things together." Now it can be done, but to the person who believed they were going to build something that was then going to integrate with the whole enterprise, there's this kind of disappointment, which is why I said I think it's expectations management versus technology.

(Vaughn at 00:15:57) The technology is solving problems. It's just not quite solving the big problem, which I think in some cases ends up better in kind of those no-code configurable buckets. But there's an important one in between in no-code. And, you know, I don't want to get ahead of you, but I'm kind of excited to jump into that as well. But anything else you want to talk about in low-code?

(Joel Beasley at 00:16:19) No, no. That makes sense. I do just want to clarify: Do you think that low-code can be improved so that you don't have to temper expectations like that?

(Vaughn at 00:16:31) Most certainly, and it will across time as it becomes no-code. But I think what's going to end up happening is that no-code is also likely—and by the way, everybody says this isn't going to happen, and it happens every time—when we go to build the Tower of Babel, we say there will be one ring to rule them all, right? You know, and I can hear that voice of whatever her name is from the Lord of the Rings: "And above all, CIOs desire to have on their resume that they have deployed the Power Platform, but they were deceived." You know? And I think my whole point on this is just, you know, we always have the dream that the new thing will allow us to centralize and consolidate everything. And what ends up happening, whether it's UNIX coming up and then fracturing, whether it's one ERP that's going to solve everybody's problems, but somehow it doesn't. And before you know it, there's 11,000 ERP choices that you can make out there.

(Vaughn at 00:17:31) And, you know, in each of these scenarios, it's because at the end of the day, there really is fracturing in the need and expectation set, the skill of each customer, what each customer brings to the table, the special requirements and challenges. You know, why would you want to build in raw capabilities in an application to handle the special needs of a special intelligence unit within the Department of Defense if they're not going to be a client? But if you do build that, you know, would somebody who never has to deal with that in a commercial entity appreciate the fact that they have to answer 23 security questions in order to get a field deployed on their form? So, you know, there is specialization that ends up happening once technology matures. And so I see the low-code vendors already on their way to becoming no-code vendors.

(Vaughn at 00:18:21) And I won't name any specifically, but, you know, anybody who's looking at this market at all will know that there are big low-code vendors who have really switched their claims quite confidently to "We are a no-code vendor." And when you dig into it, what they mean is kind of what I was just describing in that expectations management. We've got no-code interfaces for you to build an interface. We've got no-code interfaces for you to build a process diagram. But we've got low-code interfaces where you can get into the nuance details of how that's going to run, and then we've got code interfaces where you can deal with the really complicated parts that aren't available up there.

(Vaughn at 00:18:58) And I don't think that's necessarily bad. I think it's just the fact that, you know, we're trying to empower people to do complicated things. And so the choice that you've always got on the scale is: What am I willing to sacrifice in power in exchange for speed? And, you know, or what am I willing to sacrifice in flexibility for ease of use? And so I think it's impossible to say I'm going to not sacrifice any power, I'm not going to sacrifice any flexibility, but I'm still going to get the ease of use down to the point where Susie, the secretary, who's been with the company for three days, can start writing code to build a mobile platform for our customers to make requests. It, you know? And so I think that's why I say I really break this into a series of Venn diagram circles, right? There's code, which is maximum power, maximum flexibility.

(Vaughn at 00:19:50) But these days, with the low-code vendors being so good at what they do, why would you do that if you can solve the problem in low-code? So if you can solve the problem in low-code, you do it, and you just set the expectations correctly. And you say, I need my team of sort of no-code interface people with a data manager and a system thinker and somebody who's going to do governance to make sure everybody's fields will translate from that bank interface that you made for the customer to the back office interface for me to move their funds around. And if you put that team together, it just continues to get faster, and people are not disappointed with the results. I think no-code has been really interesting, and no-code is where you sacrifice even more flexibility and potentially some power for a higher ease of use and higher speed to delivery.

(Vaughn at 00:20:40) And this is where we're getting closer to the dream, but there's a challenge with it, right? This is the folks who I think are making the biggest claims of citizen development, and I think the folks who are even making the biggest inroads in terms of the concept of citizen development are in this category. But I had an interesting conversation with somebody at one of the Big Four less than a week ago. You know, we have a common client, one of the largest fund management platforms on the planet, and we were talking to him, and he said he was part of their practice or global practice for low- and no-code solutions.

(Vaughn at 00:21:16) And we got into this discussion of citizen development. And I, of course, wouldn't name his name. That would be impolite. And besides that, their lawyers would probably call me. But, you know, he admitted to me in that call that, you know, "Hey, I am part of the team that recommends, sells indirectly because they're a partner for one of the firms in our space, and deploys, configures, and deploys these solutions for people." And it was kind of a troubling moment for both of us when he said, "I've actually never seen it work where it stays outside the IT department," that boomerang thing that I was talking about, he saw. So I think, you know, the no-code vendors are often a place where people are creating prototype applications that get up and running really, really fast, and some of them make it the distance and survive in the enterprise. But oftentimes, if the key stakeholder who built it leaves, nobody can maintain it or change it. You're back to the problem you had of waiting in line for IT.

(Vaughn at 00:22:12) Now you're waiting in line for IT to figure out something that the business was supposed to be able to do. Or you want to integrate it with something else and you discover that you made limiting decisions along the way which make it difficult to do, and you end up having to spin up a team to reevaluate. And so there's this kind of excitement at the beginning of the process: We're going to get rid of having to pay these expensive developers a lot of money and give them Mountain Dew and pizza every time they ask for it. And we're going to get rid of that line at the door, and we're going to advance our office technically, and it's going to happen overnight.

(Vaughn at 00:22:44) And in reality, six months in, you begin to find that you're not hitting the traction that you wanted. The adoption is not there. It's hard for people who are not system thinkers to figure out how to deploy the thing fully. Eighteen months in, you've got some of these solutions that feel like they had a technology cap. There's only so far we can go because of the way we configured it in the beginning.

(Vaughn at 00:23:04) And you end up having to put the same kind of governance in with the no-code solutions that you've done with the low-code solutions, which is: How do I put the team together to, A, decide, does this belong in this platform? If it does, what decisions do we not want to make to make sure we don't constrain ourselves and hit a dead end? And what people do we need involved to make sure that if it does succeed, we've got it ready to be compatible with the rest of the org? And this is why I think actually the whole market is going to move to this next stage of what I would call purpose-built no-code applications. And so I don't think we're unique.

(Vaughn at 00:23:37) I imagine there's others like us out there in other categories. There may even be others out there who are tackling or succeeding at the same thing in our category. But specifically, what I mean by that is the same way the finance applications have matured to the point where you do expect—people don't call them no-code finance applications, but in fact, they are. There are visual tools for people to design the invoice for that company and the dashboard for the CFO and the routing protocol for approvals for large expenditures.

(Joel Beasley at 00:24:07) That's like standard in finance companies that the business analysts are expected to build these interfaces for the CFO and the invoice or the customer?

(Vaughn at 00:24:16) Yeah. Yes. And and by the way, there are often people who are reporting to IT who are doing these things in a lot of those implementations. But when you look at large-scale, medium-scale to large-scale finance applications, kind of finance back-office applications—yes, the expectation is there, and there are still vendors out there that are surviving not doing it. I don't know how, but that's not my problem to solve today. But the vast majority and certainly the leaders are offering and delivering those kinds of capabilities so that clients feel like they've got a high degree of power to be able to change things as they move forward. You know, they can do an acquisition of another company and make some changes and blend data. And a lot of these things are going to get into the IT realm of data management, but getting things set up so that they run the same way and their invoices look the same.

(Vaughn at 00:25:05) No, they all expect that analysts are going to be able to do this without writing any code. And so, you know, this is more complicated when you look at the problem HighGear solves, which is that we want to be able to move work across any discipline within an enterprise, any department within the enterprise, whether it's an energy company standing up, you know, 20,000-plus agreements for a pipeline that's going to cross, and every town mayor and county commissioner wants a piece of the action from them, and they've got to cross railroads, and that railroad wants an agreement they're not going to spill oil all over the tracks, you know, the rail's going to go off the track. There's a lot of things that they've got to track and do, and yet those things may go to attorneys to review and marketing people to determine if they're ready to release it and, you know, industrial people to actually implement it, environmental managers to figure out whether or not they've actually put the right controls down to make sure they don't squish fish when the trucks drive through the river to go put that next—I can't remember what they're called, the things that hold the wires up that you see out in the forest where they cut the wood through.

(Vaughn at 00:26:02) But, you know, all of these different pieces that need to get done, you know, are the kinds of things that people will end up putting into HighGear. It's a workflow system. It's for making sure that work flows through the many steps of a business's process to get done. So we have a bigger problem to solve in terms of what we're letting the analyst do, but it's still a definable problem where we're not asking them to create things from scratch in terms of functionality. We're not asking them to think of how should workflow function. We're not asking them to think of what should the presentation of work look like. We don't ask them to think of how would you handle dividing one department's work from another so they don't see it until they should. How do you make sure they should see it when they should?

(Vaughn at 00:26:47) Right? Those are things that we've built in in terms of transactional best practices the same way in that finance model that I was talking about. We don't expect the business analyst to write a transactional engine with those configuration tools. They're using the no-code tools in there to configure the behavior of those transactional components that already bring the best practices, right?

(Vaughn at 00:27:08) So this is where I think the whole market is going to go in that I think there are going to continue to be emergent special-purpose applications, but that the whole market is going to be expected to deliver them in a no-code format. And I think when that happens, you're going to see more consolidation. I think big companies will buy small companies that are really good at the no-code capabilities and blend them in. But I also think that, you know, small companies may become big companies because of providing those kinds of services. Because instead of me having to look at 1,100 ERPs and decide which one fits us, as more and more of that power becomes configurable in each implementation, the company says, "I've only really got to look at 10 or 20 of these and make sure they've got the flexibility I need, because they will work for all those different use cases I've got."

(Vaughn at 00:27:59) Our warehouse, our manufacturing environment, our distribution center, our sales team, because we've got that configuration capability. And so I'm going to just take a pause there and say, you know, that's where I think the dream is going to come true. We are going to get to the point where business stakeholders are building their own solutions. I'm just skeptical about the idea that we're going to take business stakeholders who are not systems thinkers and are not trained with some classic IT, we're going to let them loose into something that gives them nearly the equivalent power of writing code from scratch and hope that they don't do things that tie the organization's feet and cause them to fall before they get to the finish line.

(Vaughn at 00:28:39) That's what I'm skeptical of. And I think the industry has to move towards what business people want, which is: We want high control, but we also want high assurances that you've built the best practices for us, and we're just using the tools to deploy those best practices against our problems.

(Joel Beasley at 00:28:57) So I want to ask for a little bit of clarification on the energy company example. So how does it work without implementing a no-code configurable software when they have to go through all of the different stakeholders, the local governments that need to approve, the railroad that needs to approve, the environmental approvals that need to be made? What is actually happening without a no-code configurable software, and then what is the no-code enabling?

(Vaughn at 00:29:32) Great, great question. So let's just picture for a minute the reality we've run into in a number of scenarios in companies like that. And I'll tell you that if anybody goes and looks at our website and sees energy companies out there, give them credit. They've already figured out how to do this right. That's why they're letting us use their logo. The ones that are still figuring it out won't let us put our logo or their logo up there yet. But we've run into energy companies where, quite frankly, multibillion-dollar projects were being run by sticky notes and spreadsheets and emails and shared documents. And people would say, you know, "Well, through Google Docs, we can all get into the same spreadsheet. We can update where we are, and has this one moved through legal?" and, you know. But the problem that you would run into is if you had somebody in legal updating something at the same time as somebody in marketing, the last person won.

(Vaughn at 00:30:26) And a lot of people argue that, "Hey, with, you know, Google Docs and Office, you've got an audit trail." Okay, if anybody looks at the audit trail. What—and it doesn't assure that if that row sits there and nobody's looked at it for a year, that it comes to anybody's attention, you know? So these best practices are all about escalation and monitoring and management and the creation of visibility. So without a no-code solution, there's really two things that we see, which is, you know, no maturity where people are just doing workarounds all over the place. And that's how nature works. We start out as a small company.

(Vaughn at 00:31:00) You know, think of financial services, right? We start out as a small wealth management company. We get our first customer. We high-five each other. We put his file into our one filing cabinet. Everybody knows where it is. And, you know, 11 years later, 3,000 customers on board, nobody can find that file. You've got to have systems in place. And, you know, the person who sells them the account is no longer the same person doing the onboarding or managing their funds as it was when it was just a business of one.

(Vaughn at 00:31:28) And when you're at 5,000 employees, now you specialize down to, you know, somebody is going through the legal part. Somebody is onboarding the customer from the customer service perspective. Somebody else is allocating their funds into funds. And all of these things have broken up in the way nature works, just like in a coral reef. You know, you've got something that comes along that deposited a little bit of rock. Something else comes along and says, hey, that's a good place for me as a little anemone to hook up. Some plants start to develop there, and now some more of the little things that make rock show up. And before you know it, you've got this growing ecosystem. Business is the same way. We start out with what we know well and what we do well, and we put workarounds in place as we have to.

(Vaughn at 00:32:09) As we scale out of something and it starts to be broken, we put it in. But those workarounds are not done systemically. They're not done by tech experts. They're done by people who go, wow, we used to be doing this by calling each other or having a weekly meeting. It's not gonna work anymore. Let's start agreeing. We'll do an email. Let's have a Word doc that we all update. And they're gonna work with these things.

(Vaughn at 00:32:29) So the two pathways that we see is that they either are still stuck in that at a painful point, or that they've tried to custom homegrow something. Whether it's with code or low code, we often see organizations make one, maybe even two attempts at growing these things internally because they'll kind of look out at the marketplace and say we couldn't find anything with the flexibility or the security that we needed, so we're gonna try to grow it from scratch. And the challenge that I often see, the same business analyst that we empower are kind of the middlemen or middle ladies in these scenarios. You know, what happens is they come in and they meet with the business stakeholders who say, hey, we've got this problem. We're emailing people, and, you know, I'm sending everything out, but we never realized that this guy never finished the agreement with that railroad. And now here, the construction crew's out there ready to put the pipeline over the railroad 18 feet, you know, like we thought we'd agreed to, but there's no agreement, and they won't let us do the work. And so they say to the business analyst, you've gotta give us something that gives us a dashboard that lets us put in all the requests for all the agreements and commitments that we're gonna need for this massive pipeline, and we need a dashboard where we can, A, see all of them, but B, drill down to just the ones that are overdue, drill down to the ones that are within five days of being due, drill down to the ones that don't have legal approval yet. And so somebody delivers that for them. And then phase two, they go, you know, the legal team has said they're willing to get into this thing. They'd like to just filter it down and work on the things in here that are waiting for legal. And so they do that. And then legal says, wait a minute, wait a minute, we don't wanna see everything that's waiting for legal because some of it's not actually ready for us yet, right? And so they want more filters. And so you typically will organically, via a whole series of workarounds done by business person telling business analyst who writes it down and communicates it to a developer—developer says, hold on, I gotta wait until I'm done with this project I'm on. Then I come over, I put some time on it, I deliver it. Business analyst brings it back to business person who often, in one or two rounds, says, oops, that's not what I was looking for, right? And so you repeat the process a couple of times until you get what you're looking for. And so business analysts are frustrated with that because they feel like they're frustrating developers with continuously emerging requirements. The developers are frustrated because they don't feel like they're getting clear requirements the first or second time. The business people are frustrated because they're like, this business analyst, doesn't she get what I'm asking for? You know, why does she keep coming back with something different? But it's like playing telephone. And so when we show a lot of these business analysts that they can configure this application themselves right in front of the business stakeholders and say, well, wait a minute, wait a minute, you want the form to look like this? You want the list to look like this? What else are we gonna need? That's great. But the exciting part to them is when they realize that part two, when legal comes back and says, hey, I do wanna see the things that are awaiting legal, but only if there's a document attached for me to review. So can you build me a dashboard where I see everything that's flowing through this process as long as it's awaiting legal and has a document attached? And when they realize that they can make those changes and make those incremental improvements in moments, that's really where the lights come on for them. And by the way, we're not a threat to IT and the line at IT's door because we're not an app factory. We're not building that mobile app for somebody who wants to change their accounts. We may end up handling the work when it comes back in. But because we're going to facilitate standardized naming, controlled permissions, hierarchical permissions across the organizations, workflow, routing, escalation, visualization, presentation, because all of the things are gonna happen, somebody can take the low code app and build the thing where the customer requests to—take our energy example. Maybe they put a sign up on everything. Says if you ever see a leak here, go to this URL, or maybe it's a QR code. And they've got a little form to say where they are, and it's geotagging the info and saying, would you please take a picture and upload it? Well, that's gonna come in through a simple integration into a back office process.

(Vaughn at 00:36:30) Now that business analyst doesn't know how to do that integration. He's gonna still have to go talk to the IT people who will decide, could I do it with a low code app, or do we need to write this from scratch with code? Maybe it's even a no code app. Maybe it's something in the Microsoft Power Platform, and they say, hey, I'm gonna teach you how to do this yourself. There's something really cool you could do to put a form up and just come back to me when it's done and you got it the way you want it, and I'll help you tie that in with HighGear's APIs and Microsoft's APIs to take that form out there and shove it right into HighGear and have it run through the whole back office process with all that automated escalation and routing. We're gonna get it to legal at the right time. We're gonna make sure somebody can't try to push it to legal without attaching the document. All of those kinds of things are what happened in a no code world.

(Vaughn at 00:37:12) So it's not just that we're gonna get the solution up faster, because we're not necessarily gonna be faster on day one than a no code app. If I write something from scratch in no code, it's gonna be quick. If I write it from scratch in—they're not writing from scratch. Let me give a better choice of words here. If I build a no code application using a standard no code app factory, or if I build a no code workflow application using a no code workflow platform, both are going to be very quick. But because this one already has 80 to 90% of the logic done for me, and the only thing I'm doing is adding new behaviors and escalation rules and new form fields, the incremental changes to make the solution keep up with the business are not only going to be faster, but they're going to stay out there in the field. You know, again, we're not the only folks who are doing this. Like I said, my finance model example, these things don't end up back in the IT department if they train analysts how to do it. Likewise, we're one of the first vendors in the no code field because we've really gotten into this no code configurable piece where the vast majority of our solutions are entirely customer managed by non-IT people. 90% of our customers do 100% of their own implementation, and 70% of those customers are analysts, not IT people. And we do have IT people who love our software and get involved in it and collaborate on it. So some of our customers do have IT people blended in, but it's because of their strategy or their decisions, not because of a requirement. And that's where I think this whole thing is going. I think people are gonna have to look at it. It's not, do I do low code or no code? Do I do no code or configurable no code? Do I do no code or code? No. The reality is that organizations that are on the leading edge of this are saying, I need all of them, right? But I need to measure them and use them wisely. I don't need all of everything all of them can sell me. I don't need a universal license for a low code platform. I need a limited license for the folks who are actually likely to succeed with it, but I just wanna make sure that everybody can use the apps that we do from it. I don't need a no code license for everybody because even those people have to be systemic thinkers, but they're probably never gonna write any code. And I need those. I need those even if I've got a no code configurable application because this one is purpose built and isn't going to write my non-purpose built requirement over here. And so I think that's where the future is going. And so back to your energy question, you know, what we see is that people either migrate towards building things themselves, languishing in pain, or finding solutions that actually can keep up with the speed of business and regulation and new requirements.

(Joel Beasley at 00:39:54) So for the no code configurable application to be able to tie back into the back end of the business, what is the setup like upfront when someone adopts a solution like HighGear? You're giving me this example of the business analyst being able to just spin up the software that can take all the requests from the construction workers for the permits that they need and then also pass that off to legal. But I imagine that has to be plugged into the back end of the—I'm not sure how to articulate it.

(Vaughn at 00:40:26) Yeah, great. Yeah. I know. I get what you—it's really the integrating it into your other enterprise technology, right?

(Joel Beasley at 00:40:31) Yeah.

(Vaughn at 00:40:31) So let me give you a couple of answers to that. You know, and people in the market are approaching this in different ways, and I think there's a lot of good ways to address this. I'm gonna mainly tell you about ours. One of the things that we've done is we've integrated with Zapier, which is an integration bridge. It's an open integration bridge. So, you know, you can build Zaps in there. And what is that? I don't wanna sound like an advertisement for them, but I will for a minute anyway. You know, so even if you don't use a solution like HighGear, you can still get an account with Zapier, and you could say, hey, whenever I receive an email from my boss, I wanna send it through this other application that can do sentiment analysis. By the way, you could do the same thing with the Power Platform, right? So maybe you could say, if I get an email through Office 365, I wanna go figure out how to use that same kind of component in the Power Platform. Zapier just gives you the ability to get not just to Microsoft applications, but to a whole universe of thousands of applications that do special purpose things. So you could say, I wanna do sentiment analysis. And if this email is from my boss and she looks angry, then I wanted to text my phone and go, you better go run back over to your computer, act like you were working, and call your boss, right? That would be a simple Zap. I might do a multi-step Zap where I could say, if anybody ever emails me a file with an attachment, I wanna send it to Zapier. I wanna have it do an OCR on the attachment. If it includes the word new application, then I want to stick it into my OneDrive folder and send me an email with a link to it saying I've got a new application. And so these are the kinds of mini automations that you can do at a high level. And so, you know, we empower our business analysts. And by the way, you can do all that without any code. That's why we've partnered with them. We look at them as like-minded. They're trying to empower people who don't wanna have to write code. They're not doing everything. They're not doing deep integrations. Microsoft Dynamics offers connectors out there, but you're not gonna be able to do everything you could do with their API or advanced programmer's interface, but you're gonna be able to do the most common things. Create a new invoice, pull up a customer record, see what the status of their payments are. There are simple things like that that you'll have to do an authenticated connection to get those things, but you can get the same kinds of things you would get out of the app, but sort of orchestrate them to happen. So now I could say, I wanna take that new application, but if it's from a customer who hasn't paid their bill, I don't wanna send a notification. I'll work on that tomorrow. I don't need to jump on that right away. So, you know, it's really being able to do those kinds of things through a no code tool in the Zapier space. That was kind of answer one for us, where if somebody says, I just need to take something when we get to the end of this and have it create an invoice in our finance system. If you're doing 100 of those a month, Zapier is probably a perfect solution, and you could get it done in an hour. We've had people do Salesforce integrations in under 15 minutes where they've said, hey, when I sell something in Salesforce, I wanna create a workflow in HighGear to do all the back office work to fulfill that new order. But if you're doing thousands or hundreds of thousands or millions a day or something, right, you're probably gonna wanna go use our API so you're not paying transactional fees through this cool new no code application out there, which has a cost. You can write the code yourself. You could do that with code or low code. I don't think you could do it with no code, but you could do it with code or low code in a way that would not have any transactional fees for you.

(Vaughn at 00:43:52) But part of it, you asked getting started, what do you have to think about? So let me finish the thought though nonetheless. The second option is that we do have very rich APIs. Anything a human being can do in the HighGear application can be done as well through an API call, which is authenticated. So it would look like Adam did it or Vaughn did it even if we came in through another application or an integration. The third way is that there's experience integration, and this is something that's becoming increasingly popular, of course, not just with us. The same thing with APIs. Most good companies in any of these sectors from low code and no code and the configurable no code space are offering good APIs. That's kind of a staple you should expect at this point. But interface integration or mashups is the ability to say, hey, I've got the customer's address. I'd really love to be able to show that in Google Maps in a pop-up window without having to recreate Google Maps functionality. People are used to doing that on the web. You know, you go look at your favorite restaurant and their address shows up in there, but it's from Google. If you click on it, you're in Google, right? We give people the ability to do the same kinds of integrations without having to write code by just sort of stitching the two applications together and saying the key thing that I wanna stitch them together with is, here I have a tracking number on my HighGear work record. And UPS, if I give them a tracking number, will show me where that package is. And I just wanna display that result in a window to my worker who's getting a question from somebody saying, hey, I never received my package, where is it? And you can say, ah, looks like, you know, just by pulling it up in the same system they're already in, not having to go to UPS's website. That's a simple example of interface integration. And all of these things really depend on you thinking about standardization of data. And this is where no code configurable applications actually begin to pull away in terms of terrific value for an organization. Because when you get into the reusability and best practices, you're not building discrete apps, right? Like, I joke around sometimes, I'm not negative on no code or low code app factories. They serve their purpose.

(Vaughn at 00:45:53) They're very powerful, and we partner with them a lot. But if somebody brings it in and doesn't think about what's going to happen, it's like starting up a rabbit farm. You come out and there's more rabbits than you thought there would be, and then there's even more rabbits, right? And so each of those apps being a discrete rabbit out there in the rabbit farm has not necessarily been thought of in a coherent way to connect to the other ones.

(Vaughn at 00:46:14) And so as you begin to say, "Okay, but I need this one to talk to this one," this is where some of the challenges come in without that guidance from IT. Without IT really being a partner in low code or no code applications, you end up with a lot of rabbits. And so in the configurable no code space, well, let's go back to the finance example.

(Vaughn at 00:46:34) When we create an invoice, we know what that is. That invoice is an income record. It is a credit to our accounts receivable. So those kinds of things are known quantities. It's really the same way in that we're creating known quantities.

(Vaughn at 00:46:51) When somebody's creating a new work record, they don't have to think about how to objectify that. It's a work record. And so we could change that work record that is with a compliance person who needs to make sure we've done all the government filing to get this pipeline section up, and now I'm going to hand it over to legal to review the agreements we've got before we sign them and send them back to the railroad company or the small town mayor or whatever else. But it's still work. So all we're going to do is take that work that was in this form and move it over to this presentation layer and then over to this presentation layer. And so the advantage that purpose-built no code configurable applications are going to have is that people don't have to think all the way down the stack to, "Well, what are the implications of me creating another field called amount? Might somebody have created another field called AMT period in another one of those rabbits? Might somebody else have called it billable AMT, right?" And so you've got the idea of the reusability of these pieces and the centrality of the object. This is why document management is kind of the same thing. So to give another example, document management is a more mature space that is typically configurable via no code. And the reason is everybody knows what's happening.

(Vaughn at 00:48:10) You have a document. The document is the center of the universe. We handle documents as one of our artifacts or assets, but the center of our universe is work, and everybody knows what that object is going to be all the way through. It's going to be work. It could be a project. It could be a subtask. Well, document management was the same way. You have a document that comes in that might need to go through 15 steps to get generated, two to get approved, and then a final publication step. But at the end of the day, everybody knows what it is while it moves through. It's a document. So it made it easier for people who are not programmers. They don't have to think about the structure of a document or what this thing is going to become when it grows up. It's going to become a document. It was a document when it started. I'm just configuring the process and the behavior of the application and who it should go to and who it should be presented to, how they should see it, what parts they should be able to contribute to as I build that flow up. So we've really taken those same kinds of concepts and just moved it over to the large-scale management of work.

(Joel Beasley at 00:49:07) That makes a ton of sense. I feel like I'm connecting the dots now that having a configurable application just automates the stack all the way down rather than having to have each person that wants to make their own part of the application make their own object names and what you're talking about, the standardization of data that can just ruin everything very quickly if you're having different people make disjointed applications and try to put them together.

(Vaughn at 00:49:40) That's right. And you've got this consolidated or centralized presentation where everybody's going to the same interface. You can move something from one stage to another stage if another group says, "Hey, we'll jump into that as well." You're not having to think it up from scratch and create it from scratch. You're just adding a new presentation of the same bits of work already flowing through. So again, not making it specific to us and wanting to add value to the discussion in general, right? I think this is where the industry is moving in that all of these competitors, all of these different categories are still going to have value proposition and exist. But I think what's going to happen is if we want to get to really fulfilling the dream of citizen development, we're going to point the citizens at the purpose-built application, and we're still going to have IT partner with them for the governance and say, "Hey, we've got to control the authentication. You can't just be letting anybody in this thing. We've got 3,000 employees around here. We're handling billions or trillions of dollars in our funds. We've got to put some rules around this, but we want those rules to be simple and quick so that all you need to think about is what do I want the form to look like? Who do I want it to flow to? And how do I want to present the data about status?"

(Vaughn at 00:50:49) The same way all the way back to that finance metaphor. I don't have to be afraid that I'm giving an analyst the power to configure the invoice unless I'm afraid of what they'll make the invoice look like, because that's not giving them the power to rewrite the way the application runs or to expose data to somebody that shouldn't see it. And I think that's where we're really going to get to that dream being fulfilled to where a CIO is going to hand the keys to business stakeholders. I don't ever believe they're going to hand the keys to everybody in the building. I don't think that's going to happen, but they're going to find the savvy Susies, the smart Sams in their team who everybody already goes to to say, "I can't print," and "How do you make that cool graph in Excel?" And they're going to show them, "Hey, I've got this tool where you can take your subject matter expertise about the way we do our part of onboarding new clients in our big fund management operation, and you're going to be able to build the forms. You're going to be able to build the dashboards. You're going to be able to build the work list. You're going to be able to control who can see them within our team, and I don't have to worry that that's exposing anything to you about what HR is also doing in the tool that you should never see." That's where they're going to hand those keys out and not have them come flying back in with a, "Hey, we can't keep this thing working, and we need some changes, and Susie left." That's my thinking on this in summary.

(Joel Beasley at 00:52:14) Gotcha. Well, Vaughn, I feel like you've expanded my mind quite a bit here. Thank you for that. Is there anything that you want to make sure we touch on that we didn't get to yet before we wrap up today?

(Vaughn at 00:52:27) Well, I've had a fun conversation with you. I definitely appreciate that. I definitely would love to know what kind of microphone you have because you've got that perfect FM radio sound. I know you said you've got an audio background, and I've got some kids that are really into audio, and they're going to want to know what kind of—so what kind of microphone do you have?

(Joel Beasley at 00:52:46) Yeah. This is a Shure SM7B. It's actually a remake. It's been popularized in podcasting because Joe Rogan uses it, but it's been a really popular mic for a long time. It's a remake of the one that Michael Jackson used, the Shure SM7. So today, it's the SM7B. Don't know why they put the B on the end of it.

(Vaughn at 00:53:05) To let you know it's going to cost you more. Yeah, that's right. I had a Shure microphone when I was a young guy and imagined myself—actually, you know what? I'm not even going to tell that story. I'll just leave that alone. But yeah, I'm familiar with the brand. All right. Well, no, I don't really have anything else to cover. I really appreciate you giving me the opportunity to expand out on this topic because quite frankly, I think a lot of the market is confused. And by the way, I think I'm doing a favor to my friends in low code and no code who might consider us an alternative. I don't think we are. I think there's a place for all of us in the enterprise, and I think, like I said, the most forward-looking and progressive acting enterprises that we serve are bringing all of these applications in but being very careful and judicious about where they deploy them. Citizen development, I'm seeing as successful in the no code configurable space. I'm seeing developers become accelerated in the low code space. I'm seeing para-programmers do really interesting things in the no code space without blowing up. I'm not seeing business people be super successful over the long term in the no code or low code or code space. And I don't think that it's impossible, but I think it's going to be the emergence of more purpose-built applications, minimizing what those folks are doing. And I think the way we've covered that today, hopefully, you said it expanded your mind. Hopefully, it helps other people, including my competitors, recognize this is a reality of future positioning. It's what we're seeing resonate with customers as well, and we're just excited to see the whole industry continue to emerge, and I appreciate the opportunity to talk to you about it today.

(Joel Beasley at 00:54:43) 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.