Etiquette for Tech Teams

For a Happy Workplace

This article attempts to offer some of the rules for a productive, cohesive and enjoyable working environment for tech teams. It is a semi-working article that I will add to over time.

Meetings

• Always include an Agenda and Objective to meeting invites. It helps invitees decide whether the meeting is relevant to them.
• Long blocks of uninterrupted time is when the magic happens, for most engineers. Be mindful of this when scheduling meetings. The “best” time will differ depending on who you are inviting to the meeting.
• Default meeting duration is 30 minutes. Meetings longer than 1 hour tend to become unproductive: avoid them.
• Keep in mind everyone in the meeting, avoid tangents that are not applicable to the majority of the room. Stick to the agenda! Some conversations should just go into a ticket or google doc.
• At any point, excuse yourself from a meeting if it is not relevant to you.
• Announcing the meeting in #meetings slack channel. Don’t invite the whole company to every meeting, but allow people to invite themselves to things that are of interest to them.
• If you need a room make sure you book a room, so you’re not taking it from anybody else.
• Feel free to use your laptops in meetings unless the host specifically states otherwise.

Headphones

If someone has headphones on, DO NOT GO TO THEIR DESK AND INTERRUPT THEM, stay calm, do not make eye contact, stay as small as possible, keep quiet, back away slowly and slack them instead.

Slack

Slack is asynchronous communication, it’s like email — don’t expect a reply within seconds.

Avoid using @here in #general, unless it is urgent and applicable to the WHOLE company. Examples of what is acceptable:

• There is a fire in the office,
• The All-Hands are about to start.

Unacceptable:

• There is food in the kitchen (there is always food in the kitchen and we have #foodanddrink),
• You want to tell everyone about a great show you went to see,
• There newest cryptocurrency is ICOing and everyone should buy it.

When initiating conversation with a tech team member increase message density by using full sentences when opening a new message to someone. Lots of short messages are distracting. Keep your initial greeting and question on one line. E.g. “Hello! Is Jono away today?”.

Example of Hoff-ing

No hoff-ing (and such like) in #general. Keep it in #random and remember excess hoff-ing is not funny!

Try and use of the “start a thread” button to reply to any opening post and to hold conversations together, this can keep things tidy.

The larger the channel, the less it should be used for any kind of decision. Big rooms are only for notifications. For technical decisions see: Technical Design Doc Section (below).

There is also a social aspect to slack, and it can become a bit like a company reddit. Create channels for each interest, for example we have channels for movies, yoga, music, podcasts, etc.

Politics should only be discussed in #politics. No-one is obliged to subscribe to this channel.

Feedback

Feedback is one of the most important contribution you can give to your peers. Find the time.

Use anonymous and onymous feedback forms. If you are really short on time and know it will get sugar coated, submit blunter feedback.

Meaningful feedback takes practice. It’s important to remember that feedback isn’t anybody being angry at you. It’s an indicator of the image you project. It’s not a criticism.

Making sure your feedback is balanced and considered. Do not give feedback immediately after feeling that someone has wronged you. Sleep on it, leave the feedback the following day.

Pull Requests (PR)

Use labels to help communicate the state (reviewable/deployable) of a PR.

Add meaningful titles and descriptions to the PR, add the JIRA ticket (if applicable). Describe why the PR is open — what problem are you solving?

Sometimes updating the README is better than a good PR description!

Squash on merge, this keeps the commits tidy and give more context to meaningless commit messages. Delete your branch after a merge!

If you want, announce your PR in the #tech.

Review everyone’s/anyone’s PR, even if you think you might not be a lot of help.

Always leave a comment, even if you have nothing to say, so that the PR owner knows someone has seen it.

Technical Design Doc

Where technical decisions are discussed and made.

There are a number of advantages to using design docs for each major technical decision over meetings:

• An audit log.
• Developers can take their time to think about the problem; rather than, in meetings, coming up with solutions on the spot.
• Everyone in the tech team can have a say, you don’t have to find a time where everyone is free.
• Junior engineers can read and learn, without feeling they are taking up room/time in meetings where they have little to contribute.
• If possible, save technical design docs into the /Tech Gsuite folder.

If it’s related to anther department, ensure to include it in their systems. E.g. if customer-related, add it to the CRM (Customer Relationship Management) system.

Define the business problem as well as the technical problem. List the potential solutions, along with pros and cons.

Sometimes whiteboards are absolutely necessary to a discussion, in which case, hold a meeting, snap a photo of the whiteboard and put it into the design doc.

Same rule as PRs. Comment, even if you have nothing to say. “LGTM” comment on the title, if you’re happy.

Share a link to the doc in #tech slack channel.

Deploying

Deploy small amounts of code, often!

• Only builds from the master branch should be deployed to live. Exceptions to this rule are possible (e.g. hot-fixes, experimental branches, a/b testing services etc), but please announce in the #tech slack channel and get buy-in from a(nother) senior engineer.
• We have a warning if attempting to deploy after 4:30 pm or at weekends; try not to deploy close to these times (e.g. Fridays or at 4:50 pm). Make sure you are around on slack for at least 20 minutes after a deployment; don’t deploy then immediately leave the office for lunch. If you have to think whether it’s a good time to deploy, it’s not.
• After deploying, check logs, metrics, integration tests and anything else relevant to the particular deploy, to ensure you haven’t broken anything.
• Same rules apply for data replay or ML model deployments.
• Take ownership of your Pull-Requests (PRs). Address comments when someone has reviewed your PR and feel free to chase them up after you have made changes. Finally, you are charged with merging your own PRs.

Stand Up

List your stand-up in #tech slack channel before standup.

Take discussions offline (out of standup). If you think a discussion is happening and it’s wasting your time, call the person out.

Stand-ups away from others’ desks.

Keep it relevant to the group. No need to repeat everything that’s happened the last few days. Pick your content, feel free to add a longer list of things to the slack #tech stand-up.