Extract

EVERYONE in your business.

• What is a systems champion and why they’re essential for building a systems-centred business.
• Why flowcharts and screenshots suck when creating systems and processes.

You’ve identified the critical systems in your business, you’ve assigned key departments and responsibilities, and you’ve identified where the knowledge resides. Now you need to work with those team members to create long, boring standard operating procedures (SOPs) no one will ever read.

You know the documents I’m talking about. Epic, long, numbered lists, with roman numeral sub-lists, hundreds of bullet points, millions of screenshots and flowcharts no one can edit.

Ahhh … this sounds painful. How the heck are you going to find the time to do this?

Well, if you followed the instructions carefully from the previous chapters and many of these tasks have been assigned to other team members, you could just rule with an iron fist. Yeah, that sounds good.

Force your team members to find the time to document their jobs. If they don’t like it, you can always fire ’em.

Actually, no, don’t do that. That would be idiotic.

You know as well as I do that your best team members are every bit as busy as you and there’s a good chance many of them won’t relish the idea of creating systems! Do you really want to force them to do something they don’t want to do?

Of course not. And you don’t have to. Because the SYSTEMology version of creating systems is nothing like anything you’ve tried before. This is the stage that’s going to knock out the biggest myth of all.

That the actual process of creating the systems is time-consuming and painful.

I used to believe this myself until I found a better way. Before SYSTEMology, back when I was looking to step away from my digital agency, I explained to a mentor of mine how much of a challenge it was to document my systems. Almost without a second thought he suggested, “Why don’t you just hire a consultant to create them for you?” My immediate response, at least in my head, was, “Yeah but I don’t want to pay some overpriced consultant to come in and create some documents for parts of my business they know little to nothing about.”

But while my initial reaction was to write off the idea, I am a sucker for business shortcuts. I’m always on the lookout for ways to get the best result in the least possible moves. So, the idea that I didn’t have to be the one creating the systems was definitely one that I kept coming back to.

Fast forward a few years. After doing things the hard way for way too long, I came up with a spin on the idea. I decided to produce a podcast on which I would interview experts who knew how to solve the problems I was having in my business. Although, I didn’t plan on marketing it this way to my guests. Ahem.

If I wanted to know how to do something, I would simply find the person who knew how to do it, and I would have them share their stepby-step system on the podcast. The plan was to then go one step further and get my team to turn those podcasts into documented systems.

Pretty cool idea, huh? Can you guess who the first person I interviewed was? That’s right. I sat down with a podcast expert who could teach me everything about how to produce a podcast.

That very first podcast show covered creating, editing, launching and marketing a podcast. I then gave that interview to my team to document and turn into a system that we still use to this day.

As ideas go, it was pretty good – even if I do say so myself (you can listen to the podcast here: www.SYSTEMology.com/podcast).

The astute reader might have just picked up one of the secrets to this process …

The first secret: creating systems is a two-person job¶

The SYSTEMology method of creating and documenting systems is very similar to my podcast idea. One person shares their knowledge (the knowledgeable worker) and another documents it (your ‘systems champion’). This change, while small in principle, is huge in terms of getting the job done. If you try to get one person to do both parts of the task (explaining and documenting), I can guarantee you’ll hit resistance. But if you make this a two-person job where you just record what the person is already doing, while they’re doing it, and then assign someone else to document the system, you absolutely change the game!

You can then maximise the accuracy of the process by getting the knowledgeable worker to review and edit the created documentation.

Most people, if they have a choice, much prefer to edit something that already exists, rather than having to try to create something from a blank page. Get ‘version one’ of a system done by someone else (someone who likes writing these sorts of documents) and you’ll find it infinitely easier to get the knowledgeable worker to review it. Give it a try.

Like many things in business, fighting strong resistance head-on is rarely the best way forward. Play to your team’s strengths and do everything in your power to make it easier for them to do their best work.

Your systems champion¶

Continuing with this train of thought, is there anyone currently on your team who loves creating systems and processes? They might not have consciously realised it, but you can typically spot these people because they’re known for being extremely organised, detail-oriented people. They’re the kind of people who enjoy creating to-do lists and organising projects, and get great satisfaction in seeing things run smoothly.

It’s worth identifying these people early and getting them involved in the SYSTEMology process. Whether it’s to help with interviewing the knowledgeable workers, creating the documentation or just overseeing the process, they will play a key role in ensuring you get the results you’re looking for. You always want to play to people’s strengths, so make sure you get this book into the hands of the team members who can make this happen. I recall a great example of finding a systems champion when I did some work for a company called Portavac, which cleans residential and commercial roofing gutters. One of the first things they did was identify their systems champion even before we even started work together. Kane was a curious, give-anything-a-go twenty-year-old who worked in their head office.

Over the course of a few months, he worked closely with me in applying SYSTEMology. He helped connect me with the right team members, attended all of my sessions with the team and even conducted some of the recordings himself. He even, on more than one occasion, literally grabbed a camera and went out into the field to capture different parts of their business process. He then shared those recordings with our team and helped with the documentation.

It produced some great results, and what I loved most about it was that it ensured they had someone who understood the whole methodology inside their business – someone who could keep driving the process forward well after we finished our engagement.

It really can be that simple. And I love this example because it highlights the fact that you don’t need special training (beyond reading this book) to be a systems champion. The right person will just ‘get’ this stuff and they’ll make your job easier.

If you don’t think you have that person in your team just yet, that’s okay for now. But the sooner you can find someone to take ownership over this project, the better. You might even consider hiring a new person for this position.

I’ve had great success, for instance, with return-to-work mums and dads. Often you can hire great, highly skilled team members who aren’t able to return to work full-time but could work part-time in your business. They may have worked in corporate or larger companies and can bring a wealth of knowledge. Perhaps you find someone locally, give them this book and have them help you implement it within your business. This could easily start out as a 10–15 hour per week job over a 3–6 month period, and if they prove to be a good fit, you can offer them a more permanent position later.

Either way, once you identify your systems champion, this is the perfect time for the business owner to step out of the process and allow their team to begin building these processes without them. Let the systems champion drive things.

The second secret: the System for Creating Systems¶

If the first secret to systems extraction is that it’s a two-person job, the second secret is that you need a ‘System for Creating Systems’. It’s a bit meta – having a system that outlines the system for documenting systems – but successfully wrap your head around this now and everything after this will run just that little bit smoother.

This system template will outline the structure all your systems will follow to ensure consistency. It will remind your team to keep things simple and make it easy for anyone to easily capture, document and share what they’re doing.

I’ll walk you through the process here in more detail, but you can also grab an easily shareable version of the system here: www.SYSTEMology.com/resources.

Okay, you have identified your Critical Client Flow (CCF). You’ve identified who in your team has the knowledge, and now we need to get it out of their heads. Let’s jump right in. We’ll start by documenting your first system.

Step #1: Identify the result you’re looking to achieve with this system.

Pick one of the identified systems from the CCF to be your guinea pig. I suggest starting with something simple so you can become familiar with the process.

Alternatively, you can pick a system that solves a very specific problem you know your business is having right now. For example, if you’re having troubles around the delivery of your product or service, focus on the onboarding and delivery systems. Having trouble selling? Create a system for your sales process.

Either way, stay within the bounds of the CCF and prioritise at your discretion.

For our example, we’ll pick an easy-to-understand process – handling inbound enquiries via the phone or website. We’ll name it something clear but descriptive: ‘Handling an incoming enquiry’.

Step #2: Identify who produces the result.

You’ve already completed this step in the previous chapter, so this is easy enough. Look at your DRTC and see who is marked as the knowledgeable worker of the system – the knowledgeable worker who knows HOW to do the job for which you’re creating a system. We’ll extract the system from them and then aim to bring everyone else up to that standard.

Step #3: Determine the capture method.

What will be the most effective way to capture the person who is sharing their knowledge?

Most of the time this will be recording them doing the task, as they’re doing it, using screen-recording software, a camera or your mobile phone. See www.SYSTEMology.com/resources for our current software recommendations.

For an office task, I’d suggest using screen-recording software; for an outside job that is very physical, get a GoPro camera or something similar. For a sales task, you might just use a Dictaphone app on your phone or a combination of methods.

Note: In situations where it’s not possible to capture the actual event happening live, have the knowledgeable worker roleplay the process or take the systems champion through their process step-by-step. Always look for the method that creates the least friction or anxiety for the team members.

Step #4: Record the task being completed.

If you’re lucky, your knowledgeable workers will immediately recognise the benefits of systemisation and will be fully on board with the process. Otherwise, it’s well worth taking some time to prepare them before conducting your recording.

Start by explaining why this systemisation process is being carried out and frame it in terms of the benefit to the worker. For example, having their tasks systemised will ensure their work can be managed effectively while they’re on vacation.

“You know how every time you go on vacation you come back to a mountain of work to catch up on? Or worse, while on vacation you still need to keep working to keep things moving? This will ensure we can get the team to manage things while you’re away.”

You should also make it clear that the heavy lifting – the documentation, uploading, tweaking, etc. – is going to be handled by someone else. All they really have to do is carry out the task and talk about it as they go along. We’ll cover more tips on how to introduce SYSTEMology to your team in a later chapter.

Depending on the complexity of the task, it can be helpful to ask the worker to make a few bullet point notes before the recording, outlining some of the key steps. This pre-planning gives the worker the chance to think through a task that they may have been completing on autopilot for a long time.

You should also stress the point that we’re not looking to have this system ‘perfect’ or fully optimised. While it’s okay to make minor tweaks, you want to avoid trying to completely re-engineer things. Optimising comes later. At this stage, we’re looking to keep things simple and just capture how things are currently done.

One final point to keep in mind is that not everyone will be comfortable being recorded, so a little preparation and scene-setting can go a long way to calm the nerves. If you have a systems champion, have them schedule times on the calendar for when these extractions will happen and have them conduct the team member’s recording.

It’s time to hit the ‘record’ button and let the knowledgeable worker do their thing. Remind them to describe everything they’re doing as they’re doing it and aim to capture every detail you can. This will make things much easier at documentation time.

By definition, this team member is a knowledgeable worker. They know how to complete this task and they’re able to complete it to a great standard. So, don’t worry about any mistakes or interruptions in the recording. If you break off or, worse, restart after every flub, the task will take forever.

If the knowledgeable worker messes up, get them to explain what went wrong and then just carry on. Mistakes can be edited out in postproduction if required, but sometimes the errors can be instructive if it demonstrates how to recover from a mistake. Just keep rolling and capture everything as you go.

In circumstances where the tasks may be completed in stages or where it’s not possible to go through from start to finish in one go, just capture it in pieces. Later you can decide if it’s best to combine these or keep them as separate standalone systems.

The final result won’t be great. The odd element might have been missed, the recording might look a bit amateurish and/or the worker might have gone slower than usual. None of that is important.

Remember that your first version is highly unlikely to be the final, definitive version. You’ll get better as you go along, and every time you create a new iteration, your end result will get a little better, a little more efficient and a little more accurate.

The Kaizen philosophy is embedded deeply in the SYSTEMology method. The idea behind constant and never-ending improvement is that nothing is ever finished or considered perfect; there’s always room for improvement. You must get comfortable with this idea and just get your version number one complete.

Step #5: Create a new system.

The first time you document a system, you need to decide where you’re going to store it. Ideally, you might already have a file storage system or, better yet, systems management software that can easily be managed, edited and accessed by everyone in your business.

We’ll cover this in more detail in the next chapter, but either way, my best advice is to always go with whatever makes things easiest for your team members. There is a trend for software that attempts to do a little bit of everything; in my experience, this tends to overcomplicate things by providing lots of bells and whistles, 99 per cent of which you probably won’t use.

Assuming you have your database in place, ready to use, your systems champion should now have everything they need to create a system based on the material that’s been extracted.

Get them to create folders in your systems management software based on the different business departments you identified earlier, such as Sales, Finance, Operations, etc. The systems champion can then store a new system in the appropriate folder.

This system document aims to have everything in one place so your systems champion can do their thing. Here are a few extra points of information you might consider adding to your document.

System title: This should be concise, but not at the expense of using the most appropriate and descriptive keywords. Thought should be given to the search terms that your team might use when trying to locate this system in the future. Also, consider creating a naming convention to ensure consistency.

System description: Again, this should be brief but clear. It should state what the system is about and what results or outcomes are expected from following it. I would suggest not more than a couple of paragraphs. Relevant links: Add a link to the video recording of the task being completed and other files, templates and required resources.

Knowledgeable worker: It’s a good idea to have this person noted in the system itself since typically this person becomes the primary point of contact for questions relating to the system.

Team members: Identify other team members (or at least one) who you’d like to also be able to carry out the task. These team members can act as the backup for this task if the knowledgeable worker is unavailable. This last point is an important one that starts to remove key person dependency and creates business owner freedom. Remember that all tasks and roles should have more than one team member who’s able to step in and complete those duties.

Having redundancy reduces team member anxiety around taking leave, provides business owner confidence and gets you one step closer to complete business reliability.

Step #6: Create step-by-step documentation.

Remember the first secret of the extraction phase is to make it a twoperson job: the person with the knowledge and the systems champion.

Have your systems champion watch the recording of the task being completed and get them to note down the steps carried out in a linear fashion. Literally, “Step 1: Do this. Step 2: Do that.”

Each step should be as detailed as it needs to be, using sub-bullets and clarification comments as required. These steps should be typed directly into the main body of the system.

How do you know if the level of detail is correct? There is no perfect answer here and it’s often dictated by the system itself and the skill level of the team members who will carry out the task. Low-skilled roles with higher turnover of staff may require very detailed instructions when compared to tasks completed by highly skilled, long-term members, which may require less.

That said, I’m not a big believer in hiring unskilled fifteen-year-olds to do all the tasks in your business for minimum wage (unless you sell hamburgers … then I’ll grant you an exception). Don’t create every system for the lowest common denominator.

Take Reed Hastings’ (founder of Netflix) advice from the Masters of Scale podcast: “What we failed to understand is by dummy proofing all the systems that we would have a system where only dummies wanted to work there.”

The goal is not to develop robots who mindlessly follow step-by-step instructions. We want to give smart people the instructions they need to deliver a great outcome. Keep it simple, with less detail than you think you need.

Remember, you will keep evolving your systems over time (we haven’t even got to the optimisation stage yet).

A reader with some knowledge should be able to read the main headings for each step and, from this information, have a good idea of what needs to be done. They should then be able to read all the additional information described in each step and, with a little practice and guidance, be able to complete the task to a good standard.

In one of the later steps, we’re actually going to put this to the test. But for now, the systems champion should be aware that this is the goal when creating the system. It needs to be specific, clear and detailed enough to allow the process to be followed without any gaps. It can also be really helpful to conclude the documentation with a few criteria that can be used to double-check the task has been successfully completed.

The systems champion should also be consistent in their approach. The text, the style of writing, the layout, even details such as whether the step number is indicated numerically (1, 2, 3, etc.) or alphabetically (one, two, three, etc.) should be uniform throughout.

The right person for this job will be fastidious about achieving this level of detail and consistency.

Finally, the system should conclude with a ‘supporting notes’ section, containing the source videos and audios, required templates and attachments, and any other relevant information.

Step #7: Review the system.

Once you have your first draft, it can be sent to the knowledgeable worker who originally recorded it. They’re usually the best person to judge how it’s coming along. However, rather than simply reading it, get them to follow through the steps when they next complete the task so they can compare it directly.

They should be looking for errors, critical omissions and anything they think might send someone off track. This feedback can be made either directly into the system or to the systems champion for them to update it. Go with whatever is easiest for the knowledgeable worker.

At this stage, the system should be good for review by another set of eyes. If the department head hasn’t been involved in the creation of the system until now, get them to take a look. Remember that the knowledgeable worker is focused primarily on getting a specific job done, whereas upper management can view the system from the wider point of view of how it impacts the department and other areas of the business.

This is also where you may discover insight into how other areas of the business can be improved and/or where energies and resources are being wasted.

Discuss any suggested tweaks and additions with the knowledgeable worker and adjust the system with any agreed changes.

Step #8: Have your team follow the system and cross-train other team members.

The final step in the process for your shiny new system is to use it in the real world. The original knowledgeable worker can continue to review and tweak it over the next few cycles of that task being completed and, once they feel good about the process, they can use it to train someone else. This step is going to expose any remaining weaknesses and confusions in the documented system.

Have another team member go through the task, watching the original video, reading the notes and then completing the task. They can refer back to the original knowledgeable worker, asking questions and seeking clarity where needed.

This gives the knowledgeable worker or systems champion another chance to further improve the system. Repeat this step as often as required until the tester is able to complete the task to a reasonable standard without any intervention or feedback required.

You should also view new hires as an opportunity to review every system related to that person’s role. A fresh pair of eyes will often reveal new opportunities to improve and streamline things.

Flow charts come last¶

I see this all the time when people read a book on Six Sigma – they think every system must first be flow charted before it’s improved. Maybe this is true for multinational corporations and/or companies with existing detailed documentation, but for small businesses this is overkill.

Flow charts are a graphical representation of systems depicting inputs, decision points and outputs. The problem is that these are usually created by a systems nerd using some fancy software that only they know how to use. And because no one else can figure it out, once they’re created, they’re rarely (if ever) updated.

Remember, you’ll want to involve multiple team members and make things as easy as possible for them. Don’t set them up for failure by creating flow charts that will be out of date in the blink of an eye. Save it until the end, once your system has been in action for some time and you’ve been through the final optimisation stage of SYSTEMology. At least by this point, your flow charts will be less likely to need updating.

The same can be said for using too many screenshots within your systems. Often, I see systems that include screenshots for every step in a process, and while that sounds good for clarity, in reality it’s a nightmare to keep them updated. Software updates all the time, so don’t set yourself up for failure. Take my advice and keep your screenshots to a minimum. Refer to appendices 1.1 and 1.2 for a couple of examples of systems from our digital agency. Just keep in mind, I modified these for simplicity and clarity.

Set yourself up for success¶

Great job, you’re all the way through documenting your first system! Keep working through the CCF to keep you on track and commit to documenting a minimum of two systems per week. You might consider prioritising which systems you create first by those that you know will solve problems you’re already having within the business.

This stage of SYSTEMology (the extraction) is easily one of the largest with regards to the volume of work. It’s how the sausages get made. Commit to the process and get a solid understanding of the System for Creating Systems because, if you can nail this one, everything else will become that much easier.

I’ve used this system countless times and it’s proven to work for virtually any kind of system imaginable. If you ever feel stuck or you’re not sure how to capture a particular process, remember to simplify. Make the system an overview system and document only the top-level steps. You can always circle back around and create more detailed instructions for each of those steps if required.

This often occurs when you get to the onboarding and delivery section of the CCF. There’s a very real possibility that this could get quite complex – please resist this urge the first time around.

Just do whatever you need to do to keep the momentum going.

Ask yourself, “How can I ensure I keep moving forward through the extraction phase?” I know it’s easy to prioritise other jobs within your business, so how could you reward, punish and/or create some accountability for yourself?

One of the best examples of accountability I remember was from a colleague who had just quit his day job to become an entrepreneur, working from home. But what he didn’t anticipate was just how hard it was going to be to get out of bed each day without the pressure of having to be in the office by 9 am. He was fine once he was up, but actually rolling out of bed each morning became a constant battle.

So, he came up with this ingenious idea (his self-inflicted positive constraint) to park his car in a clearway zone out the front of his house. If he didn’t get out of bed and move his car by 8 am he knew it would be towed away, and this completely eliminated any temptation to stay under the duvet. The price was just too high.

How can you create a little positive pressure to ensure you and your team get all the steps in your CCF documented within a set timeframe? Which do you think will work better – the carrot, the stick or a combination of both?

Make the commitment, do the work and reap the rewards.