Distributing Operational Knowledge Across a Team

Written by: Chris Ward

I am sure we have all worked (or work) for companies, teams, or clients where communication of internal information is somewhere on the scale between nonexistent and abysmal. Despite constant advances in information storage and communication technology, I'm sure many of you would agree that we are still not any better at communicating with each other. In this post, I will discuss some tooling options to consider, but more important, cover when, why, and how to use them.

[caption id="attachment_5970" align="aligncenter" width="960"]

Every organization has communication issues.[/caption]

Knowledge management is an entire role and sector in itself, and one with a lengthy history. Companies with employees that have this role are typically much larger, but there's no reason smaller teams can't adopt some of the same practices. In fact, a small or new team is often in a better place to affect change as you have less baggage and inertia.

Tools

Many tools can, in theory, fit into the category of 'knowledge management,' and listing them all would be a long and tedious article to write and read. Instead, I will introduce the principles of tools, mention the most popular, and then point you in the direction of where to find lists of options to consider.

Task managers

A task management tool varies in complexity from more straightforward options such as a shared 'To Do' lists that mark a task as done or not, to customized issue tracking software with multiple projects and access levels.

At the simpler end are tools like Wunderlist or Keep, and I recommend you read this Guardian article for a round-up of seven to consider. These tools don't allow for much discussion on tasks, or for handing tasks backward and forwards, but for smaller teams with concrete and obvious tasks, they can be more than enough.

[caption id="attachment_5971" align="aligncenter" width="960"]

Making to dos doesn't make you any better at completing them.[/caption]

Trello firmly occupies the middle ground of task management tools, but it also has many alternatives, and I recommend this Quora thread to find some options to consider. These tools typically offer multiple user accounts with differing levels of access, different projects, a degree of discussion on each task, task statuses, and integration with other services.

At the higher end is the tool that everyone loves to hate, Jira, and it has plenty of alternatives you can find in this workzone post or on alternative.to. These tools allow for in-depth discussions around issues, complex categorizing of issues, a lot of integration options and white-labeling for your business or project. Depending on which option you choose, configuration options are almost endless, and this is one of the issues with this level of tools, they often require a more significant time investment for setup and daily usage, which can lead to abandonment if you're not careful.

Knowledge repositories

Task management tools help teams communicate tasks with some form of deadline and (typically) minimal discussion. For information that you need in the longer term, or that requires more content than is usually readable in a comment, you will need other tools. These can vary from shared documents in a folder to complex wiki tools. This area of tooling is not as clear-cut as with task managers, as tools have more gray areas between the functionality they offer. It's also a tooling area that has existed for a lot longer, and so there are more modern takes on an older idea, which grays the lines even more.

Creating a shared folder on a networked drive and storing documents for team members to refer to and collaborate on is not a new practice, but the options for sharing a drive have. Among dozens of cloud-based options, Dropbox is the most popular, but there are many more, and also options that you can also self-host. If you want to keep your options more traditional and use a shared volume on your local network, then options vary depending on what varieties of Windows, macOS or Linux you are running, but it is possible.

It's worth noting that not all the options mentioned above are truly collaborative. For example, Dropbox is for sharing; if two of you work on a file (locally) at the same time, you will create a file conflict. However, with other options, such as Google docs, you can edit files in a browser window, collaboratively seeing the changes everyone is making in real time. For those more technically minded of you who are up for a challenge, another great option is using version control such as Git and GitHub. There is a small learning curve, but it gives you fine-grained collaboration that few of the other options provide.

Wikis are also not a new technology, and their popularity rises and falls. Wikis allow for collaborative creation and editing of information, typically rendered as a web page. Depending on how you setup permissions, they enable users to create content they feel is missing, and suggest edits to other content. If rendered as a web page, you can embed other forms of media into a wiki such as images and video that can help clarify complex topics. Confluence is one of the more popular commercial options, but there are many others to choose from, including a lot of open source alternatives.

Communications

Companies and projects that are attempting to 'disrupt email' have grown at a rate almost comparable to JavaScript frameworks and databases. I will address the more systemic issues behind knowledge exchange later in this article that led to this desire, but most communications tools are similar in the way they attempt to "fix it."

[caption id="attachment_5972" align="aligncenter" width="960"]

Too much communication can be a bad thing.[/caption]

These tools allow users to create "channels" or discussions around particular topics and also message individual users. On top of this are user roles and permissions, notification preferences and integration with other tools. Slack has been the recent success story, but this is also not a new field of tooling, and there are also a lot of commercial and open source alternatives. The main differences between the platforms come in usability and features vs. price; you pick what works for you.

CRMs

Customer/Client/Constituent Relationship Management tools (CRMs) are often part of an attempt to unify many of the tools included in this article so far and add much more besides. CRMs are often by nature complex tools that need setup and configuration, and you often don't need to use one as soon as you think. CRMs focus on whatever the 'C' stands for to you and your interactions with them. Depending on your configuration, you can track communications, memberships, sales, tasks, meetings and much more. They are people-centered, and if your project doesn't revolve around interactions with people, then they are also probably not necessary for you.

[caption id="attachment_5973" align="aligncenter" width="960"]

A CRM focuses on a person.[/caption]

Salesforce is one of the biggest players in this space, and while the name indicates its popularity among sales teams, people use it in other contexts. CRMs are BIG business, and thus, there are a lot of commercial and open source alternatives. I used to contribute to and implement an open source CRM, and it's worth noting that they can require a lot of initial resources to get started with and customize them in the future.

!Sign up for a free Codeship Account

Practices

Picking tools is easy, getting people to use them is the hard part. I have spent time in companies attempting to get people to use tooling, and to use it correctly, and it's a particular bugbear and passion of mine. Good communications and usage of tools help people understand where to find what they need, it keeps everyone informed of progress and in the long run should save time wasted repeating questions that already have answers. However, we have all worked in companies where typical responses are instead "just send me an email," "Oh, I never use tool X," "I couldn't find an answer to X," "I didn't put it in the calendar" etc. In my opinion, getting people to use tooling is a paired 'carrot' and 'stick' approach.

The carrot - make them usable and relevant

It may sound obvious, but in so many cases people don't use a tool because they haven't received any training in using it, it's not set up to suit their workflow or the barrier to using it is too high. I remember working at an organization that paid thousands each month for a SharePoint (document collaboration) installation, but everyone used Google Docs because they found it easier to use.

[caption id="attachment_5974" align="aligncenter" width="960"]

Encourage people to communicate better.[/caption]

If you are working for an older company with established work practices, run a research survey to assess what people are using for their work, and where their pain-points are. If you don't address these pain-points (or worse, create a new process that is harder), then there's a high likelihood that your tool roll-out will fail.

The stick - there is no choice

While what I posted above is an ideal, I'm sure anyone who has had any involvement with creating an application designed for multiple use cases knows that balancing the workflows and needs of everyone is impossible, so there also needs to be an element of 'gentle encouragement.' Often inter-person and inter-team collaboration need you to define some standards and commonality; if everyone can work the way they want, it results in chaos. You may need to define expectations and force usage of particular tools for particular work, i.e., "We only handle issues that are logged in Jira." You may need to take these guidelines further by also defining communication guidelines around style, clarity, language and response times. After all, a team logging information that no-one pays any attention to is still wasting its time.

[caption id="attachment_5975" align="aligncenter" width="960"]

Force people to communicate.[/caption]

There's a fine line to tread between lack of and too much communication. Finding that signal-to-noise ratio that suits your company or team culture will take time and also vary from country to country and person to person. I would say start with communicating too much and filter out what you realize isn't needed. Starting the other way around could result in "not knowing what you don't know."

Talk to the face

In all this discussion of tooling, and especially in how it can help distributed teams operate, it's easy to forget the lasting importance of face-to-face contact. While in some organizations and people, the quantity of meetings you have has almost become a badge of honor, the occasional meeting (in person or via VoIP) can be essential for clarifying assumptions, dedicating time to resolving specific issues, and building team morale. For example, a common trend in modern businesses is to have a daily standup, a short meeting where the whole team discusses what they have been working on, what they will work on, and any blocks they have to accomplish this. With teams spread around time zones this meeting might need to be asynchronous, or at different times to allow for a fair spread of times for the whole team.

As engineers, or working for engineering-focused companies, we have the tendency to get distracted by tooling and the latest shiny gadget or application that will solve all our problems. Whatever tool you use for communication or collaboration is enhancing a human practice, and any processes improvement project that ignores this is doomed to fail. Ignore the person at your peril.

Stay up to date

We'll never share your email address and you can opt out at any time, we promise.