Unlocking Your Automation Superpower

Lindsay McGuire: The more I think about it, the more I'm convinced that automation is the answer to almost every workplace issue. More automation means less menial tasks, which means happier employees and more capacity for better work. But even I'll admit that the starting point for automation can seem a little overwhelming, especially if you're non-technical like me. Or maybe it doesn't have to be that way. At least this episode's guest surely doesn't think so. Daniel Zrust is a solutions architect at Make, a platform that's helping some of the biggest companies in the world automate tons of their daily tasks. In our conversation, you're going to learn tons about how you can start to automate your daily work life little by little, and how non-technical people can get started in creating automations that will make work so much better. Here's Daniel. Thank you, Daniel for taking some time today to join us on Practically Genius. We're so excited you're here.

Daniel Zrust: I should be more excited than you. So happy to be here.

Lindsay McGuire: So first off, tell our listeners about Make, for those who may not have ever heard about your organization, tell us about what you do.

Daniel Zrust: Okay, so I guess if you go to make.com, the first thing you will see there is our tagline, right? We say that Make allows anyone to visually design, build and automate anything from small tasks to complex workflows and systems without need for coding expertise. And that last few words is very important. So it means that no matter if you are a programmer, which of course you can be, but if you are just a regular business person, you don't really have to know anything about programming and you will still be able to use Make. So it's a very visual platform which allows you to build scenarios. This is how we call our automations. And by building scenarios you are basically converting your business process to a automated sequence of events, actions, searches, et cetera. And they form the scenario which runs either on its own or on scheduled basis. It really depends how you set it up and what apps and modules you are using within Make.

Lindsay McGuire: I really like how you position that as scenarios. A lot of times we just talk about automations or workflows, but I think scenarios makes it much more realistic for a user. So can you talk about some maybe of what the most common scenarios are that people are automating, using Make?

Daniel Zrust: I can describe a very specific example which everyone will understand. Let's say you have thousands and thousands of emails coming in every day to your Gmail or whatever service you are using and you might be wanting to store, I don't know, your attachments from those emails to a Google Drive folder. It's very common task and for that, you can build this automation scenario in Make, which will listen for the new incoming emails and based on various conditions you set, you can store those emails, but you can take it one step further for example, and you can introduce conditional logic into your scenario. So you can say, Hey, if it's email from my boss, save it to a boss folder. If it's from my mom, save it to my mom's folder. Right. And then you can build these very simple but at the same time very complex scenarios at Make, which allow you to do exactly what you need to do at particular moment.

Lindsay McGuire: I'd love to hear more about just your role with Make and what you do, and just describing what your role is.

Daniel Zrust: I'm solutions architect officially, which sounds very fancy, but what does it really mean, right? When I say to someone I'm solutions architect like, okay, nice, but what do you do? The shortest answer I always have is I figure out stuff and that means that I usually need to come up with a scenario or with a solution for our client or for our partners, which we work with. For example, Formstack or big names, I don't know, LinkedIn, Facebook. We are always in touch with all those teams and we do co-marketing together and we promote each other's companies, we do webinars, et cetera.

And all these things require some sort of knowledge of Make how things can be done, what can be presented to the public, right, to our users, how they can improve their scenarios, how they can build more scenarios, how to identify, for example, good use cases within their business. This is where solutions architect comes in and figures out what to do basically with the scenario or how to build it. I did not study programming. All right. I am that person who has no coding background and still here I am able to stand here today as solutions engineer. Right. This really demonstrate the it's for anyone.

Lindsay McGuire: First off I have to say I love that you brought up the fact that you are not a programmer, you're not a coder. We are all about the no-code life here. We're all about pushing for empowering those frontline employees to be able to do things they might think would need a coder or an IT person or someone who studied computer programming. So just thank you for bringing that up and putting that out there because I think it is an easy assumption to make that anyone with a solutions engineer title or any kind of fancy IT seeming or tech-heavy title would be like a coder or someone who has heavy IT background. So really appreciate you bringing that point up. How can people who might not be as technical minded or have any experience as a solutions engineer in a fancy role, like you said, how can they maybe tap into more of that creativity of figuring out what processes they can automate or what problems that they can bring automation into? Any advice for how to kind of maybe think more like a solution engineer?

Daniel Zrust: I know it can be frightening. You've never seen it, right? It just came to work and maybe your boss told you, Hey, you are good with Excel, maybe you should help us out to automate something in our company. Go and figure it out. So you'll probably go to Google and you will look for automation platforms, but before you actually sign up for anything, you should identify your crucial business processes, which you may want to automate. Identify a few candidates, maybe three to five and say, okay, this is the painful part of our business. We hate doing it. And maybe there is a way to automate it. Once you identify those candidates, and by candidate I mean for example, that think with emails, which I mentioned, right? Like processing thousands and thousands of emails and routing them conditionally to somewhere. And then once you identify these processes, you will need to sign up for a platform or maybe you will need to sign up for more to compare them.

And when you land on any of these automation platforms, we call them IPAs platforms, they will always tell you what kind of apps they support. So they will tell you, Hey, we support Gmail, we support Outlook, we support Google Drive, we support OneDrive, et cetera. But you should not be fooled by this information because it's not everything. It's like one thing to say that particle app or API is actually supported, but you are more interested what actions and triggers and searches within those apps are supported. So you should not be asking, Hey, is Gmail supported? But you should be asking, is monitoring of emails within Gmail supported on this platform? And now that's where you are going to start seeing differences. For example, Make of course we do support them and probably all other platforms support these basic operations with emails, but when it comes to some less known apps, Make might be supporting 50 endpoints and the other platforms 30 or 70.

I'm not going to say that we are the best at everything. Right. It would not be simply true, but you should be really comparing the actions and the triggers which you want to use within your business workflow. Whether that thing is supported within the platform. Let's say you've identified a process, right, you have that. You've made a good choice of your platform and it's supporting all those actions and triggers you want to use. And then you just should start building out the process within the platform. So in Make it will be called scenario. You build it out and you just see how it goes. It's really important to feel comfortable with that platform because once you build the first scenario or automation, then you are going to build another one and another one. You are going to be depending on this. It's going to be core of your business very likely because you will see of what's possible and every new solve problem basically unlocks another more difficult problem with which you will like to automate.

Lindsay McGuire: You talk about thinking about how tech not only is going to serve you now, but how it's going to serve you in the future. And it's something that we've talked a lot about with our 2022 state of digital maturity report. We create a vast scale that organizations can now use to figure out how digitally mature they are. And one big, big, big piece we found with more digitally mature organizations is when they're investing in technology, they're not just investing right now for the problem they have to kind of put a bandaid on it or have an easy fix. They're taking the time to invest technology that will grow with them, that will scale with them, that they can use not only for that first use case but all those other use cases down the road. So I really like that you brought that up and honed in on the importance of that.

I do have a question. When you are in these initial stages and you're trying to figure out what are maybe the first two or three automations I want to bring to either my team or my department or my organization probably depends on the size of your company, kind of which category you're choosing. But when you're in that part of the process, how deep do you suggest getting into let's say workflow one? And I'm thinking about all those triggers and automations, how far should you get with that to get a grasp of which platform is right, or which tool will help you get where you want to go?

Daniel Zrust: So my approach is usually just tried by doing it right? Because when you automate something, there might be a lot of little nuances which you will just learn when you build a solution. There sometimes isn't another way around, you just have to sit down and try to build it and then you will learn, hey, okay, so maybe this field is not available there. Right. Maybe you have a system providing two phone numbers. One is like business phone number and the other is personal phone number, and then you want to pass it to another system. And that system may be supporting two phone numbers within the web interface, but the automation platform which you are using is just offering one field, maybe the business one. You really just learn this by seeing it for real until you get to that very step. So I really would say, hey, try to build it as best as you can and then see what are the compromises.

Frequently, no matter how good your automation platform is, you will have to be making some compromises because not everything which you made up in your head is actually possible to do. Automation is nice, but sometimes it's just not going to fit your best dreams. You will have to sacrifice maybe some steps or certain fields or certain rules like you will have to make compromises on your automation endeavors.

Lindsay McGuire: That is such a good point to make because I think for people who might not have done a lot of automating yet or haven't taken the dive into the automation pool might think, oh well once I figure out what I want to automate or what I want to integrate and pull together, it's just all going to be magic and it's going to be rainbows and butterflies and beautiful and make a lot of sense. But you bring up a really great point that it's not always going to be perfect and there are going to be places where you need to be flexible and have some capacity for compromise like you said. But I do want to ask, what is the importance of being able to integrate your tools together? Why should that be an important part of this automation dream scape we're talking about?

Daniel Zrust: There are probably 50 different reasons why you should automate, but I'm going to just list a few of them. But I guess the first thing which always comes to my mind is that you want to have fresh data across all your systems. If you have inconsistencies between systems, let's say you have a phone number in Salesforce which was supposed to be carried over from a Google Sheet and that Google Sheet got updated, but the number in Salesforce didn't get updated, then your sales guys are going to call a dead number. Right. And delete a step, maybe. Or maybe the person will reply three days later because it was his personal phone which was not available. This inconsistencies in systems is a big deal in business. I mean it kind of goes without saying, right? But this is what's automation about, it's about passing data from one system another or from one system to multiple systems to make sure that all the information is supposed to be there, to make sure that all the information is where it's supposed to be at the right time.

Even worse case is that hey, someone is manually copying from Google Sheets to Salesforce at the moment and the person just did not show up for work. Right. So you are missing data in Salesforce. Whereas if there is automation doing this for you, you don't really care about that person not showing up for work. So again, removing basically human errors from that workflow and making it a 100% reliable, that's the biggest selling point of automation. Besides these human errors, you are minimizing lead times and by lead time, I mean for example, you generate a lead on your website and you pass it to your CRM or maybe you generate a lead on Facebook and you pass it to your CRM immediately, real time. Right.

So the sales guys operating within your CRM can go and call the person in five minutes. But let's say there is no automation in place, so you are generating leads on Facebook and then once or maybe twice a day you go there, you download a CSV and again you manually type those records from that CSV to your CRM and then you figure out you made five mistakes, maybe you forgot two rows, and by the time you call the lead, they are that anyway. So really it's about being quick and being perfect and removing any sort of manual inputs.

Another cool thing I think is that in our businesses we might be doing tasks which we absolutely hate, and it's not very good for work morale. Right. So if you allow your employees to remove these boring tasks, which literally don't generate much of the business value and you let them focus on something which they like to do and which they know makes sense and which they know is going to actually generate some value, it's also very freeing for the employees that, okay, I don't have to worry about this boring part, which I've been doing for years and years manually. Now I will let machines do it and I can focus finally on something important. Shall I continue? It's like it's never ending list.

Lindsay McGuire: You can go on and on and on, I bet, right?

Daniel Zrust: Yeah, yeah exactly.

Lindsay McGuire: I could just let you go on for the next two hours.

Daniel Zrust: Yeah.

Lindsay McGuire: I love it though because you bring up so many things and it's kind of funny to listen to you and it just correlates so much into that stage of digital maturity report I brought back before. You're talking about these menial repetitive copy and paste tasks that literally we all hate. We can all admit we all hate doing these redundant, repetitive time wasters that suck us away from the things we really need to focus on. And we found in our research that 50% of employees spend at least two hours every day on things like this. It's crazy. That's so much time each week. And if you could just bring in some automation and some integrations that would eliminate that, what we found is that the more digitally mature an organization is, which usually means the more digitized, automated and have more their workflows in kind of an automated space, then the more healthy, happier and less stressed their employees are.

So why do you think it is important for organizations to be able to empower those people to make their own changes and to bring in these automations and integrate their tools? There's kind of been like a shift in the last three or five years I think with the no-code movement and what's happened with no-code. But why do you think it is important to be able to empower those people who don't have those technical skills, don't have the coding knowledge, don't have any of that IT know-how, but why should they be empowered to be able to do these things? Because it does seem kind of like a heavy lift at first, but like you said, it can take just a little bit of time to learn and get acclimated and then off you go.

Daniel Zrust: I would say that until recently there was scarcity on the [inaudible 00:16:12] market. Right. Maybe the times might be changing in the past few months, but moving into future, there will be always a scarcity of IT knowledgeable people. Right. Let's face it, it's probably not going to change that much. You have very ambitious employees who again might be hating parts of their jobs, which are repetitive and they want to do cool things, so they just want to remove that hurdle and focus on something what matters to them.

Lindsay McGuire: You brought up a good point though with the devs because I think it was in our rise of the no code economy report we released a few years ago, we talk about the fact that we just can't keep up with the demand for developers. I think there's something like if you look at the world population, it's like 1% of people in the professional working sphere can qualify as a developer. And so there's just not enough of those people to come in for those technical jobs. And I love our dev team at Formstack, don't get me wrong, but anytime I have to submit a request to our dev team, I'm like, oh no, because I know it's going to be a backlog and I know that it's going to take them while to get to my ticket in the queue, right?

Daniel Zrust: Yeah, exactly.

Lindsay McGuire: Because nobody has enough of them. And I even work in tech and I'm at a SaaS company, so if I don't have enough, I can't imagine other organizations that aren't in tech and what they come up against. And we actually found this correlation also in that digital maturity report. We found that organizations that are more digitally mature rely on no code to fill those gaps because they see that not only is there a limited supplies, people, they're getting more and more expensive year over year. And especially now you're looking at inflation and labor costs and all these crazy things coming into this perfect tornado. These organizations who are more digitally mature have seen that no code is a viable answer that can grow and be a part of their strategy over time. And so I think you made some really good points there about if you just shift your mindset to giving the freedom to these frontline employees, just amazing magical things can happen.

Daniel Zrust: Let's say that your organization has unlimited number of developers and you could ask anyone, but still if you have something really silly, you don't really need to have a developer for that. That developer can still be utilized for something more important, more strategic. Right. And the simple stuff, can be still automated with no code. It's not even about not really having the developers. It's like, Hey, let's allocate our time even if we have those resources wisely because time matters, right?

Lindsay McGuire: That is a really excellent point. And another one I will tie into that too is that sometimes even if you have access to those developers and you have the ability to submit your projects and your ideas, sometimes it can be difficult to communicate across those lines because you're almost talking different languages. I mean, in reality you are. I mean if you're going down actual coding, you are talking different languages.

Daniel Zrust: Yeah. You are.

Lindsay McGuire: But one thing that's really interesting with no code is it can kind of almost come in as a interpreter sometimes for those non-technical workers to say, this is what I'm thinking, this is what I really want the long term. And it can kind of be used as that MVP,

Daniel Zrust: Yeah, I was going to say.

Lindsay McGuire: To hand to devs.

Daniel Zrust: Exactly. Yeah. You automate your process, maybe it's not perfect, but hey, you come to your developers and say, Hey, this is step one, step two, step three. Here we edit router because there is some conditional logic to be made. Can you build this? Can you make a solid process out of it? Why not? Like yes, you can use it for prototyping, even within huge companies. Right. It doesn't have to be like [inaudible 00:19:33]. It can be on enterprises.

Lindsay McGuire: And I want to hit on that enterprise point. How can those larger organizations who have all of these different pieces of technology in their tech stack figure out almost like where to start, or what's the most crucial points to begin with, with their automation journey?

Daniel Zrust: So I guess all the points which we said at the beginning where to start, they are kind of valid. Right. They will still have to map out their processes, they will have to make their processes solid with no ambiguities. Right. It needs to be clear process, which needs to happen every single time the same way or maybe under a slightly different conditions. When it comes to the enterprise world there are two big differentiating factors. One is obviously security. Is your platform secure enough if I ask this really silly question? And then the other is support for enterprise related apps.

So at Make we do really focus on enterprise related apps, so we try to add more and more of them, but I can imagine that other platforms may not be that focused and it may not be on their plans because building an enterprise level app like Workday for example, it's usually not easy to get access to those APIs and making public for other companies. We allocate lots of resources to building these enterprise great apps for our customers. So there can be differences in the portfolio of enterprise apps on the marketplace. And obviously if you're like CIO, you are going to look into those, right? Because okay, I use this, this, this. How much of this stuff is supported?

Lindsay McGuire: So a second question to this conversation. If I am considering adding a new piece of technology to my organization, I have some kind of problem and I'm thinking about what tech can be brought in to be the solution. What are some things that I should be thinking about when looking into these new options? What are some things on the checklist that I should make sure this new piece of tech has so that it can work in the ecosystem of tools I already have?

Daniel Zrust: My first question would be, okay, so if I use this, how easy is it to connect to my other systems? Will I need to use our internal developers? If yes, probably a problem. Will I be just filed by using an automation platform like make.com? Yeah, it's fine. And if it's possible, what can I do within those automations? Are all the actions, are all the, let's say syncs between that new system and my existing systems, are they actually possible? So this would be the types of questions which I will be asking at the very beginning. And then there is always the user side of things, right? Because it's not always the IT guy who's operating with these systems.

So regular folks needs to be able to actually operate a system. Right. The interface needs to be easy to understand, it needs to allow them quickly do what they need to do. They can't be figuring it out two hours per day, how to do very basic tasks. Right. So usability and options for integrations would be kind of the two big things I would be asking. And obviously then there are objective factors like features and price, et cetera. But at the end of the day, when you bring in new system, it's about, okay, it's new. How well am I able to integrate it into my current stack?

Lindsay McGuire: And what are some key factors that make a tool easier to integrate into your current systems?

Daniel Zrust: Nowadays, when it's really modern app, those apps or services, they usually have integration sections somewhere within those services. So it's not always that you need to actually use an automation platform to integrate that new thing with your current systems. But very frequently those apps allow themselves to integrate with those systems of yours. Right. And now the question would be, okay, so if I use this native integration within the service, is it bringing over everything I need or is something missing? Right. And again, it's all about testing and playing with it and seeing whether it's good enough or not. And maybe then going for an automation platform, which generally speaking will be always more flexible because when there are native integrations built into those systems, then developers of that integration usually make choices. Right. They decide what they are going to allow, what fields will be there, et cetera.

However, with automation platforms, they generally will allow you to access more endpoints, more doors into the API. They will usually work with all available fields, which there are, et cetera. So these available integrations are a big thing. And if they are good enough for you, then you don't even need an automation platform. But frequently the truth is that maybe you'll be using native integration for five systems out of 10 and maybe for other five you will need to use automation platform because the native integrations are either not there at all or they're just not good enough. Another big thing is obviously level of support. Are there real people on the other side which you can talk to when you need? Right. If there is no one, it's just like chatbot, which doesn't really offer any important information, then you're not going to do a good job when you get stuck. Right. But if there are real people 24/7 available, then it's a big factor and people should factor that in, that good support is always important.

Lindsay McGuire: So can you talk a little bit about why it is important to try to avoid point solutions and just a single product for one single use case and why it's probably better to think about it as a kind of ecosystem or kind of like what are the possibilities with this tool versus I have problem A and here's solution B and we're done.

Daniel Zrust: So if you use a new piece of software for every little problem you are solving, it's going to be a nightmare for you even if you have perfect automations running between all the things in your stack. Let's face it, things go wrong. They're not going to work forever with no issues. Sometimes one of the services may not be responding when it's supposed to, right? And the more apps you add to your tech stack, the more likely you are going to see some failures. Sooner or later it's just going to happen and it's normal. It's not like, Hey, this doesn't work. So it's a bad tool. No, it's the way it is. It's just things fail and you have to take care of them. This is usually a number one thing for me to consider, Hey, do I really need this? Because it's going to create yet another dependency within my process or within my business, yet another thing to maintain, yet another thing to take care of the billing for. Right.

And sometimes you just forget to replace your card when it expires and you somehow have all your notifications in spam and one day that service stops working because you missed all the notifications. I know it's silly. It is silly. But these things, they happen in real life. When you are about minimizing risks, it's always to use less maybe with little compromises and just keep expanding and expanding all the systems which you could potentially use because you are going to create a spaghetti of dependencies on you and on the person who is supposed to maintain this. And now we can take it one step further, right, and let's say you've integrated, I don't know, 20 apps, and that person has been working on the project for five years with no documentation, and one day the person is gone, right? And you're supposed to bring in someone new. What do you do? It's going to be very difficult. You should be documenting everything you do. And if it's not you doing the automations, you should force your employees to document what they do.

Lindsay McGuire: Oh, I mean, if you're a listener who has listened to our past episodes this season, you know we are all about the documentation. Because if you don't have that documentation to back up exactly what's happening when and the know-how, I mean it is just a gamble, but a very, very risky gamble to take.

Daniel Zrust: Yeah. Exactly.

Lindsay McGuire: So that's a great, oh, it's a great point. And I think the thing to take away is do not create a spaghetti of dependencies. That is the takeaway from that portion of this. I love that description because it really is. I mean, I can see that and I can feel how sticky and messy it just, ugh. So let's avoid that and let's make sure we have documentation. Let's make sure that we're avoiding point solutions and we're integrating all our tools effectively and efficiently as far as we can. Well, Daniel, a few questions, kind of wrap up our conversation here. So why should innovative leaders care about integrating their tools?

Daniel Zrust: They have to care. They have no choice. They want to keep their data solids across all their tech stack. There is no why. They have to. It's what it is.

Lindsay McGuire: It's like the Yoda quote, right? There is no try. There's only dos. Is that right? Something in that realm. Someone corrected me, hit me up on social media because I don't think that's quite right, but the essence of that idea. Right. And so if you had one piece of advice for innovative leaders on how they can start to integrate and automate their tools, what would it be?

Daniel Zrust: I would say don't be scared and go and try it. You will see it doesn't hurt. Feel free to fail. It's normal. It's completely normal to see errors and failures. Every one of us have been there. Right. We all went through that phase. So it's completely normal. Don't feel like when something doesn't work, it is the end of the world. No, take it as information and do something about it and then proceed to the next step. But just go and try it.

Lindsay McGuire: And I will say, few things feel as amazing as when you do set up an automation and it does work.

Daniel Zrust: Exactly.

Lindsay McGuire: And you test it and you're like, oh my gosh, this works, this works. And then you're like, but is it actually going to work in the real life scenario? And then when it does, I mean, oh, and even things as silly as I talked about earlier. A lot of my automations live within my Monday boards with my projects and just setting something just as that small or even the automations in Formstack where you set up a workflow or an email that triggers automatically, I mean, it's just a beautiful feeling so.

Daniel Zrust: Yeah, you feel like superhero, right? You actually feel like a developer even though nothing about coding, right? But,

Lindsay McGuire: Don't tell my coder friends.

Daniel Zrust: Yeah. It's really what it is. I had those feelings myself when I was starting.

Lindsay McGuire: One last question for you. So what do you think makes practical ideas like integrating your tools and automating your work so genius?

Daniel Zrust: I think that that feeling of that something runs and you don't have to touch it and it just goes and goes forever. That's the genius idea, which I always feel.

Lindsay McGuire: And that's probably why you're still doing the work you're doing today, right?

Daniel Zrust: Yeah, of course. If I didn't like it, I would not be here.

Lindsay McGuire: Well, Daniel, thank you so much for taking so much time today to talk about integrating your tools and automating your workflows. I mean, it has really been a conversation chock full of great tips and advice, and I cannot wait for people to listen. Thank you so much for joining us for this great conversation with Daniel. I'm taking all of my notes from this amazing conversation and applying them to our Practically Genius insider newsletter, which you should definitely sign up for. You can do that by clicking the link in the show notes. And as always, rate, review, share on LinkedIn and tell another innovator about the show. You never know. You might just get your next practically genius idea right here.

‍