Making Work Visible - Avoid DMs
We create more value by having conversations in public instead of behind closed doors.
This is a blurb I add to the teams wiki page.
Avoid sending DMs/PMs for support and technical questions
We value making work visible
Part of this is achieved by us making an effort to ensure we’re asking for support and technical questions by starting a thread in our squads (or the relevant) room - instead of via of direct messaging (or calling) an individual.
This helps with:
- Sharing knowledge amongst the team.
- Identifying common problems that others might be having or aware of.
- Balances support to prevent any individual getting overloaded.
- Helps ensure a timely response.
- Allowing others to keep up to date with ongoing issues.
- Eases cognitive load by:
- Reducing the number of notifications people receive
- Reducing context switching.
- Allows people to search for previously occurring questions and answers.
- Highlighting documentation gaps.
- Making work visible.
For more information see:
Thank you, 😊
Just like with software development, conversations benefit from being open
The majority of our work conversations should be open and benefit from the feedback and different perspectives of others.
Open communication helps to foster a blameless culture, where people are encouraged to share their ideas, ask questions and embrace the idea of “I don’t know”.
Learning, sharing and understanding within a silo is often a waste of time and effort. We can create more value by having conversations in ‘public’ instead of behind closed doors.
Changing peoples habits from having private, 1 on 1 conversations to having public, open conversations often requires people to be reminded of the benefits.
For some it is a change in behaviour, for others it is a change in mindset.
Many people often default 1 on 1 private conversations based on common false assumptions.
“I don’t want to share my ideas with the team until they’re fully formed”
By sharing your ideas as they are forming you benefit from the feedback and different perspectives of others.
This isn’t just important for the problem you’re trying to solve - it is also large part of how we learn and improve in the long term.
“The others are busy with their own work, I don’t want to bother them with something they don’t care about”
As a sender of information, who are you to decide what others are interested in?
Shouldn’t it be the listener’s right to decide if they can add value to a conversation?
Even if you don’t have anything to contribute, you can still learn from listening to a conversation.
Getting an answer or piece of insight from someone you didn’t expect is common when you start moving your discussions out into the open1.
“I don’t want to interrupt others with my questions”
Communicating openly does not mean yelling your ideas over the top of everyone, it doesn’t even mean they have to be notified of your conversation let alone requested to participate in it.
Embracing and opt-in communication style, people have the option to choose to ignore the discussion if it doesn’t interest them, or even to prioritise it and perhaps read through it later at their convenience.
Communicating effectively means using the tools properly to minimise noise and the cognitive load of others.
🧵 Using threads to promote open team communication
Many of the tools we use for communication are designed to be open and transparent - but it’s up to us to use them properly.
Using threads can significantly reduce context switching, cognitive load and promotes more engaging communication.
Without threads - you’re constantly notifying everyone in the room of your train of thought - this might seem good for you, but it’s not for everyone else. Even if people have notifications turned off they will desensitise to discussions and will miss important information.
1. Conversations are grouped by context
Knowing the context (topic, problem, idea, etc) of a conversation is important for understanding the conversation while reducing context switching.
You can have multiple simultaneous, asynchronous conversations without worrying about tripping over over each other or the need to create a new channel.
2. Reading a stream of conversation is easy
Without threaded conversations the signal to noise ration is low, you often have to skip over unrelated messages to follow and make sense of the conversation.
3. Threaded discussions reduce the number of notifications people receive
There is nothing worse than opening a messaging app and seeing an indicator of a large number of unread messages.
If you’re not interested in a conversation you can choose to ignore all of it by not joining the thread.
If you’ve joined the thread you can choose to mute it if its no longer relevant to you.
4. Makes it easier search for and retain knowledge
One risk with frequent conversations is that previously occurring questions or decisions can become hard to find.
By using threads you not only can you search for the context/topic/starting message of a thread - you can also link to it - sharing knowledge of the discussion and not just a single persons message.
The ability for new starters, people you assume aren’t interested - or even outsiders to have access to the teams discussions and historical knowledge can help to reduce the need for synchronous communication events such as large meetings, the constant re-sharing of information and occurrences of invented here syndrome.
5. It allows people to prioritise their engagement
People can read through the a discussion at their convenience - or not at all if it doesn’t interest them.
Open discussions avoidance is (in part) a learned habit
From email where “best practices” include having as few people as possible, from managers booking meeting rooms with a select group of people and from the fear of being perceived as asking too many questions when we’re new to a team.
Remember: We create more value by having conversations in public instead of behind closed doors.
References / Links
- Slack collaboration etiquette tips
- GitLab’s Communication Handbook - Don’t Send Direct Messages
Thanks to Ville Saarinen from FlowDock’s (now defunct) blog for the inspiration and some of the content for this post. ↩︎