Katalina (00:12)
Hello and welcome back to another episode of Career Path. I am your host, Katalina. Today we are covering the topic of how Systems Drive Success. And here to discuss this with me, I have Nikki Noyes, who is the Director of Compliance at Bureau's Inc. And we just found out we don't live too far from one another. So that's pretty fun. Nikki, it is such a pleasure to have you on today. Thank you for joining me.
Nikki (00:35)
Thanks for having me.
Katalina (00:36)
Before we dive into this topic, we're gonna start this episode just like we do every other episode. Can you tell us a little bit about yourself and how you got to where you are today?
Nikki (00:45)
So I've been in the industry for almost 20 years now. I cannot believe that it happened that fast. A couple of different companies, a couple of different positions, always either in an administrative role or a compliance function. And so the administrative roles kind of led me to see the necessity of the compliance functions, and that's how I started building the compliance management systems.
Katalina (01:16)
Yeah, that makes sense. Being in those two roles, systems are very, very vital. So to dive into our topic, I want to start with actually pulling in a quote from a book that I'm sure a lot of you are familiar with. It's called Atomic Habits, about systems. And this very much informs the rest of our discussion; this very much speaks to it. So the quote is: goals are for people who care about winning once; systems are for people who care about winning repeatedly.
And I don't know about you, Nikki. I very much agree with that. And with that being said, I'd love to dive into the benefits of systems. Can we talk a little bit about that?
Nikki (01:56)
Yeah, so every system that you create hopefully is to solve a problem. And so instead of having to solve the same problem over and over again, you have this system in place that's going to save you time, right?
It will reduce your stress 'cause you already have the answer after you figured it out once, right? Sometimes you have to do the first problem-solving, but once you figure it out once, you don't have to keep reinventing the wheel. And so once you have a system that you know works, then you use that every time you come across that scenario, and then you know that your processes are accurate. And once you have consistent accuracy, you can scale it for growth.
Katalina (02:44)
Absolutely. So when you say scale for growth, I think one of the biggest things there is that you don't need the same person to do the same job if you've built an actual system in there. You can then teach different people, especially if you have an SOP, like a standard operating procedure. You can train people on all those different things, which will improve the entire way everybody's doing it. It's gonna save that time, create that consistency, and be usable across different teammates and sometimes even different departments. And I'm gonna bring in a personal story that happened very recently where we've spent a lot of time building SOPs in our company here. And some of it covers things that are repetitive. You do it the same way every time, but you may not do it every day.
I feel like once you're trained on it and you're doing it every day, it's very easy to remember. Thank goodness we still have the backup of having those policies and procedures in place, especially if somebody's training or new, that they can fall back on. But if you're not doing something every day, you do it once a year or a handful of times a year, you might get back to it and be like, gosh, what do I do with this again?
And we had that happen recently, as something happened with a site and a decommissioning, and I was like, What do I do for this again? And I just went, wait a second, we have a whole policy and procedure on this exact sort of thing. And I went right into there, and I read through the system, and I was like, yeah, that's what I did. And I even built the dang thing, but I couldn't remember it myself.
So thankfully we had it written down, and I could go right back to it and be like, not only do I now see exactly the trajectory, like every single step that we need to do in this process. But I had built the system within the system, which was like, you were talking about the repetition. There's repetition a lot of times in what you say to people or what you, like, email you send and things. And I was like, I have email templates built for this too, that are ready to go. I just have to put the correct information for this exact situation in, like, plug in this data point, and then send it.
And it made everything so much easier. My God. Because without that, I would have been like, man, now I have to think through everything I need to do. I have to draft all these emails. And a process that could have taken me an hour because there wasn't anything turned into five minutes because there was a whole process in place. There was a system built. There were templates and everything.
And it saved so much time and reduced my stress significantly. And if anything were to happen and I'm not even in this role anymore, or somebody else has to step in for that particular job, at a conference or something, that procedure's there. It's translatable.
Nikki (05:35)
You are speaking my language. So while you were talking about forgetting your own processes, I was laughing internally because I wrote most of the procedures and the work instructions and the policies. And we just had some turnover. And naturally, with turnover and new people taking on those roles, they keep coming to me with questions, and I'm like, I don't know, but I know it's documented. So let me just go find the answer for you. And then you can also see why.
So it turns into actually a training tool of not just click here and do this and do this, but it also contains the why each step matters and making sure that, as there's turnover or different people taking it over, or if it was me doing it versus somebody brand new, that it's consistent amongst all of us that we all do it exactly the same way with the same outcome.
Katalina (06:30)
And that is why I feel like it is so key for your entire team. So it's not just like, we do it this way. I'm huge into the why. And I told a story not too long ago on Career Path where I was a bit of an annoying person in school because I asked questions all the time in this one class. It was a calculus class. I'd be like, but why are we doing this? But why are we doing this?
It was so hard for me to be like, okay, I'm gonna memorize all these different types of equations and processes and do them all the time for homework when I don't even understand why we're doing it. Like, what does this equation do? I need the why behind things. And I feel like so many teams operate the same way. Some people might not care; they're like, I don't need a why.
But when you have that extra layer of understanding, it informs everything that you do. And if there's ever any chance that something can be better, then a teammate can come up and be like, hey, if we're doing this for this reason, this might actually be a better way to get that result. And it leaves a ton of room for improvement in whatever system you've built by giving the whys behind things and informing your team.
So we've talked a lot about the benefits. I'd love to start diving into how you create one. Like from square one, if somebody had a new business, where do you start with systems?
Nikki (07:51)
So I think we touched on it a little bit, but the first thing would be to identify what's repetitive, right? Whether it's a template, like you said, I love templates. I love email templates, letter templates. Templates can save you so much time from trying to recreate the same thing over and over.
So identify what's repetitive and then just make what the steps are for that task, whether it's sending an email, processing something coming in, posting payments, whatever it could be. If it's repetitive, then you can create a process around it.
Katalina (08:24)
Something that I find repetitive in my job, and I bet a lot of other people do, is frequently asked questions. I mean, there's a reason we have sections on Google for it, on websites. You get the same questions all the time. And then I would also say, by extension, when you see the same responses to things- not just like the same questions- you're like, I have answers to those questions, but if you see the same responses to any of the templates that you do, like any confusion, continue to tweak.
For example, I'll use our business again. We will send video scripts for people to review, and then when you send the same name, people don't understand that it's a different thing when you send the script versus the video. So if we were making a client video, say "Compliance in 2026" is the video. If we go to send it to the client for review and they need to look at the script, we need to say This is the script for the Compliance in 2026 video. Versus when you send the video, you go, "Okay, this is the video.”
Now, for you to review, because I realized if I sent the same template of, like, this is ready for review, they go, I already reviewed Compliance in 2026. So just minor tweaks where you realize, okay, here's where even my system is falling flat a little bit, and I need to add in a little bit of changes or tweaks here or there to improve it and have more clarity and just make it more successful overall.
Nikki (09:57)
Yeah, I think that's something that I continue to learn over and over again is that sometimes things make sense to me, but to somebody removed from the position or the routine or the process itself, it might not be crystal clear to them. So I have a work instruction or a policy or a procedure that I think makes perfect sense.
But sometimes you have to get a completely separate party to take a look at it and see if they can follow it or if they can understand it. Because when it's my everyday job, and I can picture it in my head, it does not mean that somebody who's never seen that program before or that circumstance before knows what the heck it means.
Katalina (10:39)
100%. So that slight difference in verbiage is huge. Just to, or even if it isn't a slight difference, if it's a big difference, just recognizing that. And I think you also touched on something very important there: bringing in another person to review whatever system you created can be very, very valuable. A second set of eyes on anything can be extremely valuable.
I even gave an example recently; I think it was earlier today. I was talking to somebody, and I was like, my God, second set of eyes, always, please check it, double-check it, triple-check it. Because when you are so into something, you've been working on it a ton, you almost become a little bit blind to it. Not just the procedure itself, but maybe the wording or anything like that.
I can think back to a number of times where my colleague Leah took one look at something I created, and she was like, hey, all the content's great, but the first word on the first page is spelled wrong. And I'm like, my God, how did I miss that so many times? But just having a second set of eyes take a look and catch something that you're like, I never even saw that. So worthwhile.
We've kind of started transitioning our discussion right here from just creating the system to watching out for pitfalls or ways you can kind of trip along the way. Both by watching, like your wording, making sure people check what you did, as well as making sure that it's translatable across different people and maybe even different departments, depending on whatever that system is or is supposed to do. Are there any other pitfalls that you should watch out for when creating systems?
Nikki (12:15)
Yeah, so I would say make sure that you don't make it so specific that it's not revisable, or you talked about being able to make little changes to it, so if you include such specificity. It's a tough word, right? If you include such specificity that you're not able to change whether it's a program name or a person's name being responsible for the task instead of a department or something like that, you want it to be able to be living and breathing.
As you come up with changes to your environment, you want the system to be adaptable. And so that could be something that needs to be tracked in, like version tracking, or it could be that there's a whole new step in the process. Or you notice that there's some consistent or recurring confusion, right? So having it be able to be modified to meet the current environment as the environment changes.
Katalina (13:13)
We actually had to do that this year when I went over our standard operating procedures at the beginning of the year. I was looking at some of it, and I was like, we name specific people instead of titles. And some of them aren't here anymore for whatever reason. And I'm like, we need to pull names out of these and make sure that it says just the title. So the graphics lead or whatever it is.
And even given that, there will still have to be changes, but making it more translatable is better. So that if a bunch of different people have to do it, you can say, like, a graphics team and make it just translatable. Sometimes you will still need an update. Like previously, we had the graphics lead handle podcast production. We now have a podcast department. So we had to go in there and be like, this no longer says graphics lead; this says podcast lead.
So there will still be changes, but the more flexible you can make it, the better it seems. Is that what you're kinda getting at?
Nikki (14:12)
Yeah, so that it's adaptable as regulations change, your environment changes, and your staff changes. You need to be able to not have to revamp the whole system that you had in place.
Katalina (14:24)
There's sometimes also a risk that, when you were talking earlier about not being too specific, you want to avoid locking your organization into inefficient processes or things that make it more difficult. So if you're switching email systems, you don't want the standard operating procedures to talk about exactly where to click and exactly where to do things. Because in a matter of months, even if it's just your email system, you're not changing platforms, the system updates.
Now you have to change everything because the layout is completely different. So watch out for that as well and make sure you're not being way too hyper-specific, keeping it specific enough that it is a full system, but that it's not too specific, that it's easily broken by minor changes that are outside of your control.
Nikki (15:17)
One thousand percent.
Katalina (15:18)
So would you like to share a little bit more about who should be involved in the process of creating a system? Is it only for upper management, or is it something that is more created by an entire department?
Nikki (15:31)
I would say both because upper management is gonna have the expertise in why certain controls are required and what has to be included. But in reality, a lot of times upper management is not boots on the ground. So they may not be familiar with the minutiae of variations that can occur and need to be accounted for.
So it probably starts with the employee doing the task and then gets reviewed and approved by a higher-level supervisor and then back down to the person doing the task. So the policies, procedures, and work instructions that I have created, I protect like they are my children.
Because I've had people go in- well-intentioned people go in and make a change, but now I don't have the true version that was reviewed, ratified, approved, provided to clients, provided to regulators, so you have to be really careful that whoever is allowed to make a change knows what your systems for making a change are.
And that it's captured and documented as needed. I mean everybody can take a document and make their own notes someplace else, but it should not be on the master copy.
Katalina (16:54)
Absolutely. gosh. I totally agree with that. And I'm so glad that Google Docs gives you such great control over who has access. You can have viewer access, you can have commenter access, or you can have editor access. And only you or a very select few people should have full editor access.
Even if you want the team's input, just put it in the comments so that people aren't directly changing things, and instead they can redline or comment any questions or concerns that they have about the process because it can get very confusing, especially if something changes and then you don't know what changed. And now it's like a treasure hunt: where is something different in here? I don't know. It can get so complicated so quickly.
Nikki (17:42)
So I think that's a great point too. We kind of talked about bringing in a second set of eyes, but who should be the people doing it? But also, there tends to be value in comments from complete outsiders. So before I roll out any policy or system, I have lots of people look at it because, as a compliance person, I have a different mindset than maybe the operations team or the IT team. And so even though it might be strictly a compliance function and it's my team that does it, when the IT guy looks at it, he might have different feedback, comments, or suggestions than the ops people who are more money-focused, right?
And they're like, well, this should probably include this. So always get other input. Maybe not just the people who actually are doing it, but have outsider eyes on it too. And they would have comment-only access.
Katalina (18:40)
And that'll definitely help clarify if there are any misunderstandings in the documents as well that you and I were talking about before. But by extension, I think we kind of talked about just making sure that it was clear that it's not like- it just makes sense in my head, but even in the way that it's written, we want to make sure it's not like technical jargon.
Or, like, filled with fluff; it doesn't need to sound like the most profound technical or legal document ever, even though it is a standard operating procedure. It should be accessible to the least sophisticated employee. Because if they need to read it and it's not just like, I don't really understand what we're doing here, or if they're just like, I don't even know what any of this means, then there's a big problem.
You need to make sure it's written in a way that reduces any potential confusion across the board. It doesn't need to sound like the most polished legal document ever. We're not lawyers. Some of you may be, but not all of us are lawyers.
Nikki (19:49)
Yeah, I guess I would call it like an editing habit of being like, can we say these five sentences in like two? Like, why is this instruction 17 pages long? Can we make it into a one-page cheat sheet? Like nobody's gonna read 17 pages on how to do a simple task. It needs to be like highlights. Highlights of what somebody can use as a reference guide, not a Bible, so to speak.
Katalina (20:13)
Exactly. That just keeping it concise and easy to reference if you do need it and like I did the other day and it was hard to go find, that would have been that would have been rough. And I'm not gonna sugarcoat it. That SOP is probably 50 pages long, but we have tabs, and we have a search function, and I was able to search it really quickly. And once I got to that section, it was so easily broken down. It was like you do A, you do B, you do C.
That's what it is. And here, here was the cherry on top. The links to the email template were right there in the document. We have links to those other things that you need to do those steps, which was just this extra level that made the system so easy to execute. We spent all this time writing it, but now if you make it just one more step easy to execute by providing those links, it makes all the difference.
As I said, I turned that one-hour thing into a five-minute thing. I was like, found the steps, have the templates, here we go, boom, boom, boom, done. So easy. I love it. So I kind of wrap this all together. We've talked about why it's important, those benefits. We've talked a little bit about creating the system and what to watch out for when you're creating it. I really want to just tie this with a bow by talking about maintaining a system. How do you make sure you're able to scale it and build it?
Nikki (21:38)
So the first step for maintaining it, we touched on, was: don't let everybody have access to change it.
Katalina (21:46)
Good point.
Nikki (21:47)
But other than that, I think you have to make sure that you're regularly reviewing it, which we also touched on, because your environment's gonna change, your staff is gonna change, your needs are going to change. And if it's a living, breathing, editable system.
Then it still is applicable. You just need to revise it and make sure it goes through the appropriate approval channels. The other piece would be to measure its effectiveness. Maybe there's a policy or a procedure that no longer serves you because technology has changed or requirements have changed or whatever the case may be. Don't pigeonhole yourself into a system to check a box; like we also touched on, really understand the why. Because if you understand the why, then you know if it's still serving you or not.
Katalina (22:32)
Yes, absolutely.
Nikki (22:34)
The other thing I think is understanding what it can actually do for you. So I would say I kind of fell into compliance because I noticed patterns of, like, always needing to answer the same audit questions. Right. And so whether it's a client audit, whether it's an internal audit, whether it's a regulator audit, you're always answering the same questions. So why not make your policies, procedures, and your systems fulfill that purpose for you?
So that every time you can say, Yep, I know where that is. It's in this SOP. And that way, you're not reinventing the wheel and trying to come up with the perfect language every time; it's right there for you because if you're doing things consistently using systems across the board, your answers are going to be the same, and they'll be truthful and uniform.
Katalina (23:29)
Yeah. And when you train the team not only on the system, but where it lives, how to use and reference it, then it's so much more hands-off. You no longer have to guide the entire process every single time. You mentioned something that I think is wildly important, and I do it typically annually, but I'm not sure if that is the right schedule. How often should you be reviewing your systems and your operating procedures?
Nikki (23:54)
I think annually is a good starting point. And if you undergo some major change or notice a new pattern or need to make a change, that's also like a good pulse check.
But the way that I manage my systems is that I'm kind of always in them. And so I'll notice something that probably could be refined or that could be updated a little bit. But if you have one that you're not in all the time, you probably want to at least look at it annually to make sure that it doesn't need to be changed or updated.
Katalina (24:27)
So if you are creating systems that solve a problem and you've made it so it is repeatable, it can be used by even the least sophisticated employee on your team that needs to be using it, then you are laying the groundwork for longevity and ultimately success. Would you agree with that?
Nikki (24:46)
Absolutely. Yep.
Katalina (24:47)
Awesome. Well, I want to thank you, Nikki, so much for coming on today. Unfortunately, we are out of time, but this has been a great discussion. Thank you so much for sharing all about systems and how you have spent a career building them. This has been great.
Nikki (25:00)
Thank you so much, Katalina.
Katalina (25:02)
To all of our listeners, if you have any other questions, comments, or topics that you would like to see us cover, please leave them in the comments below. We will always do our best to get to all of them. Otherwise, we will see you in the next episode. Thanks. Bye.
