Thank you to Mike Simmons and Jennifer Simmons for inviting me to the Leader Lab community event to discuss business efficiency, specifically how creating and documenting processes helps you easily complete, delegate, and repeat good work.
Leader Lab is a space where dedicated, growth-minded leaders gather to find clarity, sharpen their focus, and boost confidence through collaboration and connection. Mike and I first chatted on Mike’s podcast: Find My Catalyst episode and he invited me to speak at one of their Leader Lab events.
|
The meeting covered these topics (which link down to that section of the blog):
|
What does the word ‘efficiency’ mean to you?.
It can seem very vague word in some business advice, so let’s make it real.
Some dictionaries will tell you efficiency is the “state of being efficient,” which is not a helpful answer; you can see that in the first entry. The second entry is a little more useful. Efficient operations, as measured by a comparison of production with cost (as in energy, time, and money) or the ratio of the useful energy delivered by a dynamic system to the energy supplied to it.
A Quickbooks blog denotes TYPEs of efficiency, which is helpful for adding context to that definition:
A more helpful and HUMAN answer about 'What is efficiency?' may be:
Efficiency is the ability, the art, and the science of taking less time and effort to complete routine work.
Which usually results in cost savings, work with fewer errors, therefore less time is needed to correct errors, and stress savings, from eliminating the need to rush and fewer errors to correct creates less stress.
Another part of the human side of it:
Being efficient with routine work gives you time and energy to devote to new challenges, new problems to solve, work that actually needs your creativity and effort. Work that you likely enjoy doing more, and has more impact on your goals.
Sometimes the word efficiency can have negative connotations, like layoffs, moving jobs to other countries, having fewer resources, and rumors of replacing jobs with AI.
So I think it’s helpful to talk about these human benefits of efficiency, to get over any negative connotations of the word.
‘Productivity’ is a related word, which is usually more about ‘amount’ done, less about time/resources it’s done in. If you feel that is a more positive word, feel free to use that!
Aside from my own experience, I did some research to make sure I covered more options to achieve or improve efficiency, to gain the benefits of efficiency:
A first step to using many of these tactics is:
Process documentation.
We are focusing on ONE of those ways to gain efficiency in your job or business:
Documenting, which is writing down or recording your processes.
So the “how to do the work” information and context live somewhere other than inside your brain.
Not many people talk or write about process documentation, compared to the trendier efficiency topics we just discussed, but documentation is a foundational piece for efficiency. Especially if one way you’re looking to be more efficient with your OWN time is to delegate this routine, repeated work to other people, documentation is key. For training AI and creating automation, you will likely need to have documentation of some sort. You can think of AI as “the new hire” in this meme from Trainual, if that helps explain the context.
Documentation is recording who, what, where, when, why, and how to do everything in your company or role.
and
Storing that information in one place where other people can find it and use it.
The storing part is often called knowledge management, but we’re not getting into those semantic differences today.
Basically, documentation is any recorded information. Information that is not only located in someone’s head.
Documentation is sometimes referred to as Standard Operating Procedures (SOPs), Business handbooks or manuals…but the words 'process' and 'procedures' can be intimidating.
I like to make it more relatable and easy for all roles in the company to understand.
Documentation is content. Helpful content!
Documentation is knowledge sharing!
It also doesn’t have to be written. It can be in video format. Start with the format easiest for you to actually do. So you actually start. Something is better than nothing!
Here’s a visual example of a knowledge base article from Gitlab, which is one of the original champions of documentation and open source, open access to information. You can see the table of contents here for the steps of the process in two places, a static location at the top of the page and in a sticky menu on the right that follows you down the page as you scroll.
Here’s another visual of a documentation format that I use in my classes:
Continuing to break down process documentation into human language and make it less intimidating, let's make sure we're aligned about the definition of processes.
The dictionary says process is a series of actions or steps taken in order to achieve a particular end.
Process can sound like a scary word, like something big, complicated, difficult, and intimidating.
A more human definition:
A process is something repeatable you do in your business or job.
Such as sending a marketing email. What are the steps to do that?
It could be thought of as a routine you do as a result of learning from many different sources, different people, and trial and error over time.
Let’s write it down to remove future errors!
Mike and I talked about documentation in his podcast, and he had this great point below about processes and efficiency that could be helpful for you to think about. Especially if your initial objection or reaction is “I don’t have any processes.”
Now that we’re all on the same page with the same foundational level of understanding about efficiency, processes, and documentation, the ‘what’ of this article or presentation, we’re going to talk more about why you want to create and use documentation.
Why does having good documentation help improve your efficiency?
I interviewed some experts for a blog on why documentation is important, and so you're not just hearing my opinions, here’s what they have to say about documentation fostering efficiency:
There are many other benefits to process documentation besides efficiency, but we're trying to focus this conversation on the efficiency benefits.
So we've covered the WHAT and the WHY, and before we get into the HOW specifics, I want to help you overcome some common time or efficiency-related objections, questions, and myths about documentation. Maybe overcoming your own reluctance and objection to spending time on this work.
You can see this meme, which is geared towards developers, but debugging is solving problems, fixing problems, fixing errors, that would not be there IF someone reads the documentation to perform that work instead of just winging it and doing whatever they feel like.
You could have a whole session or talk on overcoming objections, but the summary, too long didn’t read, version is:
Overcoming objections is most successful when you know what the person you’re talking to cares about, and you explain the specific benefit that relates to that care.
Personalize your defense to align with what that person cares about.
What does leadership care about?
Achieving business goals.
In this case, you will want to tie the benefits of documentation to either the goals of their role in the company or to their values as people (possibly related to company culture), if you know the person well enough to know their values.
Time-related objections are most closely related to efficiency, our topic today. Here is a time-related objection you may hear.
“Our company is innovative, we move fast and break things, we don’t have time to document. It’s a waste of time.”
Here are some phrases or scripts you can use to overcome that objection:
Another time-related objection you may hear is:
“I don’t have time to create documentation or to ensure other people do it.”
If you hear this objection, here are some phrases to overcome it:
I did a lot of selling you on the why, because documentation is something many people are unfamiliar with, since most companies don’t do it or don’t do it well.
People resist it, people are naturally seeking that magic silver bullet efficiency solution, looking for an easier way,
Instead of spending that same amount of 'searching time' on building the efficiency foundation with documentation.
I also made that first part of the presentation so you can convince other people in your company to document and use documentation, because when you are scaling this behavior and habit across the company, that is when it becomes really useful, and you see more of the efficiency benefits.
A lot of companies don’t get to that point, but hopefully you will.
So let’s get into the how of documentation.
I suggest starting to document by writing the steps of the process or task.
This is the bare bones of process documentation - the steps to complete the processes.
The fancy business consultants and efficiency experts will talk about business process mapping as the documentation that you need, but that is less creator-friendly or user-friendly for most people to learn that software. Learning what all the shapes mean is a barrier to starting documentation and making this a habit.
Simply using a document of steps is a great place, an accessible place, to start your efforts. It is something everyone can do.
A helpful analogy to use to write process steps is to think of writing a process like writing the steps of a recipe.
Think about what you do first, second, and third in order to complete the task or achieve the outcome (make the food or eat the food).
Thinking of the process steps like a recipe can also relieve some of the pressure you may feel when you're procrastinating documentation. Getting over the fear of the blank page or writer’s block. Thinking of writing about making yourself some food instead of thinking about how to do something you need to do to be successful in your job can relieve enough stress for you to start a first draft of your process documentation.
Thinking of the steps of the process like a recipe can also help you think of steps you do automatically, but they are steps that other people wouldn’t know how to do. Thinking of it like physically assembling and cooking something, as opposed to thinking about clicking around on the computer.
Recipe thinking also helps you with breaking the process down into small steps. Use small, clear, manageable steps.
Sadly, there is no secret answer, but general tactics include:
Then we walked through the sections of the documentation writing template.
One more important note to help you get over the fear of the blank page, to help you not get stuck, and be efficient:
There may be parts of the process where you don’t have all the information yet.
That is OK!
Your document could start as a skeleton with one section filled out, and the rest of the sections say “coming soon,” "in progress", language like that. You can fill in the rest later as you return to the process, the next time you perform it.
Think of documents as living, living documentation, updated often, and don’t have to be completed all at once.
One reason is to accommodate different learning preferences, such as visual learners who prefer seeing words, visual learners who prefer seeing images, or audio learners. Different people prefer to learn using different formats; keep that in mind.
Another reason may be that a document of 30 steps related to what to click in your software may not be user-friendly; a short 1-minute video may be more helpful to embed in the document.
I also recommend that visuals be added as the last step, since the written-out steps are often needed to decide which step would best be displayed or illustrated using which type of visual.
Read more about visuals for documentation in this blog post.
Once you feel confident writing the documentation itself, how do you keep it updated efficiently?
By having a system and by involving other people instead of relying on one person for all documentation in your company.
In order to help convince other people to use or be involved in documentation, you’ll want to have a proven system for yourself first.
Set up your personal documentation system first, so other people:
You’re the beta tester to make sure this system works before adding other people to the system.
So let’s back up for a minute and talk about what I mean by system, since a lot of us may be in the tech industry and immediately think about software as the system.
In this context, a system is more like what the Oxford dictionary says:
If you skip all this system work and go straight into choosing a documentation storage tool and expect the tool to work miracles all by itself, that is likely to fail. And I don’t want you to fail.
So the system we’re talking about is the combination of:
How do you remind yourself to do this documentation work on a regular basis?
Remember that documentation is not a set it and forget it, not a one-time project. It is living and constantly evolving.
So you’ll want to start creating your systems by reserving time to create, use, and improve documentation.
A few time-reserving examples:
Having a system of reminders is very important.
Not just having this task sitting on your calendar or in your project management system, but think about how is it going to get in front of you to remind you to do it? Some kind of pop-up or time-delayed notification will work.
Then, to efficiently complete this work, instead of spending this time block searching all around trying to remember what exactly you were going to work on regarding documentation, where you left off:
Add the specific details of what you are going to work on next time into your time blocks or tasks, ideally with links that go straight to the work in progress.
Interlinking everything into a system is a big theme to make it easy to find what you need to work on, with less searching around in all your tools.
Three project management tactics for your documentation system:
People aren’t going to know that documentation exists and why they should use or create it unless you communicate about it regularly.
Eventually, you’ll have many methods, interlinked, of communicating about new or improved documentation as you’re building a culture of documentation
But start small.
Pick one channel, method, or tool to start this communication while you’re building your own documentation system.
Test and see what people respond to. Then expand to additional channels.
Example: Using a new Slack channel just for processes (give it an interesting name, not "documentation"), create opportunities for two-way communication for questions and requests as well as announcements.
Later, you can copy the important messages from the Slack channel into a weekly internal newsletter section or a weekly meeting topic agenda. This gives you one source of truth, so you can efficiently distribute the info.
In that first stage of creating version 1.0 documentation, you are using the creation and storage tool easiest for you. because the habit is more important than the tool, especially in the early stages.
Remember that you can hire someone later to migrate your documentation from one system to another, or delegate that task to someone on your team later on. But it is very difficult to hire someone to write your processes for you, to extract that information from your brain.
Write version 1 first.
When you’re ready to add other people as users of documentation, you will start to think about a tool that is easy for your team to use, which may or may not be different than the tool you’re currently using for yourself.
My #1 tip is to use a tool your team is already using daily.
Then you don't have to teach them a new tool IN ADDITION to teaching them new habits about creating, using, and updating documentation.
New tool adoption is hard.
Unlike simply migrating tools for current work, documentation may be a new area of work or a new habit, especially for the people responsible for creating and editing it.
Building new habits is hard.
We want to make documentation as easy as possible to get other people to use and create and update, so using a current tool for documentation creation, storage, or retrieval is a great place to start creating those habits!
Let’s talk about roles, the different ways people can be involved in your documentation system. This is how you are going to scale your efforts efficiently. Because you can’t do it all yourself for the whole company unless maybe if your company IS one person.
The roles you want to assign people:
Don’t try to introduce all the roles at once unless you already have a system in place that you are improving! You will get overwhelmed, and your team will also get overwhelmed. It may take 6 months or more to roll out these roles in the above order, after 3 or more months of working on and doing your personal system
Read more about roles in this blog.
When you're ready to start your documentation initiative, think about:
Why have you struggled with starting or maintaining documentation? What have been your roadblocks? Why is it so difficult to start?
Time is the most common answer, which is also why we’re talking about efficiency and time.
But let’s identify the reason causing you to feel you don’t have time.
The biggest reason is usually overwhelm.
Another reason is if you’re worried about team adoption.
Or perhaps you’re worried about getting leadership buy-in.
To help simplify where to start your documentation journey, I have 3 suggestions based on three common roadblocks.
Most importantly, don’t overthink it! Start taking action.
If you're not sure what your roadblock is, start small, choose that one! If you can find a process that meets more than one of these solution criteria, that is probably a great choice to start with.
Thanks again to Mike and Jennifer for inviting me to chat at Leader Lab!
Thank you to all the community members who participated with excellent questions!