Sailing in the digital world
Savage’s analogy of metis and the deployment of digital tools really struck a chord with me. I look back to summer evenings spent sailing with my dad on Lake DuBay, and I understand the point he was trying to make. The goal of sailing and of deploying digital tools isn’t to master anything; that isn’t possible. It is to be responsive to several factors that can change quickly and sometimes all at the same time. My Dad’s C-scow was a fun boat to sail, but it was a highly temperamental boat to race.
For those who may not know, scows are wide and flat bottomed sailboats. They are slow when sailed flat, but they become much faster when they are leaned up on edge. The waterline changes from wide and flat to very narrow and long, which drastically reduces the surface in contact with the water. When everything is going well, it is fast and exciting. Racing the boat is a matter of weighing risk and reacting quickly. You can always lean the boat less and sail it less aggressively, which will allow for more time to respond to changing conditions. Or, you can lean it far, sail very quickly, and sacrifice some of your time to react to changing conditions.
What does all of that have to do with deploying digital tools? Some of it is preparation, making sure you have done the testing needed to make sure everything works and understand how it works. Next, you need to have a team or crew that you can trust to handle their job if anything changes. The final portion is learning to pay attention to the signs in front of you. There are a lot of variables in both that can change, so paying close attention to everything around you is key to reacting to those changes. If you don’t notice a problem, it is unlikely that you will react soon enough or in the right way to be useful.
Each of us must exercise critical digital literacy to succeed in this ever changing digital world. We must understand more than just the context of our work. We must also have a strong grasp of the tools available to us and how best to use them. This was part of what prompted our switch over to HTML based documentation. The majority of employees work from home, so information needs to be accessible and able to be retrieved quickly. They also frequently have several programs open at once. HTML files are much smaller sized, and they open from a browser rather than Microsoft Word. This reduces the resources needed to open access and use the documentation.
The readings discussed single sourcing, which is another thing my team is working toward. We have established common wording guides to for frequently used portions of text or steps in processes that are program specific. This helps save time and drive consistency throughout our documentation, which can be difficult with eight different writers sharing the workload. We also have editors who help raise the quality of the documents and unify the voice.