‘No, no, no!’ the writing tutor admonished the class. ‘What is the ultimate point of communication?’
I was at the first day of a writing course and the class had written down what they thought was the purpose of communication.
As the tutor read the answers aloud, he was clearly disappointed.
And we were only 10 minutes into the class.
‘”To get along with the people around you” – no’ he said wryly.
‘”To get your point across” – not bad, but not good either.’
‘All of you missed the crucial point of communication – to get what you want!’ he continued, ‘Or at least try to.’
It sounded awfully selfish and blunt. But then he gave a rather unselfish example:
Imagine you were looking out across the road and you see a distracted person about to cross into the path of an oncoming bus.
You would shout, ‘Stop! A bus!’
You’re communicating with them so they avoid a horrendous accident.
At the same time, it is, ultimately, to get what you want.
You don’t want someone to get hurt.
You want someone to avoid a terrible accident.
I began to see how his argument worked with all types of communication. Press releases, check. Emojis, check. Small talk, check. Advertisements, check. The half-hearted phone calls you make to your grandparents to let them know you haven’t forgotten them, check.
However, with each situation comes the danger of messages becoming lost in translation, or communicating something completely different to the intended message.
Take for example, emojis.
And software teams.
But first, let’s look at emojis…
‘That emoji does not mean what you think it means’
A recent Gizmodo article, ‘That Emoji Does Not Mean What You Think It Means’, exemplifies how a message can be communicated in a way that is vastly different to the intended message.
When we enter an emojis on our phones, what you’re really entering is a Unicode character that renders on your phone as a pictograph. The rendering across different platforms is where most of the miscommunication happens.
The article references a study of where 304 participants rated the sentiment expressed by a variety of Unicode characters on a scale from strongly negative (-5) to strongly positive (+5). The study used five platforms to display the emojis – Apple, Google, LG, Microsoft, Samsung.
Let’s take a look at how the U+1F601 Unicode character with the description of ‘grinning face with smiling eyes’ was rated.
This particular emoji was described by study participants as ‘blissfully happy’ and ‘ready to fight’ depending on the platform.
The average score of the Google-rendered emoji (the one described as ‘blissfully happy’ by some study participants) was 4.
Here is what it looks like:
The average score of the Apple-rendered emoji (the one described as ‘ready to fight’ by some study participants) was -1. This particular emoji has effectively been lost in translation.
Here is what it looks like:
Although the Unicode character is the same, and the platforms are trying to emote ‘grinning face with smiling eyes’, it’s clear that the interpretation of ‘blissfully happy’ and ‘ready to fight’ are polar opposites of the positive/negative spectrum.
If these are the results of a relatively small-scale study, imagine how many people are misunderstanding the 6 billion emojis sent every day. That’s a LOT of potential miscommunication! I miss the days when : ) === : )
What do emojis and tech teams have in common?
The multiple platforms of the emojis is where the miscommunication lies. One message – ‘grinning face with smiling eyes’ – delivered through multiple platforms, and interpreted multiple ways.
I do believe the writing tutor is correct with his theory that the goal of communication is to get what you want, or at least try to. The failure of a message usually lies in its delivery.
Let’s take a look at tech teams.
What do tech teams want? Better error management. How? Here’s a few:
- Bug-free features
- Issue-free deployments
- To save money
- To quickly resolve bugs
- To understand why errors are occurring
- To be informed of existing issues affecting end users
- Clear communication between teams and team members
And here is a conservative list of communication channels tech teams use to try to achieve better error management:
- Instant messaging
- Conference calls
- Video calls
- Text messages
- Phone calls
- Messaging apps
Just like the multiple platforms trying to communicate a particular emotion, the multiple channels used by a team equals multiple ways that a message can potentially fail.
With the array of communication channels available, it’s an understatement to say it’s difficult for a team to cut the clutter and concentrate on getting what it really wants.
For those unacquainted with Slack, Slack is a messaging app for teams that makes collaboration hassle-free and, dare I say it, a joy. Teams have dedicated channels depending on its purpose – for example, ‘#deployments’ or ‘#marketing-team’ – and channels only include team members who need to be part of the conversation.
What a perfectly simple way to cut the clutter. You only listen and participate in conversations that you care about.
However, the existence of Slack in your workplace does not mean smooth sailing from here on out. Teams have to use Slack efficiently for better error management systems.
I heard of an Agile team that spanned two continents, but where only half the team used Slack. The non-Slack users were the product owner and half the design team on the other side of the world.
If you think my list of communication channels above in no way applies to any real life examples, this particular team used six out of the seven on the list.
Changes to project requirements, including bug fixes, usually went like this: an initial video conference to make sure everyone was on the same page, then group emails to nut out details, then individual calls with the design team if you were the one tasked with making UI changes, and then jumping on the team’s Slack channel to ask technical questions, and then a video conference with the whole team to make sure all the details were correct … you get the picture.
Aside from getting the whole team on a Slack, what this team needed, and eventually used, was to integrate Slack with Raygun Crash Reporting.
#errors: Using Slack for better error management
Tech teams want to develop and deliver code with minimal disruption to users. If there is an issue affecting users, the first time you hear about it might be customer complaints.
The solution? Send all your website’s or app’s errors to a dedicated Slack channel (e.g #errors) with Raygun Crash Reporting.
In the event of bugs, you are alerted the moment an issue happens and you can take immediate action to fix it. Most of the time you can make fixes before users even notice there was a bug in the first place – keeping your team one step ahead of users.
Teaming Slack with Raygun Crash Reporting garners the efficiency of Slack with the power of Raygun Crash Reporting. It leads to better error management within teams by improving the efficiency of communication.
Let’s take a look at the list of what tech teams want again, but this time with details on how this integration could vastly improve parts of a tech team’s workflow, and make for better error management in your development team.
Bug-free features and issue-free deployments
Although having consistently 100% bug-free features and deployments remains elusive, teams can greatly reduce the amount of bug-free features and deployments by checking any errors that occur in test environments.
The process for better error management starts when deploying to production, as with Slack you will be notified of any issues the moment they happen.
Raygun Crash Reporting also supports tags, so when you see an error notification on Slack, the tags you create in Raygun are also included:
The old adage ‘time equals money’ holds true here. With one source of communication and the full stack information, teams cut down on the time it takes to debug and action bug fixes. No more confusing email chains!
Quickly resolve bugs, understand why errors are occurring, be informed of existing issues affecting end users
As soon as you send data to Raygun Crash Reporting, you will be notified of any existing errors on your website or app. There may even be errors you had no idea existed.
Raygun Crash Reporting offers detailed information on error groups like:
- The full stack trace
- Knowing when errors occur
- The version of your app an error occurs in
- The affected users
Clear communication between teams and team members
All team members can view the error groups in the #error channel. If you need further information from the key team members ask them about it immediately using @user.
You can also use Slack’s notifications for specific messages depending on the severity of the error:
@everyone: Notify all members using Slack.
@channel: Notify all members of a channel – active or away.
@here: Notify only members who are currently active.
/msg @user write your message here: Send a DM to a user from any channel.
Integrating Slack with Raygun is seriously easy. Checkout the setup video to get Slack integrated with Raygun Crash Reporting in under one minute:
You can also view step-by-step instructions here.
Avoid miscommunication in your team by using a messaging app like Slack. This means teams have dedicated channels depending specific purposes and channels only include team members who need to be part of the conversation.
If discovering and fixing issues affecting your customers is a priority, integrate Slack with Raygun Crash Reporting pronto. You’ll be notified of any errors happening in your website or app immediately. Better error management starts with better communication. You’ll be able to fix errors well before any of your customers notice bugs in the first place.
Oh, and it might not be a bad idea to give your grandparents a call, too 😉