Q&A with Catalytic CEO Sean Chou about one of 2021's top trends: Upskilling employees with no-code tools
One of the largest barriers for companies to digitize operations—especially at the speed required to adapt to changes in 2020—is the shortage of technical talent in their workforce, or the length of time traditional software development takes.
To meet this need, one of 2021’s top digital trends in companies’ operations strategies is upskilling employees to become citizen developers on their line-of-business teams. This means training and empowering tech-savvy employees to use no-code tools so they can create new digital apps and automated workflows for the everyday business challenges they know best.
With a combination of upskilling, low-code/no-code tools and a governance model to allow all of it to work together, companies can have all the resources they need to rapidly produce an unlimited number of solutions, like digital apps or automated workflows, built by business people. With each one, the company can operate more efficiently than before and bring innovation to the market faster.
Recently, Catalytic co-founder and CEO Sean Chou sat down with Scott Taylor, The Data Whisperer, to talk about this trend for an episode of the EM360 podcast. In the excerpt below, Chou clarifies some of these definitions and explores some of the ways employees, IT and company leadership teams are coming together to achieve digital goals.
Can you help demystify this notion of low-code and no-code development, and give us a sense of what some of the positives and negatives are? First, how do you define low-code and no-code?
I think that the past few years we've been kind of wrestling with this as a concept within the software community. But it really comes to the front today. And I think it will continue to really explode over the next decade or so.
The way I think about code vs. low-code vs. no-code is as a continuum, as opposed to things that are mutually exclusive. So the traditional view of software developers is just squarely in the bucket of code: people who are trained in computer science and understand at a very deep level how code works.
They understand how it's interacting at the hardware level. They are very familiar with traditional software life cycle development and an amazing skillset. But in the effort of, “How do we expand the people who can help with software developement?,” we start thinking about low-code.
With low code, at least our definition, is taking a technical business user who has become comfortable with scripts. And so they may have started as the Excel hacker within their company. And then they started looking at how to go beyond just really complex formulas. And they're starting to use even things like VBA within their Excel sheet. Or maybe they were a system admin in Salesforce and they started writing some workflows. So, once someone starts developing that set of skills, that largely is around script, then we really think of them as low-code.
"They're not afraid to dig in. They're technical, but not necessarily scripters, and definitely not coders."
And then the final category for us is really around no-code. So you have technical users, again, maybe that Excel hacker who still aren't really working with any sort of scripting language, but they're just really comfortable with all the different complexity, if/then conditions, and the business logic that exists. And let's say they use a more complex spreadsheet. That's kind of the no-code demographic people who are technical. They're not afraid to dig in. They probably have a really good base of experience building these complex Excel spreadsheets, maybe a Microsoft Access-style database on a more modern platform. They built something out in Airtable, Salesforce or something like that. So they're technical, but not necessarily scripters, and definitely not coders.
So no-code is bringing that capability to them so they can begin to really focus more on the creative side?
I think it's bringing a technical capability to people who are not necessarily focused entirely on development. So, to your point about the creative side: imagine taking your folks who are creative problem-solvers, or taking your folks who are business analysts, or taking your folks who are really crunching numbers, and broadening their capabilities, like essentially giving them a new sort of superpower.
And if we just stick with that “creative side” analogy a little bit more...When Photoshop was introduced, like pre-Photoshop, design was done very manually. Post-Photoshop, things are done very differently and the capabilities and the speed of the things that are produced now with Photoshop and other visual imaging programs are amazing. So it was really the introduction of a new technical capability that created this sort of explosive power. No-code is about providing that same sort of thing to, you know, a non-developer audience.
So I ran across this quote in social somewhere: Programming is 10% writing code and 90% figuring out why it doesn't work. So I'm assuming no-code begins to change that dynamic.
That's funny, I think there's actually a lot of truth in that. Part of the dynamic that you see with the traditional software development life cycle is this constant back-and-forth between the programmers who have the technical know-how and with the business functions who have an understanding of the business requirements. This is a constant iterative approach that creates a lot of challenges. If you're looking at traditional software, it can have very long timelines, timelines that exceed the rate of change in businesses because they are changing very fast—especially with the pandemic—but even pre pandemic.
"The rate of change and consumer expectations has gotten faster and faster."
The rate of change and consumer expectations has gotten faster and faster. So you have these two different groups of people who are passing information back and forth iterating, but they're on two fundamentally different timelines and that's going to create a massive problem. It’s why you always hear about scope creep, incorrect requirements...So one of the huge advantages of putting capabilities directly within the business functions’ hands is that you can cut out that loop or back-and-forth.
With a platform that is focused on low-code and no-code, you also accelerate the timelines, so that instead of having a traditional timeline that's longer, you have a platform that's really amenable to hitting those quick iterative sort of cycles that the business community really needs.
I'd love your thoughts on the notion of sponsorship. How can leaders from the technical and business sides enable a collaborative program?
We see both where we've initially gotten the attention of the technical sponsors, and they're looking for further business sponsorship. We’ve also seen the reverse where we have a business sponsor and they're looking for the technical team’s sponsorship. But to have a successful citizen developer program, the business and technology sides both must be synced up to a point of co-sponsorship.
For a long time we've had business applications being developed in a silo. A lot of times they're just done on someone's desktop, like the Excel spreadsheet. So the business side of the house has been creating applications with this kind of mix of email and Excel spreadsheets for a long time.
"A staggeringly large number or percentage of businesses are actually still run in Excel and email."
I heard something that's like a staggeringly large number or percentage of businesses are actually still run in Excel and email. That's really problematic because it has no visibility that, and they don't know what's happening. If someone leaves the company and doesn't transition that spreadsheet over correctly, it could all be lost. A huge percentage of business is actually run in this really fragile manner like this.
So co-sponsorship is really important for a citizen developer program to have so that they can ensure these business apps are created in a safe way.
We'll start a lot of times with that technology group. And the first thing that they have to do is of course, vet the technology and build conviction, but that's typically not that challenging. The next thing they have to do is seek out that business sponsorship. That usually means getting a good problem-solution match with a no-code platform.
"It's not a question of, Do you have this problem or not? It's, Do you have this class of problems? Do you have a lot of inefficiencies within these particular areas?"
It is a platform, so it's not a point solution. It's not a question of: Do you have this problem or not? It's: Do you have this class of problems? Do you have a lot of inefficiencies within these particular areas? If that's a yes, then the next question is the very first use case. And once you overcome that first use case and find that good initial business problem-solution match, the use case queue typically fills up really quickly after that.
In the reverse, if we get a business sponsor who really understands the platform and feels a problem, how do they get the technology sponsorship? Because when citizen developers from the business are building things on a no-code platform, sometimes it can actually involve working with IT systems and data structures.
This is where you want to make sure you have that technology stewardship and governance. In a lot of those cases, it’s less about seeking sponsorship and more about seeking authorization and approval and proving that it fits soundly within the overall technology structure and the architecture of that company. It meets all of their data security requirements that meets all of their compliance requirements.
Both are very different kinds of processes, but both very essential.