Consider holding daily standups on Slack
The daily standup meeting is the start of the day for many software development teams, and is a chance for everyone to explain in brief where they are with their projects. These meetings help team members and team leaders when it comes to being on top of their workflow, and they ensure everyone is, in basic terms, aligned on goals for the day. These meetings are held in different ways depending on a company's culture and methodologies.
With a remote engineering team, daily standup meetings could easily take place through text, on Slack. You could set up a specific chat for the daily standup, and then have each team member contribute a line or two about what they are working on. Not only does this ensure that information is not lost because of any potentially flagging attention spans (everything that is said is saved in the chat so it can be reviewed if need be), but it also ensures that your developers can be at their desk and focusing on their work right from the start of the day.
What you lose from this change of format is the immediacy of having your whole team talking to each other - but if you want that, why not use Zoom for the ten-minute standup if it is across more than one office (any longer and you risk losing momentum), and the link the call to the Slack chat? That way, everyone is ready at their workstations and the meeting is experienced the same by all team members, whatever location they are in.
Small-group developer discussions
In any case, an organization shouldn’t be using the daily standup as the only contact it has with its remote engineering. One-to-one meetings are the optimum for generating understanding with your team, but realistically there will be times when you’re all working so hard on specific tasks that this isn’t practical. For these times, Slack comes into its own.
Small-group developer discussions within Slack allow for asynchronous communication on specialized concerns, and keep up any required conversation between, for example, your DevOps people in the remote software development team, and management at head office.
Many developers dislike explaining complex matters to non-specialists, and keeping Slack chats, along with chats on other collaboration tools, restricted to those who need to be in them, excluding extraneous voices, can mean you get better answers on concerns and issues, and that you ensure the right people are answering the right questions.
Use polls instead of long threads
If you’ve got something to ask all of your organization, or all of your remote engineering team, there are more, and less, efficient ways of doing it. Sidetracking your software engineers with long threads, each message bringing a notification, when it’s not related directly to the task at hand, can take your people out of the rhythm they’ve established.
This is why the various poll plugins designed for Slack are excellent additions to any group chat. They allow for relatively minor matters like team evenings out, lunch orders, or the colour of the company hoodie - all of them, certainly, important questions to someone, but probably not paramount on the mind of your software engineers with deadlines raining down - to be voted-on and then moved-on from in one click, adding an efficiency saving to the working day.
Slack is great for maximizing focus on the matters which require them, if its teams and chats are customized to the benefit of those using them. If it is crucial for, to take one example, a member of the marketing team to have a direct line to a software engineer, set it up so that the engineer's line manager can monitor traffic, and can step in if their team is being unnecessarily distracted from key business. As we will discuss further, if the engineer wants to mute this chat for a length of time, flag it up with the others on the chat, and give them the chance to create the right kind of workflow.
Limit the noise
Everyone has a different way of working, but within your team there will be certain matters on which you can all reach consensus. For example, maybe some of your team like to express themselves through pictures and GIFs. This is absolutely fine - as long as all the team agrees to it. If it doesn’t disturb colleagues, or diminish the effectiveness of using Slack for collaboration in the first place, sending visuals might actually help team spirit and self-expression.
However, team members should be free to type “/collapse” in the text box and mute visual posts where it helps them to work better. They can always type “/expand” to get them back if they change their mind.
Do not disturb... at certain times
Additionally, as alluded-to above, if you set certain times in a working day when your team is not to be disturbed, then it adds a sense of common understanding. Arrange with your team, or with individual team members, when they want to snooze their notifications, and get them to stick to those times. Not only will it establish routine for the team, but it will also mean that anyone sending an ad-hoc request to a software engineer on your team knows the system, and respects it.
Share code snippets
Whether your engineers use Github or another code repository, they can use Slack to share parts of that code in code snippets. This allows engineers to see specific lines of code in Slack, without trawling through other code or logfiles to get to what they need.
Slack allows the sharing of code or logs in around 60 programming languages. This is a great productivity aid for busy members of a remote engineering team.
Issues / triage channel
An issues channel, or as it’s frequently known, a triage channel, can help team-wide focus by taking the need away from busy software engineers to respond to questions. It does this by assigning one person, on a rotating basis, to answer all bug-, feature-, or issue-related questions on behalf of other team members.
As this kind of channel is most useful when it is restricted to engineers, they are welcome to use specialist language in this chat, and also to develop a format for reporting and questioning that suits the majority of the team.
System for signaling
This is something they will have to come up with as a group, but it is possible to use Slack's own emojis, along with slackmojis (an independently developed range of emojis) to indicate how many people are affected by the issue. They could also use traffic-light symbols to show the urgency with which the question needs to be answered, or issue resolved.
One of the reasons Slack has been such a success since it first hit the market is its endless customizability, meaning it can be moulded to the needs of your teams and individuals. In order to make use of Slack in a way that enables remote software engineers to do great work, and helps keep the minds of a whole team on what is important, a conversation needs to be had on how that team likes to work, and how Slack can facilitate that.
Want to build your own team of remote software engineers? Talk to the experts at Base B!