(also, since Revue doesn’t have a horizontal divider element, I’ll start doing this to split sections 👇)
<><><><><><><><><><><><><><><><><><><><><><>
#1: How to Scale Pull Communication?
This one is more straightforward to answer.
IF you want to scale pull communication THEN you need a Single-Source-of-Truth (SSoT).
As discussed in a previous issue, the SSoT ensures that information is accurate and up-to-date.
The emphasis of this concept is on the word single
If you have more than one instance of a documentation the following can happen:
Duplication: There will eventually be more than one version of the information (guidelines_1.docx // guidelines_1.1.docx // [MASTER]Guidelines_Company.docx)
Multiple “Truths”: Duplication leads to uncertainty. Which documentation is the correct one?
Waste and Errors: In a best-case scenario your team will waste time and effort. In a worst-case scenario your team will make errors based on incorrect information.
Therefore, it is important to pick one location for your information and use it consistently.
Here are a few implementation ideas:
-
Handbooks: Use a product like Github, GitLab, or GitBook to allow for the state-of-the-art change request process.
-
Wikis & Team Spaces: Use a product like Confluence, Notion, or Slab to manage a dedicated knowledge space. The only difference to the handbook examples from above is that you can’t really manage change requests (which might not be relevant for your organization at this stage).
In order for your SSoT to scale, it needs to check the following boxes:
-
🔑 Access: Team members need to be able to access information.
-
🔎 Search: Internal search becomes more important as the scope of the knowledge repository grows.
- 🔐 User Rights: You need a way to have editors and viewers. In the beginning, it would be sufficient to give editor rights to department heads who would own their own sections of the SSoT.
With these points in mind, you should be able to scale a v1.0 of your internal knowledge repository.
<><><><><><><><><><><><><><><><><><><><><><>
#2: How to Incentivize Your Team to Pull Information?
I have to drop my favorite quote again 👇
Culture eats strategy for breakfast.
Just because you want it to work for your team doesn’t mean that you will be able to change habits and ways of working.
Culture change requires [intentional effort * repetition * time]. It takes a while.
Here are a couple of ideas - ranging from soft to hard - that can steer your team to adhere to pull communication:
-
🧑🏫 Training: Be transparent about the change in SOPs (standard operating procedures), explain the reasoning and the benefits, and set clear expectations.
-
🖋 Executive Buy-In: All change has to start at the top. If employees see that execs/top management are not adhering to the set policies, then they won’t either. Lead by example.
- 🔗 Answering by Link: The main idea of the handbook first methodology is that you document first, and communicate second. If you get a question, don’t answer one-off, but document it and share the link to the documentation.
-
Chat Tools Strictly for Informal Communication: No more info requests via Slack. Slack is exclusively reserved for catch-up and personal communication. Everything else needs to be documented in your SSoT 📒
- 🗑 Expire Slack/Teams Messages After 90 Days: This here is a forcing function. It forces the team by design to document the most important aspects of work in the SSoT instead of communicating it via chat tools. That way the SSoT will hold the most accurate information over time and will incentivize people to pull information from there first.
<><><><><><><><><><><><><><><><><><><><><><>
Ginelle, I hope this answers your questions.
Tweet
Share