Write how to guides if your a busy person

The clock ticks. There's a pile of 100 sticky notes on your desk. Each being a TODO item. But you only have bandwidth to do say 20 of those items in one day. The next day another 25 sticky notes get added to that pile. To the point that TODO list will never be empty.

Sometimes it feels like you just have a giant backpack of stress/burden strapped on you 24/7.

If that sounds anything like you, you probably are a really busy person. Heck, you probably have books like "7 habits of effective people" or "Getting things done" to figure out how to be more productive. You probably tried some crazy notion setup to help organize your thoughts

You might be the type of person that also feels like they need to do everything. Because you have an obsession over shipping things with quality.

You've realized you need to delegate work because your just one person. You've tried though, but sorely failed.

I used to design restaurants for a living. I've helped build a few dozen, some becoming very successful franchises. One thing I learned while working in this industry is finding & keeping talent is hard. Training people is hard. These aren't just from my own set of experiences, but accounts I heard from my clients

The solution to this is writing "How To Guides". Companies like Amazon, [insert any large corporate chain], live and die by documents like these. A successful "How to guide" can be broken down into a few metrics:

  • Use tools everyone knows how to use
  • Create as few interpretations in a document
  • Test out how-to-guides on multiple people
  • Think win-win
  • Write the how-to-guide on the spot

Use tools everyone knows how to use

When I was in college, I used to help run IT infrastructure for a few small businesses. I'd get calls like "hey why isn't my computer turning on" to "can you setup a salesforce instance?".

Sometimes I'd get shiny tool syndrome. I'd find this cool useful tool that helps me in my day to day operations, so I install it on someone else's system

My stress went up through the roof those days. Calls now became "I can't find documentation on this tool! How do I set this custom GUI file explorer on here?". And sure enough my weekends went down the drain.

I've learned to just stick with tools everyone knows. This concept really stuck with me when I used to work as a coding tutor for a national bootcamp

Most companies will use sharepoint, or some fancy system for managing their internal docs. This place had their entire training manual in dozens of google docs interlinked with each other. Like 100s of documents. And it actually surprisingly worked pretty well too

Always roll with tools that everyone knows how to use unless you have a good reason not too. It makes onboarding the delegation much easier too

Create as few interpretations in a how to guide

It's a really common pitfall to just "throw money" at a problem, or just assume that if you hire someone in that domain expertise, things magically get solved.

I've seen multiple clients that have done this. "Hey if we hire another person, that should be twice as efficient as one person doing the job!"

That never actually happens.

I've learned this lesson when I've had to hire designers, video editors for side projects I worked on. Don't state "how it should be done", rather "what you expect"

So describe the problem your trying to solve. What kind of logo do you want? What is marketable and brandable, and who's your target audience? From there, you want to create a document that follows the 20/80 rule. 80% of your document should not be misintrepretable. Leave the last 20% for random unexpect things that might come up and to be pleasantly surprised on improvements that might've been made

An example of this as such:

  1. "We need a logo for a restaurant. It needs to be red and orange"
  2. "We need a logo for restaurant. Our focus is serving fusion asian food, we're primarily thai and vietnamnese, here are logos that are close to the aesthetic we want"

The first bulletpoint is too vague and doesn't convey what's being solved. You want to create ownership and let someone who will be focusing on the task to own it and put their own spin on it.

Test out how-to-guides on multiple people

We sometimes call these user studies. There super important. If you work in a domain space too long, chances are you can't see tell a bad idea from a good one right away. They all look the same to you.

This is especially true if your building a logo for instance. You won't spot caveats to it, like if a logo looks like something it shouldn't be.

When we designed Tampa Devs, we ran through 3-4 user studies across 3 week on about 100 people. We had iterations that were deemed sexist, sometimes not gender neutral enough, or unfriendly. Sometimes the logo didn't just look right, or didn't fit the right theme.

Run your how to guide through multiple people - this will ensure it's easily understood

Think win-win

I used to work at a startup where I was paid "sweat equity". I built the app originally as a hackathon app between jobs so I just continued helping out to see where it'd go

We started getting into OKR(objective key result) topics, but the founders missed a key part of the topic. I had nothing to gain (asides experience I wanted and got at the time), so once that got stale I left

When you think win-win, you need to consider what the other person is gaining. In a contract, this is usually pay, a promotion, etc

But if you run a nonprofit, where you want to create a community, this is a totally different story. You instead want to create coshared experiences /hardships, a sense of growth, and a story that people want to rally behind.

Think win win - what does the other person have to gain?

Write the how-to-guide on the spot

The best way to write a how to guide is to do it right then and there. If your training employees on how to operate a piece of machinery, just have record of a video of it. It doesn't need to be super complex, as long as the point gets across. You can just dump all these videos on a google drive / youtube with some supportive text links as well

If your doing a more technical task, like triggering a devops pipeline, screenshotting different stages of the process is better.

Each document depends on the situation and the training needed. Once you incorporate this like a muscle, it becomes a habit.

It does take more time to do a task this way, but you'll save yourself so much time in the long run

Here's my cluttered stickynote desk for reference as well

Image description

Hi 👋

I'm Vincent Tang, a software engineer specialized in product manufacturing. This website is my public notes of leadership lessons and technical build logs of problems I solved. I'm the founder of Tampa Devs and I also run a coding podcast called Code Chefs

TwitterGithub