How To Get Your Team Out Of Process Documentation Hell Using AI & Automation

Read The Transcript:

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

Galen Low: Welcome to our panel discussion on getting your team out of process documentation hell using automation and AI and other technology. We do events like this once every month as a way for our members and our VIP guests to engage directly with the experts who contribute and collaborate with us here at The Digital Project Manager.

For those of you who don't know me, my name is Galen Low. I am the co-founder of The Digital Project Manager and your host for today. And I've also got with me an amazing trio of agency operations experts — Alyson Caffrey, Gray Mackenzie, and Brian Kessman. Let's dive in. 

Today, we are exploring the practical realities of whether AI automation and other bits of tech can help take away that pain of documenting and reinforcing your processes so that your teams can finally function consistently, predictably, effectively, all those good adverbs. I would say that most teams at agencies and also within other organizations are actually quite terrible at standardizing project and operational processes and also writing them down.

Maybe it's because they see every project or person doing the job as being different sort of unique snowflakes. Maybe it's because they want to foster this culture of building the plane while they fly it. Or maybe they just have this internal allergy to standardization. A lot of the time, like intentions are good and the blocker is often time. For agencies, it's non billable time that's leaving money on the table.

For small businesses, it's an opportunity cost. For any team, it's tedious, it's boring, it's repetitive. Yeah, usually there's something, right? Usually there's like a wiki, but maybe it's not up to date or there's a pile of screen recordings waiting to be transcribed or polished or turned into a full document.

And sometimes the process is honestly just an oral tradition passed down from person to person with no written record at all. But the problem is, without good process documentation, your team's going to be lost, your stakeholders are going to be confused, and your organization won't be able to scale towards its goals.

So really the question I wanted to discuss and explore today, not as a lesson, but as a conversation is why isn't there a better way in this day and age of AI-driven technology and all of this process automation to make process documentation and adoption, just like smoother auto magic, aren't we there yet? I suspect the answer is yes and no, but I thought maybe we could dive into it. 

Let's start with the big question, which is why is creating process documentation and standard operating procedures so painful in agencies and other organizations? Aly, do you want to lead us off? You deal with a lot of folks in process pain. 

Alyson Caffrey: Oh yeah, we do a lot of documentation work at Operations Agency. And I think what folks struggle to, I think, understand with it is that it's not a one and done project, right? So we can't just bite this project off one time and not think that it's going to need to be updated or refined or amplified over time, and so there's usually a three phase process in which I like assess whether a process is good or not good, right? 

And the first is we need to understand that we can be in these three phases. And only when we understand where we are, can we effectively create documentation or work to get ourselves into the next bucket. So the cycle is first you test something. So let's just say, one of the key processes in any business, right, is how do we generate leads, right? Let's just use that one as an example. The first thing that we want to do is we say, Oh, are we in the testing phase of this? Are we throwing the spaghetti at the wall and figuring out what's going to net us the best leads and the highest quality prospects and things like that?

The second phase is the adjusting phase. So maybe we found a pretty good way, but we need to like work on the copy or work on the platform that we're putting this on. And so are we in that adjusting phase? And then the third phase is the operationalized phase, right, and the amplify. So you can actually operationalize it and then you can scale it, right?

So I think a lot of people think that they're in the operationalized phase and then they go to do their documentation. And then they're like, actually, I'm in the testing phase. And so that's why when I saw shelf life come into the chat, I was like, yeah, shelf life is going to suffer if you're in the testing phase, because you're constantly going to need to be updating best practices and ways that you're finding on doing things.

So I think before you sit down to tackle a documentation project, we need to take a look at the four major processes in the business. How do we get leads? How do we convert those leads? How do we fulfill and keep the promises that we make to clients? And then how do we improve? Those are the four big things.

Like we don't have to complicate it. And then we ask ourselves the question, are we testing lead getting? Are we testing, conversion mechanisms? And if the answer is yes, then we might need to do a little bit more work before we write stuff down. 

Galen Low: I love that. And I see that happen so much and I'm guilty of it too.

Or I'm like, we're testing this thing. I better write it down so we can, I don't know, test harder. And then come back six months later. I'm like, well, this document, I didn't even finish writing a sentence in it. Like it was a good intention, but not the right stage. And I love that you've broken it down into like different parts of the business, not necessarily to oversimplify, but to reduce the overwhelm of, Hey, let's document everything we do in our company today.

Alyson Caffrey: Yeah. Because if you've got like the temperature of the room when you're on a sales call, like that's too much documentation. Like we got to ratchet that back a little bit. So be encouraged by the answer is like first assess where you are and figure out whether or not documentation is actually just a pipe dream or whether you can actually do it. And then of course, don't go too far in any direction.

Right. Because if we are new to this process documenting game, you want to be able to stay lean and stay nimble with, that resource. 

Galen Low: Brian, I'm wondering if you've got anything to add to that. I know you're like you're working in sort of op model and strategy specifically for agencies. Where does process documentation come in and like, how are you framing it to your clients about this is important at these times and yes, it's going to be a pain or maybe here's how it won't be a pain?

Brian Kessman: When a client contacts me and we start talking about process, I have to point them back to the strategy of their overall organization because process is what makes the strategy come to life in the end.

Right. And so there's a few, I mean, I think you asked originally, like, why is it so painful? Process documentation is so painful in agencies. And I think there's a question of what factors need to be or what pieces need to be put into place for it to even be possible. There's things that I see all the time if an agency's business strategy is that we're a firm for all kinds of clients and we do all kinds of work.

Well, there's never going to be a standardized process in that type of environment, right? And I've seen that way too many times. Because you get, what happens is lots of reinvention of services. Every project's different, recreating the wheel, all of that. So how can you possibly have a process for that?

Even if you try, it's going to change, right? And so that just creates frustration, burnout, all the stuff that you know, right. But there's other things at play, which is the agency business model in general. It's actually working against an agency's own success. If the agency is still using a labor-based business model, selling billable hours, the culture and the priorities for the business are going to be influenced by billable utilization.

And so it's always going to be about getting work done, not internal process, servicing client needs first and foremost. And then there's one other piece of that I'll add in, and that's usually team structure. That also creates some complexity. The traditional team structure that I see all the time really fosters the wrong mindset and behaviors.

So the example is when today, like most traditional firms, new work comes in and people are going to be assigned to projects from different disciplines. We're going to pluck who's available or who's right for the job, that Hollywood model, casting the right talent for the job. But every project that a team member's on has its own set of meetings.

So meetings start to multiply, communication overhead multiplies. And so rather than, in a dedicated team structure or the pod model, I think others know it by, and that's where the team stays together from project to project. And what that does, it builds a shared sense of team and the group is really focused on working better together.

And there's not going to be resistance to process in that setting as there will be in a temporary project team setting. And so there's greater ownership and interest. And you're going to be working with that team together ongoing. So how do we just figure out how to work better together? Everyone's invested in it.

So I think those are some of the key pieces and that's the lens that I look at the question through. 

Galen Low: I love that because I've worked in agencies and other organizations of various sizes. And one of the hardest things to do is like wholesale rollout, a process across the entire organization.

And you would need to do that if you had these sort of temporary teams that are always dynamic and, like, how are we doing things all the same way? The answer is no one ever does in that configuration. But if it's a team process, then like a) it's actually everybody's job to own that process, deliver that process, document that process.

And it's not this thing that you have to go and evangelize and convince the rest of the organization is something that is more localized and therefore less painful to define, I guess. 

Brian Kessman: Yeah. And I think there's still a layer of foundational structure for the firms, such as everybody needs to use the same project management system so that we can work across groups and teams and all that. But then there's also the team level culture and process wide. Right. And so how do we create that? 

Galen Low: Love that. 

I'm imagining that all three of you probably encounter clients and folks in your network who just want to fight you. They want to fight you tooth and nail on not investing. They want to not invest in their sort of process ecosystem.

How do you frame the value of this sort of investment of time to your sort of naysayer? It's just great. I know that in my conversations with you, I know that this is it comes up, right, when you're working with clients of we don't need to do this, Gray. It seems like a waste. Can't we just plug in the machine, turn it on and start making more money?

How do you frame the value of this sort of endeavor? 

Gray Mackenzie: The reason that this feels like hell or we can't make time for it in a lot of cases is because we're not getting value from it. Nobody, oh, at least very rarely are owners saying, boy, these sales calls take a lot of time. I just can't make time for sales calls.

It's no, because we've seen the value that comes out of a sales call. But the reality is most people have not experienced the value that comes from really well done processes where you can actually hand stuff off. Aly, a question I want to come back to you on at some point is what is the threshold?

How do we know when we're now in the operationalize or amplify phase, what are the benchmarks for that? And we've got some thoughts around how we identify where can we scale this or not. But that's the reason that it's hard for folks to value this or create time for it. And it's because they haven't experienced the benefit that comes from having really easy to deploy, right processes for their team to be able to delegate quickly and save time. 

Ultimately, if it's done well, you're getting value on two different hands. The first one is the efficiency. So it's either, Hey, we can do things faster, or we may even be doing things slower, but we're doing it with more cost efficient labor model. So it's on that side. And then the other side of it is what's the outcome? What's the efficacy of what we're doing? Not efficiency, but how effective is what we're doing. And so that piece is around, Hey, remember the last three times that we did this and we screwed it up twice and that one client left because of that's the pain that we're trying to avoid.

So in terms of framing the value, it'll be on one of those two sides at a minimum, usually two. But everyone is feeling a different component of that. So, that's where I'll try to drill into conversations with folks and figure out, Hey what piece is the one that hurts the most to help motivate you?

You've got process either way. There is a process currently, it's just not documented. Everyone's got a different process for how they do it, but there's a process for how things happen. Right now, either way, you're going to invest, you're either going to pay in the consequences for not having done this on the front end, or you're going to pay some upfront work to make things smoother in the future.

You can decide where you want the pain and the payment to happen, but you're going to pay for it either way. And really, this is about not necessarily, Hey, do you have to work with ZenPilot to do this or not? We've agreed process makes sense for you and you decide what piece is going to motivate you.

I'm trying to help folks get motivated to take that step towards, Hey, let's invest in the areas where we ought to be investing here. 

Galen Low: I knew you would go to the attribution things, like people not seeing the benefit directly from good process design and documentation, but I hadn't thought of the other thing, which is most of us haven't seen what good looks like yet, but the pain we have is real. 

The pain we have is real and we can get to good that would solve that pain. And I like that sort of measurement angle. It's yeah, we all have the stories of the client that left, but are we measuring the sort of benefit of some of the improvements we're making to process? 

I do think I like that you threw it to Aly and I want to go there actually, if we could, before we dive into some practical stuff, I think the threshold question is interesting. It's like, when do you know that you've moved from testing to the next phase and that phase to operationalization? When do you know when the right time is to start writing stuff down? 

Alyson Caffrey: So I think this is an excellent question, Gray. And honestly, I get asked this a lot and I'm going to tell a story first and then I'll get a little bit more tactical.

When I was in high school, I used to keep the stats for basketball. And that taught me a lot because I was never a basketball player. I'm like a whopping 5'2, never was a great basketball player. I always wanted to be, I love to watch basketball. I love to be involved in the sport. And so we would keep these stats and what I would see in the stats being handed over to the coaches is that the coaches would take the stats and then they would augment the way that they would practice the next day. 

And I think that's a really important analogy to wrap our heads around at our agency. Because if we are moving from testing to changing, augmenting process, we first need to measure the impact of some of those things, right? Whether that's, decreasing our cost per lead or increasing our lifetime value or increasing our gross profit on projects, right?

Those are three really key components that if I'm testing something, I'm changing some things around, I can keep those kind of three big numbers in my purview or whichever numbers I'm hoping that these implementation of processes will actually affect. And then I can start to say, cool, now that I know that this particular project structure or tackling quality assurance or revisions in this way helps us keep clients longer or have higher gross profit on our projects, now it's time to put that thing down on paper because I've done a required amount of connection between the business improvement metrics.

The other thing is like I think Kobe Bryant said, best never get bored with the basics. Like you have to do the reps. I think a lot of us think that we go to change a process or we go to implement something. And I think instead of saying that thing doesn't work in the very beginning, we actually don't give ourselves a long enough runway to see if it does improve our agency over time.

That proverbial shiny object syndrome, like every little thing looks like grass is greener on the other side. So I always encourage my agency owners to connect process improvement with an actual business metric that they can actually see that it does improve the business. And then the second is actually give yourself enough runway to make sure that this works.

Usually I like to do 90 days. It's a really elegant, it's a quarter of time. You're usually measuring things in the business at that rate anyway. So I'm a big fan of the give it 90 days and see how it works. 

Galen Low: I like that whole thing around we all have process because we're all doing something, but maybe we shouldn't make it until we know it's working.

And in order to know it's working, we have to be, we have to give it enough time and we have to be intentional about what we're measuring before we just throw it away or before we start spending like three days a week, 24 hours a week to like writing process down without knowing if it works. 

I wonder if maybe we can dive into sort of some tips and best practices, but just wondering what tools and technology are you all using with your clients to remove that pain when you get to that point of creating process documentation?

And also are these tools working for them? Are there situations where actually it ends up holding them back and you're like no, we actually probably shouldn't use this. Aly, I thought I'd start with you because I was watching the webinar you were on last week with Marcel, you had said something that jumped out.

You said, record your screen. And I remember you had said that to me like three years ago. And I was like cool. Yeah, I got it. And now AI is changing everything. It's not just recording your screen. There's more to it. Can you share about some of like how that works for your clients in terms of taking a screen recording and then having it come out as something that is a usable sort of referenceable process?

Alyson Caffrey: Yes. And Loom, anybody there, if you're listening, please sponsor me. I'm a big fan of Loom. Loom also just recently released as a, I think a few months ago, like an AI feature to create documents and things like that. That is personally my favorite kind of landing place for documenting processes, at least in the very beginning.

So the two reasons I love it are because they bookend the documentation experience. The first is if you don't have processes and you don't have time to create processes and all those things, what's likely happening is you're working in your business. And if you can fold that time and record your screen and show somebody else how you're getting these types of results, even if the process isn't perfect, they can likely take that video and pick that up.

Or you can get a I to work on a document for somebody and then they can go replicate that again, even if it's not perfect, even if it's not massively scalable, if we're still in that testing phase, right? So that's number one bookend. The end bookend, which I actually think is super important is that when you go and use AI to create your processes, so we use Scribe quite a bit with our clients.

I use Loom and the AI function because that fits best with my workflow. But when you are writing all of your processes, I think what AI can do a really great job of is organizing, categorizing step by step and making sure that things look nice and readable and flowable. But the real secret sauce, I think, especially for agencies that are looking to grow quickly is keeping quality under control and at the forefront.

So we can go through a process, but somebody can phone it in, but we really need to know to use Tony Robbins's definition. He says definition of done, right? What is that thing that we should walk away with? And I think recording your screen does a fantastic job of being like, this is what the website wireframe should look like.

If you've run this process correctly, then having a wealth of examples through the one on one work that either you've done or an account director or a lead builder at your agency has done can help amass multiple examples of what this quality should look like at your agency. So Loom all day.

When in doubt, Loom it out, is my opinion. 

Galen Low: Does the Loom side ever create any sort of I was gonna say limitations for folks? I was thinking of a) that paralysis of okay, well, we won't document this process until we have a wireframe that's good enough to be the benchmark of quality in this Loom video.

And secondly, I imagine there's a lot of folks who are like, please don't make me go on camera. I don't want to be recorded. I don't want to, be documented. Just let me type. 

Alyson Caffrey: I mean, no, you don't have to be recorded, so you don't have to turn your camera on. You can just, show your screen and kind of talk through things.

I think that's a really important thing. And then zooming out 30,000 feet, like my opinion on operations isn't that operations in a business exists to put red tape all over stuff. It really just shows us how we rebound, like how we fix stuff that we break so that nothing falls through the cracks, right?

It like seals a nice foundation for us. Because we shouldn't believe that for an entire year or for an entire three years that we're never going to find a better way to do something. That's just asinine, right? Like we're always going to find better ways to do things. Our processes are going to be improving.

They're going to be changing. And so to me, I'm like, well, I'd rather just swap out a Loom video on something I found a better way to do a week from now, rather than go through the whole process of updating the SOP and then putting it into our knowledge base and then rolling it out to the team.

Those are for the things that we've already made it into phase three on right that we know we want to amplify and then I'd want to train somebody on in terms of a best practice. So I love Loom. It's a great like little incubator tool to be able to share some of the things in my opinion that I'm working on that other people can help me with.

Galen Low: Love that. 

Brian, I thought maybe I'd throw to you of, are there any other sort of tools and techniques sort of technology hacks, I guess, so to speak that you've seen your clients working with, or that you're recommending to your clients in terms of just like how they are capturing the process of what they're doing?

Brian Kessman: So just a little context on the role I play in this campaign. So there's two ways that I would help related to your question. One is first setting up an AI council with the agency so that we can determine their tech strategy and policies, all of that, and quality expectations, data security, all of that, and we choose the right tools.

The second is not necessarily documenting the process on their behalf, but creating the work sessions so that we can get that from the teams, right? So that they all have that ownership over that process. And then I'll coach somebody on how to now build that out. So there are a couple of tools that we would use.

But we need to figure out, are we writing documentation for people? Or are we writing documentation for machines to automate workflows? And so there's two categories there. That's how I look at it, right? So for people, it's got to be easily consumable, right? So the tools that we focus on there is custom GPTs or assistants through OpenAI, and that's really easy for drafting processes. 

Take what you learned in those work sessions or from interviews with team members and let the custom GPT, however you configure it, write the documentation, organize your insights, the analysis, all of that as a draft. There's also, this, you all know this workflow platforms, ClickUp, Monday.com, Notion, everything has AI built in now. So is that enough? Do we really need to introduce another tool? 

On the video side, though, Loom is excellent. I'm not familiar with Loom's full capabilities, but I have come across a tool called Tango. If you're familiar with it, you have screen recordings and it creates the chapters and the documentation for you.

I mean, you just walk through it and it'll take care of basically most of the tasks. Scribe is another, someone was mentioning that in the chat. If you're a product manager, ChatPRD is a great product for writing product requirement docs. And test it for other purposes too. You'd be surprised what you get back and it can be really helpful.

And then Jasper for marketing needs. So that's all the people side of things. But then there's for the machines, right? And so the recent news from OpenAI or others in the industry are saying OpenAI will be publishing their first agent or releasing their first agent functionality by the end of the year or early next year.

So now agents can follow workflow. You can automate workflows with your agents. And so if that's true that's amazing. I'm interested to see what that's but there are other tools out there now where you can do that. And it's all about prompting the AI to follow this specific steps of your workflow and then combining all those agents to complete that workflow.

And so Copy AI is great for any sort of go to market or sales or marketing needs. There's make.com, I believe it is, right, for just general workflows. And writer.com also can automate workflows. So all of those are really powerful tools. And so that's how I look at it. It's really those two categories.

I can keep going. 

Galen Low: I hadn't even really necessarily grouped them together in my mind, the sort of process for humans and process for machines. Like automation, I think of as sure, we're going to document steps, but I like this notion of approaching it a different way to create an experience for whoever is going to be executing the task or whatever is going to be executing the task.

And yeah, this notion of agents has been like flooding my feed recently, right, of Oh no, agents are coming and they're taking your jobs and blah, blah, blah. But I love that thought of how can we set ourselves up for success so that we can feed this in to an agent situation. 

Brian Kessman: Well, the nice thing is that it's really not all that different, right?

If you're speaking to the, or typing to the AI, as you would a human in terms of setting those expectations, providing the inputs, giving examples of the quality you're expecting. It's all just natural. So it's just a matter of how you break it up into specific agents. And that's really the hardest part of it all.

And there's UI interface you need to learn how to navigate. Generally, pretty easy. You can probably figure it out in half a day. 

Galen Low: Is there like a criteria you follow to be like, this has to be a human process right now, and this is something that we should automate? What does that sort of conversation look like, and?

Brian Kessman: Yeah, well, I start by thinking about who's going to be following the process in terms of, are they looking for is it predictable? Is it a predictable process? You're not going to need any guidance. There's no question whatsoever. The inputs, again, you can define those really clearly. You can set the expectation for outputs.

You have example, and it can complete a task from start to finish, great. Let's see if we can automate that. Still, there's always human revision or review, but you can also create an agent to do that for you as a first step too. And then can give it to yourself. So that's what I look for. Right. And then the other areas, the people side where we can automate, it's going to be, is there a trust?

Is there a need for greater trust? Is there a need to tap into unique experiences? Are there nuances that we need to think about or navigate? And so if we put them into those two categories, we can start to figure out what is appropriate for automation. 

Galen Low: I thought maybe I'd shift this into the other bookend, I guess, thinking about Aly's model, not just the documentation, but also we're getting there with you, Brian, anyways, right?

Like the, how are people using this process or this documentation to do their jobs and how are we iterating on it? And how are we improving it? How do people actually adopt these? And I saw this in the chat earlier where, someone's yes, adoption resistance is something, it's real. It's something I'm dealing with right now.

Around these pain points about like finding the documentation when you need it, what tools have been effective for you at being able to just put this information at the fingertips of the people doing the work, so that they're not like searching through the J drive or whatever. Also, does anyone have an SOP chat bot yet?

Gray, I thought maybe I'd take that to you because, I know that there is a lot of this woven into some of these productivity platforms. And, Brian, to your point, like some of the automation and AI is inbuilt. How are you helping people have these processes at their fingertips so that they actually use them and want to use them?

Gray Mackenzie: Yeah, I think that's one of the big drivers for not finding value out of this. It's I wrote this all one on the binder on the shelf, and then, oh man, it got opened again next year. I was very inspired to look at it. Huge believer in make the process live where the work gets done. That's one of our core pillars of the ZenPilot methodology is, we're signing out work to people to do, we want to make the SOP linked to directly from that task. So wherever we can, we want to have that in place already. We may not have an SOP, that's fine. There's ad hoc stuff that comes up, but there's an awful lot of repeatable work that happens in most organizations.

And so link to it directly from the task itself. That piece helps a lot. And then the other piece is just, this is a habits problem. Like most of this is a habits problem. We can talk about, maybe if we have time, I'll talk about a a custom GPT as well that we're using. But a lot of this is like culturally we get what we tolerate and we get what we celebrate that determines what we wind up getting in anything.

And so the same thing applies with process adoption or people doing if you're fine saying, hey, you're good at what you do. And generally things work out well. So I don't care if you do things in the wrong order or you're constantly Slacking people asking for updates instead of checking the PM system. Even though I said everybody keep everything up to date. Then you're tolerating non adoption. So you're going to get more of that. That's just inevitably going to happen. So it's like any other habit. They're all hard to build at first and they get way easier once, you don't even think about it once it becomes a routine, but building that habit of not tolerating, not using the process.

And part of that not tolerating has to be like, well, what's the reason? We've got to be a little bit introspective and realize you're not following it because it's a bad process or because it's too cumbersome to, you know, Aly and Brian both mentioned, Hey, how do we make this simple and consumable for people?

And that's a piece of it. If you throw a six minute Loom video to me, there's no way I want the, I'll follow that my first time ever doing it. Other than that give me the bullet points real quickly. So using Loom to get it, that's way more efficient to get it out for the first time. That makes total sense.

Using Loom for somebody's first time doing it or first time doing it in a long time, that makes total sense. But then combining that with, Hey, here's the bullet points and here's the timestamp to go grab what you need. Okay, now we're talking, now I can go grab what that is. So I think it's gotta be, Hey, we've got to make these as accessible as possible, make the process live for the work it's done.

And then don't tolerate and make sure that we do celebrate the consistency that we're bringing from those new processes. And to Aly's point, like gross margin in most of our clients cases, that's the core thing that we're going to influence with process work. We got to celebrate the advances that we're making there.

Galen Low: I'm totally that guy too. Like I feel so triggered right now. Cause I'm that person I'm like, yeah, you're smart. If you don't follow the process, like that's fine. Like I celebrate you because I hired you as a smart individual, but it doesn't mean that them following a process makes them not smart.

My why for having a process is so that when I don't have a small team, my team gets bigger, it's not the wild West, right. And we can grow and it won't be chaos. And so if I can remember that, then, it will be a lot of work for me not to celebrate just sort of like yeah, be a professional human.

That's fine. I know you get the job done without seeing the long game, which is but later when I have 27 smart, capable humans, all doing different stuff, all doing one thing, 27 different ways, yeah, it's going to be a problem. 

Can we dive into that custom GPT? Now I'm intrigued. You teased it.

Gray Mackenzie: Yeah. So, there's a couple of different ones that have been very helpful for us, but one simple one is so we're helping teams take the processes they have and build outcome. What is the workflow look like in ClickUp specifically? And so that means, hey, we're using a parent task here is your deliverable and then each of the individual action tasks or actionable steps are sub tasks beneath that.

And then there's a whole methodology around for most teams wanting to see workload combat. Like how do we do capacity management and kind of day to day tactical resource allocation. How do we make decisions around what gets bumped and where we need to let a client know, Hey, this is going to be late or whatever else it looks like.

So things like time estimates are important. What role is responsible for getting that done is important. So one of the custom GPTs that we get built, you throw in kind of a screenshot of, Hey, here's what I've got built as a template. It gives it a grade on a scale of 1 to 10 and it tells you what specifically should look different.

So, naming mechanisms, keeping those consistent is pretty important. So, your deliverable is a noun, and then each of the tasks is a, it's going to start with a verb. Is there an estimated amount of time? Are there dependencies set between tasks? Do we have a timeline here that we normally follow in our workload?

And so we'll go through and spot any issues and point out, hey, here's what doesn't make sense or what could be better so that you can have a whole variety of people creating those because that's a huge pieces. Otherwise, you get one person does this one global overhaul one time and then it's all out of date 6 months later and it doesn't matter at all.

So we need to have the ability and the muscle built by various team members, the people who are actually good at what they do to get stuff in there. But they're not going to remember everything or build it the right way the first time, every time. So that has been a really useful custom GPT that we're using.

Galen Low: I really like that. 

Actually, I wonder if we can dive in there too, because this whole notion of keeping things up to date, and I see some of the questions and we'll get into them as well. But what does that look like for some of the others here on the panel? How are you reinforcing updates so that your process always reflects what is actually happening? 

Brian Kessman: About the updating. Well, I think there's a process of sort of continuous improvement that needs to happen there and it's the culture to support that, but there's a, if you've used Google's NotebookLM, that's really great for uploading a really large wealth of documentation.

It's, I believe it was originally positioned as a research tool, but there's so many great ways to use it. And if you upload all of your different process documents, then you can create instantly some pretty good deliverables for that, such as a table of contents, even a study guide if you wanted to test your people on your process.

And even a podcast, right? Where you can have someone listen to a podcast all about your processes. What could be more exciting than that? So there's a lot of great use cases for that, even beyond what I've shared, but it's a, what do they call it? A RAG system, right? Retrieval-Augmented Generation. And so that's what it's all about.

And I think some of the other products have this, right? But Google's is really effective and really easy to uncheck and check different documents you want referenced. And so when you add a new document, you can uncheck an older version and check the new version and so on. And so it's just a powerful tool for that kind of purpose.

Galen Low: Aly, I was thinking about the Loom video side of things too, because, we were talking about the bookends. And yeah, there's that initial effort of creating the video. Is the answer to augmenting that process to record another video, or is it we just go through and do the text updates? Like what is the sort of source of truth and process for augmenting documentation that starts this video?

Alyson Caffrey: Yeah, I think always having a fresh video is ideal, right? And I think that, it's not as cumbersome to create because somebody is doing the process in the different way anyway. So it might not be you, right?

Say you've created the initial process with the walkthrough video, you've handed it to somebody and then you're like, Hey, maybe they have found a better way to do that, which is awesome. That means we've hired the right people. And then we say, Hey, listen, would you just mind next time you go to tackle this thing, just go ahead and create a new video.

And I actually think that helps a lot with adoption because oftentimes there's two big reasons why I think teams don't end up following our documentation or updating it is number one, nobody's reminding them on a consistent basis. I read a Patrick Lincioni book recently, and he was like, You need to be chief reminding officer, like as the CEO of your company, and that's a really important function.

So if it doesn't live with you as like the founder CEO leader, it needs to live with somebody. So, like assigning an SOP champion or an internal knowledge champion, somebody who's going to actually take point on doing some of the things that Brian mentioned, like tactically and going through the material or reminding people to update their screencasts or their documentation in text form is super duper important. 

And then second, we haven't really painted the picture of what possibility looks like. So a lot of what Gray was talking about in terms of being sure that we understand what are the benefits and the impacts of doing this? We talked a lot about data, but if we're talking to a team, the team maybe doesn't super care what our gross profit margin is because they're not attached to the bottom line.

But what they do care about is work life integration, being able to go out on vacation, not having to train every single team member that they're overseeing from scratch one on one and taking a ton of time out of their day to day. So I think being able to position some of those benefits is super, super important when you want to talk about adoption and following process.

Tell your individual contributors that there's a path to become a manager. Tell your manager that there's a path to become a director, and it all comes down to being able to create some of this repeatability and being able to create a Google for your business. Because I think the power of Google is that it has so many contributors.

It's not just one person, word vomiting, all of their opinions and thoughts and facts on everybody. So like your knowledge base and your processes become stronger when there's lots of contribution as your team grows. I always say that until the team is at about 70, at least from working with agencies over the last 10 years.

So until you're about 70, operations or process documentation is like a small portion of everybody's role instead of just like one department's role, if that makes sense. So I think if you're an agency listening to this and you're like, yeah, I'm a team of 30, it's cool. 10 percent of everybody's job description is you help improve processes, you help document procedures that specifically relate to your role. 

Galen Low: I love that idea of Google for your company and multiple contributors. And it's let's let the good ideas sort of rise to the top. 

All right, I'm going to go into Q&A. The first one is about remaining agile. 

 The question is what kind of solutions have people come up with to remain agile while at the same time, setting up parameters and guidelines so new hires have a good starting point? Which I think is a super juicy question, because we're talking about this notion of Google for your company and how do they know which one is the right one to follow? How can it be clear what solutions have we come up with to be agile, but also not chaotic? 

Does anyone want to take that? 

Brian Kessman: So there's operating principles. Start there. I think, how are we all going to work together? What are the principles that we're going to all agree to? There's a, you can borrow lots of principles from Agile and just translate them to the creative space, being sensitive of the limitations that Agile may put on the creative process.

But we can certainly learn a lot from Agile and Lean as well. Lean in terms of eliminating waste in processes. What's your minimum viable process? Let's think in terms of that way and how we define our processes. Only looking at the most important, those that impact revenue or client experience. And so those operating principles would be really a great start.

And then at the team level, there's just a simple team charter, more of that informal social contract. How are we going to work together as a team? And you can do a search online and find examples of team charters with 20 or so questions that you would answer as a team. Start with the top five that the team feels are most important. 

And then after your next retrospective, are there other questions that we realized we should be really asking and answering as a team to define how we're going to work together? So those are just two quick ways where you can maintain your agility and also eliminate confusion and create more consistency.

Galen Low: Like that sort of charter approach and like community approach as well. And it ties into what you were saying earlier in the discussion about maybe having like dedicated teams, smaller groupings of people that are like working together often. And then Aly, what you were saying, right? Everyone owns it together.

And if you have a new hire or you're onboarding someone into that team, you can kind of go through the charter, go through the values and the way we work together. And yes, things are fluid and we're agile, but you know, here's how we know what each other are doing at any given point.

Alyson Caffrey: I'll add really quick that if, when I've worked with agencies over the years, there's really two sets of standards that we can operate by to remain agile and feel like we've got at least an end, a shared end result, and maybe the process still seems a little hairy. And I think creating production standards.

So like, when are we responding to clients? How fast are we getting this done? Like those types of things. So deadline-driven types of standards and then quality standards, right? So what should this look like when it's met the quality standards and the production standards? I know a lot of agencies that, operate really Lean, that really benefit from that instead of figuring out the messy middle of the process. They say, this is the production standard and this is the quality standard that we all operate by. 

Galen Low: I think maybe I'll shift on to the next question here. It's a more tool specific. The question is, would love to hear the panelists thoughts on tools like Trainual or Scribe.

And I know we've talked about Scribe a little bit. I'll be honest, I'm not as familiar with either of those tools, but that was a great opportunity if you've got thoughts or opinions and folks in the audience as well on using tools like Trainual and Scribe. 

Gray Mackenzie: I'll take the first shot at this one. I actually like and know the folks at Trainual and at Scribe.

Both the tools are great, like process documentation, easy to repeat and push it out there. I think they are a really dumbed down version of a project management tool with some features that are enhanced. And I think for most teams, you should pick between one or two of the either do a PM tool and build it into your knowledge management tool as well, or go the other way and say, we're gonna use this knowledge management tool.

We know that we are sacrificing some PM capabilities. But running those in concert has just led to a lot of challenges for teams. And there's some teams who use it and love it. And they're like, Hey we have stuff in our PM and we link out to that. That makes sense. So I realized that there are some cases where that it does make sense that both, but across the thousands of teams that we have seen and worked with way more frequently, the results in terms of gross margin and efficiency and efficacy get improved when they just pick one or the other.

Galen Low: I get too many tools syndrome and to your point, like someone looking at that might not make that connection that a PM tool can do some of those things. You don't need both necessarily. It looks like you might need both, but it might not be the right answer. It's interesting. Brian, Aly, any thoughts on things like Trainual and Scribe?

Alyson Caffrey: I'm a partner at Trainual, so I have to go ahead and shout from the rooftops. I super love Trainual. We were actually one of their first certified partners. So I've been working in Trainual for the last six years. I think that for my higher growth companies, ones that know that we're about to enter into a season of hiring or maybe an agency that has an acquisition-based growth model, we've actually seen a ton of solid success with Trainual because Trainual, one of their core values is like getting people up to speed.

That's like the name of the game. And so when a new person joins the organization or when organizations merge, there needs to be like an adoption time. And I think on ramping with Trainual using your standard operating procedures, putting all of that information in one place, it's really user friendly.

But from a pure, like AI documentation perspective, Loom and Scribe are really incredible tools. If you're not like entering into a massive season of hiring, or if you don't have an acquisition based model, I think that using Scribe to keep everybody on the same page and Scribe can be embedded, like Gray was saying in project management tools.

I'm also a big fan of keeping the information where the work is done. I always say that you should be like one to two clicks from anything you might need inside of the organization. So if we know okay, we're doing the work in this platform and it easily links to some of the knowledge and all of that stuff.

I think it's really great. And I agree that keeping the project management tool for project management and keeping the documentation tool for documentation is super important. And I do see a lot of companies benefit from having both, but integrating them is, and making sure that rules of engagement are established is super important.

So what goes into which tool is a critical element. 

Galen Low: Love that. Goes back to that charter thing too, right? I've got the two questions in the queue, and I want to see if I can get to them both in three minutes. I'm going to try. 

But one of the questions is, are there any tips on prompts that people have used for AI to help build processes? Are there any sort of prompts that y'all have been playing with to help build processes? 

Gray Mackenzie: I'll go super quickly on this one. I've just prompted it for the like level of the person who's going to see it. So I'll take some of the documentation that we have, and I'll prompt it to say, if I was a new hire at this company that does this what would you change about the documentation and just paste in what we have that has been helpful for some of the onboarding stuff.

So that's my, maybe the one thing that pops to mind that as condensed a version as I can think of. 

Galen Low: I like that. I like that. Brian, any good prompts that you're quite deep into? 

Brian Kessman: It's hard to say, here's a prompt that's going to work for you. And everybody's situation is so different. Everybody's audience is so different as Gray was saying.

So I think it's more about the principles and it's just as if you were managing somebody or helping to guide a new hire in your office, just be very specific about what you're looking for, who they're developing it for, what you need the outcome to be, right? And then provide any sort of additional context and the task for exactly what you need.

Even the format that you need it in, if you have even a template, without the information in it, but just showing the headers and all of that, as specific as you can be, then you'll get better results that way. 

Galen Low: I like that. I also liked that the answer wasn't here's a prompt to create a process that you don't have now from scratch.

Please generate a process for me. Act as an agency that wants to grow real fast. 

Brian Kessman: It would be helpful to have a prompt that, that helps you write a prompt for a new process or something like that. I mean, you could certainly develop that or a prompt really more useful would be something that asks you for the right information that you need in order to create the right kind of output so that it's at least guiding your thought process for you.

I think that would be something helpful and useful. I've developed something like that. It was a virtual chief pricing officer. And so basically it would help agencies price their work into three different options and use, understand if you're up against a price-driven buyer or a value-driven buyer, and it would give you pricing strategies and all of that.

But it does the same thing. It asks you the questions it needs to know to execute the task. So aim for something like that. 

Galen Low: Boom. I love that. I think I'll wrap it there. A very big thank you to our panelists for volunteering their time and knowledge today, Gray, Brian, Aly, this was so much fun. I always love chatting with each of you. Glad we had this opportunity to get all three of you in the same room together. This has been a slice. 

Brian Kessman: Thanks for having us. 

Alyson Caffrey: Thanks, Galen. Appreciate you. 

Galen Low: All right folks, there you have it. As always, if you'd like to join the conversation with over a thousand like-minded project management champions, come join our collective. Head on over to thedigitalprojectmanager.com/membership to learn more. And if you like what you heard today, please subscribe and stay in touch at thedigitalprojectmanager.com. Until next time, thanks for listening.