Taming Slack

Tips on using Slack like a pro

Digit is a Slack-only company. While we use email for automated alerts and GitHub emails, nearly all of our communication happens on Slack. We're north of 100 employees, and without proper usage, Slack can get incredibly noisy and distracting.

While one may be tempted to blame Slack, the root of the problem is human communication -- communication volume grows quadratically with the growth of a community. Organizational hierarchies are one solution to this problem: they impose a tree-like communication structure that, in theory, dampens the volume of communication. However, deeply hierarchical organizations have other issues, resulting in modern companies trying to be "flat." In a flat, trusting, information-should-be-free company, there are lots of messages floating around.

Using Slack in such an environment gives rise to some common anti-patterns:

  1. Missed messages. Important messages that need a response get buried in a sea of business-as-usual stuff. To ensure that everyone reads important messages, people start using `@here` and `@channel`

  2. Channel disorganization. Lots of channels, lots of messages. Nobody knows the "right" channel to post or follow a particular message. So people post to the most convenient channel, often breaking a team's flow or causing problem #1.

  3. Interwoven threads. We commonly have more than one conversation going on at any time in one channel. Because each message is a top-level object, multiple conversations get woven together, making one stream challenging to follow.

  4. No inbox zero. For people (like me) who like to clear their queues, Slack can be challenging. Where do you store messages that you want to get to later?

Not all of these problems are specific to Slack. We've certainly seen variants of all of these with email. Email has had a more extended timeframe for people to build tooling around it and specialize to suit their needs. Slack is relatively new -- and so we have a greater need to develop conventions from scratch.

Here are some of the things that have worked to help tame Slack, divided into team-related conventions and personal workflow.

Team Practices

1. Have a channel naming convention

Channels in Slack are free and can explode. Channel names should signify a channel's purpose. Names help people understand where to post things without having to read through all the channel's content. For example, #engineering-fyi, #product-fyi, #release-fyi, and other #-fyi channels are meant for important information about a particular topic. They are generally low volume, but when you see something pop up, it's probably critical. #savings-team, #onboarding-team, and other #-team channels, on the other hand, are for everyday team conversations. High volume, a mix of business and banter, generally not intended for people who are not on the team (but we keep them public, more on that later.) Some channels (e.g. #feedback) have specific conventions associated with them and automated bots to help run these channels. "How to run a triage channel" is an excellent example of a triage channel, which we implemented using a custom slack bot.

2. Encourage threaded replies

For high-volume channels, a conversation can become difficult to follow if messages are interspersed. Essential conversations can get lost or be left incomplete while being hard to follow for interested parties. This problem is more acute in broad channels than DMs or small groups. Using threaded replies solves this problem -- however, getting everyone to use threaded replies is challenging. We use a cute :shame: emoji to gently remind people to use threaded replies -- it works well, and people laugh at the inevitable slip-ups.

3. Ban @here and @channel

@mentions can be incredibly distracting because they notify people in most circumstances. @channel and @here take this distraction to a new level by notifying everyone in a channel; when used in a broad channel, like #fyi can essentially notify the entire company. There are certain rare occasions when breaking through peoples' filters is necessary: β€œ@channel we're shutting down the office because of covid-19.”

In most cases, however, using these notification mechanisms is rude and should be avoided. It assumes that people don't read their Slack messages or that whatever you're posting is important enough that they need to look at it now. @here makes very little sense in a distributed, remote world -- but teams tend to use it as a sort of lightweight @channel, as if notifying the people who happen to be working right now is okay, but notifying others is not. There are circumstances where these make sense: @here I'm locked out, can someone please open the door but other than that, these should be banned.

4. Discourage group DMs

How many times have you started a "quick message" between a few colleagues as a group DM, which has subsequently escalated into an entire meaningful conversation, which needs some more people ... and you're stuck. Because Slack doesn't allow expanding group DMs (come on, Slack folks!) There is a solution - it's free and easy -- it's called a channel. Just convert group DMs into a private channel as soon as possible. We encourage people to start public channels for brief discussions with a naming convention - #tmp-something-something - and archive it once complete. Group DMs aren't indexed well either and generally suck. Channels are free; use them.

5. Post in the right channel, cross-post for visibility

Often, we don't know where we should post a particular message. Not knowing is okay -- we post in a broad channel and ask or take our best guess. Have a little emoji to indicate that you should probably ask the question in a different channel: we use :polite-racoon:. Sometimes, a message is important enough for a few related channels. We post the message to the most appropriate channel in such cases and share it (Slack s) to other channels.

6. Setup emoji conventions

Slack doesn't let people know you've read their message or taken care of something: a vexing problem when, for example, delegating something to someone. We use the πŸ‘€ :eyes: emoji to indicate that we've read something, βœ… :white_check_mark: to suggest that something has been taken care of. Some channels have even more specific emoji conventions in use, but people broadly understand these two across the company. When we have a call to action, we post a message similar to β€œPlease do this task and βœ… this when you've done it. -- this helps us keep track of who's done something, and we can follow up accordingly.

Personal Tips

Team tips are great to help the whole team use Slack in the same way. To achieve productivity zen, you need to combine these with ways to manage your unread queues and reach inbox zero.

1. Use /mute liberally

Lots of channels mean lots of messages. Everyone wants to be in the loop on everything, but the reality is, much like world news, most of it doesn't affect you daily. To get some control over information overload (so you're not just reading slack messages all day), you can do two things: leave irrelevant channels or mute them. I prefer to mute them to read them at my leisure, without affecting my unread count or showing up in my Unread section.

2. Use /remind or Save to keep your GTD flow

There are two GTD flows that I've seen people use (or some mix of both): Remind and Save. Remind essentially takes a message and asks Slack to bring it back as unread in some time: similar to Gmail's snooze feature (itself of Inbox fame.) The Slack command is /remind.

The alternative is to use a queue and clear it every morning and evening (or whatever cadence suits you.) Clearing queues is my preferred approach -- I use Save or hotkey a when reading my messages -- to keep track of things I need to get back to.

3. Use scheduled posts for after-hours posting

While we operate on mostly west coast hours, we're split all over the world. Moreover, we all have different working schedules -- with my family, I sign out starting around 5 pm but am incredibly productive between 9 pm - 1 am (a combination of my night owl-ness and my family sleeping peacefully.) However, sending people tons of slack messages at midnight is ... not good. It can come across as a poor work flex (look at how hard I'm working), and it doesn't work: you're not going to get replies in the middle of the night anyway. So use scheduled posting (πŸ™πŸ½ πŸ™πŸ½ πŸ™πŸ½ Slack for finally shipping this) to post at more reasonable hours. Alternately, I queue up some drafts and fire them off first thing in the morning.

4. Use Notify me for threaded conversations

Sometimes you'll see a fascinating topic, but you'll lose out on the subsequent conversation because your team uses threads. Instead of chiming in with a Following or similar message, you can hit the β ‡button on the thread and ask Slack to notify you of future updates. Now everything shows up in your threaded list and is easy to clear, like any other queue.

5. Quickly read through All Unreads and Threads

Both of these help me go through all incoming messages rapidly and clear my queues. When I find myself consistently thumbing through a particular channel without responding to it, I mute it.

6. Organize channels by topic

Slack launched custom sections to allow creating folders for channel organization. Folders let me manage my channels by topic, such as "team," or "recruiting," or "engineering."

I hope these tips are helpful. If there are other things you or your organization do to make Slack usage more effective, I'd love to know - please drop me an email or DM.


Thanks to David Kossnick for thoughtful suggestions and edits. Thanks to the Digit team for implementing the practices and conventions discussed above.

If you like this content, please consider forwarding to your friends and colleagues.

If you’re interested in fintech and making financial health a reality for all Americans, come join us at Digit. We’re hiring for a number of roles across product and engineering.

Building Cathedrals

The York Minster Cathedral took 242 years to build. Photo by MatzeTrier CC BY-SA 3.0

Building great products takes enormous hard work over a long time. When we’re deep in the execution tunnel, blocking and tackling the problems that come our way, we can lose sight of the greater goal. Whenever that happens, motivation sinks, and both the volume out of output and the quality of work suffer.

We have to remind ourselves and our teams of the greater purpose constantly. What is the big problem we’re solving? Why does it matter? Where does it go over the next decade?

One of my favorite stories:

Two bricklayers are busy at work.

You walk up to them and ask: β€œWhat is your job?” β€œI’m laying bricks,” they say.

Ask the second: β€œWhat is your job?” and they reply: β€œI’m building a cathedral.”

We are all building cathedrals. We need the occasional reminder because we have to lay down a million bricks.

2021

πŸ‘‹πŸ½

I cannot believe we are in February already.

2020 was a clusterf*** of a year -- COVID, forced isolation, millions sick, hundreds of thousands dead, a nerve-wracking election, and the aftermath that would not end. January felt like a continuation of December'20 to some extent. But thankfully, things are looking a little better. Vaccines are out, we have a new government, and things are looking up.

I'm starting the year with an upgrade to the website. You'll notice a new theme and some splashes of color -- they're nice, but the key upgrade is below the hood. I've moved off Jekyll to Hugo. I don't love Ruby; I don't love how Jekyll has tons of ugly _s everywhere; I'm not fond of managing dependencies. Built using Go, Hugo is clean and fast. Structure and templates make sense. The community has ported most of the Jekyll templates over. I'm still using GitHub Pages to host (free and straightforward) but moved the site generation over to Hugo.

Enough about SSGs. Though the world of SSGs is fascinating and worth a peek. Why have fancy database-driven websites (I'm looking at you, WordPress) when a simple statically generated site could suffice? And the interwebs are very good at pushing bits of text around -- no fancy database lookups, and everything works blazingly fast.

I care about writing, and this upgrade will let me write more. My goal is to write shorter posts more often. I hope you, dear reader, enjoy them. 

Here's to a great 2021 and a giant f-you to 2020.

The Humble Note-Taker

or How to Write Notes and Influence Teams

Welcome to your first team meeting as the new PM. You're busy trying to learn what the team does and who everyone is. The team is discussing an important decision they need to make. What should you do?

  1. Do nothing. You don't have all the context, how could you contribute?

  2. Jump in with your ideas. You're a person of action and this is why they hired you.

  3. Offer to take notes. Ask a clarifying question. Post the notes after the meeting.

Doing nothing, while gentle, is ineffective. You don't make progress in building trust with your team or extend the understanding of the subject matter.

Jumping in with your ideas is plain obnoxious. You have no context. In your rush to "add value" you're showing everyone that you know barely anything.

Taking notes, asking the occasional clarifying question, perhaps suggesting a minor reframing, and posting the notes publicly β€” these are activities that simultaneously add value and improve your own understanding and knowledge.

Note-taking is historic record-keeping. Nobody will remember what they discussed or agreed upon, a few days after the meeting. What everyone will look at are the notes. If you have any doubts about this, try and think of your precise position on a meeting you were in, one week ago.

Note-taking is an incredibly powerful way to learn. People learn through writing. By taking notes, you force yourself to understand things and ask questions. In some cases, you find references to read through, deepening your knowledge. In other cases, the questions you have are the same questions everyone else has. Either way, your learning accelerates rapidly through taking notes.

Note-taking progresses rapidly to decision-making. You start by taking notes for your team. You post them publicly. Everyone is so grateful that you took on a menial and tedious task. Slowly, you develop the most in-depth knowledge of everything the team is doing. People start asking you for your opinion. At some point, they delegate the decision over to you, because you have the most knowledge and most up-to-date view.

Thanks to Shishir Mehrotra, for the original idea, years ago. Thanks to Jules Walter and DeVaris Brown for proof-reading and feedback.

10 tips for using OKRs effectively

I’m back after a long hiatus from writing.

We are in planning season at Digit. Like a number of other technology companies, we use OKRs. I was puzzled by the wide range of OKR effectiveness at different companies. My study of the nuances of different approaches led to the conclusions outlined in this note. OKRs are incredibly useful but it takes a long time for OKR usage to become effective. Shortcut your company's learning process by understanding and implementing the following ten ideas. If you find them helpful, drop me a note.

What are OKRs?

OKRs stands for Objectives and Key Results. They capture two things:

  1. Objective: The goal a company wants to achieve ("What")

  2. Key Results: The path to achieving that goal ("How")

OKRs are an invaluable management tool for organizations of all sizes. Used properly, they allow an organization to unlock four superpowers:

  1. Focus and commit to priorities.

  2. Align and connect for teamwork.

  3. Accountability through tracking.

  4. Stretch to achieve the impossible.

[Measure What Matters, John Doerr]

OKRs are a tool. The act of using OKRs does not guarantee Google-like performance, innovation, or market dominance. OKRs are not a strategy, nor do they make up for lack of strategy. OKRs force a company or organization to think rigorously, to hold themselves accountable, to stretch, and to learn and grow. Persistent usage over time guarantees increased focus, alignment, and execution. Here are 10 ideas to use them more effectively πŸ‘‡πŸ½

10 Tips for using OKRs effectively

1. Objectives must be Big and Motivating

A great, challenging goal is inspiring. It brings teams together. It ignites that thing in us that led to human spaceflight and exploration of unknown frontiers. Inspirational objectives are critical at the company level, since company OKRs cascade down to teams and individuals. Everyone should feel proud to accomplish their objectives and together achieve a higher goal.

Objective: Win the Super Bowl

KR1: Passing attack amasses 300+ yards per game. 

KR2: Defense allows fewer than 17 points per game. 

KR3: Special-teams unit ranks in top 3 in punts return coverage.

[whatmatters.org]

2. KRs must be measurable

There are three important components of a key result:

  1. The metric by which you will measure progress.

  2. Where you are starting and what the goal is.

  3. When you'll be done. The time is assumed to be end of the execution period (quarter or half) if not mentioned explicitly.

For example, let's say you want to reduce your AWS costs by improving server efficiency.

Objective: Reduce AWS costs.

KR: Increase server utilization.

How will we know whether we have achieved our OKR or not? When should we stop working on this or work harder? The OKR could be rephrased to make it clearer:

Objective: Reduce AWS costs from $100 to $80.

KR: Increase server utilization from 65% to 80% by the end of the quarter.

3. Use binary KRs sparingly

A binary KR is one that is either done or not done. For example:

Objective: Reduce AWS costs from $100 to $80.

KR: Turn on auto-scaling for all services by the end of the quarter.

Binary KRs are measurable β€” they were either accomplished or not β€” but usually need to be combined with quality counter-metrics to be effective. More on metrics and counter-metrics below.

Another example of binary KRs are "Ship KRs". They are often used when rolling out new features. Without baseline data, there is no way to measure or predict how a feature will perform. The team can put in work to predict outcomes, but sometimes, it is easier to ship something and see the impact. Ship KRs have their place, use them with caution.

4. All Key Results must have dashboards

The natural consequence of measurability is the scoreboard. Every measurable KR should have an associated dashboard. These need not be fancy β€” an excel sheet is sufficient to get started.

Some results are only measured fully in retrospect or take a while to get an accurate read. Retention is an example of such a measure β€” we don't know upfront which user will churn. In such cases, teams should use alternate approaches, such as:

  1. Create a proxy "operational" metric that correlates well with the goal metric. 1-day retention can be used for 30-day retention if we find that the bulk of churned users churn within a day.

  2. Use a forecasted or predicted number as the operational metric. Monitor the predicted metric to keep the error within bounds.

5. Key Results must be exhaustive

Another common trap that leads to a feeling of inadequacy at the end of the quarter is missing an objective despite accomplishing its KRs. Imagine we take on a feature activation goal that ladders to some critical company objective.

Objective: Increase usage of feature X from 100 DAU to 200 DAU.

KR1: Improve activation funnel efficiency from 85% to 90% 
by August 1.

KR2: Improve feature X retention from 90% to 95% 
by September 1.

We get to the end of the quarter, both KRs are green, and feature usage hasn't gone up at all.

What if the lack of feature X had more to do with how you marketed it? If the problem is at the top of the funnel, increasing funnel efficiency is unlikely to achieve the goal.

Missed KRs are abundantly evident in hindsight, but much harder to think of ahead of time. One approach is to ensure that the goal (or the first KR) captures the intended outcome (100 DAU to 200 DAU) and let the team add KRs along the way if enough progress is not being made.

6. Pair Metrics with Counter-Metrics

There is natural pressure and temptation to achieve progress at all costs. There have been innumerable examples in the corporate world, with Enron and Wells Fargo being the most recent, where the drive to achieve a particular outcome, such as "Open more accounts," compromised the company's core values.

To guard against such adverse outcomes, you can pair metrics with counter-metrics. For example, Wells Fargo could have paired "number of active accounts" with defensive metrics such as "each account must be active," "each account must have a certain balance," "no more than X accounts per person in a week."

In product-feature land, there is a natural pairing of growth-based KRs and quality-based KRs.

KR1: Feature X will have 100 users by the end of the quarter.

KR2: 7-day retention for Feature X will be 90%. 

KR3: P0 and P1 bugs will be closed within a day.

7. Distinguish between Committed and Aspirational OKRs

OKRs are scored on a scale of 0.0 to 1.0. What's a "good" score? Many tech organizations believe the answer is 0.7, based directly on Google's scoring approach [whatmatters.org β€” how to grade OKRs]

However, the Google scoring system applies to Aspirational OKRs β€” typically Big, Hairy, Audacious Goals that you don't know how to hit. You know it's going to be hard, and you're likely to fall short. But if you don't reach for the moon, you're never going to get there. The purpose of aspirational OKRs is to stretch you, to motivate you to solve more significant problems and to think differently.

In contrast, some OKRs are expected to be delivered in full. Doerr calls these Committed OKRs. For the business to succeed, for cross-functional teams to depend on each other, these goals must be achieved in full. You are pushing for complete success, not setting aspirational visions. The expected score for these OKRs is 1.0, with low variance.

Distinguishing between committed and aspirational OKRs is essential. If a team biases too much toward commitment, they may not stretch enough. If you go all aspirational, you may not hit any goal. Leadership must make deliberate choices about how their company should think about their OKR bias.

My current personal leaning is to bias toward committed OKRs for nearly everything, with one or two aspirational OKRs for things that are truly game-changing.

8. Cascade OKRs up, down, and laterally

High functioning organizations speak the language of OKRs. When you depend on another team to hit your goal, you should expect to see that dependency in the other team's OKRs. If you don't, your likelihood of failure has increased significantly.

Similarly, company Key Results often become Objectives for organizations within the company. Organization Key Results become Objectives for individual teams.

OKRs can also cascade upward. For example, a team could discover that they have no way of hitting their goals, given their level of staffing. They refuse to take on the OKR, which in turn changes the OKRs above them, and so on.

This cascade of OKRs through the organization is a critical step of aligning the entire company. While it may sound chaotic in theory, the company or organization should quiesce in a week or two.

9. Personal OKRs are powerful. Use them to accelerate your career

Company and Team OKRs drive organizational alignment and focus. You can create your personal OKRs too. While some will inevitably be congruent with your team's OKRs, there could be others that are about making progress in your career or growing as an individual. Personal OKRs clarify your priorities with your manager and your peers. They hold you accountable for accomplishing what you set out to do.

I think of Personal OKRs as writing my self-review, six months ahead of time. I have been creating personal OKRs, putting them into a document, and sharing them with my manager for about six years. They have helped me be clear with my manager about what constitutes success and failure, what is paramount in their minds, and keeps me accountable for making progress. I strongly recommend doing Personal OKRs and taking charge of your career.

When writing personal OKRs, you must focus on outcomes, not activities. This trap is avoided at the team and company level by making all KRs measurable. However, when looking at personal OKRs, we start using language like "Participate in interviewing" or "Be a part of X team." Consider rephrasing into outcomes instead, such as "Hire 3 engineers by the end of quarter" or "Conduct an average of 1 interview per week."

10. Prefer a small number of tightly focused OKRs to a long list

OKRs should add focus. A large number of OKRs, whether individual or team, imply a lack of focus. When push comes to shove, which OKR is going to drop? Don't bother adding OKR priorities β€” that is simply a bandaid over the root cause: you have too many OKRs.

OKRs should also represent commitment. Picking one OKR means that we cannot do something else. In your OKR discussions, you could include a list of things you chose not to do to illustrate an effort to add focus.

Bonus: Effective OKR usage takes years

If you're getting started with OKRs, know that your initial implementation will suck. You may have too many, or they may not be measurable, chaos may reign as OKRs cascade across the organization. Know that there is no pinnacle of OKR usage β€” Google struggles with them as much as a series-A startup. Their struggles are different, and they've had more than two decades to get it right. But keep at it and make your version of OKRs better over time. Be patient.

Reference

This note is a combination of practical experience from a decade of practicing OKRs and Goals at Google and Facebook, and reading through three books:

  1. The Practice Of Management β€” Drucker

  2. High Output Management β€” Grove

  3. Measure What Matters β€” Doerr

Thanks

Many thanks to Leo Shklovski, Lily Zhang, Jules Walter, DeVaris Brown, and Ethan Bloch for reviewing early drafts of this work and providing invaluable feedback.

Loading more posts…