A well-run organization will have a pretty solid internal Slack communication structure.
Inevitably, the organization or the teams within it will need to collaborate with external partners. This is especially true for agencies, consultancy firms, dev shops, digital product studios, and other business innovation partners like Revelry: constant interaction with partners and ventures is a given.
It can be tempting to be flexible and adapt to whichever communication style works for the partner, but at Revelry we believe in our process, and we’re building companies and solutions that align with it.
“Clients are paying just as much for our process as they are for the code,” we sometimes say. So we invite clients and innovation partners into our communication flow.
Why do we intentionally invite clients to get all up in our business?
Because they have asked us to get all up in theirs!
Many of our innovation partners get as excited about the process of working with us as they do about the results.
Here’s how that works:
We Bring Partners Into Our Slack Communication
Slack provides a single, centralized place where all collaboration and project status flows. And, it’s a great place to get to know each other. Recently, Slack introduced Shared Channels in order to facilitate a connection between existing chat teams.
That’s pretty cool, and it will solve problems for a lot of folks. But that’s not how we do it.
Invite External Partners to Slack
We utilize the Multi-Channel and Single Channel Guests function within Slack to invite collaboration partners to a specific channel. These guests do not have access to all of our internal conversations; only the single appropriate channel for their project. We prefer this method over Shared Channels because it ensures that we will always retain control over the conversations and product decisions contained in the channel. This is what helps us learn from each project and solidify our processes.
Customize the Slack Channel
We deploy the same process for each product we set out to build. The project gets its own Google Drive, GitHub repository (and corresponding Kanban board), and Slack channel. We invite the Revelers who will work on that project and the key stakeholders to the Drive, the repository, and the channel. As the Issue Board, Continuous Integration, and other appropriate tools are set up, we connect notification structures via Slack’s integration feature.
Create a Channel Topic
The channel topic is constantly visible at the top of the conversation pane, so this is where we place links to the most valuable project resources. Our project channels have the same format across the board. Here’s what everyone can see and have handy, via the Topic line, any time they are in the channel:
README: This is the backbone of the project. The README will include contact information, project brief, links to Google Drive and other resources, tech stack, and other crucial details.
KANBAN: A link to the project’s kanban board (this lists GitHub Issues in a helpful, visual layout.)
As project conversations progress, certain comments, links, or conversations always prove noteworthy. The InVision link to the wireframes, the link to the staging/demo site, and other handy channel comments help teammates quickly get to valuable documentation. Again, it’s still all available in the README, but hey – we’re living in an instant gratification sort of culture at this point, aren’t we?
We connect all of the software, bots, monitors, and databases that we use to launch and maintain software solutions to the Slack channel by integration. The integration bots automatically post to the channel when an action takes place in the build.
This helps us add as much transparency as we possibly can to the project. But, it can create a lot of notifications and “noise” in the channel. Even still, we believe in this as a useful tool in our product strategy. So, we remind each other and our innovation partners how to communicate amidst the noise.
Sometimes, we’re mid-conversation when the bots pop up. They’re automatically generated, so they can’t really be well-timed. If the conversation is happening synchronously, we trust that everyone will scan past the bots and review for the human responses. If the conversation is happening asynchronously, then we should use @mentions or threaded replies in order to make sure that comments aren’t lost in the noise.
But that doesn’t mean that all bot traffic is to be ignored. We link to it for a reason.
Making sense of bot updates
The creation of tickets in GitHub, and the comments providing status updates and questions in GitHub Issues, link to the project channel so that there is full transparency into what’s happening.
Each GitHub update includes a link to the ticket. If an answer is required, it’s important to follow the link to the ticket itself and leave a comment there. (Hint: if you’re doing all of this out of pocket, make sure your phone knows how to log in to GitHub or you’ll get thrown a 404.) Leaving a comment directly in Slack might be a good place to kick off a conversation, but any decisions that impact the project story should be re-captured directly on the GitHub ticket.
If an answer isn’t required, but you’re delighted by the work that’s being shown, you can always share a smile or other emoji right there in the channel. We do that a lot when our talented illustrator updates our content tickets with header images.
Yes, this means the partner has total access to the team.
“But, you let external contacts talk directly with your developers?” Yeah. We do. “But, how do you protect their time?” Well, at Revelry one of our Core Values is Earn and Dispense Trust. Trust is dispensed – and earned – in many ways.
One way is that we trust each teammate to block and protect their own time. When our teammates need a “heads-down” block of time, we trust that they’ll turn off notifications so that we can’t disturb them during work mode. And, we trust that they’ll provide an update and check for messages when that block of time reaches a stopping point.
Another way is that we trust our team to hold all conversations in the open and to report any inappropriate or ineffective conversations, should they occur.
Effective Slack communication
Even though Slack feels more “instant access” than email, it’s still accepted that asynchronous communication is the default expectation. We do not support unrealistic availability expectations. But, we’re pretty available.
Even still, utilizing channel notification protocol is a great way to cut through the noise and get a conversation started.
Use the @ symbol to tag a team member to direct your comment at someone.
@aline Did you get my feedback on the sprint report?
@josh Where do I find the latest copy updates?
Use @here if you’re not sure who to ask, but you’d love to alert someone.
@here I’ll be five minutes late to today’s sprint planning call.
Use the react tools to respond to a previous message, so it’s clear what you’re commenting on. Asynchronous Slack communication is great, until a random “Sounds good, thanks!” appears late in the afternoon with no apparent reason.
Hover over the message, and use the options that appear at the right of the screen.
Add an emoji just to say “thumbs up”
Click the conversation bubble to start a thread
Click the reply arrow to quote the message along with your new comment.
We do our best to discourage Direct Messages, both internally and externally. We find there is very rarely a reason to send a Direct Message. Design conversations, product direction, questions about timing – these are all extremely useful conversations for the entire team to use as a resource.
We find that Direct Messaging is only good for “Human Resources” type conversations that need to be private. Anytime we are about to send a DM we think, “95% of conversations do not belong in a DM… is this really that 5%?” and usually jump back into the project channel to post our question/comment there. And, we encourage our partners to do the same.
We bring partners into GitHub Issues, Kanban, Zoom, and Google Drive too.
It’s not just our Slack communication that our innovation partners join. Google Drive is a great place to store existing logo sets, PDFs, and business documentation that exist prior to the collaboration. And, new documents that help support implementation can find a common home here too. Watch for our next post where we’ll explain how to organize, update, and sync your Google Drive.
Bringing partners into GitHub and our kanban – even if it means having them create an account for the first time – is crucial to delivering successful one week sprints. And since we use Zoom for all of our internal meetings, we ask our partners to join us via video conferencing on Zoom as well. Via video is the really important part here. It’s handy that Zoom makes dial-in conferencing easy for those once-in-awhile I’m-on-the-go calls. But we find that the ability to screen share and see each other’s faces increases the value of teamwork, so we push for using the full features that Zoom offers as often as we can.