Vizzuality playbook in progress
This project is maintained by Vizzuality
The aim of the slack guidelines is to: (1) help on transparency, organisation of information, (2) reduce noise and lack of focus, which lead to more efficiency and better well being.
Slack is expected to be an asynchronous form of communication. It is not aimed at documenting decisions and storing important documents.
Synchronous communication: communication that happens in real-time, with instant reads and responses.
Asynchronous communication: communication that does not happen in real-time, where responses are intermittent and delayed.
Get familiar with the Slack preferences and options to customise notifications and the view, this can be helpful to reduce the noise and increase the focus.
Below are helpful links to best practices and tips on managing your notifications and reducing noise in Slack.
Consider using Slack’s Sections to categorise channels and set up their visibility on the side bar.
Look & Feel: As you explore the preferences of Slack, you might want to change the theme to use the Vizzuality colours for the sidebar. #000000,#222222,#000000,#FFE229,#222222,#FFFFFF,#2BA4A0,#2BA4A0,#222222,#FFFFFF
Sections: You can organise your channels in Slack using sections.
This is very personal and depending on how you want to organise your slack you choose how categorise the channels. Some ways are categorising by project, functional area, topic, or how frequently you have to check them…
Channel presence: Make sure you regularly do a channel purge. Remember, leaving a channel is not a problem, come and go as you like.
The status and availability in Slack can help inform everyone on how quickly you might be able to respond. You can use a custom status and duration, but we have some predefined ones in our workspace:
In a meeting: (lasts an hour) It synchronises with your Google Calendar, or you can put it manually.Nom nom nom break: (lasts an hour) break time for lunch.BRB!: (permanent) to notify when you are away from the computer or busy.Vacationing: Use this status to notify of your absence because of vacations.Working remotely: To notify you are working from a remote location.While the customisation of slack is a personal choice, the usage guidelines explain what is expected from each individual when creating channels and sending messages.
Slack is a place to discuss topics, and in Vizzuality we embrace conflict in a positive way. In Slack we follow the same rules of communication we follow on the rest of channels in Vizzuality, you a have a couple of link to know more about this:
Blogin Post about SMO: Embracing conflicts.
Using non-violent communication.
Anyone can create a channel. There is a list of current channels in this doc, it is updated monthly with a manual trigger.
Use the search bar in slack to see if there is a channel with the topic of interest, you can also check the channel list to see if there is already a channel for your purpose.
Set a channel name that states the purpose of the channel, use the naming nomenclature. Be highly descriptive in the name. Where appropriate use the full project or Functional Area names especially where acronyms are not well known (e.g. #half-earth-whatever, not #he-whatever).
use hyphen/dash separators
Name should include one or several of the following:
<project name> and/or
<functional area>
<theme> e.g. quality, SMO, comms, etc
<task> e.g. retro, workshop, proposal, QA/QC etc
<time> e.g. year and/or quarter
<shared status> i.e. include ‘shared’ if shared with another org
legal-<people-affected>-<theme> (more information below)
Add a description to the channel:
Purpose: why this channel exist and who is expected to be in the channel
Related channels
Channel handle (optional, see more about channel handles below)
Invite all relevant parties
Monitor the usage of the channel. When you create a channel you are responsible for achieving it when its use is no longer necessary.
Inform the channel of the planned closure
Channel must be archived after used
Public Slack channels are used for digital communication. This saves time in filling others in on statuses of projects and helps collaboration. People on a channel are interested in the discussion of a topic right now. When decision-making is needed, a clear timeline should be stated and the affected parties directly informed (tagging individuals or user groups) to ensure asynchronous reviewing. This ensures that people can be present, leave and rejoin channels as they please, remember, the affected parties are tagged when necessary.
@channel or @here should be avoided unless really necessary - meaning everyone in that channel should be immediately aware of something. Find out more about these handles in the slack documentation
Find out if the channel uses a group handle (this information should be in the description of the channel).
Discussions should be kept within threads and the outcome of the conversation shared as well in the channel. The :thread: emoji is used to remind of this guideline. Discussion threads make the page history easily navigable and reduces the noise in any given channel down to a simple index of topics. Remember that slack is not aimed at documenting dicisions, make sure the outcome is properly documented outside of Slack (e.g. project folder, wiki…)
Acknowledge reading messages with an emoji. Unlikely threads, reacting with an emoji does not automatically start to follow a thread and reduces the number of notifications.
When using direct messages be aware that direct messages discourage collaboration. You might actually be contacting the wrong person, and they cannot easily redirect you to the right person. If the person is unavailable at the moment, it is less efficient because other people cannot jump in and help. You might rather use a public channel and mention the person or group you want to reach. In that way it is easier for other people to chime in, involve other people if needed, and learn from whatever is discussed.
When using group direct messages keep in mind that they are very hard to maintain, track and respond to. You might want to consider whether the conversation can take place in a public channel.
From the side bar you can see which user groups already exist (People and user groups - this may be hidden inside the More... tab). Some channels have specified user groups (check the description of the channel). Also user group handles allow to reduce the noise of using @channel and @here. Each individual can choose to be in a user group. So far there are two useful types of handles:
User groups of a functional area: @backend, @bd, @designers, @resigners, @fronterizos, @pms, @researchers, @science. These handles are useful to notify people from a Functional area in a channel where they are not expected to be or there is not knows representative. The :at: emoji is used to remind of this guideline and you can use a thread to mention the user group.
User groups of a project: These are useful handles for daily stand ups or important project notifications. Depending on the development status of the project different people will be part of the handle. It is the responsibility of each individual to be inside the handle.
These are channels with general topics:
#announcements: where all company announcements are shared, the message should be succinct and inform on any deadline and place for further discussion (slack channel or Blogin or google doc). @channel and @here shouldn’t be used unless urgent response is required by everybody;
#general: Where we have work related company-wide discussions, say good morning and celebrate team achievements, welcome new staff, birthdays, vizzdays and births;
#random: For random non-work related topics;
#recognition: To give praise to our teammates.
These channels do not have constant activity but they are operational and concentrate conversations related to the internal functioning of Vizzuality. These channels often affect everyone in the company or a big portion, make sure the creation of this channel is broadly announced.
#all-hands: where we work on our playbook and the all hands call agenda is shared.vizz-tracker: where issues and questions about VizzTracker are shared.
#one-team: where we organise discussions on internal functioning.
#blogin-taxonomy: where we iterate on the taxonomy of Blogin categories.
#capacity-planning: where capacity for new and ongoing projects is organised. Use the request a team for new project workflow to reach the functional area representatives.
#remote-experience: to discuss material and practices that should improve remote interactions.
#madrid-office-bookings: to coordinate the use of the Madrid office.#legal-<people-affected>-<theme> (e.g. #legal-madrid-risk-assessment, #legal-remote-spain-law).The initiatives that have a channel are listed in a live document.
Join functional areas channels if you are interested in keeping up with updates from those areas. Remember the user group handles to ping them in channels that are not these ones. The expected people in these channels are those that belong to the FA.
#backend-devs
#communications-team
#frontismos
#pms-united
#real-design-room
#scienceteam
#business-dev: Discussion and writing proposals for new work. Information on the development status of proposals is found here. From this channel teams are created to write new proposals. It is the responsibility of each FA to state how the information should flow from this channel to the rest of the members of the FA.
#bd-<project-name>-proposal type of channels are used to coordinate the writing of proposals. If the proposal is accepted, the channel is renamed to become an ongoing project. If the proposal is not successful the channel is archived. All the important documentation should be in the Proposal Folder.
Join project related channels if you are interested in keeping up with updates from those teams. Depending on the project or the cycle moment of the project other project related channels might be created and any decision carried out inside reported back to the main project channel.
#<Project name>-channel: Debriefing from client meetings, broadcasting outcomes from meetings, discussions on the wide scope of the project live here.
#<Project name>-dev: The different team members should ask for information to other members in this channel during the development of the channel.
#<Project name>-<fa>: Large projects with several people from the same functional area might have a subchannel to carry out discussions. The #project-name-channel must be updated with updates and decisions.
Thematic: #books, #gamez, #music, #pets, #run
Geographic: #madrizz, #uk-crew, #portugal