Tools Do Not Solve Problems
Process, methodologies, and champions do
For the last 15 years, I have worked in the world of technology. This landscape has undergone numerous shifts and changes, but one thing has always stayed true – teams have internal problems they need solved. I have been on the technical side fixing technology and people’s relationship with it. I have lead quality assurance teams. I have headed product management for SaaS companies. Now, I am solely a consultant. I build systems, and more importantly, processes for teams to solve their problems. I confidently do this job because of my varied experience, and this experience has taught me a valuable lesson – tools cannot and will never solve a problem.
Tools, both software and hardware, are indeed designed to solve problems. While they do provide the mechanism to solve them, people are people and a solution is never that straightforward. When the bike was invented, it solved the need for faster more efficient travel, but it didn’t give us the capability to travel long distances. We had to put in the time to build the skills and muscles to go miles. When the calculator was invented, it allowed us to solve higher level math problems much faster, but we still needed to know the equations and steps. Even today, with SaaS tools that claim to solve all of your operational deficiencies, you still need process to account for the variable in every solution – the human using it.
Over the years in this industry, I have had many solutions to leverage. They were physical and sometimes digital. I have facilitated hundreds of trainings and workshops, both in person and remotely. No matter how well the tool was designed, we always need rules and guidelines to reinforce them.
Below, we are going to go over the four topics I enforce when building operational systems for teams and individuals.
Process
The foundation to any tools’ success requires process. Before new process is created, you must understand where the old process went wrong. Was there simply no process? Was the process inefficient, resulting in more work and wasted time?
To determine this, we need to audit what is not working. Interview team members, finding out their process – both the how and why. This can be done synchronously, in person or over a call. This can also be done asynchronously, over a chat or using a form. Depending on the size of your team, I recommend getting this data from 10-20% of the whole team, managers and individual contributors alike.
Review these processes. Find trends, both good and bad ones. Identify if these trends were due to a limitation of a tool or lack of process. After a few interviews, the trends should start to become obvious.
When crafting the new process, document it in detail. Write it down, simply and clearly. Make a video, a simple screen recording usually works. Add a decision tree – a simple multi-path flow chart going through each step and the possible decision. By making these varied mediums, it will setup a solid foundation for change.
Methodologies
After the foundation has been laid, I recommend finding ways to solidify your process. The easiest way to do this is to find or create any accompanying methodologies. This will allow for easier repeatability.
If you are implementing team goals, I recommend using something like OKRs (Objectives and Key Results). It is a simple goal + metrics system that works very efficiently. The nice thing about OKRs, is that they can be massaged to any teams’ needs. I have worked with dozens of clients that use their own versions. I’d recommend starting with the default system, then scale it up or down as needed.
If your team is finding it hard to prioritize their work, consider a methodology such as SCRUM, Kanban, or even the simple Eisenhower Method. These all provide tried and true systems that scale for varied team types. I personally like the simplicity of Kanban for most teams. It isn’t too structured, while still providing enough guidelines for teams to use it efficiently.
Some teams find it challenging to decide how and where to store files. Most teams just follow whatever comes naturally, but a methodology here can be very helpful. The two that I reference the most often are PARA and Johnny.decimal. These are starkly different systems, but both are extremely effective. PARA is fluid, while Johnny.decimal is a bit rigid. Each type of team can benefit from each system in their own way. It is a bit hard switching between each, so selecting one and going all in is key.
Training
In order for your team to understand how all of these tools, processes, and methodologies work together – they need training. Training can be facilitated 100% asynchronously or be done live. Both are fine, but I recommend mixing them up.
When rolling out something new, do a live session going over the high-level process and methodologies. The first session should be with the whole team. If your company is large, break it up, but don’t make them too small. Mix departments and teams together. In addition to this, have documentation and async video training available that goes into the details. If you have team or department-level systems being rolled out, hold those trainings separately.
The essential part of training is to vary it. Offer different levels for different companies, departments, teams, and people. Go wide at first, then over the coming weeks, get very narrow. Get down to individual training if that works for your company.
Championship
A system, tool, process, or methodology is useless, unless you have people backing it up. During the crafting of a new system, ask for volunteers. These volunteers may not come forward immediately. They might show organically. They are the people that are the most vocal and bought into the new system. They will be the first ones to test the tool, make sure the process is sound, and swear by the methodology. They might even want to facilitate some trainings.
I recommend finding these champions early. The earlier you find them, the more they will provide feedback and spread the word. You should have as many as possible. In a small org, there might only be a few, maybe just the leadership or management team. But in larger orgs there should be at least one in every department or team with a seat at the table in their working group. They should be the people at sprint planning, yearly and quarterly goal setting, the design critiques. As decisions are made and tools are used, they can tell the team if they are doing it incorrectly or reinforce good behaviors.
Teams try to rollout new tools all the time and I have seen so many fail. They migrate from one to another, lose historical data, and waste dozens of hours. This is not only expensive, it’s exhausting. While there is a time to switch tools, there is a new tool launching every day. You should only switch if you can support the switch with practices and ways of working that foster them.
If you are thinking about rolling out a new tool or have a hole in your system, I would love to chat with your team. I am a Digital Operations Consultant, helping teams with their operational efficiency. I am a Notion Certified consultant and have 15 years of experience working in and helping product-driven orgs. Schedule a discovery call!