Automation works when you get clear on what’s real, what’s used, and what’s necessary
E12

Automation works when you get clear on what’s real, what’s used, and what’s necessary

BE_Ep12
===

​[00:00:00]

Blessing Richardson: I am no longer a fan of overhauling people's digital systems in their business. Not when most of my work is coming in and building more rigid and durable automated systems. And so, yes, I use tools sometimes like Zapier and these low code tools or no code tools to the workflows.

But oftentimes when I'm put into a project, somebody has scoped out a process in the business. That we ultimately want to take out of human hands and make mostly automated, if not fully automated. And so what that means is as I build out this [00:01:00] automation, I'm asking questions like, where should notifications get sent to?

Now with AI it's more like, you know, if the AI agent has questions and need to literally have a conversation with somebody, where should that conversation happen? If the agent needs information and data, where should look to go? If consistently find information like who your contacts or clients are.

Where should the agent go to know what's on your calendar? Where does the agent need to go to find your SOPs in your Wiki so it knows how to do the thing you're asking it to do. When I start to ask those questions, there's a myriad of things that come up like, well, technically the SOPs are split in different places and well, we don't really have a CRM that has all of our information together. Well, we have a marketing CRM, but like, not one that's really clean to like figuring out the clients or data. So data's like everywhere. There are files in Google Drive , there's Notion, there's a smattering here, and that makes it really difficult to build, if not simple, just sane systems.

Because the lack of decision around how we do things as an organization or as a team, that lack of decision [00:02:00] shows up as tech debt and complexity in our automated systems. And so when I get asked to help build an automation that takes work off of someone's plate, the first question is how well defined is the work to begin with?

And if we can't get to a real consensus around, if we have to write this down every single step from like one to like 100, all the little steps that happen, can we get close to like 60% of it? You know, if we can't get that kind of clarity, then there's all these hidden costs of automation that begin to crop up during the project and ultimately.

Really result in a horrible deployment of an automated system for the most part. And if we get to a successful deployment, then it runs really, really great. But then anytime anybody in the business needs to make a change, they get nervous. They get scared. And now we have this thing that does something that we need it to do when we built it, but now it's like six months later or eight months later and we just turn it off because we're too scared to touch it.

All that complexity has snowballed into this automation. And so I wanna talk more about that, but also what [00:03:00] actually works? What do we do if we're at a place where maybe building a fully automated process doesn't quite make sense yet, and what teams are actually really good at doing this thing?

I'm talking about handling and maintaining full automations. And then my advice for leaders who are trying to figure out how to get their teams to be this way. So what's the real cost? Well, the real cost can be counted in messy data and immature processes. Regardless of the size of business or the age or maturity of your business our businesses are kind of living and breathing.

There are always changes. We have new offerings, new products. There's new tech, there's changes that require us to pivot. We have new team members, older team members. We have all these things that mean that our data itself ages. And so because our data ages is often split into different tools and different systems, even in my own business, it is hard to say, I'm going to move off this platform I've been on for like 12 months, more than 12 months, and I'm gonna move totally into another platform.

And so we end up carrying all of this [00:04:00] systems and tech debt anyways. It splits our data and our data looks differently, and we don't have a single source of truth for our key data sets. In your business, you have some key data sets, especially as a service business.

Your client book, not just who your clients are, but how you've engaged with them over time , so your clients and their engagements, you have your audience if you're doing marketing, which are people who may or may not be your clients who want to be aware of things going on in your world and in your orbit, and are usually gonna be on your email list.

Yes, there's social media, there's all that other stuff, but if you have somebody's email, you can consider that a strong audience member because you have a direct line to that person. And so ultimately those roads lead to email. But then you do have your social media accounts and you have all your followers on them.

We also have our financial information. From the moment you transact a penny in your business and you get that as revenue, and the moment you have an expense in your business and you pay that out of your account, you now have [00:05:00] a financial data trail that doesn't just disappear because the books have been closed for the year and you filed your taxes.

I wish I knew this. So much better. But what can I do? I was like 17 when I started my online business. And I was freelancing for web design and graphic design and added photography about a year later. And I didn't know, I didn't know Jack anything. There's no way I could have future proofed my business for what is now the modern side of finance and bookkeeping and accounting for online businesses. There's no way. But I have technically all this cruft, all this data where if not only for accounting purposes, technically, if my books were really, really clean from back then I could go back and see every single person who paid me.

I can go back and figure out who I work with, how I work with them. I could circle back and say, Hey, it's been like, I don't know, 10 years. How are you, I could at least maintain those relationships if my data was clean. I could also have a singular view of the types of things that have made me money.

I can audit them and said, what are the types of [00:06:00] things I did that I did well? What were the costs and expenses associated with doing certain things? Sometimes we do launches online, like we do this whole marketing campaign and we spend all this money or maybe not that much money on doing these webinars.

And we do ads sometimes and we pay for all the software and stuff, but technically all those expenses are tied to ideally revenue generating activity. And if my data was set up correctly, I could tell that story. We can go on from category to category about different data sets in our business that are key for us to understand our own systems and processes.

But oftentimes they're fractured and split, which makes it really, really hard to tell the story of our business from a data perspective. AI cannot just magically make sense of that. The same way that everybody files their taxes quite uniquely, everyone's business is quite unique. In AI, there's no one singular AI that's gonna be able to look at a year's worth, let alone 10 years worth of data, and be able to tell the story of your business the way you would if you had a chance to tell it.

And so when I build these team members, these AI team members, yeah, having organized and [00:07:00] cleaned data where things literally, if you look at the spreadsheet or you look at the database and it makes sense to a person, it's like, okay, great. The AI would make sense of it. That's pretty magical.

But if the data isn't clean, now we have to do a lot more work When we build systems to make sure the systems understand the data and interpret it the right way. Unclear process is another thing that just, I mean, it will extend any project, particularly projects where the processes are ones where multiple people participate.

And we can't get the view of multiple people to actually tell the story about how this process really happened. Let's say I'm a photographer. I love going back to photography because I really understand that business personally. So I have a photography business and I have an assistant photographer, and I have an assistant who also takes calls.

Let's say I have those two people on my team and between the three of us. It is somehow handled that when somebody says they want a photo shoot, so when we do the photo shoot, give 'em their files. The three of us, we figure it out. Clients are happy.

To us every client is not the same. Every client is unique, which [00:08:00] also means that we believe that our process needs to be unique for every client as well. We have a little bit of special snowflake syndrome over here where it's okay if a client gets their initial call after they book with us on the website, they get that call from somebody in a day or two or three.

Like we like to get around in about a week, but eventually we make that call and whenever we take that call, it's okay for my assistant to have the notes in her head. Like, she'll just brief me on it the next time that we meet. And we might do that meeting on a Google meet or we might do it like over the phone, but like we're gonna meet at some point and we're gonna talk.

And then my assistant photographer again, it's okay if they figure out at some point when the shoot happens. 'cause technically we, like, we always, always, always mostly have a pre-shoot planning session about a week before the shoot.

That inconsistency in process means that if you now try to add an automated system into it, it doesn't know where to go to look for the call notes. It doesn't know when to anticipate that a photo shoot is confirmed. If it's technically only confirmed once we meet a week before the photo shoot.

But that's [00:09:00] inconsistent and it may or may not happen on a date that's on the calendar or not. The AI doesn't have anything to grapple with to join your process. The automations can't figure it out. Also that usually means that when you're sitting down talking to somebody trying to understand the process that you're gonna automate, it means that there's a lot of things that each person believes happened that may or may not really be true.

And the only story that is accurate is each person telling the story about what they do. I can't tell you the number of times I've seen a business leader get really frustrated in thinking that, well, I know how this happens.

You know, I wrote that document, I wrote that process. This is how this is supposed to work. And then we start talking to people and we realize like why things aren't working the way that they thought it was. And it's usually because they wrote it at a time where they were either part of the process themselves and they no longer are, or really their document, which sometimes gets passed on as an edict was really just a.

Paper napkin sketch because the people who actually do the thing are always gonna be the real arbiters of truth about how the thing gets [00:10:00] done. And so there's this bit of just like figuring out what really happens to make this process real. And then we go through and we do the conversion from semi-automated and a log in digital to mostly automated and digital.

So if our data isn't together and our processes aren't known, it becomes a longer endeavor, if not a little bit more painful to figure out what's the right way to automate something that actually helps the team. And automating a manual and analog process does not translate into a one-to-one systems automation, particularly when we start bringing in ai, that changes the nature of things quite a bit.

Another thing that really harms automation for teams. Like this is a, usually I find there's low tech adoption within the team itself. Like yeah, there might, there might be a bunch of software and subscriptions around that we say we use and some people use and others don't. But we don't have consistency around using a simple set of tools or a singular set of tools to accomplish specific outcomes.

And so one of the, the smells of [00:11:00] this is hearing, there's this manager, there's this team lead who doesn't like this app, and so we just, we have to call them, we have to message them because they don't really like this. Or we have a business leader who is wears explicitly by a certain system re tool. And all the other team members are like, yeah, this doesn't work for us.

And so we barely use it and we still have to meet a lot. Why is that a problem? Automated systems tend to do things asynchronously when we start automating larger and larger processes, which means that it does it when it kind of gets to it behind the scenes. It might not do things immediately.

If you ever built anything that runs on a webhook or a trigger, then you're building asynchronous systems, right? We don't know when the stripe payment is gonna come in, but we know when the payment comes in, these things happen. We don't know when the file's gonna show up in the Google drive, but the moment it does, all these things are gonna happen, and I don't need that system to check in with me to do it.

That's async. It's kind of doing it at its own pace, at its own time, based off other things. But a synchronous process is like when we're in a meeting together, we're all here at the same time. We're doing things together in a [00:12:00] synchronized fashion. We're having conversation, we're making decisions, which kind of defeats the purpose a little bit of having automated AI team members that do work while you sleep.

That is why not having a central hub and mature processes and clear systems for each of your processes that you want to automate often smells trouble when it comes to automating.

The last one, which I can kind of build around but is really helpful when there's a strong solution for is project management. Project management in any small team looks like having a place where we can go in and say, within this team, this is what's being worked on. Either that is a picture of what is happening today, this week, this month, this quarter, or this year.

There's a singular place where we can go and say, I know what is going on regarding this project, regarding the scope of work. There's one place to go there. The teams that I see do really well with project management are the ones that make a decision that says, if it's not in the project management tool, it's effectively not real. It's not that we don't talk about it in [00:13:00] Slack and Google Chat and all these other apps. It's just that when it comes to the PM tool, that is where the most up-to-date status of things have to live.

So those teams have rhythms like by end of day, wherever you are with this task, you update that status that says that you started on it, you're not working on it, or you're blocked and you need help. Just those simple rhythms mean that at any point, anyone who's a manager in an organization or who's a lead of a project can go look at that and say, well, I assigned this task to my assistant and my assistant photographer has this other task, and I can go see where we are in prepping for this photo shoot.

I can see that the email has gone out. I can see that. Oh yeah. We did send that referral to a stylist to make sure that the client is styled correctly. At least they have the option of opting for one. We have this whole like dashboard, a command center of understanding where we are in our different processes and tasks.

Why this matters for automations is because, well, naturally, if you have project management in it, there's no reason why your automations and your [00:14:00] AIs can't be assigned tasks. So you can have a place where the automation says, oh yeah, I got that task. I'm working on it. It says it to in progress. Oh yeah, I'm stuck on this.

The automation updates, it's blocked. See now we're not buried in Slack or even email to see this, where you go to see where everything else is happening in the business. It's naturally where your AI and your automation show up. And so I'm really a fan of teams that have that process in place, but I realize that that's a shift too on how we use our digital tools and how we work.

Oftentimes, it's more of a cultural shift and thinking about what does it mean to do things well, what does it mean to be courteous to other team members, so that way we have a shared understanding of what we're doing and how we're doing it. Those are all cultural things that often have to be in place to then make the tech adoption more seamless and more effortless within a team.

So what actually works? Let's say, you know what? This sounds like a dream. It might not even be my dream, but you know, it sounds like a thing. But you know, we're just not at a point today where we have this robust project management solution that we really [00:15:00] use or like this to-do list app.

Our conversation and communication, it's still scattered and we still feel like we have a bunch of tools, but we just need to automate. What I advise you to do is get clear on your systems. Honestly, there are three core hubs of tools that I recommend every business have when it comes to looking at your business from really the automation lens or the digital lens.

And one is your comms hub. I get email will always have its place. I can see that being used for HR emails. Formal announcements, right? I can see email always being reserved for that, but the most efficient teams I see, they tend to use chat tools like Slack.

There are other things, if it's a really simple team or like just a one-off project, they'll marry their project management tool and their chat tool as a one. So it's just one platform as a whole that they use. Otherwise, they tend to have a dedicated one. When you have people who work on multiple projects and multiple things.

But either way, we're making a choice about where we communicate about work and different things. The second one is project management. There are [00:16:00] some teams who will literally just run project management in Slack. Your project lead knows where to go. We do a check-in round.

Even if it's a meeting, we know that we post an update of status back to the Slack channel because we decided that this is where this information lives. And so whatever that is for you, you have chosen to say, this is the status of what is in progress, what is coming down the line and what has been done.

There's someplace where that lives. And then the last one is your business data itself. So where do we store our files in our databases? Now, before I would've just said files, but in truth, as we build data-driven businesses. And you have all these different data sets, like I mentioned, and they need a place to live.

And so that could look like your Airtable, your notion, your Smartsheet. It doesn't really matter. So long as we choose and we say, you know what? All the data that sits under this domain, all the finance data lives here, all of the client information data lives here. Well, technically we might have a marketing CRM that might have every single member in our audience, but still we know how we've tagged our clients.

And we have our client [00:17:00] database here. We're making these choices to say, data has to live somewhere, even if it's not perfect, even if it is a new choice. Data has to have a place, and you have to choose where it lives. And we have those three things in place.

We can come to that decision. Now building automations that run in the business and for the business is a lot more straightforward because then we can make sane assumptions about how those automations have to work in order for them to actually support the way everyone else works .

Now, who should really be spearheading this initiative? Who should really come in and say, okay, we need to get our stuff together. I believe it starts with the leaders because what I see is that if a leader doesn't champion the change, even though they might not be the ones necessarily spearheading it or actually leading the project, if they don't champion the change and say.

We're gonna stick to it for probably at least two quarters , if not a year, that we are going to not only say we're gonna change tools, but we're also gonna go through the training and we're going to adjust our pace of getting work done, our pace of client services and delivery to account for the fact we're [00:18:00] all learning something new.

We might even hire an outside firm to jump us across the timeline to getting something built, knowing that it's still gonna take time from us to communicate how we want our processes to work. To paint the dream and then build it reasonably. It might even take us time to do that, but we know we're gonna invest the time and commit to doing this migration because when I hear this dissension from the leaders, what team members say is.

OK, yeah, but like so and so didn't really like this, so it's probably not gonna stick around. And then people check out. They check out if it is somebody more junior in the organization that's really spearheading this, and it might be their idea, but the leaders does not take this up and become the champion.

Then what this becomes pigeonholed as is, well this is this person's project, is this person's like initiative, and when now it needs to be a team effort to own. The automations and to own the systems and to take ownership in how the process is developed and maintained. What people say is, well, this was Blessing's project anyways, so like, shouldn't she be the one to update the system?

Even though like what happens in accounting [00:19:00] isn't technically Blessing's like job, but because she understands Airtable the best, then maybe it's Blessing's job to fix the Airtable. Hmm. That's a trap. It's a trap because the people who understand what the data is and how it works are often the ones who should be given the specifications for how it should be built and maintained.

They're the only ones who are gonna know if something is really wrong. Sure, from like a tech perspective, I might be able to make some reasonable assumptions about how this should work, but if I don't know your process, I don't understand your data, I can see the data. But if I don't understand what it means to the business, if I don't know why it's a big deal, that in this column one decimal being off is a problem, I might not be the best one to actually maintain the system and do the audit.

It might have to be a paired job. And so what we want inside of our teams is an environment where people feel comfortable to come up with innovation. We want leaders who will be the champion of change themselves and back up their team members and their consultants who come in to actually deliver that change.

We want leaders who [00:20:00] encourage team members to come up with new things to quote, automate themselves out of a job, which is very common inside of tech spaces. I find that it is quite hostile outside of it because the idea of automating myself out of a job somehow sounds like I won't have a job. When in reality there's always work to do.

There's always so much work to do there. You automate yourself out of one role. You should be promoting yourself into the next, but that takes a culture. That takes a culture to believe that is so, and it takes leaders to deliver on that promise. If you want your teams to be naturally innovative for the innovation or the pace of innovation, to not break the teams, there has to be an understanding of how processes or systems are connected.

If I go on Airtable and start changing, you know, column names and start redesigning views and moving buttons and boxes in places, who am I impacting? Who's process am I breaking? Who's gonna wake up today and go, I don't know what just happened. I can't do my job I wanna know who touched that because I'm actually responsible for how that works.

And I was not aware of the changes. I wasn't even involved in the decision making. So there has to be some ownership and authority into who owns what parts of these systems and these [00:21:00] automations. And I think people also have to feel free to have ideas even about processes that aren't theirs because they are connected.

There's nothing that we love more inside of tech informed opinions, like informed and opinionated is great. Uninformed and opinionated. That might get you hurt in some places. Okay. So we like, we like an informed, opinionated person and anybody who was touched or affected by a process should technically have the freedom to suggest improvements or at least to speak to the things that they might be seeing that could be improved. Do we have a culture and a forum for that kind of feedback? All these things kind of parlay into this thing that in tech we like to call continuous improvement. Because again, our businesses are living and ever changing, and our tech is always living and ever changing.

If you're not using legacy software, which means that there's always gonna be something to change, there's always gonna be something to fix, and if nothing else, as a business leader, I'd imagine what you would want is for your teams to be ahead of the curve, not too far ahead, but just enough to be thinking about how can we do the things that we're doing [00:22:00] better, more effectively.

Possibly more efficiently where efficiency is necessary. Might be places where you actually should not be looking for efficiency. How do you then make other areas efficient so you can spend time where you should be spending time?

These are all the characteristics of teams that when we start to answer these questions and shift our thinking around what it means to do well when it comes to working digitally. Building the automations is kind of trivial at that point. It's very easy. As a matter of fact, your team members begin to envision and ideate their own solutions.

Which brings me back to, I think the last thing, which many people might have thought was the first thing, which is your tools. If your tools themselves allow for team members who should have the rights and the permissions to, they've probably gone through their trainings and understand how to use the tool.

They know how to build their own automations and they can build their own systems. Well then your company is now automating like it's a core tenet of its existence, if you decide to put a rule in place that says, anytime we do anything three times, we should be having a conversation about how we automate it.

Is this something that needs to be formalized and in [00:23:00] any way should it be formalized to just one person's role, as in it's a personal automation and it's fine, which means whether or not it breaks, you should still have a way to do it and the whole process should get done. Is it like a task at that point, or is this like a whole automated system that the company needs to own collectively?

The whole team needs to own this thing. Because we're gonna treat this automated system like a team member. We're gonna delegate work and hold to it, and we need to know that it's gonna do it consistently. So does that require a bit of a deeper conversation, but a bit more strategy, a little bit more design, and more thought into what it does and who does it and who maintains it.

These are all conversations and things that I think help to make automation much more of a natural byproduct of a team. Meaning that we don't need this, massive quantum leap or initiative to quote, go digital or do automation. It's just in how we do things. It's just in the way that we think and in those kind of environments, it's a lot easier to come in and say, okay, we have, these automations but we wanna build something that's a bit more [00:24:00] polished.

We actually want to do more of what we have. We wanna consolidate. Simplify, knowing that it might mean a more complex system, but it doesn't necessarily mean complicated because now we can measure the trade off and the value of building this kind of automation and delegating this whole task. We know how much time it takes people to do.

Why? Because we have project management in place. We know about how many times to go back and forth figuring things out. Why? Because we have observable conversation about it. Oh, we know that we need, like, you know, these 10 bits of information to complete this task. Why? Because, well, I pulled the files from here in Google Drive.

The data lives in this database over here. We know we need our CRM over here. We know we referenced these dates on our calendar here. We can begin to piece that together, even if it's not perfect. Having some process in place and having a culture around automation and innovation means that it's a lot easier of a lift.

When we start to actually build automations and then to do all of that, then throw on a conversation about, well, you know, maybe we should make an overhaul to the systems we're using. Come on. I have learned the hard way that [00:25:00] does not breed success. So to summarize all that, if you're listening to this going, this is a dream, but I don't like any of my systems or processes enough to marry them, to the point where we're gonna start to build.

More mature and more permanent automations, more permanent digital team members into the team. I don't like them enough to be comfortable with that. Then we're back at the systems step and we need to go back and probably update and rehab some of our systems and our processes before we get to a point of saying, okay, this is great.

Now we want to cement this, want to build more custom digital stuff on top of it to do more and more and amplify what we're already doing.

If there's nothing else you take away from this there's a culture to innovation, there's a mindset. This is not, you know, an academic debrief on what that is. But I did call out some characteristics and things that I know that show up in teams that do well with automated systems.

There is a culture to automation. It does require a leader to be a champion, not necessarily be the person who implements it, but to be a champion. And so from that [00:26:00] perspective, consider ways that you can foster a learning environment, foster an environment that is resilient to mistakes. How do we create an environment where we are resistant to failure? How do we create an environment that applauds ideas? How do we create an environment that helps people become informed rapidly so they can have informed opinions and ideas?

And while you know, there's always a reason to somehow justify an overhaul, you know, everything is permissible, but not everything's beneficial. So to that end, keep what works. If we don't know what will be gained from really bringing in some form of heavy automation. Keep what works. When you spend time to automate things.

Address the pain points, address the points of friction. Address the things that need help. That way we know that if we're going to go through some unpleasant change or things that take longer. We always have this access of evaluating.

Is it really worth it or do we need to go back to what works? We can first identify, does this action need an automation to begin with? If you have ever undergone an automation [00:27:00] project and at some point through it you realize this was a bit more involved than we thought, I would love to hear your stories. Please find me on socials at Blessing Effect. That is B-L-E-S-S-I-G-E-F-F-E-C-T. You can find me on Instagram or threads and I'm always a fan of a good voice note, so if you send me like a nice audio note, your girl's gonna listen, so please send that over.

I'm always learning about how to present tech projects to different people that makes it easier for them to go on that journey of transformation. And so I would love to hear your stories.