A guide on how to be dignified, elegant, and gracious in our social interactions through the internet at Tesselo.

✅ Agreed on by the Tech Team on Feb 25, 2022 🖊

Slack

Channel availability

All channels should be public unless strictly necessary. Private channels do not appear in search results until the person searching is invited to the channel. One common reason to create private channels is not to overload our colleagues with more notifications, but in this case the solution is to enable them to either join or disable the notifications for the channel instead of hiding the information behind a wall.

On later stages, having public channels helps with the on-boarding, as we only need to place the list of channels and their purpose in the welcome document.

Guests

We can invite people from another slacks or from outside and restrict their access to a single or several channels. This is convenient when we have a long term partnership and a channel shared in both slack to cooperate or when we have a short term person to aid with a specific task. This way the guests will not see all the channels and the N.D.A. they should sign gets narrowed in scope.

Channel naming

Identifying the purpose and scope of the channels by their name is useful when we are browsing the full list, in order to keep an ordered list and also to identify the information we can expect when we receive a notification.

Agreeing if we will use underscores or slashes to separate different words also gives a piece of mind to punctilious individuals.

A proposal could be:

sales-NAME For a particular prospect. If we sign contract it will be upgraded to customer, otherwise it will be archived. No need to create a new slack channel for all prospects, only if it is necessary.

client-NAME For discussing a customer

prj-NAME For a particular project

fun-NAME for fun matters

team-NAME for each team channel

serv-NAME to discuss about an internal service

alert-NAME for automated errors and alerts

monit-NAME for automated monitoring information

ind-NAME for discussing how to interact with a certain industry

dev-null the channel that only robots should read

We should avoid adding words with none or little information into the channel names.

Channel policies

We differentiate the level of importance that they have for each team or person on their daily work.

The following policies apply

• fun- channels can be muted at your discretion
• prj- channels can be muted by Tesseras that don't work on the project
• alert- and monit- can be muted by anyone not called Daniel
• dev-null should be muted by everyone that is not a robot
• team- requests that address the @channel need to be should be answered within 2 hours during working hours (see below)
• *- if there is a contribution is off-topic or not in a thread when it should be, the post should be redirected to the relevant channel or thread

We are generally used to be flooded by notifications. All pieces of software and services are fighting hard to get the maximum share of our attention and we end up turning a blind eye to the meaning of those notifications.

Being able to determine right away if a notification requires our attention, the level of importance that it has and if there is an action required from has one architectural part and a also a daily attitude.

Thread usage

Threads represent a conversation, while a channel represents a topic. Threads should be used to reply to requests and other topic opening posts, as a way to focus the conversation around the initial contribution.

There is a huge advantage of using threads: only the people tagged or writing on it will get the second and later notifications of new messages.

Another important difference of using threads is the aid they give when it comes to scan one or multiple channels in order to get a grasp of the different topics discussed. Specially important when we are back from holidays and everything seems too much.

Away status

It is helpful to have a rough idea if you will get an answer from a colleague when you are working. Using the away status is a tool that help us achieve this goal. If we are focusing or not in front of the keyboard, we should have an away status so other colleagues will not be blocked waiting for our answer.

Asking for help

Whenever we have a question or a problem to solve, we should direct our message to the most specific channel available for it. For example, if we are in doubt about some project delivery, and we have a channel for the customer and another one for the project, we should ask in the later one.

If we guess that a person might have the answer, we do write the question in the channel, and we tag that person, instead of writing a private message. This will get answers faster if that person is busy and someone else has an answer too.

If there is an on-going conversation in a topic specific channel, and we want to request the attention of a team, we can do it by starting to write @ and searching for the team. That will notify everyone in that team.

If a voice conversation is held about it, sharing the meeting link can be an invitation for others to join the discussion.

Direct Messages

Every time we write a direct message we should ask to ourselves: is this information really private?

Discussing work topics in private messages is a bad idea for several reasons, the main two being:

n-plication of information and time: if a single person has the answer and others ask in private, that person will need to spend the time to answer to the other n. Not only that, if a new person comes to the company, it is most probable that this question will be made once more.

availability of information: what we ask in a direct message the information will be only available to the two people in that conversation. It will not appear in searches by another people, and if someone else needs to be included in the conversation they are lacking the context.

It takes some inner gym to get there, but it is a good habit to redirect to a channel a question if we are asked in a private message. It is kind gesture for the whole team.

Channel life cycles

Following the conventions within these agreements, channels can be created and archived at discretion. Timely gardening of the channels will be required.

Meetings

Attention focus

Meetings are moments of collaboration, where everyone's attention should be fully dedicated to the meeting as long as it lasts. This means that as much as possible, disable slack notifications while you are in a meeting, and update your slack status communicating to the team that you are busy in a meeting.

If a person can foresee that will not be able to pay full attention to the meeting, it is preferable to skip or postpone the meeting instead of not being present.

Scheduling

Meetings should be scheduled in advance and agreed by all the assistants, specially if it is a one-on-one meeting.

For ad-hoc meeting requests, the same rule apply by asking about availability over slack. If a person is dedicating their full attention to another task, creating a zoom call before agreeing on starting the meeting creates a tension and a distraction and it must be avoided.

The topic of the meeting should also be clarified in advance, and ideally also the agenda and desired outcomes.

As a principle, we should avoid meetings where people disconnect because they are not involved. So if people feel disconnected or bored in a meeting, something about the scheduling went wrong.

Meetings should be kept under 45 minutes to make it possible for people to stay focused. Scheduling meetings on Thursdays is discouraged because of Focus Thursdays.

Collaboration on documents

When collaborating on documents (such as code or Bahamut posts), screen sharing should be avoided as much as possible.

It is encouraged to use tools that allow everyone to directly edit the document at hand, and the meeting is for audio and video sharing only. This increases the productivity a lot and makes everyone more involved. And it is way more fun! 🎓

For some more guided collaboration meetings, a scribus will be identified that leads the document editing and whipping of the participants.

Off work time

We value our time off work and respect everyone's personal space.

Contacting Tesseras with work related issues outside of work hours is not allowed.

This applies to all communication channels, including but not limited to WhatsApp, Signal, Slack, and E-mail.

Whenever possible, try to send communications only during work hours. So if you work late, here are examples for avoiding messaging off business hours.

• Holding emails as drafts until the next morning.
• Using message scheduling in slack to send messages only the next day during work hours.
• Push your code to GitHub but only create the pull request the next morning.