On this episode of the podcast, we speak to Alex Zekoff and Dan Parsons. Alex and Dan are the co-founders of Thoughtful Automation.
Dan Parsons, Mark Percival, Brent Sanders, Alex Zekoff
Brent Sanders 00:06
So today we have Alex and Dan from thoughtful automation with us. Thoughtful automation is a company that actually came across my radar. What a couple weeks ago with a press release slash case study that was featured by the folks at rebel Corp. So what appeared to be a new style of automation consultancy? And you guys tell me if I have it right? Or have it wrong. And we'll let you guys introduce and tell us a little bit more about the company. But the interesting thing was, it was very similar, I think, to what Mark and I see sort of the future of automation. The future of our future of RPA is this, like, open source sort of democratization of RPA. So welcome to the podcast, I wanted to get the story of what thoughtful automation is, as well as your backstory. So I'll leave it to you who wants to start first. Maybe tell us, you know, what was the founding story of the company and a little bit of background around it?
Alex Zekoff 01:05
Yeah, I'll kick things off. Brent, appreciate the warm introduction. My name is Alex Zekoff, the CEO and co founder of Thoughtful Automation. And I'll let Dan introduce themselves after I kind of kick off the Genesis story. Because actually, it was a I went into thought was a solo founder. And I realized this was way too big of an opportunity to do alone. So brought Dan in pretty quickly after I realized I was a bit in over my head with how big this opportunity is. So I actually come from a big four, implementation kind of tech consulting background. And I've been doing this for several years at fortune 50 customers, and seeing just firsthand and you know, in the trenches, what was working and what wasn't. And I had just graduated from business school with an entrepreneurial focus on the west coast. And so I basically left that mindset of business school with like this entrepreneurship kind of problem solving Lean Startup methodology framework. And I went back to my tech consulting firm, and got into RPA, and I was I just had this lens of, there's an immense amount of value here. This is the future of how we think computers and bots are going to operate. And yet, I just don't see the value being derived after these bots are being deployed, I saw a huge problem of bots being deployed into production, and then failing, and really like 80% failure rates and a lot of the bots that we deployed into some of these fortune 50 customers. And so I said, that's the real problem to solve is how do we keep bots adding value consistently and sustainably. So, I left my previous firm, I bought thoughtful automation comm for $12. I just liked the name. And I was like, Alright, cool. No one's really maybe thinking about automation thoughtfully and about outcomes and about value and all those things. And from there, it just, it just kind of went into our model of really focusing on our customers focusing on value, and trying to really understand how can we price our automation so that our customers can achieve value in three to six months versus three to six years of standing up and internal RPA capability and building overhead and then to reduce overhead. And so yeah, and now we're here we are, it's been a crazy year, as you know, in the startup world of like, from zero to six account enterprise accounts very quickly. We're hiring people. And I love Dan shooting here too, because that's where, you know, he's coming. And really getting us that, that operations, mindset and huge value out there.
Dan Parsons 03:43
Yeah, so Alex, and I forgot to mention that we actually met for the first time when we were in college. I was at University of Cincinnati, and he was at University of Miami in Ohio. And ironically, like one of my college buddies was also one of his best friends from high school. So we met just in a just like a random, you know, apartment party or whatever. And that's kind of where I party. That's like, where the seed, I think, like our relationship started. And then when Alex was out in California, going to Berkeley for getting his MBA, I'd spent eight years of my previous, you know, his career in Chicago, where our top automations actually my third startup, so I just got off the tail end of selling my last company, which was a 50 person consultancy, so I kind of been through, you know, the, the founding and growth of like, that type of work and the enterprise software space. So I naturally hit up Alex, but I moved out to the Bay Area, just you know, I didn't have a big network out here. And so we started just hanging out just being you know, just like buddies are going to concerts and stuff. So Alex got started with automation. You know, I was an early advisor and investor and just like really, you know, I was just one to play. Bet on Alex I just knew, like, Alex had, like, I talked to a ton of founders in my previous world, just through my like advising and investing world. And like I knew, whatever it was, I figured, like Alex is the guy to figure something out. So that's kind of like, I think the genesis of like, how our professional relationship started. And then you know, that advising slowly grew into more, you know, more time spent more time spent, and like, you know, I think I think then just naturally the vision for, you know, where we wanted the company to go, and how we want to help organizations and people do the best work of their lives. And that became like, kind of our core mission, you know, was like, was really the really exciting part. And then I think what Alex kind of mentioned, his big insight was doing the top four implementations around, like, the major problem isn't like how to build a bot. The major problem is, how do we have a long term value driving successful bought program at scale for, like, really hard, complex enterprise problems? So I think that that's where we're spending a lot of our time and energy is what are the tools that we can be building? What are the frameworks and technologies that we can be using? Who's the talent, the team that we need to be cultivating? So we can go to customers and really offer that long term value proposition and say, Hey, we're not going to help you stand up like an internal program. So you can build a bot, ship it, and then it's your problem? It's gonna we want to come in and say, how do we help you drive a long term program, that's something that's repeatable, and that's in that you can scale, you know, start small and scale within the organization, and really allow your people to get out from doing the crappy work, and get into doing the like, the fun creative stuff that makes humans thrive?
Brent Sanders 06:41
Sure, yeah. It's a great story. So Alex, as you mentioned, you got exposure at I'm assuming some one of the big consulting firms to RPA. Like, how is that different moving into your own? firm? Like, obviously, there's, I just assumed, you know, when I think of the Big Four, I think of like, the McKinsey is the Deloitte to the world. And you're coming in as part of a large digital transformation. RPA is just one component of that. Is that fairly accurate?
Alex Zekoff 07:10
Yeah, absolutely. There's obviously a lot of initiatives that companies when they come in, and coming from my previous experience, you know, our firm had seven different projects going on the same time at that same customer and rk was just one of those value add projects within like a massive consulting engagement at that customer. And so, I had actually been at that client when I was 22 years old, funny story about this, and I helped build their SAP instance. So I started in SAP technology implementation work, help train users to like run transaction codes in SAP, I was ordered to cash in so like, do one for all US SAP nerds out there. And so basically, did that. And then like, 10 years later, I rolled on to the same client, but in the nrpa capacity, and I was literally creating bots to automate out like people that I trained to use those same t codes and do 10 years later. So within 10 years, I have seen a full automation cycle of like paper billing and shipping receiving to like bots, that automated the system that automated that paper.
Brent Sanders 08:16
Yeah, that's cool. I mean, you hear about a lot of the commentary that you were seeing, at least online with various people, and some people that have been on the podcast are just saying that, like RPA is sort of GRP 2.0. It's like, we were just trying to get the pen and paper done. Okay, we've accomplished that now, how do we now everything's electronic? There's a way to optimize that even further. And this is sort of the next level there. So, you know, coming from that background into a startup, how has it been? Like, it's just a different? It seems like it's a different pitch, different frame, different, like, clientele that you're going to be working with are not necessarily being sold the digital transformation piece, how has that been a contrast?
Alex Zekoff 09:02
Yeah, there's a lot of education right now in the RPA. space, I think the fortune 500 has had a couple years, several years headstart and RPA. And they're all still figuring it out. I wouldn't call it like the green cloud success yet in fortune 500 category. I think there's a lot I've gone in, I've chatted with people who have internal RPA groups that are seeing a lot of failures, and they're trying again and pivoting and trying to figure it out. So I still think the industry is in this like very beginning stages of like, how is this all working? How is this all integrated into our current tech stack? How do we think about turning on a new system in the future? Does RPA play into turning on new systems? So as a startup, you know, it's very difficult, as you know, to go into a fortune 500 enterprise level and get any traction. So really a lot of our jobs educating consumers on RPA to begin with, like what is this technology? That's typically the first feedback we get is like, Whoa, like this is like this is available now like these bots. And so a lot of it, you know, first starts in the first couple of weeks of just educating of what they can do. I get a lot of questions of, Oh, can it do that? Can it? Can it scrape this data? Like? My short answer in my head that I always say is like, I always tell myself, it can do anything. I have to, like, answer these questions in a way that, you know, seems thoughtful to the question, but really, it's like, these bots can do anything, the art of the possible is really in a day with machine learning and RPA, you can really solve any problem. And so a lot of education at this stage.
Brent Sanders 10:36
Dan you know, coming from we actually have somewhat similar backgrounds, I ran an agency for a long time, much smaller than aura, but in Chicago, more development focused. Like, what's your view of the RPA? industry? Like me and I'm kind of projecting this, I need to see if you agree, but my view of our people got me really excited was that it feels like where maybe web and mobile development was in like the early 2000s. And that mark, and I always talk about this, but I'm curious if you share that perspective.
Dan Parsons 11:08
That's pretty funny, because I believe I actually, like when Alex and I was first getting positive feedback and getting expansion calls from our early customers. I literally think I said that exact same thing to Alex. I was like, Dude, this kind of feels like what mobile felt like in 2009 2010. Yeah, where it's like, people don't know they need to do it. But they don't necessarily know how or what they just know, like, like, the back of the day, you know? Yeah, exactly. Like back in the day. They're just like, like, Alright, we need an app. And then you know, you're talking to, you could be talking to a fortune 100 company, and you're like, I agree, but like. What do you want to do? Like we all know, but we just know, we need a net. So it does feel similar. And I think, I think what's interesting now, and like this is I'm sure you can relate, Brent, but like, this is part of the value of having done it before. And now going back and doing it again, is, is now like we recognize the size of the opportunity. And I think there are things that we're going to that I will be doing differently. You know, and Alex mentioned it to make sure that it really capitalize on that we're like, that wave of mobile, I don't think anyone knew how big that was gonna be. Like, I think like, especially when we started building blackberry apps, like we were early mobile, and it was like, at that point, like, we had no clue that like, you know, then the App Store and then now it's like, mobile is ubiquitous with the internet, right? So I think we're trying to take that mindset and get out of pigeonholing ourselves, even with RPA specific, and just thinking about automation, as a broader category. And thinking about automation in a way of just simply saying, like, let's figure out what humans are bad at doing and that computers are good at doing. And let's build that bridge. And let's use the technologies. And like, that's part of our philosophy, too, is like, yeah, we're great. RPA implementers. But that's just like the first act of our, of how we look at this. Like what we're that's why we were tying closely with with antium, what they're doing a robo CT, we do, we do UiPath and other things, too, but like, you know, getting to the core of like engineering level technologies, and saying, like, we want to solve problems that engineers are required to solve, because they're that hard. And the minutia is there, and you have to write programs to actually do it. Like, that's the mindset that we wouldn't be built in. So we're, you know, we're experimenting with building our own tooling internally to help these things be successful that one day, we might bring the market. But yeah, we really are not taking this opportunity for granted. And we're trying to say like, you know, how do we not just say where we do RPA? But how can we go in and say like, we solve problems, and there's a lot of ways to do that.
Brent Sanders 14:02
That's great. So as you mentioned, you work with the folks at Robocorp, you do some other UiPath. You guys, like what's your philosophy around the tech that you implement? I mean, are there hard and fast rules around? Are you like, adapt to different situations? I mean, usually this question that I asked everybody is like, what platform you're on, and why did you choose it? Like, how do you guys think about platforms?
Dan Parsons 14:25
Sure, I mean, our bias tends to be towards open source and like programmers programming, so like Python, you know, so that's our, that's our, and that's why we love keeping an RPA framework, but that's why we love the work that that the Robocop folks are doing. And you know, that's why that's why I can't believe speaking right now. That's if we have our choice, we go and we use that because it allows us to hop into the ML and allows us to kind of, you know, use the technologies of the internet to be most effective. So that Like, that's where we look. But we've done UiPath implementation and we can support other things like I saw automation being automation success as our Plaza platform. That's kind of like how we view that it's like we are successful automation implementations, like, you know, we look at a crop, we're somewhat agnostic, but our platform of choices is the open source works. That's why that's why we're doing a lot of Robocop stuff at the moment.
Brent Sanders 15:28
Yeah. Yeah, I agree. Going back to Alex, what you're talking about, like failure rates, and I've heard this actually just just on a phone call earlier, with a, you know, from a, one of the big consulting companies, somebody who's a consultant and was saying, he was quoting some study, or it was even like, a paper by a consulting company saying like, 60% of RPA engagements fail. And he was kind of laughing. It's like, the only reason they know that is that there? Are there engagements where a firm comes in, and they try to set up a Corp, and then they leave and the pilot was great. But like the success in the, in the measurement for a lot of these companies is like, do you release resources? Can these workers go and do other things? Can they, you know, add value somewhere else, versus doing these, like robotic tests. And the study was saying, this is all anecdotal. So take it with a grain of salt. But he was saying, like, somewhere around a 60% failure rate and was kind of laughing like, you know, it's almost like that's in these marketing material, but it shouldn't be because it's like, a really bad success rate. I mean, it sounds like you were echoing that, like you've seen similar rates? Like, why do you think that is?
Alex Zekoff 16:45
Yeah, well, I think there's a lack of trust with people. Let's say they're in the loop, and they're triggering the automations. And I want to use an example of something that'd be very typical of a bot, let's say a break, and how long it might take to get that fixed, and why a person would be skeptical of using a bot. So as we know, RPA is a little finicky with any UI changes in and Bob, let's say a pop up occurs, and the bot doesn't know what to do. So it just breaks. So typically, like, that's a simple fix, right? And like a thoughtful automation, we're building tooling to, like, fix this problem, right? Like, success is huge. And like, this shouldn't be a problem. This should be like a person obviously knows how to do this. So how do we like make bots better smarter, so that in a typical, it like RPA, kind of group, let's say, the person realizes the bots broken, that might take a day, then they like, they don't necessarily know what's broken and arcade groups on it's like actively monitoring because they, you know, they're still scaling and figuring stuff out. So once they figure out, okay, it's broken, they send it to RPA, RPA group takes a day or two to identify what's going on, then they put it into a sprint to fix it, that might take a week or two. And then they redeploy it and, you know, tested, redeploy it. So I mean, that small thing can take two weeks to fix men and a person, there's like, well, I need to use this daily, potentially, and it's been down for two weeks, that's like a co worker not coming into work for two weeks. And you're like, like they were supposed to be there. And they just didn't show up. And so you people lose trust in the technology immediately when that problem should have been fixed within 24 hours. And then at that boss back up and running and adding value the person trusted, it's then becomes a co worker, a digital coworker, I use that term sometimes. And so it's like anything in life, like trust is huge with these, like revolutionary technology changes. And so that's why I do think most of these, and I saw this within my own implementations, when I was at the previous consulting firm, is that it just took an extended period of time to fix these small things. And the arcade group didn't really know how to triage, prioritize, and, and fix like small versus, you know, larger upgrades and overhauls quickly enough for the person that manages that bought to really trust that it works, right?
Dan Parsons 19:00
And yeah, just double click on that to just to Alex's point, the trust that two week period, then that employee has to go back to doing what they were doing previously. And that's like, that's the gap in trust, like until you can completely augment and remove that workflow, then the bot really hasn't provided really any value. So that I think that's like how the, that's how the failure gets delivered, is they go back to doing what they were doing before. And then it's almost like when the bots fix, then they have to go back, you know, to the other workflow. And at that point, like there's no real efficiency gain.
Brent Sanders 19:39
Yeah, dropping into a business continuity plan is a pretty ugly experience. I wouldn't wish that on anybody really, because it's like, once you go through that once or twice, it's rare to think that you're going to, as you said, trust this bot to, to show up to work. I mean, it's, I always say these are these bots are our co workers and you wouldn't tolerate that you'd fire them or not hand them the project again. So yeah, it's a tough situation.
Mark Percival 20:07
And when you think about that, you mentioned this in the case study with Rocorp the minimum viable bot strategy, how do you kind of tie that in where you start with, you know, a minimal viable coworker? Like how do you build that trust from that point of going small and then expanding out? And yeah, just how do you build that trust?
Dan Parsons 20:24
Yeah, that's a great question. So if we look at the will call a person's daily tasks, it represents 100% of the workflow. And we come in and we identify, let's say, a core, you know, timesaving, let's say, we can automate 10 or 20% of their workload daily, and they can just wake up in the morning log in, hit the bot, and it, you know, runs through some backlog of stuff and gets them ahead in the day, right. So instead of us going in and trying to say, hey, end to end, we're going to automate your entire day, let's just start with that little sliver and give you a win in the morning, let's not, let's not build you this complex, massive solution. Let's start with the minimum viable bot, and then add to that bot the daily things to your day. That one is just a great strategy for all, you know, products that are launched is to start with the smallest sliver of value and then add to and then once a person builds that trust early on, then they're more likely to say, hey, yeah, can you add something to that, I'd like you to add this component of my work. And so instead of having a high likelihood of failure, because you tried to automate, you know, six different decision paths and all these permutations, and that's just a highly complex engineering project. Let's start with a high a high success rate when early on build the trust and then add to it and then sort of add those. Yeah, the guardrails for trust and reliability all that over time.
Brent Sanders 21:44
Very good. Um, you know, one of the things that we were kind of commented on when was introducing you guys like, it seems like we have very similar worldviews, as you mentioned, kind of reach for the the open source tooling to start and you mentioned that you guys are, are working on developing your own software. I mean, Mark and I've worked on a couple of projects internally and an open source them over time. I mean, there's still very, very early, but it just seems like there's a big gap. There's all these, again, going back to the analog of mobile, or web development, in the early 2000s, there were all these things that were missing, right? It's like now you spin up a new web project, you've got, you know, really good error tracking all these different external tools that you can plug in to make your life so easy, and they seem to be missing, like, where do you guys see gaps? I mean, if you're working on something in the skunkworks, don't, don't feel like you need to share it. But here's what spaces are, what gaps Do you see that you think will be filled in the next either three to five years by the robo corcos? UiPath? Folks, other vendors out there, like where do you think the gaps are?
Dan Parsons 22:54
Yeah, I mean, we know that obvious gaps. And then Robocorp, I think, is doing a great job around the developer toolkit. So you know, I think that's pretty, they're doing, it's very well served, especially if you think about like an adventure capacity, like where the venture dollars is gonna go. Like, I think right now with UiPath. And with that UiPath taking on this, like citizen developer world, and from a business side, and then you have like, Robocop taking on citizen development, maybe or at least democratizing development for developers. So now making it easier for Python engineers to get into RPA. You know, we believe that those dollars will be well allocated, and those companies are capable of solving those problems. And that's why we've decided to partner with them. However, the space that we are focused on is success from the business perspective. So now we say like, what's the layer on top of the engineering problem? And say, let's assume, let's assume developers can build awesome bots, and they can build it and with good speed, and we can keep the licensing cost and everything all that under control? Now, what is how do we deliver a successful implementation and a successful design of an automation? And then how do we deliver a multi year successful program? So that's the gap that we right now we think is underserved. And we are trying to fill that gap by taking a consultancy angle. So it's changing the model of how consultants approach the problem. And then additionally, by doing that, we are learning how we can build technology to help us help solve that. Those problems, some of those problems, and and to be candid, it's still real early. No one's no one's got a ton of reps on it. So we're just trying to get reps we're talking to customers. We're learning from our own mistakes.
Brent Sanders 24:50
Yeah. Yeah, it sounds very familiar. That's good. I mean, it's good to speak with somebody. I mean, I feel like again, the worldview is very similar around this probably because they have similar backgrounds and experiences. But when it comes to you know, this decision, and we've talked to a variety of people, and we've gotten both sides of it, when it comes to the decision for a company that maybe they've gone through a pilot, they've decided, you know, probably start in the finance department accounting wanted to automate something, it worked really well. And it comes down to deployment and expansion of the program, and they used internal resources to start, but it's hard, you got to start hiring a bunch of people. And it becomes this question of, do we go internal? And do like, build our own CV? And, you know, bring new new bodies in? Or do we go with an external partner, one of our first podcast with Laci ryndam, he, he explained how he was at this giant company, right ISS, I forget the size of it, but it's like a global multinational Corporation, and he just had a spreadsheet that's like, your problem needs to be worth this amount in this spreadsheet, and then we can go to this outsourced partner, and they will take care of everything. And so he laid out an interesting path for, you know, painlessly rolling out RPA throughout the organization, because it was like, we have a vendor, they're responsible to our SLA, and we're happy with them, versus other companies where it's like, Hey, you want a competitive advantage? automation is going to be something that will set you apart, and you want to invest in that internally. And that's how you capture that value. Obviously, you guys are a consulting firm, so you're not impartial. But like, what are your perspectives on building and growing looks internally versus externally?
Alex Zekoff 26:33
Yeah, it's a great question. I can only give you the experience I've seen with internal RPA groups at large companies. And what I've seen is, it's, it's not working yet, because people haven't figured out that value flow of how to prioritize projects. I think a lot of bureaucracy gets in the way. And a lot of large companies have like, Oh, this project has this person who has some initiative. And so that gets prioritized. And that gets deployed first. And that's what I saw in my engagement was we had a pipeline of, you know, we had a whole process of pipelining ideas for bots into the CSV and try to, you know, prioritize that. But the actual selection was not actually as objective as I thought it would be, there was a lot of politics and bureaucracy involved in that decision. And then we deploy these bots. And at the end of the day, some people just didn't use them, because I don't think the value was really assessed in a true objective way. And so I think if this really is going to be done internally at a company, pipeline, and assessment and economic return have to be absolute, they have to be apples to apples comparisons, they have to have consistent, you know, ways of going into different parts of the organization, finding opportunities, assessing those opportunities. And then the biggest part that I don't see happening is realizing the value. Right? So let's say it's an hour's avoidance, right? There's some cost reduction, how are you going to reallocate those people to higher value activities, I still haven't seen a company do that yet, is actually take a strategy of reallocating those people to more creative work so that they can, you know, build a new business line, or solve the new problems that need to be solved. And until that actually happens, I don't know if internal groups are going to actually just gonna keep adding overhead, it's gonna keep adding headcount. So I agree that we are a little biased. But I look at this the same way, as you know, building an on premise server versus using cloud. A lot of people did that at first, they're like, Yeah, we got to have on premise, we got it, we got to lower operating cost. And then GCP, and AWS came in and Azure and was like, Nah, you, you don't need to be in the business of building servers. That's not your core capabilities. And so I think automation is that same exact corollary of interesting, a lot of people are going to be building their on prem RPA groups, and then it's all going to go external and the end be sort of like how the cloud went. Yeah, with an off premise. Yeah, my hypothesis, and I'm, I'm thinking, I'm taking a big bet on that. Well, I think I think that to back your bed, Alex, so is the veteran community. So I think what's going to happen is groups like Robocop groups, like topple automation, you know, we're very, you know, we're very aligned with pushing the envelope from an R & D perspective. And like our bet and our hypothesis is that we will always be able to deliver a more effective cost effective streamlined with a high efficacy program purely because we're concentrating the venture capital investment, we're concentrating the talent. So I think it's just like a lot of things. It's like me, we can look, you know, across all a lot of the big verticals, it's just we're able to concentrate that research and development.
Brent Sanders 29:58
Yeah, so more. What you're saying is more Resources kind of heading into that direction.
Alex Zekoff 30:03
Yeah, solely focused like not not not part of the bureaucracy not getting pulled, because there's internal agendas purely focused on like, our number one priority. And our whole point of our business existing is to make sure that there are successful RPA programs. Yeah. And to add to your point, Dan, like, that focuses us right now we're in that era of hiring the best RPA talent, you know, in the world right now, so that we can design the best bots. And so companies that are not necessarily going to be able to hire the best talent, because we're ahead of the game, we're trying to hire the best talent get, get, basically our product is our boss. And so we want the best people designing, building, deploying, managing, maintaining, hosting all of those bots. And so in the future, as Dan was mentioning, is, we're just going to have our products, our bots, and they're going to be the best because we have the talent. And that's what we're focused on, versus a company is just going to have to go through probably an 18 month exercise of trying to find how to hire those people. You know, that process of hiring, like we've already been doing this past year, is to figure out how to hire the talent that takes, you know, 18 months to figure out?
Brent Sanders 31:09
Yeah, yeah, I mean, recruiting stuff. I mean, you monitor the job boards and see who's hiring and how long some of these posts stay open, especially in a leadership role. It's a fairly new space. But when it comes back to development talent, like, I'd love to get your perspective on two things. One, you know, how do you find good talent? How do you assess talent? And as it relates to automation, as a general engineering practice, versus like, we just want to level to UiPath developer, which seems kind of arbitrary or platform specific developers? It's like, how do you think about who's right for thoughtful automation versus like, a per project or skill set basis? Is it more like a general engineer? Or is it more of somebody? Yeah, go ahead.
Dan Parsons 31:52
Yeah, we have a bias towards, towards engineers. So we look for a track record. And like, you know, we've had to go up against this, like, we don't hire UiPath engineers, we hire developers who have experienced solving problems writing complex applications. And we would rather invest, you know, a little bit of time upfront, getting them brought up to speed in our tooling, and in our practices, and how we do RPA versus find someone who has RPA experience, and then bring them into into the fold, just because we believe like, you know, the aperture of our technology stack is continuing to widen. And we want we believe, like engineers, are best suited to fit that environment. So yeah, that tends to be how we look at things. Like at the end of the day, like, we're I mean, we're so early, we're like, we started last year, right? So like, yeah, I if I, if I were to look at thoughtful automation, three or four years from now, we will look, we will look much more like, you know, like a massive, you know, SAS company as it relates to like, what our product and engineering team looks like, versus what a consultancy will look like.
Brent Sanders 33:01
Yeah, that makes sense. You know, one thing I read, I found, you know, it, and we talked about this on with, I think entrepreneurial Corp around like, you know, finding talent specific to that platform has been really interesting, because you have this plethora of really savvy test automators, right in the robot framework world. And there's a glut of those people that have been doing test automation, and what I feel like, have been kind of kept in a dark corner of the internet and paid low wages. And there is a lot of talent there. There's been a lot of interesting, sort of updates for their career path now with this new platform. But anyways, the other part of the question I want to talk about is like, how do you guys feel about, you know, citizen development? And, you know, you mentioned that's kind of the UiPath thing, or, you know, there are a whole bunch of and we've had some of these platform creators on their platforms that are there, no code, low code, like a web flow for RPA, with a very purpose built, and they seem to allow for, you know, you can use their tool and kind of work within that universe. But I'm curious, like, in the engagements that you've had thus far, do you see a position where you would come in and almost do like capabilities building? Or is it kind of, hey, we're gonna provide the bots and we'll do our best to consult and make sure that these are successful engagements, but Leave it to us or how do you feel about general citizen development?
Alex Zekoff 34:27
Yeah, so I take a pretty contrarian point of view on citizen development. And I have another example outside of RPA to kind of pious my own point is that I think citizen development is a pipe dream. I think it is a utopian view and I really think it is an honorable thing to strive toward. But if you look at other citizens development intended communities like WordPress, for example, that was meant for anyone to be able to code a website. Now I've gotten into WordPress recently and it is complicated like it is not for us citizens.It is now there are WordPress engineers. Because what happens is these low code, no code become their own engineering problem that then you have to train, you know, UiPath, you know, certified engineers to do it. So it becomes not a citizen developer. And I also take it that most people don't have the time every day to go code their own bots in a no code, low code, I have been in these no code, low code. thing, and they're not, they're not as intuitive. I know, there's the macros and things. But that can solve very point to point problems. And we're talking about real hard to solve engineering problems. We've seen this actually is that our coding in UiPath, typically will have to develop outside of a no code low code environment to solve a real hard problem. So we'll have to write a script that is outside of that no code, low code environment to solve that. So at the end of the day, if we're going to solve really complex automation problems, not just the Zapier type, like, you know, a to b system problems of integrations. Citizen developers do not need to be spending their time solving that problem. This isn't developer needs to identify the problem and send that to a partner to go design, develop, deploy and host maintain. That's where the citizen developer understands the citizen, the business user understands their problems the best, but to spend their time designing and sort of building and managing their own automation is not where their time needs to be spent. It needs to be spent on creating value going into meetings, whiteboarding ideas. So I just think the whole idea is nice, it's a nice idea. I just don't think in the real world, it actually happens like that.
Brent Sanders 36:43
Yeah. Yeah, it's a mix. From everything we've had on it's been, you know, we get the full perspective, which is always why it's a fun question to ask, because everyone's kind of got their own take on it. I'd say, you know, go ahead, Dan.
Dan Parsons 36:57
Oh, yeah, I was gonna say we believe that, that the citizen plays an active part in this in the stack. We just don't think that, like, you know, developing a 400 step, multi enterprise software, you know, 99%, success rate, automation, it becomes a part of that, because it is a part of their job. And if it is it slowly will become their job. And then and then you're back to that, you know, then you're, you've just, you've just done a SWOT, and you don't do it, you don't get the efficiencies. So again, yeah, I think that's, that's where we're also investing in, like, how do we still make that person valuable? How do we get the citizens involved in the ecosystem? But how do we not set the expectation that they're the one who's gonna build and manage the automation?
Brent Sanders 37:51
You know, as it relates to like, for looking for 2021? Are there any things that you guys are looking at that you're excited about or be dreading in this year? You know, ahead, and specifically, what I'm thinking of like, advancements in machine learning AI, like, what do you see happening this year in the industry? What do you hoping happens? What are you hoping doesn't happen?
Dan Parsons 38:18
I think but yeah. The easy one, for me, is the new norm of working. So like we're already hearing from a lot of customers that now that you don't have people in a central office, one that they have to figure out what remote hiring looks like, like they don't, they've never done that before, especially when you get into some bigger companies. And we think automation plays a big part in that where they can look at automation as a resource versus going and trying to hire, you know, to spend energy there. So I think, yeah, that whole evolution, I think is just really exciting. exciting for us. Good.
Alex Zekoff 38:58
Yeah, I very much agree. I think this is the pandemic, which has been very unfortunate for many companies and has only accelerated RPA. And the demand. And I think when I got into this a year ago, and I had no idea how long this was going to take before the wave hit, and then the pandemic hit, and I felt demand surge, right. Like I felt this wave and I was like, Okay, this is just maybe in my mind accelerated this two years. So I'm really excited for this year, because we're already, you know, feeling it. And I think for us, you know, I just want to make sure, the only thing that we focus on this year is our customers adding value, and building really high fidelity quality automations that work, and then we scale within those companies. So our goal is to, you know, whether we start with a proof of concept or a couple bots, we want to have, My vision is that you know, 70% of their processes are automated through our bots, right? That's my business each account that we land, and so I'm just hiring Folks and excited about the idea of going from one to 50 bots at each account that we land. And how do we do that? How do we figure that out? How do we not turn a bot? How do we keep those bots up and running and successfully like integrating with each other? I'm actually excited about the idea of bots interacting with each other, as we get like more than 10 boss, how do those bots like hand something over to another bot and kind of have this, this operability between each other that I think is exciting. And I think as we just grow and grow, we'll get to play with those new things that will emerge?
Brent Sanders 40:28
Yeah, yeah, in my mind, I always think about self healing, that's a trend we hear about, and we just had a guest on, Doug Shannon was saying he had a very effective yet simple self healing technique where, and I think they're on UiPath, or something. But you know, essentially, the VMs, or the bot figures out, there's an issue and it just goes to the start menu and restarts and then takes it from the top and it is fixed, I think he said something like 90% of the errors, go away with that simple step. So it's like, that seems really trivial. And then if you start kind of layering on that you talk about UI is changing, you talk about, you know, if you take that time, and involve the resources, like artificial intelligence, or other things that you can do to infer changes or identify changes, and not bring that down cycle in for whether you're working internally or externally. But like, if the bot can figure out a way to, to get a tail. So on that note, I mean, are you guys to play with any of the toys and API's or, you know, things that are out there in the AI and machine learning world? Is there anything that you guys are doing in that world? That's interesting.
Dan Parsons 41:34
I mean, our developers are always toying with stuff, I would say. But yeah, I mean, nothing, nothing that we're, we're like thinking about productizing, or really bringing it on in a meaningful way. Sure. You know, we've seen this, we've seen the act act before. And I think just we're too early, like a focus right now is a competitive advantage. And also, it's like, it's how you stay alive. So for now, it's just like, we just have to stay laser focused on where the value is being created for our customers. Good.
Alex Zekoff 41:34
Yeah, I will. I will add to that, that I think there is an amazing opportunity with machine learning, because I think in the AI journey, I think RPA is beginner AI, I think it's right, it's Yeah, it's a good way for getting its beginner AI. And so I think to get the machine learning, you need it, you obviously need a ton of a ton of training data. To get that training data, I think RPA bots provide an immense way to accelerate the amount of training data you can get through bot operations, analytics of that bots and failure points. So again, another hypothesis I have is that RPA actually using as a training data tool, to train ml is potentially something very exciting over the next four to five years that I think we'll see emerge as using your own bots to train your own ml models from process data that you're collecting. So at the end of the day, ml, I think is a very awesome technology that you need a ton of data for, and a lot of companies, I think it's sold on the vision of AI, but don't necessarily see the ROI in ML yet. I think RPA you see more immediate ROI. And so that's why as Dan said, we're focused on ROI and value for our customers. And as we feel those problems emerge along the value chain, you know, I think ml and deep learning and all that stuff becomes relevant.
Brent Sanders 43:20
Yeah. I asked just purely from a, you know, forward looking perspective, I always say RPA is the gateway drug to AI. It's like, once you start down that path, it's like, what can you enable the bots to do further, but I agree, it's like, even in our practice, like we're using it for very discreet purposes, but it's not like, it's not driving cars. It's not doing you know, it's not doing anything crazy at this point. So, with that being said, Mark, do you have any questions? I feel like I've been hogging these guys.
Mark Percival 43:49
So great. I mean, I think, obviously, you guys have this case study out with Robocode that you put together, which was really informative. It's always interesting to see, I think, anybody in the open source RPA space, because I don't think that gets talked about enough. Yeah, anytime you read an article today, it's almost always UiPath. To that note, I mean, as you can have, obviously, different clients, you're willing to use UiPath, whatever, whatever makes the most sense, where do you kind of draw that line to the client? Is it going to the client and saying, Hey, you know, this client is already on UiPath. So we're gonna continue that road? Or is it more of practices on what's actually being implemented and what they already have? You know, maybe the town resources they have locally, what kind of drives that decision factor and where you pick a platform? Yeah, I mean, for us, it's pretty straightforward. If there's no requirement and we go with, and we're going with open source, and that's and that tends to be we are starting a net new with a lot of our customers. So we are the very first automation program. And at that point, you know, we get in and then there's just we're past the point of return. They don't have any other point of reference. However, we You know, we there are some, like migration opportunities as well that we're exploring or some broken, like, you know, we hired a group they came in, we've worked on it for a year, it's botched, like, Come help us fix this, sometimes we'll pick up, you know, UiPath, wherever that where they left off, and we're comfortable doing that. And also, and this is kind of like will be a coolest shout out to the Robocop guys. When we first were getting going with them. Like our confidence was low, we had some customers that we couldn't afford to mess it up. So, like our plan, we implemented it in UiPath. And then, like, in lockstep we were building with Robo CT. Okay, so we actually have side by side case studies. Yeah, and we actually have true performance, it does show that the open source way, from a pure technology performance way is better, and more efficient and more cost effective. So like, when we have those conversations with our customers, we can say, you know, with full confidence that this is the path we choose. However, you know, we're here to solve problems and add value. So if a technology to us is secondary. Yeah, that makes sense. I mean, it's, it's, uh, it's certainly still very new. And you guys have been around a year. And so Robo code also feels like I think, a year at this point, I think they're pretty new as well. It's pretty exciting, how quickly they have moved into something that's, you know, pretty, fairly competent setup, sort of tools. Yeah, totally. And we're in the slack channels via, you know, join slack where, like, we're basically like, in development side by side. So it's like, it's cool, also, for us to be able to inform how they think about their roadmap. It's been a pleasure to work with these guys from that perspective. Yeah, that's exciting. Yeah, it's exciting. It's definitely an exciting space. I mean, going back to the mobile and web development side of it, it does feel like the some of the other platforms of the you know, what we had back in the day with like, the proprietary platforms like you know, a rental app but like the flash media servers, like all the like crazy proprietary action scripting, you could do? Yeah, but yeah, it was and it all started to get her served by the, you know, the PHP 's of the world and the rubies.
Brent Sanders 47:13
Yeah. Yeah. With that being said, you know, anything you guys want to shout out, I think I saw on LinkedIn, you guys are hiring. So the company is growing. I mean, anything you guys want to plug.
Alex Zekoff 47:27
Yeah, I will plug. I'm looking for a top notch salesperson to come in and help us be our first sales hire. I've been pitching founder led sales all year and I just like, then run out of chicken with my head cut off. So I'm ready for my first salesperson. So anyone out there is just fast tech sales and can crush a pipeline. DM me on LinkedIn love to chat, right.
Dan Parsons 47:51
And then yeah, additionally, you know, we are a remote first company, you know, we hire globally. We are interested in hiring the best open source development talent. So, anyone with with with general Python experience that wants to get involved with automation and wants to get involved with RPA anyone with you know Node JS experience who wants to get involved in building application around the space or even you know, x Deloitte, consultants who want to want to get involved with a with an early stage startup with a who have an eye for, you know, process design? You know, we love to have conversations with all of you.
Brent Sanders 48:35
Excellent. Excellent. Alex, Dan, thanks so much for joining us. Yeah, thanks for being on the podcast and for telling us your story.
Alex Zekoff 48:44
Awesome. Thanks, Brend and Mark. It's been a pleasure.
Dan Parsons 48:44
Thanks so much guys.