Superlatives are dangerous. They pressure you to line up the alternatives in a row, judge them all, make the perfect decision.
This implies that databases can be compared based on internal qualities. Performance, reliability, scalability, integrity, what else is there?
We know better than that. We recognize that relational databases, graph databases, document stores etc serve different use cases.
“What are you going to do with it?”
This is progress; we are now considering the larger problem. Can we define the best database per use case?
In 7 Rules of Effective Change, Esther Derby recommends balance among (1) inner needs and capabilities, (2) the needs and capabilities of those near you, and (3) the larger context and problem. (This is called “congruence.”)
“What is the best?” considers only (1) internal qualities. Asking “What are you doing with it?” adds (3) the problem we’re solving. What about (2) the people and systems nearby?
Maybe you want to store JSON blobs and the high-scale solution is Mongo. But is that the “best” for your situation?
does anyone on the team know how to use and administer it?
are there good drivers and client libraries for your language?
does it run well in the production environment you already run?
do the frameworks you use integrate with it?
do you have diagnostic tools and utilities for it?
Maybe you’ve never used Mongo before. Maybe you already know PostgreSQL, and it already runs at your company. Can you store your JSON blobs there instead? Maybe we don’t need anything “better.”
The people we are and systems we have matter. If a component works smoothly with them, and is good enough to do the task at hand, great. What works for you is better than anyone else’s “best.”
A lot of us are using Slack now. Some of us are past the shiny and into misery, where we wish for the good old days of email and talking with our mouths.
Let’s look at this technology thoughtfully, and see whether we can corral it into helpfulness. Dan North gave a great talk about Eli Goldratt’s The Goal, which teaches how to take advantage of and prevent harm from a new technology. He included examples from manufacturing, accounting, and DevOps. Let’s use this technique for Slack.
Four questions to ask about any new technology:
What is the power?
What limitations does the technology diminish?
What rules enabled us to manage this limitation? (gotta throw those away, or you get no benefit)
What new rules will we need?
What is the power of Slack?
Slack brings instant, persistent communication to the masses. Compared to email, it’s fast. Compared to IRC, it’s accessible, bringing critical mass of network size. Compared to in-person communication, it’s persistent and searchable.
Slack also changes a decision point: with an email or a meeting invite, the transmitter of information chose the recipient. In public Slack channels, everyone can look at it, including people who weren’t even in the company when I posted it, hypothetically. This moves power from the writer to the reader.
What limitations does Slack diminish?
There are two varieties of communication to consider separately. One is informal discussion, which used to happen in person. This requires speed or response. The other is broadcast, which happened over email or in speeches. This is supposed to be received by everyone.
Now, with Slack, informal discussion can be fast and spontaneous without sound transmission between people in the same room. That’s a release of space limitations. Now, informal discussion doesn’t require you to break someone else’s concentration. You can ask a question, and they can look when they hit a stopping point. That’s a release of time limitations. Then there’s an even bigger release: you don’t have to be in that room at that time in order to overhear the conversation. The discussion and decision is available to the rest of the team whenever they get to work, in whatever time zone they work in.
Broadcast was once limited to speeches or emails — or before that, memos. These take time to compose. Slack messages are faster: throw them out there. You can get immediate feedback from everyone, potentially. Broadcasting to the whole company, to anyone who subscribes (now or later), is cheap and easy.
What rules enabled us to manage this limitation?
We had communication mechanisms before Slack, I swear we did.
For discussions we know we needed, we scheduled meetings and reserved conference rooms.
For discussions we didn’t know we needed, we had the kitchen, with its coffeemaker. Smoke breaks, back in the day. Shared space and time: physical colocation and standard work hours.
For broadcast, we had the hierarchy. Decisions and vision statements passed down from executive to manager to manager to manager to worker. Then results passed upward in the reverse hierarchy of status meetings: everyone sit here while each of you reports to me on your individual work.
Now that we’re free of these limitations, we can work anywhere, on any schedule, and we have transparency, so everyone can learn what’s happening from the CEO and CTO, and we can all know what the most important thing for us to work on is because we have all the information, right?
What new rules do we need?
Clearly we don’t have all the information, because Slack contains far more information than we can each absorb.
What did we lose when we lost the old limitations? When throwing things out there became cheap and easy?
We lost curation. More information is not better — it isn’t even more. When there’s more out there than we can take in, we take in less. When every time a nurse brings up a patient record they get eight warnings, they stop reading any of them. When we log in to Slack and all the channels have dozens of unread messages, we hit Shift-Esc. At least I do, so that the channels all unbold and I can think again. There is value in transmitting less, in deciding what is important before you send it, so that everyone else in the company doesn’t have to decide for you.
We lost common ground. Common ground is shared knowledge that everyone knows that everyone knows. It’s a basis for efficient communication and trust in each others’ decisionmaking. When a team has its discussions in Slack, there’s an assumption that everyone heard everything. When someone was on vacation or troubleshooting production or just getting work done, they miss that, and no one else on the team knows they missed it. Or a manager writes something in a channel, they think everyone got it, and they’re wrong. We miss the feedback loop of seeing who is in the room, the grace of “oh right you weren’t there that day.” Thinking someone knows something they don’t leads to dangerous miscommunication.
We lost focused conversation. Asynchronous messaging is suited to multitasking. Multitasking is not suited to effective communication. Nor is the single dimension of ASCII text. Emojis help, but they can’t substitute for seeing each others’ faces. Nonverbal cues help transmit intention, and that prevents and heals hurt feelings. Also, focused dialogues and discussions help us develop shared mental models much more quickly. That means we need to talk synchronously: at the same time, in the same room (even if it’s a Zoom room).
At this extreme, more information is less.
What new rules do we need?
Right. So what conventions and guidelines can help us overcome this pain?
I haven’t got it all figured out, but I can give you a few that help at Atomist.
Verbosity is inversely related to Importance
Each channel has an expectation-of-reading level.
There are a few “everyone reads all of this when they get back from vacation” channels, containing only brief updates about significant changes. There’s #announce for official announcements (including birthdays; it’s a small company). There’s #what-happened, where architectural or vision redirection is reported, usually including a link to detailed discussion in another channel.
There’s one “everyone reads this daily but not when they come back from vacation channel” called #standup. These are the daily goings-on, what’s about to go to Prod, what objectives each person has, and what’s blocking them. We also have a 15-minute daily standup video call, which we record and post in #standup for people who are in other time zones or at the dentist that day.
Then there are channels for items and questions that many people care about; #engineering gets “can someone help me debug this prod slowdown?” and “I’m about to restart the test database” and “I’m stumped and need a pair.” I check this channel when I’m online, but I won’t scroll back far when I get there in the morning.
Each project has a channel for updates and chatter relating to it. We talk about and create issues, help each other troubleshoot, and answer questions like “Why did we do it this way again?” For updates on the code, @atomist bot condenses GitHub, Travis CI, and deployment notifications into tight, dynamically-updated messages. (You can get this too.) There’s no expectation of keeping up; each of us joins one or two of these channels while working actively on the project.
Personal streams: I have a channel called #jessitron-stream that I use like a notebook. If I don’t have a pair, I’ll rubber-duck here. When I get a new error message, I’ll post it here and then track it down, and post the resolution. That’s handy for searching later. As a bonus, sometimes other people are poking around and jump in with “have you tried this?” When I need to ask someone a question, I’ll @-mention them in my channel, and then they can see the context of the question. Unless I specifically call for someone, there’s no expectation that anyone reads it. Google Calendar integration posts meetings at me, which is handy when someone wonders what I’m doing. Other personal streams in our Atomist slack include #tanya-coding, #kipz-corner, #radio-russ, and #aarrr-day.
Move to Zoom quickly
As soon as a discussion gets interesting, if it has all your attention or if it should, move it to Zoom (or your video conferencing choice, or in-person if that’s a thing). This improves concentration, increases information transfer, and removes a sneaky impression that everyone was part of the discussion when they weren’t.
We have one Zoom room that’s a default for helping each other, asking questions, or generally hanging out while we’re working. We call it “bang-zoom” because our bot posts a link to it in response to “!zoom” in Slack. So when it’s time to share a screen or look each other in the eye, we type “!zoom” and head in there for face time.
Zoom for Safety
If something you read in Slack hurts, stop. Make a guess that the person didn’t intend it the way it came across, and get into a Zoom meeting ASAP to learn more detail. Your feelings are a useful clue that some information is missing on at least one side, so get that resolved and gain some common ground out of it.
We have a :zoom-for-safety: reactji. After I read something and then smack my desk in frustration, I use that reactji instead of responding on Slack.
Threads: if a channel’s conversation has moved on since the message we want to reply to, we’ll put that reply in a thread. No one is expected to read a thread they weren’t @-mentioned in.
Emoji: I need them. I love reacting without adding a message to the channel. When there’s something I want to say that doesn’t easily iconify: any image that comes up in a google search for that phrase is fair game. I’ll put some of my favorites at the end of this post.
Channel profligacy: so what if there are hundreds of channels? We join and leave, create and archive as our projects and people change. Crucial: just because someone is in a channel doesn’t mean they read it.
@-mention response time: This is asynchronous, people. If I want your attention, I’ll @-mention you; check Slack when you’re at a stopping point. I am not checking Slack while focused on writing this post. When I’m done, I’ll respond to all @-mentions and direct messages. If it’s an emergency, somebody has my cell phone number.
@channel: treated as an @-mention to everyone; read them.
@here: for something urgent right now (“I’m shutting down the dev environment for 15 minutes”) but not relevant later.
Private channels: useful for surprising someone for their birthday. Otherwise considered rude.
Direct messages: go for it, have a chat. When I want to ask @kipz a question about current work, I @-mention him in #jessitron-stream instead, in case anyone else wants to pipe in.
Slack is a technology like any other: useless unless you change how you work, painful unless you choose how you work.
At best, asynchronous messaging removes interruption; lets us search our history of solved problems; and catches us up on what we missed, giving freedom in time and space. At worst, it multiplies interruptions and hides information in a pile of cruft. It’s our choices that let us use it effectively, and stop it from using us.
Here are more of my favorite emoji.
The famous party parrot has flashy colors that can trigger migraines or seizures. Be accessible! Replace it with this one.