A few of my savvier (small-ish) software buddies use this system:
1) We have an onboarding Google Doc for everyone at the company. It is grouped into headings. One heading might be, e.g., "Common Customer Support Questions" followed by "Query: A customer complains they can't log into the software. Common phrasings for this: X, Y, Z." Research: "Go to page X in the dashboard [detailed in Internal Tools]. Search for... . If you find the customer, use the password reset tool, then copy/paste the following response to the customer, adding in their first name if you can reasonably guess it. If the tool reports no results, forward email to [email protected] and send no response."
2) Every time the proprietor gets tired of a genre of emails, they improve either the internal tools or the business rules to optimize themselves out of that workflow.
3) There is frequently a catch-all rule saying something like "If you have a novel situation and think you can handle it for under $100, do so [see: Getting Access To A Company Card], and fill in why the situation was novel, how you handled it, and what you spent on your weekly report Google doc. Don't worry, we trust you to use your judgement." (This is probably among the best pieces of actionable advice Tim Ferris ever gave.)
4) Capturing this state machine as a Google doc means the business has a memory longer than the individual workers, which is particularly important in a virtual-company sort of situation where you're dealing with VAs/freelancers who a) will often not pan out and b) when they do pan out have an expected lifetime tenure with the company of 6 ~ 24 months only.
Another solution for this is a wiki instead of a Google doc. I've seen it work well. But the important part is to make it easy to use, easy to search, and easy to update. Then just make sure as many questions as possible are answerable by the wiki. About to type an email with an answer? It better have the link to the wiki in it.
I've also seen wikis that just turn into gigantic repositories of stale data that just sit around while tribal knowledge is passed around by word of mouth. This seems to be the default state of the company wiki, really.
...and there must be at least someone, somewhere in your workforce under the impression that maintaining a wiki is somehow either the most productive or the most entertaining use of their time and effort at a given moment. That's the hard part.
Totally. A company that doesn't want to pay attention to why they do things a certain way, and keep evolving it, doesn't care to grow, or stay in business.
Too often, excuses from a site like http://www.yourlogicalfallacyis.com sums up why an organization doesn't maintain enough documentation of their business and the knowledge contained with it, and it's free to just walk out the door.
Now that's a little harsh. The fact is, every company where I've seen the internal wiki go stale is also a company that is otherwise incredibly successful. Though important processes were also documented by some additional formal process, and the wiki was a lower-priority thing anyway. Or at least, important wiki pages seemed to be better maintained.
I've observed with clients while systemizing their businesses: In the long run in those who don't keep it a priority to document, improve and transfer their knowledge capital regularly, peak out, stall and fade.
By failing to bake into the bread of their culture that understanding and sharing the why to do things a certain way.. maintaining their competitive advantage, they inevitably are exposed to becoming less effective, productive, efficient, ultimately welcoming a culture of accepting less and less.
It's also probably worth noting that I'm not talking about creating a mistake manual, but rather a why manual that helps teach the mindset that creates the types of mindset required to make decisions to grow the business
Businesses that become institutions do so with cultivating a a 50 to 100 year mindset, but few have a 10 year mindset to take what we do today and make sure it's happening while we find the next way to grow.
I don't think we disagree. Maybe you work with smaller and younger businesses than I've been employed in, because in my experience there's always SOME means of formal documentation, with the wiki as an optional layer on top of that. Or else, a really uneven wiki with some well maintained pages (generally the ones you actually need more often) and some stale data.
I agree, and so it always puzzles me why wikis are so hard to maintain. We use Google Sites at my job, and I've never found them particularly fluid, intuitive or efficient.
A markdown based wiki would be a decent start, but I still overall feel like this is an unsolved problem.
I think a lot of the problem is whenever you don't easily "see" all the information. In a document you can scan it beginning to end, and get an idea of what needs work. In a wiki you need to click through to other pages to see whether subsidiary pages need work.
Perhaps a wiki that allows pulling in "snippets" from linked pages could help.
I find a wiki that is less markdown based, but more ms word like seems to do well. Fogbugz is one example. You give up some and get some other stuff that just makes it a functional linker of docs
Besides no easy internal linking, Google Docs isn't that far off from a wiki. And as a bonus, non-technical people just see it as an ordinary word processor and don't have to understand the concept any further.
Agree. I also use a personal wiki (twiki) to keep track of all the answers and processes that I have figured out and need to use over time. Started many years ago it's close to 1900 pages at this point.
"Every time the proprietor gets tired of a genre of emails, they improve either the internal tools or the business rules to optimize themselves out of that workflow."
I really like this point.. I always think of the FAQ as a bug list. If a question comes up repeatedly enough that people have to start searching for a solution, odds are there are a way more people not asking and you're losing conversions.
This is sometimes phrased as "fix every problem twice," ie solve the immediate problem, and then figure out what to do so this problem doesn't happen again.
This can be done via tweaking your funnel or workflow, adding an FAQ entry, adding tooltips, restructuring your UI to make things intuitive, solving a technical glitch, etc.
1) We have an onboarding Google Doc for everyone at the company. It is grouped into headings. One heading might be, e.g., "Common Customer Support Questions" followed by "Query: A customer complains they can't log into the software. Common phrasings for this: X, Y, Z." Research: "Go to page X in the dashboard [detailed in Internal Tools]. Search for... . If you find the customer, use the password reset tool, then copy/paste the following response to the customer, adding in their first name if you can reasonably guess it. If the tool reports no results, forward email to [email protected] and send no response."
2) Every time the proprietor gets tired of a genre of emails, they improve either the internal tools or the business rules to optimize themselves out of that workflow.
3) There is frequently a catch-all rule saying something like "If you have a novel situation and think you can handle it for under $100, do so [see: Getting Access To A Company Card], and fill in why the situation was novel, how you handled it, and what you spent on your weekly report Google doc. Don't worry, we trust you to use your judgement." (This is probably among the best pieces of actionable advice Tim Ferris ever gave.)
4) Capturing this state machine as a Google doc means the business has a memory longer than the individual workers, which is particularly important in a virtual-company sort of situation where you're dealing with VAs/freelancers who a) will often not pan out and b) when they do pan out have an expected lifetime tenure with the company of 6 ~ 24 months only.