Team Efficiency Blueprint: Building Systems Your Team Will Actually Use

When systems fail in organizations, it's often not because the system itself is broken - it's because people don't know how to use it properly. A local high school learned this lesson the hard way when they implemented a new emergency response system. Teachers were briefly trained on a device that could call for help with one press, trigger a partial lockdown with two presses, or initiate a full lockdown with three presses. Within two weeks, the school had six false full lockdowns because teachers had forgotten their training and kept pressing the button when they thought it wasn't working. It was realized that part of the problem was that the brief training had been folded into a larger start-of-semester meeting, and most teachers had forgotten the training amongst the haze of lesson planning and room decorating that permeated the week before students arrived.

The solution wasn't scrapping the system - it was better training. After a dedicated retraining session, the false alarms stopped. This scenario plays out in businesses everywhere: systems that seem ineffective often just need proper implementation and training, or they're too complex for daily use regardless of how much training is provided.

A business runs smoothest when its systems are fully understood and utilized by the team members using it. I’ve seen businesses hire someone to build out a system to support their operations, and then that person does not fully train their team on how to use it, leaving them with routine mishaps from a lack of strong training and documentation. I’ve also seen business owners develop complex, nuanced systems that worked for them, but would completely flop with their team because they couldn’t figure out how to work it no matter how often it was explained. Whether your team efficiency problems stem from inadequate training or overly complicated processes, the key to success is building systems your team will actually use while - still achieving the desired outcomes.

‍

What Makes a System Useful?

So, what is it that makes a system flop or fly? The first key is making sure your systems, simply, make sense. Do the steps make logical sense? Does the flow minimize redundancies and help your workflow operate as efficiently as possible? Here’s an example for reference:

If I’m building a “system” for bagging groceries, bringing them to the car, unloading them, and putting them away at home, it would be insanely inefficient to bag each item in its own bag, carry them one by one to the car, and drive them separately to the house. Instead, you should put multiple items in each bag, load them into the car together, and carry them into the house together. There’s no reason to go back and forth between your house, your car, and the store more than once. 

Next, you should ask if the system is straightforward? Is it so complex that only you can understand it easily, or can any qualified team member pick it up relatively quickly? To continue the previous example:

We know it takes more than just putting groceries into random bags all willy-nilly to make a good grocery bagger, but if your solution to the subtle intricacies of grocery transportation are to gather all the groceries at the end of the conveyor belt, organize them by type and weight, carefully balance each bag on a scale and fill it to an exact optimal weight of groceries per bag with only eggs and bread together, fruits separated from vegetables, organic produce packaged separately from regular produce, frozen items exclusively in the bottom of the bags, etc., you’re making it too complicated. Not only will this take forever, but only you are going to be capable of replicating this process in every unique set of purchases. On the other hand, putting all the cold stuff together, hard stuff at the bottom of bags, soft stuff at the top of bags, eggs somewhere safe, and double bagging any packages you don’t feel confident will last to the car is straightforward and replicable while still addressing the need for strategy and nuance.

Now, this example may seem silly, but we’re more often than not doing something very similar within our own businesses! 

So to recap, sans groceries, ‍, while still handling the necessary nuances of your business’ operations. Once you feel confident your workflow organization fits those parameters, it’s time to make the call on what parts of the processes you should automate or keep manual. For more guidance on when you should and shouldn’t automate your systems and processes, see our blogs Smart Automation: What You SHOULD Automate in Your Business and 6 Things You Should NOT Automate in Your Business. To summarize briefly here, workflow automation for small businesses makes the most sense when tasks are consistent and repetitive and the least sense when tasks are complicated, creative, or require the ability to adjust to sudden changes. 

Beyond the Bare Minimum: Building Systems Suited to Your Team

Now you have a useful system, which is fantastic. You’ve created something that is practical and that your team members should be capable of using. But, if your goal is to maximize team efficiency, you’ll need to take it a step further: you need a system your team will use. This part is where it gets a bit trickier, because what exactly works best for your team will depend on… well, your team. You can do all the work to make a system successful on the tech side, but you need to consider the human factors as well for it to really stick. This is where it’s important to consider what helps your team work best naturally – color coded spreadsheets? Real time task updates? Keeping everything in one software or using multiple that can integrate? Changeable font sizes? 

You’ll also need to remember to resource capacity plan as you’re adjusting your systems. Examples: if you have three meeting rooms, you don’t want a scheduling system that lets more than three meetings get scheduled at the same time. You can avoid some comical accidents that can have serious consequences by building your system to work within your resource limits, whether those limits are from space, cost, technology, or people.

If you don’t build systems that can adapt to how your team actually works, chances are the system you adopt won’t be very sustainable long term. Either your team will have to find ways to work around problems, which will slow them down, or the learning curve will be bigger than it needs to be every time a new person joins your team, or your team will get annoyed or confused working with it so often that you’ll end up deciding it’s time to try something new, and the cycle will repeat itself. Your systems need to be practical in theory and in practice, which is why asking your team about how they work and what features they might need is always a good idea when you start to change things up! 

For the same reason, it’s important to train your employees well on any new systems put in place. For better or worse, this often means training them more than once on how to do it in meetings specifically designated for that purpose. If your training for the new system is an afterthought included in a bigger meeting, chances are your team is going to forget at least some, if not most, of the training. It also means you may need to explain the system and any related softwares in more than one way. Not everyone understands concepts in the same ways, so it’s not fair to expect that every member of your team will think about it the same way you do. It’s good practice to explain the steps of a system, particularly more complex systems, and how they relate to one another in a few ways to make sure the important parts of the training are really driven home. One way to help explain new systems can be systems mapping (read more about systems mapping here: An Engineer’s Perspective: Systems-Based Thinking), which provides a visual map of your systems and processes and how each piece interacts with the others. 

Beyond how to use a new system, it’s also necessary to train when to use a new system. If you hope to have consistent implementation on something new, it helps for employees to know when they’re supposed to do it. For example, if the point in the client onboarding process where you send your welcome email to a new client has changed, it’s good to reiterate the change in your process’ order a few times so that your team members can remember to break old habits and start new ones. Having your team practice a new system or process once or even a couple times together in a meeting will also help a lot with practical implementation, as opposed to simply showing them how to use it. Hands-on experience like that is better for forming the new neural pathways your employees may need for forming a new habit. 

Measuring ROI for Team Efficiency

When you go through the time & resource commitment of building out new systems and training your employees on them, you want to have some sort of metric to make sure it’s resulted in what you were aiming for. The goal is to increase team efficiency, so you’ll need a good way to measure the efficiency of your systems implementations. There are multiple ways you can do this, from tracking daily productivity outputs to timing individual tasks. Daily task output and timed tasks can vary a good bit for many reasons, but using your team capacity planning metrics takes a broader averaged view of your team’s abilities and can give you a better idea of how increased efficiency could impact your team in the long run: more time for client work and internal projects, less stress, a higher quality of work, and more. Then you can make a well-educated guess on potential returns from new clients, better marketing, and more tasks completed each week on average. For more on how to capacity plan for your team, see The Complete Guide to Capacity Planning for Growing Service Businesses. 

Hopefully this will help you start building systems that your team will love to use. If you found this article useful, consider subscribing to our email list for more practical business tips to help you save time each week.

‍