Skip to main content

Communication

Team communication is the corner stone in the success of any project, it should be smooth, continuous and efficient to guarantee a cohesive and warm environment necessary for developers to be fulfilled and committed toward the common objective of delivering quality on time.

Obytes, as a modern IT company, uses many communications channels since most team(s) are working remotely and this adds extra challenges that this section is trying to address.

Channels (what/why/when?)#

Email#

What? Email remains the indispensable tool, it has the advantage of being formal and universal, any professional contact should be joinable via email.

Why? A well-established and unanimous technology.

When? Email can be theoretically used anytime except when you want a Informal and immediate exchange, it's the least noisy channel but in case of emergencies you would need to use Slack. Generally it's most effective when:

  • Formal (or even legal binding) matters.
  • To get notifications about other exchanges (especially when missed): Agenda's alerts, Github pull requests, missed DMs (direct messages) in slack...
  • To get reported bugs (through Sentry or other) very quickly when they occur.
  • One of the last resorts if someone is not answering on Slack or is not joinable otherwise.
  • ...

You should always keep an eye on your emails, at least few times daily (enabling alerts on your phone and/or a browser are highly recommended though since it will allow you to be very re/pro-active).

Slack#

With the limitations Email has, teams need an instant messaging tool, at the beginning we used Skype, the features, growth and popularity explain why we have switched to Slack very early.

What?

Slack is a workplace communication tool

key features:

  • Direct messages (DM).
  • Public/Private channels.
  • inter-workspace communication: organization can have a shared channel to collaborate.
  • ...

When?

  • By convention, each project has its own set of channels:
Squad Communication:
... by leveraging Slack. When the project founders decided to use OBytes slack to host discussions about the project, all channels relating to the project should be created as private channels. A group of channels is recommended to have discussions spread based on area of expertise. 
#exampleA general discussion channel, for announcements and must include all squad, project founders, external project members, etc. 
#example-devA channel for discussing development in general, technical members should all be part of channel and project founders as well. 
#example-standupsA channel dedicated to stand up announcements and scrum planning.
#example-designA channel dedicated to discuss design requirements and need if applicable, the design channel should have the concerned member from the design team join. That will help designers to receive feedback from founders and members, stay in sync with priorities and implementation team.
...
* Daily stand-ups:Ideally, a daily stand-up is held in the morning, as it helps set the context for the coming day's work. These scrum meetings are strictly time-boxed to 15 minutes. This keeps the discussion brisk but relevant. The scope the daily stand-up should focus on,- What did you do yesterday?- What will you do today?- Are there any impediments in your way
The daily stand-ups are as well-meant to address and conclude the following objectives:  - If I have a problem, make it everyone’s problem  - Get clarity and context  - Where we are today in our milestones...(Company Handbook)
  • DMs , @hare and @channel generate alerts: so use with moderation and only when needed
  • Threads are great to have clean easily readable discussions but can get too sometimes long: so use according to how long you expect the discussion

Meetings#

...* Squad Meetings:Meetings are essential in order to maintain a unified version toward the common objective of our delivery, meetings help resolve conflicts faster and get to bottom of problems with little friction. As a standard, we recommend that squad setup and plan their calendar with following ...Weekly Sprint Planning:Weekly sprints are to plan and prioritize the scrum board cards, it is essential that project founders are engaged in the planning and overseeing of priorities. 
 - Meeting Agenda:    - Retrospect - 5 mints - by coordinator    - Blockers     - Week objective - 5 mints     - Planning - 30 mints...(Company Handbook)

These meeting are scheduled using Calendar, Zoom or Google meet, so make sure to to check/set alerts on your phone/browser for meeting you are organizing/invited to.

Challenges#

Multi-cultural, spread across different timezones and countries teams like ours bring some communication challenges:

  • Different timezones varying from GMT-6 to GMT+3: meeting and work hours' availability should be planned carefully and flexibly.
  • SLack alerts should be used effectively with timezone difference in mind, but don't hesitate to ping (the right) people in case of emergencies whatever time is.
  • English accent may vary depending on countries of partners and collaborators.
  • Information can be easily lost in DMs or in the middle of a lot of noise: always privilege written and public traces in order for the important information to be visible, accessible and reusable.

Common scenarios/DOs and DONTs#

Etiquette tips in Slack#

https://slack.com/intl/en-ma/blog/collaboration/etiquette-tips-in-slack

Always privilege written and public traces#

Slack public channels, Wikis (Slab), emails are preferred over bilateral chats/meeting when the information is expected to be shared with (some of) the team, this way there's no need to re-discuss the same matter twice and everyone (even any potential newcomers) is on the same page.

getting help to resolve issues (junior interns)#

As a beginner we have all faced the hardness of getting to know new people, new work environment and even new tools and technologies one is expected to learn quickly which doesn't come without having a lot of issues and mistake you are excepted to overcome. The point is that even if the team is always available to help, one should develop its own critical thinking, problem resolving and self-reliance abilities, so if you face a technical problem you should make sure to take enough time to try to resolve and learn yourself while still being able to rely on elders to help in case of blockers and all withing the time allocated in the planning for the task. Here is a suggestion on how to proceed:

  • Make sure you understand tasks you are assigned.
  • Make sure to always refer to official/reference documentations of tools and technologies you need to accomplish your task.
  • In case you don't have any, immediately ask manager/elders advice on documents and resources you need to read to accomplish the task/resolve issue.
  • if you face an error/issue make sure to read thoroughly the log/description, focus and try to fix by your own means first.
  • In case no log available try to add more logging statement to code (metrics using Datadog or other).
  • Check the internal documentation: Wikis, channels, the issue might have been documented somewhere (or resolved by someone).
  • When not able to resolve you can always try to quickly search (as it can be something obvious you missed, and you don't need to take from teams time for that) on the internet (Stackoverflow...) if someone has faced a similar issue (which is very likely to happen), but don't copy/paste or share any sensitive code or confidential data.
  • Describe the problem you are facing in the #dev-channel of your project, make sure to provide a comprehensive description. (avoid DMs as it generates alerts + not visible to others)
  • Make sure to ask all questions you have and try to not leave some of them suspended.
  • Don't be ashamed of asking in meetings or in channels, Obytes team has been always friendly, understanding and helping (as this culture/ethics has been established by top management since the foundation), please just make sure to respect the above because everyone is busy (as any good developer should be) to avoid any misunderstanding.
  • Feel free to add your flavor and ideas to suggestions you receive and to criticise them and find better alternatives.
  • If still blocked, make it clear to team during daily standup and weekly meeting, meanwhile feel free to ask in forums like Stackoverflow... (just make sure to not share any sensitive information).
  • In your turn, feel free to help and provide suggestions for issues others post when you can.
Last updated on by Moussa IDARDAR