Slack

We recommend starting with a reduced access and only inviting to select channels as a multi-channel guest. Over time, and as trust is built up, you can revisit.

Suggested Slack Channels

We suggest the following channels. If they exist, use those channels for the described purpose, or create new ones.

• #dev-prs

  • This channel is where all of the engineers will place their PRs that are ready to be reviewed by their fellow engineers. The engineers that are reviewing their PRs can give comments on the posts that are in this channel to further expedite the reviewing process.

• #dev-projects

  • This channel is reserved specifically for project estimations. Project estimates should be done promptly once assigned, preferably within a one to two-day period and include the following:
    • the date that the feature will be deployed
    • the optimal date the feature will be deployed
    • total hours that it will take to complete
    • link to the feature's main ticket on
  • The total estimated hours and date given above are to be logged into a Google Sheet and will be used as a reference when reporting the KPIs of that project.

• weekly-check-in-{$devName}

  • This is a private channel where the engineer's weekly check-in will take place. All relevant managers should be added to this channel.

Communication

Since we work in an environment that produces primarily text communication, it is essential to understand how to properly utilize communication through text.

No Private Messages on Slack

When an engineer is nose down on a ticket, they can oftentimes neglect important things like answering a teammate's request for help. This results in engineers privately messaging each other to get the help they need. As this activity increases, the public conversations start to disappear.

The behavior of messaging each other privately is a symptom of a team that is not working together efficiently. Lack of teamwork affects the overall success of the team, therefore the practice of private messaging is forbidden. Since we do not have the ability to turn this feature off in Slack, we have to constantly remind the team of the effect that privately messaging each other has on the overall effectiveness of the team. Any mention of a private message needs to be reprimanded with a reminder as to why we do not appreciate private messages. When an engineer remarks about talking with a teammate, asking them where that conversation took place so that you can review it is another way to probe for this undesirable behavior.

The benefit of public conversation is that anyone can contribute to the conversation. If two engineers are discussing a topic and are unable to come to a solution, a public conversation allows them to quickly include someone else. That engineer can read the previous conversation and get up to speed quickly. Public conversations can also serve as documentation. Someone searching for a term related to that conversation may find that it helps them to understand the problem they are currently facing.

Failure to maintain this standard despite several warnings should result in termination of that engineer's contract. The inability to follow this simple rule is potentially a good indicator of other failings the engineer has.

Filler Communication

We are social creatures, so it makes sense that we want to make sure that there is someone to talk to before we send a post out into the oid of a channel.

ex. "Hey, has anyone encountered problem X?"

This may seem like a rather miscellaneous question, and you'd be right. What exactly is wrong with miscellaneous questions? Answer: They waste time and space.

With miscellaneous questions, you can expect the conversation to flow like this:

[12:01] Dev 1: "Hey, has anyone encountered problem X?"

[12:03] Dev 2: "Oh yeah, that's a doozy."

[12:03] Dev 1: "How did you figure it out?"

[12:06] Dev 2: "I did fix=XYZ."

[12:08] Dev 1: "I've already tried that, didn't work."

[12:12] Dev 2: "Link me your PR"

[12:17] Dev 1: "Done"

[12:24] Dev 2: "Oh wait, your PR is for repo ABC! That's why my solution didn't work. Try fix = ABC"

[12:30] Dev 1: "You're right! That did the trick, thanks!"

That's 9 posts in a channel if they don't use threads, and over 30 minutes to solve an issue that had a quick fix.

Let's see what the conversation might look like if we cut out miscellaneous questions and instead used concise, well-thought out communication:

[12:01] Dev 1: "Hey @dev2, @dev3: I'm working on LinkToPR in Repo ABC, I've tried fix=XYZ, FIX=X. Am I approaching this the wrong way?

[12:02] Dev 3: "Did that last night, use fix=ABC"

[12:03] Dev 2: "Agree with @Dev 3. Fix=ABC is the solution."

[12:05] Dev 1: "Fix=ABC worked! Thanks!"

That took up 4 lines of code and lasted 5 minutes. Effective communication builds the team and helps the engineer learn how to communicate better.