A Culture of Documentation

When your team is remote, distributed, highly collaborative, and fast-paced, having solid documentation is core to effectiveness. Creating, collaborating, & keeping documentation keeps us all accountable & efficient. This also makes onboarding much easier.

Interested in trying your hand at writing documentation? The first step is to try it out! The learning curve is steep, but very rewarding. More info here

What is documentation?

In business (and in life), we come across the same questions & concepts quite often. We encourage everyone to document answers to questions so that they can be reused and improved upon over time. We organize our docs into a wiki that's easily searchable. Documented topics range from "How do I enter a transaction into Transactify?" to "How do I explain cast-iron plumbing to a buyer or seller?"

Why documentation?

Well written documentation increases efficiency! When everyone can easily find the answers to their questions, it helps everyone work faster and more efficiently. Likewise, when we collaborate on documentation, we get to use the collective experience & knowledge of everyone in the orgnanization vs. that of one individual.

Tribal Knowledge

My Mom taught me how to make killer spaghetti. Her Mom taught her the same recipe, and her mother before that. No one wrote down the recipe because they showed each other how to make spaghetti. This is a great example of tribal knowledge. In a company, tribal knowledge is any unwritten information that is not commonly known by others within that company. This term is used most when referencing information that may need to be known by others in order to produce quality product or service. A primary documentation goal is to find all tribal knowledge and document it so that everyone now benefits from it and the knowledge will never be lost. If you know something great, let us know so that we can document it or document it yourself!

What can I do?

Writing documentation doesn't come naturally to most people (it's normal if you don't feel like writing a wiki), but almost everyone can read and understand well written docs. When you have a question, make a habit of searching the wiki before you ask for help. When you do ask for help, see if there's existing documentation that can be improved upon and add your new knowledge to that documentation. If someone provides an excellent answer to you, reach out to Eric, Bailey, or Alex and let them know what you learned and how helpful it was. There's a good chance we'll want to document it.

How can I write documentation?

I'm super glad you asked! Functionally, it's really simple. Instead of creating a suggestion, just add a new page and get started. The most important step is simply the first step of writing something. You can always come back and improve it later. That said, here are some good pointers:

Start by identifying your problem. Questions work really well for this. "How can I write documentation" would be a great topic for a wiki.
Explain why others want to know the answer to this problem. How is this helpful?
Write a concise explanation of the solution.
Consider giving a real world example of the problem and how you were able to solve it.
Use lots of bullet points! People love to scan documentation.
Pictures are worth 1000 words! Include a helpful picture, if possible. If a fun picture would make it more entertaining, include a fun pic.

Bear in mind that writing documentation takes time. It might take you 10 minutes to show someone how to do something & 30 to write a good tutorial. Focus on how much time you'll save in the long term. The person you showed how to do something will usually come back to you with questions, unless you have documentation. The next person who has this same question can simply look up your great wiki. Writing documentation is an excellent investment in time over the long term.

When do we not want documentation?

Documentation is most helpful when it's easy to find, clear, & concise. If we document everything, then our documentation set is no longer concise and it becomes bloated and not easy to find answers within. We'll run into edge cases that happen infrequently. Whenever we identify something as an edge case, we'll choose not to document it, in order to avoid bloat. When we run into edge cases, we want to problem solve them as best we can and ask any necessary questions. (If an edge case keeps happening, it's no longer an edge case and we'll want to document it.)

Is this an edge case?

If the event happens less than 2-3 times in a year, it's probably an edge case. If it's happened once/year or less, then it's definitely an edge case.

Examples of edge cases:

An outside agent doesn't follow instructions with regards to delivering the option check to title, so we have to figure out how to get the check to the sellers.
A client is listing a condo, and despite condos typically not having surveys, the client provides us with a legitimate survey, so we provide it to the buyers and title anyway.
We have already pulled inventory from a property per our normal process, but a seller needs to return to the property to remove a box they forgot move before closing, so we have to work with the buyer's agent to help arrange access.