A very long time ago, I started a new job as a Sales Engineer (SE) at a company that would eventually be a very big deal in its space. I found myself learning new products, processes, and a new industry all at once. Add the fact that my “territory” was HALF THE PLANET, and you can imagine how overwhelming the learning curve was. I knew that to survive this massive influx of information and possibly teach it to others in the future, I would need to document everything, so I started writing.
I wrote down everything from demo conversations to install instructions and HR processes. This grew into flowcharts and lists, gotchas, and guides. Being a relatively young startup, almost all of the information was being shared organically, and there was a ton of tribal knowledge. After about 30 pages of these personal internal notes, it became pretty apparent that this was going to become a “how-to-do-your-job” guide that I would constantly be referring to, so I added a title page – “The SE Survival Guide.”
And it grew, and it grew. By the time we hired our next SE to join the team, there were entire sections in this novella for HR processes, demo activities, and undocumented debugging tricks, so I used it for training material. This is where the story takes a twist. I remember saying, “this is a living document, and it is your responsibility to contribute to it as needed.” That turned out to be incredibly powerful and has been an invaluable lesson in my career. Over the next decade, that document was contributed to by a dozen Sales Engineers and was used as training and reference material by product managers, salespeople, engineers, and implementation teams. Since we all used it, we all owned it and nurtured it.
Empowering teams to manage their documentation proved to be a powerful tool for efficiency. The learning curve is shorter because all the tribal knowledge is actually written down, not passed on verbally. It is easy to look up processes that change periodically. It is highly accessible, so anyone with new information can update it when needed. The team can benefit from fast on-boarding times and fewer knowledge gaps.
Since then, I have used that same concept in many different places – starting with my own notes, then turning them into open docs and sharing responsibility with a team. Notice I said “responsibility”, not just “edit rights”; The phrasing is important. When you share a document with edit rights, there is an understandable assumption that the person that shared it is just asking you to contribute edits. However, it is imperative that when you share a living document, it is clear there is shared ownership and responsibility. That is the key to making it work.
As I now embark on new ventures, I find myself creating new living documentation – one of the things I consider an essential building block of good teams. I look forward to seeing what this next iteration looks like.
Be awesome; Change the world.
The Bleeding Edge 
Leave a comment