Showing posts with label slack. Show all posts
Showing posts with label slack. Show all posts
Emoji imparied
I don't understand any of the dozens of emoji the folks around me use to provide feedback or exclamation.
Incident Response Slack application series
I am have finished working on the Incident Response Slack application. It was a hobby project and I feel no need to take it any further, although, I would like to switch to RDS from SimpleDB. Here are the postings related to the project
- Incident Response Slack App
- Adding persistence to the Incident Response Slack application
- Who wants to perpetuate a flawed design when a proper one is just around the corner?
- Incident Response and stating requirements
- Access AWS Secrets Manager from AWS Elastic Beanstalk
The code is on GitHub at https://github.com/andrewgilmartin/com.andrewgilmartin.incidentresponse
Incident Response Slack App
As we learn how to better use Slack we are experimenting with different ways of managing our response to incidents, aka emergencies. One experiment is that when an incident is discovered the existing #incident-response channel is used to send an alert to those on-call. We then immediately create a new channel for only the new incident's staffing and communications. While we rarely have overlapping incidents, having a dedicated channel does prevent the interleaving of messages about other incidents, too many tangents, and only those working the incident are disturbed by @channel or @here messages. When the incident is resolved the channel's messages can be copied into the beginnings of the post-mortem document, and then archived.
During the response, tasks emerge that need to be assigned and tracked. Slack itself is not good at this alone. There are many applications for task management that can be made accessible via Slack slash-commands. For incident response tasks, however, these general purpose applications were too focused on the user and not enough on the channel. When listing tasks we only want to see those for this incident. Their extra features also had a cognitive weight that I brisselled at. Overall, their fit for purpose was poor.
What was needed was a task manager with a scope limited to one channel. The task manager would be installed in the workspace, and so accessible to everyone, everywhere without configuration, but when in use was channel focused. The task manager needed to support these simple the use cases
These use cases turned into the /ir slash-command
If you are interested in the implementation then see github.com/andrewgilmartin/com.andrewgilmartin.incidentresponse
During the response, tasks emerge that need to be assigned and tracked. Slack itself is not good at this alone. There are many applications for task management that can be made accessible via Slack slash-commands. For incident response tasks, however, these general purpose applications were too focused on the user and not enough on the channel. When listing tasks we only want to see those for this incident. Their extra features also had a cognitive weight that I brisselled at. Overall, their fit for purpose was poor.
What was needed was a task manager with a scope limited to one channel. The task manager would be installed in the workspace, and so accessible to everyone, everywhere without configuration, but when in use was channel focused. The task manager needed to support these simple the use cases
- Adding tasks with a description, assignments, and a status.
- Updating a task’s description, assignments, or status. Only notify the channel when the changes are pertinent to all.
- Listing the tasks with optional criteria.
These use cases turned into the /ir slash-command
/ir description [ user … ] [ status ]
/ir task-id [ description [ user … ] [ status ]
/ir [ all | finished ] [ user … ] [ status … ]
If you are interested in the implementation then see github.com/andrewgilmartin/com.andrewgilmartin.incidentresponse
Slack messages are rarely ever completed thoughts
Comments on TechCrunch's article "Distributed teams are rewriting the rules of office(less) politics."
I don't think that article quite hit its mark, but it did contain two important bits. Loneliness is an issue for me. I like being among my colleagues. Even if nothing is said all day the presence of others roots us to a common purpose and common comfort. The other is the need to write more and with specificity.
A requirement of asynchronous communications is leaving information for others to respond to later. Ad infinitum. The longer the timespan between communications the more context each information leaving must include. It is a skill to provide brief context in these leavings along with clear answers and, perhaps, further questions. Many characterize asynchronous communications as a conversation. However, conversations are informal. Our communications are more like a dialogue where we explore problems and solutions. Problems and solutions are formal, or rather somewhere between not informal and algorithmic. And they must to be recorded and the records curated. Asynchronous communications requires a diligence that is not provided by simple conversation.
One of my favorite discoveries (unfortunately, shortly after college!) was Thinking on Paper by Howard and Barton. Writing is design thinking. (Coding is design thinking.) Design thinking is iterative and unsteady in its forward motion. Two steps forward, one step backward. Unfortunately, people still think of writing as something that happens after thoughtfulness. This misunderstanding can lead to written mistakes being harder to recover from than said ones. If you take away one bit of advice from here, it would be to assume that Slack messages are rarely ever completed thoughts.
I don't think that article quite hit its mark, but it did contain two important bits. Loneliness is an issue for me. I like being among my colleagues. Even if nothing is said all day the presence of others roots us to a common purpose and common comfort. The other is the need to write more and with specificity.
A requirement of asynchronous communications is leaving information for others to respond to later. Ad infinitum. The longer the timespan between communications the more context each information leaving must include. It is a skill to provide brief context in these leavings along with clear answers and, perhaps, further questions. Many characterize asynchronous communications as a conversation. However, conversations are informal. Our communications are more like a dialogue where we explore problems and solutions. Problems and solutions are formal, or rather somewhere between not informal and algorithmic. And they must to be recorded and the records curated. Asynchronous communications requires a diligence that is not provided by simple conversation.
One of my favorite discoveries (unfortunately, shortly after college!) was Thinking on Paper by Howard and Barton. Writing is design thinking. (Coding is design thinking.) Design thinking is iterative and unsteady in its forward motion. Two steps forward, one step backward. Unfortunately, people still think of writing as something that happens after thoughtfulness. This misunderstanding can lead to written mistakes being harder to recover from than said ones. If you take away one bit of advice from here, it would be to assume that Slack messages are rarely ever completed thoughts.
Slack and "Operation Crossfire aftermath"
I was watching Operation Crossfire aftermath and another use for Slack came to mind. Lindybeige was coordinating a miniatures wargame with several dozen people, across the world, over a 4 hour period using email. It was a logistical nightmare trying to keep track of each conversion and the materials needed to be gotten and sent to each participant -- half of whom were called "Steve"! As I watched it occurred to me that had Lindybeige instead used Slack and created, for example, a channel for each participant and a channel or two for general purpose it would have been logistically much easier. Channels in bold have unread messages, messages are organized chronologically, messages could include maps or command and control documents, messages can be pinned for easier reference, etc. Lindybeige still would have been exhausted by the effort, but, hopefully, in good spirits throughout.
I should note that using Slack in this way is not the same as using a messaging platform such as Skype, IRC, etc. In a messaging platform you are talking with an individual within the context of the rest of their life's conversions. Instead, a Slack workspace is being using to gather individuals for a shared purpose. The rest of their life happens outside of the workspace. When the individual is in the workspace they are, for all intents and purposes, the character they are playing. This is reinforce by their communicating via the named channel. I am no long Andrew Gilmartin, but instead I am #Second Lieutenant Anderson.
[1] This is a follow up to Slack for One.
[2] I know next to nothing about who is Lindybeige. I do enjoy his YouTube channel.
I should note that using Slack in this way is not the same as using a messaging platform such as Skype, IRC, etc. In a messaging platform you are talking with an individual within the context of the rest of their life's conversions. Instead, a Slack workspace is being using to gather individuals for a shared purpose. The rest of their life happens outside of the workspace. When the individual is in the workspace they are, for all intents and purposes, the character they are playing. This is reinforce by their communicating via the named channel. I am no long Andrew Gilmartin, but instead I am #Second Lieutenant Anderson.
[1] This is a follow up to Slack for One.
[2] I know next to nothing about who is Lindybeige. I do enjoy his YouTube channel.
Slack for One
Recently, I had the idea that you could use a private Slack site for personal projects and journals. Each channel is a new project or a journal. Slack's chronologically organized messages allow for text, images, (simple) formatting, and the inline inclusion of external content such as from Google Apps. There are many bots for managing each project's actions and reminders, for example. And if you do need to share the project you can. As I thought about this more there seemed no end to how to use Slack as purely a personal information tool rather than a group communications tool. I wonder if anyone has actually used Slack this way?
Grumble about messaging conversation indistinguishability
Why, why! oh mighty God, do Slack, Skype, Messenger, iMessage, and every other messaging application not make any visual distinction between two or more conversations? Squint at the screen and you will see that every conversation looks identical -- even across messaging applications! How many times have you and I and, most likely, the developers of these applications sent a message to the wrong conversation? Lots. Please, oh pretty please, allow me to at least change the background color of conversations.
Slack, "Jump to conversation", and a global shortcut
Slack's "Jump to conversation" Cmd-K shortcut is really useful to quickly contact one of our burgeoning staff or channels. Unfortunately, Cmd-K only works when Slack is the front-most application. Further, since Slack does not provide a "Jump to conversation" menu item you can't use the Keyboard System Preferences to make a global shortcut. So I wrote a small Service, SlackCommandK.workflow [1], that when run sends a Command-K to Slack. I then assigned it the Ctr-Cmd-K global shortcut. (I need to add Ctr as Cmd-K is used in other applications and their use of Cmd-K trumps the global use.)
To use the service download it, unzip it, launch it, give permission [2], install it, and then go to the Keyboard System Preferences to add the Ctr-Cmd-K shortcut.
[1] This is how tiny it is
To use the service download it, unzip it, launch it, give permission [2], install it, and then go to the Keyboard System Preferences to add the Ctr-Cmd-K shortcut.
[1] This is how tiny it is
tell application "Slack" to activate[2] Since this Service is not signed you will also need to override the default restriction on unsigned applications using the Security & Privacy System Preference. Go to its General tab and press Open Anyway button next to the text
tell application "System Events"
keystroke "k" using command down
end tell
"SlackCommandK.workflow" was blocked from opening because it is not from an identified developer."
Which answer goes with which question?
Gripe. In real-time group discussions -- Skype, Slack, HipChat, etc -- the interleaving of messages from the multiple participants will cause confusion when many questions are open and answers are given without context. Which answer goes with which question? So, when the question is "do we need to do X with Y" then answer "Re X with Y, yes" and not "yes". It takes so little extra time and, really, if you are that short on time then find another job where clear communication is not important.
Subscribe to:
Posts (Atom)