Knock Down Silos

New in Slab: Understand Every Post’s History and Activity

Jason Chen — Wed, 16 Jul 2025 20:00:00 GMT

We’ve rolled out a major update to how you see and review updates in Slab posts — making it easier than ever to follow what’s new, what’s been said, and what needs your attention.

🕰️ Redesigned Post History

Post history just got a major glow-up. It’s not only more powerful — it’s also easier and more pleasant to use.

Now, comments appear directly in context with the post content, so you can see exactly what changed and what was said about it. You’ll also notice visual cues for new threads, replies, and resolved discussions, making it effortless to track conversations over time.

To top it off, links to specific headers and comments now work right from history, so jumping to the right section is quick and seamless. Whether you're catching up on changes or reviewing feedback, the new Post History helps you do it faster, clearer, and with more confidence.

📌 New: Post Activity Timeline

No more digging through posts to understand what’s changed or what needs your attention — now, it’s all right there.

The new Post Activity timeline gives you a clear, chronological view of everything that’s happened: edits, comments, publishing, verification, and more. You’ll even see the last time you viewed the post, so you can quickly spot what’s new since then.

A dedicated Unresolved comments section ensures nothing slips through the cracks — no more scrolling or hunting for threads. And with colored indicators for recent edits and open comments, you’ll always know which posts need a closer look.

🐭 Small but Mighty

Topbar Menu Reorganization - We’ve cleaned up the topbar menus to reduce clutter and improve navigation — everything is easier to find and more consistent.
Streamlined Topic Icons - The blue topic icon and privacy indicator have been merged, giving more space for post titles and topic names, plus improved sidebar menu organization.
More Secure Images & Attachments - In the coming weeks, we’re adding token-based protection for links to uploaded images and attachments. This adds an extra layer of security without impacting day-to-day browsing in Slab.

New in Slab: Image carousels and collapsible lists

Jason Chen — Thu, 22 May 2025 20:00:00 GMT

Tell more and show more with image carousels

Images in Slab posts just got a major upgrade — you can now group them into beautiful, interactive carousels! Whether you’re showcasing product screenshots, sharing design explorations, or telling a visual story, carousels make it easier than ever to present images in a clean, scrollable format.

Creating one is simple: just add multiple images at once to start a new carousel, or drag additional images into an existing set to convert it instantly. It’s a more dynamic way to share visuals — and a big step toward making your posts more engaging and expressive.

New in Slab: Sidebar sections, public draft editing, native PDF embeds, and more

Jason Chen — Thu, 17 Apr 2025 20:00:00 GMT

Sidebar Sections brings greater customization and personalization to your own and your team's sidebar. You're already familiar with sections through Favorites, but now you can create multiple sections, each with their own customizable color and icon. The previous "Favorites" feature is now just an automatically created personal section when you join Slab. All existing Favorites have been migrated to Sections and are available for all teams.

Admins can also create and manage team sections that are visible and useable across your team. For larger organizations where All Topics or My Topics can become crowded, team sections allow for department or function-specific sections instead. Changes to team sections affect everyone, but users can individually choose which sections to include in their sidebar and what order. Learn all about Sidebar Sections here.

Public draft editing with third parties

Collaborating on Slab content with third parties has never been easier with public draft sharing, now generally available for all teams. When you make a draft publicly accessible, you can now grant editor access to those you share the URL with. They can enjoy Slab's editing capabilities, including real-time editing and comments, all without a Slab account. Similarly, you can restrict an internal draft to be viewable, but not editable, by teammates you share with.

Natively embed PDFs into posts

PDFs can now be natively embedded into a Slab post without the need for integrations. The PDF preview can be customized in the same way as any other embed, such as the width and height. Of course, you can always download the PDF file directly to view externally or with a desktop application.

Everyday improvements to look, feel, and behavior

Recently, we've focused on improving everyday usage and experiences, improving performance and stability, and making our UX more consistent and UI more pleasant, particularly in our editor. Here's a non-exhaustive list of some of these changes!

Improved post layout for editor content and comments across all screen sizes
Improved editor slash command and toolbar lists of options
Reduced conflicting interactions between the table of contents and wide embeds and images
Improved hover timings for post previews and tooltips to reduce inadvertant displays
Added toolbar for hints to quickly change between types and colors
Expanded syntax highlighting support for code snippets
Improved equation rendering support
Faster loading performance of very large posts
Removed links to user profile in several small UIs to prevent accidental navigation
Improved scrolling support to linked comments
Reduced inadvertant scrolling while editing and commenting
Improved look and feel of series in post footers
More consistent look, feel, and behavior for modals across the product
Faster loading performance across the product

Announcing Quill 2.0

Zihua Li — Tue, 16 Apr 2024 20:00:00 GMT

We are thrilled to announce the release of Quill 2.0 — a significant milestone in moving forward web editing experiences for millions of users.

Since the initial 1.0 release, Quill has seen numerous success stories from fast-growing startups, well-known brands, and established Fortune 500 companies, who have incorporated Quill into some of the most important and core parts of their user-facing products.

As we build upon this legacy, this new 2.0 version is mindful of the importance of a seamless upgrade for our developer community while also advancing Quill's functionality, reliability, and developer experience.

What's New

Our GitHub repository has grown from 23k stars at the last release of Quill 1.3.7 to over 38k stars today with the official release of Quill 2.0. Here are a few of the biggest changes we've made during this journey. At the same time, if you can’t wait to upgrade your project, head to our 2.0 migration guide for full details.

Official TypeScript Declaration

Quill's source has fully transitioned to TypeScript, enjoying all of its benefits in earlier error detection, improved maintainability, and better tooling support. The result is a more robust codebase for both Quill and our developer community.

Previously, developers would have to install @types/quill as a separate package to get TypeScript definitions. This may not have been as specific or sometimes even match Quill's actual types since our wider community maintains it. Updates also did not synchronize with the core Quill package.

With Quill 2.0, this hassle and opportunity for errors is gone, and you'll get types straight from the source. To upgrade, simply remove the @types/quill package from your project, and TypeScript will automatically pick the declarations directly from Quill.

Multiple Registries

As Quill's prevalence and use grew, we started seeing use cases more often to where it was sometimes on the same page.

For example, a blogging product might use Quill to power the full-featured editing surface for the post itself, complete with headings, images, and code blocks, while on the same page, Quill is also powering the comment input with just bold, italic, and link formats supported.

Quill 2.0's new registry feature enables this use case, allowing multiple editors with their own formatting configurations to coexist on the same page without any conflicts. Learn more about registries in our documentation.

Auto Scrolling Container Detection

Previously, developers needed to specify the editor's scrolling container when creating a Quill instance so the user's cursor or selection could be scrolled into view if needed.

But we found that this configuration was often overlooked or confusing, so this scrolling container was either incorrectly specified or not at all. Additionally, it's not always easy in larger applications and codebases to track down the correct scrolling container for a reusable editor component that might appear in different contexts.

In 2.0, Quill will automatically find the right scrolling container, so you no longer have to. This makes using Quill for longer-form text easier and enables more complex interactions, such as nested scrolling containers and horizontal scrolling, for free.

Using InputEvent

One of Quill's key advantages is an internally managed document model that doesn't rely on the DOM as the single source of truth. This offers a closer mapping to developers' mental models for rich text state and enables simpler APIs for text editing, ultimately resulting in more numerous and more powerful uses.

Quill does this by listening to DOM changes and normalizing them back into its internal document model. However, browsers can inconsistently or incorrectly handle users' actions, causing the wrong DOM changes to be generated. For example, when a user selects text in red and replaces it by typing, browsers sometimes replace it with a font element that includes the red color in its style attribute, even though the editor uses span elements to represent colors.

In Quill 2.0, we use a modern and now common browser feature to progress forward with InputEvent. Users' actions are now captured first to update the internal document model before syncing the resulting changes to the DOM.

This approach provides a more consistent and reliable editing experience, particularly with complex content and formats. This capability currently focuses on the most problematic source in text replacement interactions, with wider use planned for the future.

Behind Quill 2.0

Behind the scenes of Quill 2.0's exciting new features is also a natural evolution in its development and support.

An important and long-standing problem for the open-source ecosystem is sustainability. While this unfortunately remains an open problem for the wider industry, Quill is supported by a profitable company where the key people are the same and the incentives are aligned.

Jason Chen, the original creator of Quill, is also the founder and CEO of Slab, building the best knowledge management solution for teams. I myself am the Frontend Engineering Lead at Slab and contributed the major updates and enhancements being released today in Quill 2.0.

For Slab, content creation and collaboration are pillars of our product, and we strive to be the best in both capability and ease of use, values with roots from Quill. Our post editor continues pushing Quill's limits, while our more limited formatting is necessary for our comment input and search bar. In part, lessons from these use cases motivated the foundational and expanded functionality in 2.0.

We continue to develop and support Quill's underlying model in Parchment and its data format in Delta. Slab has further open-sourced our backend Elixir implementation of Delta and other libraries for the Elixir ecosystem. We are organizing Quill, Parchment, and Delta under Slab's GitHub account to better manage and reinforce our commitment to open-source.

What's Next

We welcome your contribution and feedback as we continue to enhance Quill beyond 2.0. We hope you'll be part of our journey in extending and maintaining the most powerful and user-friendly rich text editor on the web.

Thank you for being part of our Quill community and please star the project on GitHub 🙏

Slab's 2023 Wrapped

Jason Chen — Fri, 12 Jan 2024 20:00:00 GMT

Learn about all of our major updates and improvements for Slab from 2023, and preview what’s coming next in 2024.

AI Autofix and AI Predict - Our first AI features, both aimed to help you write better and faster
Better post history - Redesigned to make changes stand out more clearly, along with quality-of-life upgrades
Multiple post verifiers - You can now assign secondary verifiers to post verification
Flowcharts and equations - Code blocks with Mermaid or KaTeX syntax gain a preview mode
Consolidated post sharing - Posts can now be shared with groups, along with a consolidated overview of access to that post
Large comments and annotations - Use cases for "commentary" are separated into distinct features, with dedicated UI and UX
Post cover and Unsplash - Posts can now feature an image cover, along with Unsplash integration to help pick the right now
Upgraded templates - Templates are now a special type of post, gaining all of their collaboration and organization features
100+ template library - We've greatly expanded our template library, with the same high-quality bar, to help you jumpstart yours
More search filters - Explicit filtering is expanded with filters by date fields, such as edit or publish, or by what it mentions, such as a user or another post
Improved search - Several search improvements have come together to make more available for search, their use in rankings, and results
What's next in 2024? - Our biggest AI feature yet, as well as new capabilities for discovery, organization, and permissions

AI Autofix

Slab automatically fixes errors as you type, including missing, mixed, or extra characters, freeing you to focus on forward progress with your writing. This works for English words and your company and colleagues' names, so you never misspell or incorrectly case them again.

AI Autofix is available today to all teams — head to your user settings to turn it on.

Learn more about AI Autofix

AI Predict

Slab's AI Predict helps express your ideas, offering blazing-fast suggestions for the best next words to put to paper, using context around your writing. After turning on AI Predict in your user settings, suggestions will appear in posts as you type. Hit "tab" to easily accept, and the next suggestion will likely already be ready!

AI Predict is available for teams on our Startup plan or higher.

Learn more about AI Predict

Compare and cycle through post history

Post history now both looks better and works better, making it easy for your team to review and understand changes. All of Slab's content and formatting options are now clearly shown as additions or removals, alongside convenient new controls to cycle through those changes.

Reviewing changes when re-verifying a post gets these same upgrades, making it easy to check through all of the edits made since the last time the post was verified.

Learn more about Post history

Multiple post verifiers

Verifying posts no longer needs to be a solo endeavor — add secondary verifiers to spread the responsibility. There is still one primary verifier to designate who is ultimately responsible, and that person will receive one final notification if and when no one else has verified.

Edit any existing post verification to add secondary verifiers, or take advantage of more verifiers in a new post verification.

Learn more about Post verification

Syntax highlighting, flowcharts, and equations

Code blocks gained new capabilities in rendering flowcharts and equations, along with improved syntax highlighting for React and TypeScript, and across the board in dark mode.

Just set the code block's language to Mermaid or KaTeX, and a Preview option will be available in the toolbar, making it easy to draft and collaborate with flowcharts and equations with your team.

Learn more about Code blocks, Flowcharts, and Equations

Sharing posts got a lot easier and more useful. Posts can now be shared directly with users, groups, and topics from the same Share button, where other sharing and access features for that post are also consolidated. Their interactions and effects are summarized, making it easy to review who can access or edit that post.

Learn more about Post sharing

Comments, reactions, and annotations

Comments and reactions went through their own reviews and refinements. Both are now their own separate concepts, with their own distinct look, feel, and interactions. Annotations were also introduced to the mix, allowing lightweight "commentary" that is not meant to be resolved.

Large comments are now visible in a more generous view, allowing for those serious discussions on complex concepts with teammates. Comments from users without edit access to the post are also less visible, keeping your team's important posts looking neat and tidy.

Learn more about Comments and Annotations

Post cover and Unsplash

Speaking of important posts, up-level their visuals with post covers. Choose from our library of high-quality images, upload your own, or pick from endless options from Unsplash.

Learn more about Post covers

Template collaboration and organization

Post templates are completely rebuilt, gaining all the collaboration, organization, and review capabilities that regular posts have. At the same time, they are much more integrated throughout Slab, with convenient access and selection whenever you want to create a new post — without starting from scratch.

Learn more about Post templates

100+ templates from industry leaders

Not every team has a template handy for every occasion. That's why we've vastly expanded our template library with 100+ high-quality examples from leaders in the industry.

Our Library is always available on our website, but if your team is starting from scratch, the best ones will also be available and immediately usable within Slab.

Browse our Template Library

One of our most popular search features got even more options — now being able to filter results based on date attributes such as publication, edit, archival, or verification. You can also filter search results based on who or what needs to be mentioned or browse the list directly from any post's insights panel.

Learn more about Search filters and Post backlinks

Search indexing, relevance, and results

Even without using explicit filters, we've made improvements to search on all fronts, including:

Indexing more content faster, such as when posts are reorganized
Better ranking signals through more formatting contexts and semantics
Presenting more informative results with better highlighting
And analytics around search performance — both speed and relevance — for continual experimentation, iteration, and improvement

What's next in 2024?

We're gearing up for an even more exciting 2024 — here's a sneak peek at what's coming in the coming months.

AI Ask

Our biggest AI feature yet will transform how you can access and interact with your team's knowledge through an intelligent and tireless AI assistant. Combined with our other content and organization capabilities, you might never have to bother a coworker again.

AI Ask will be available to teams on our Business plan or higher, with Enterprise teams enjoying the most performant and advanced AI models.

We're bringing much more customization and personalization to your and your team's sidebar with sidebar sections. A section behaves much like Favorites today — you can add individual posts and topics in any order, either for yourself as a personal section or shared across the team.

Organization and permissions

We're not stopping at just sections when it comes to organizing your team's knowledge. Several changes and capabilities are being introduced to address current limitations and shortcomings.

Here's an overview of a few upcoming:

Show and sort defaults - Topics will gain more control over what types of posts they show and in what order.
Detached topics - Topics themselves will gain an option to be shown less prominently throughout Slab, a particularly powerful combination with Sections.
Permissions - We're overhauling the underlying models for accessing and modifying posts and topics. This ultimately enables more granular control to fit more use cases while still staying easy to use and understand.

Product updates and education

Lastly, the way we share product information is getting an overhaul, including updates, guides, and references, along with hints and touchpoints throughout the product.

There's never been a better time to start investing in your team's shared knowledge. Stay tuned!

2023 Product Changelog

Jason Chen — Tue, 02 Jan 2024 20:00:00 GMT

December 30

That's a wrap! Read Slab's 2023 Wrapped

December 23

Fix bug where links or mentions to heading would not scroll correctly
Improve warning and error handling for unsupported browsers
Fix mention navigation bugs within an iframe
Fix user mention not showing avatar within an iframe
Fix scrolling bug when using shortcuts within an embedded Google Sheet
Improve error handling and usability for embedded Slab posts by separating into more distinct categories, explanation, and options to correct

December 9

Fix navigation bugs in public posts
Fix bug where copied URL from post heading did not use the correct host
Add word and character count to post's "View insights" panel
Fix bug where updating pinned posts from Content Map would not save
Remove thanks button from posts by default
Minimize scrolling disruption from embedded Google Sheets loading
Fix bug where a template in a series would show the series icon instead of the template icon
Fix bug copying and pasting an embedded Slab post
Fix several markdown shortcut interactions within a code block
Remove editing actions from menu items in uneditable contexts, such as public posts

November 25

Limit verifications to not be exceptionally far in the future
Fix CMD+Arrow shortcuts in headers in Firefox
Fix IME not showing when at the beginning of lists in Safari
Add support for embedding YouTube shorts
Fix UI bug where option to delete reactions or annotations may be blocked by another comment above them
Improve look and feel for embedded Slab posts, Quip, Zendesk, and Google Docs
Fix bug where long team name may hide notification bell

November 18

Copying the embed code for a Slab post and pasting into another Slab post now correctly recognizes and embeds
Add several /command shortcuts for flowcharts and equations, including /flowchart, /mermaid, /equation, and /katex
Using a template or duplicating a post with annotations now also copies the new post
Inserting a blank embed or table now attributes the correct author
Using arrow keys now correctly hides the toolbar within code blocks
Triple-clicking inside a table now correctly highlights and shows the toolbar
Fix bug where images in docx file were not correctly imported
Fix bug where inviting a user did not correctly apply invitation configurations if user accepts invite with SSO
Improve reliability of uploading multiple images or file attachments

November 4

Fix bug where exported markdown would not include multiple nested inline formats in some cases
Mass importing zip files now supports nested zip files
Add support for additional Airtable URL format

October 28

Fix bug where toolbar may show edit actions in uneditable contexts, such as public posts
Stronger enforcement for API access
Support additional image filetypes in posts including WebP, BMP, HEIC, and more
Fix authentication bugs for Slab posts embedded on external websites

October 14

Add a navigation bar to quickly cycle through changes in the post history view
Add attribution to each change in the post history view
Improve real-time collaborator highlighting for all formats in posts

September 30

Add filter dropdown to search results page to more easily use search filters
Fix bug where updating topics may not update breadcrumbs used in indexed search results
Support additional clouds for Microsoft integration, including US Government L4 and L5 (DoD)
Improve performance when resyncing GitHub repos

September 16

Improved editor scrolling experience when embeds are used
Fix bug where admins cannot promote themselves to a topic owner when their membership is tied to a group
Fix bug where users cannot leave topics when they have no editing permissions
Fix print and PDF export code block overflow issue
Fix Table of Contents text overflow issue

September 2

Improved Asana mention to retain project info from the link
Improved full-screen image viewing experience
Improved template icon usage for better consistency

August 26

Improved reliability of GitHub and GitLab sync
Fix bug where template modal cannot be closed
Fix bug where the invitation modal incorrectly shows the invitee will not have access to certain posts

August 19

Improve support for larger import files
Fix bug where guests could publish a post without any topics

August 12

Add support for embedding new Dropbox links
Add support for embedding YouTube playlist links
Recategorize Team Settings for easier navigation
Improve Billing settings view for better usability and reliability
Improve Admin Insights styling
Fix header formatting's undo support
Fix bug where the annotation hover menu is hard to reach
Fix bug where converting a mention in a table cell into an embed ends up removing the mention
Fix bug where tall embeds may not be displayed correctly in the print version
Fix bug where IME cannot be used in tables or code blocks

August 5

Truncate long Slack messages in search results

July 29

Add animations for expanding and collapsing comments
Greatly improve history diff view of several content and formatting scenarios

July 22

Improve and consolidate several interactions between reactions, comments, and annotations
Add support for embedding Rows
Fix bug where last line of search result might show incorrect line formatting

July 15

Update mention UI to avoid shifting upon loading
Fix bug where some post histories would incorrectly show pricing gate for older revisions
Fix bug where new comment would sometimes not appear without refreshing

July 8

Redesigned post reactions for greater usability and aesthetics
Improve search results truncation to show more preview content when possible
Add hovercard preview for Guru search results
Greatly improve initial loading performance for all posts

July 1

Add easier option to transfer post ownership to Slab Bot when deactivating another user
Several improvements to look and feel of admin insights page

June 24

Add date facets in search to filter by published, edit, verification, and archive date
Inserting three blank lines in a code block no longer exits the code block. Previously this was one of few ways to exit the block if at the end of the post, but we've since added support for just clicking below the code block
Fix bug where notification bell counter would show even if there were no unread notifications
Fix bug where dropdowns showing posts would show a verified badge even if that verification has expired

June 17

Fix triple-clicking not working in code blocks
Markdown shortcuts are disabled in code blocks
Fix bug where Mermaid would sometimes render with a lot of extra whitespace

June 10

Offsite!

June 3

Post details sidebar now shows publish date if published instead of always showing creation date
Post backlinks in post details sidebar will show archived posts and deactivated users last
Fix bug where archived or verified post filters did not match their count label
Remove private and secret topics as options in the admin insights filter since the functionality was never allowed

May 27

Fix bug where post hovercard arrow is incorrectly positioned
Creating a secret or private subtopic will no longer automatically add parent topic members as members to the new subtopic
Fix notification bell counter sometimes showing incorrect count
Duplicating post will also copy the post cover image
Fix bug where importing post with many large images would time out
Comment visibility rules are updated so that comments of users who cannot edit a post are only visible to editors and that user. Editors' comments' are still visible to everyone. This should greatly reduce clutter due to comments for important posts.

May 20

Improve sharing dropdown by splitting into sections of users, groups, and invites
Fix bug where clearing the provision in an invitation would reset the role
Fix bug where the total count of posts in a topic was incorrectly summed
Exported markdown now supports image captions
Fix bug where importing markdown with code blocks inserted extra lines after code blocks
Greatly improve text matching used in jump to search and mention autocomplete

May 13

Improve initial loading of posts with many embeds and/or mentions

May 6

Exported markdown is no longer HTML-escaped
Improve detecting and importing Mermaid and Katex code blocks
Add group creation request for regular users
Add admin setting to allow regular users to create groups without requesting
Fix bug where very large posts were not searchable, posts of any size are now indexed

April 29

My Topics now also includes a topic creation shortcut that is present in All Topics
Exact match search queries will work even if match is now at the end of a large post
Improve UI/UX of topic breadcrumbs for public posts for logged out users

April 22

Improve usability of lists of posts within topics
Several Google Calendar settings are now preserved when embedding into Slab including colors, navigation, and title
Admin actions are now accompanied by a visual label, ex making yourself the owner of a topic
Using admin privileges to join a topic or group will now join as an owner instead of regular member by default
History diffs will no longer show fragmentation when text if overwritten by a paste

April 15

Fix bug where some guests could not accept invitation if SSO was required for regular users
Clicking below a table or embed when it is at the end of a post will now insert a newline after

April 8

Fix bug where links to comment threads would not scroll to comment position
Improve post editing performance of large posts
Improve post preview loading performance
Automatically trim leading and trailing whitespace in names and titles

March 25

Add unread count to notification bell icon
Improve table performance when modifying many rows/columns of large tables

March 18

Improve copy/paste performance of large tables
Support double-clicking on Mermaid charts to full-screen
History view of Mermaid and KaTeX will show code instead of rendering
Fix bug where exiting code block prompt will show in read mode
Fix bug where topic to organize under will not show in edit modal

March 11

Improve loading performance of very large tables
Fix bug that prevented uploading files 100MB+ attachments
Improve loading performance of many common views
Fix markdown import but when ## is present as a regular character on a heading line

March 4

Revision histories for mermaid and math will now show underlying code instead of preview
Add "Back home" to settings page to make it easier to exit
Fix add comment keyboard shortcut not focusing comment textbox in a table
Fix bug where comment underline does not show in a table when creating a new comment
Editor no longer shifts when scrollbar gutter being added or removed
Improve typing performance on large posts, especially when Grammarly is enabled
Fix bug where mention to same post with heading does not scroll when clicked
Update search copy to emphasize jump to functionality
Fix bug where pasting into search bar would overwrite existing text
Add post status bar (which shows archive, draft, and other states) to post hovercards

February 25

Fix bug where comment or annotation would appear in the wrong vertical position when formatting existed in the corresponding text
Fix bug where admins on the free plan on teams with guests might see inaccurate upgrade seat count estimations
Fix multiple bugs related to table of contents showing inaccurate active headings

February 18

Add and improve active and hover states and animations across post editor
Fix bug where custom upload limits would not be permitted

February 11

Separate navigation sections in search dropdown for better usability
Search result within tables, code, and image captions are now both formatted and highlighted in search results
Posts can now be shared directly with groups

February 4

Fix bug where selected posts cannot be moved when reorganizing in Content Map
Improve search results truncation to always show highlighted text and maximizing amount of preview shown
Fix bug where long search query would overlap info icon
Fix bug where multiline search query would only show first line

January 28

Fix bug where the desktop application would prompt unnecessarily for login
Fix text alignment bug on post verification notification emails
Fix bug where Todist could not be integrated or mentioned for existing integrations
Improve user experience when deciding to scroll to an image not fully in view
Add and improve animation when showing toolbars and modals
Improve user experience around active annotations and comments and corresponding text

January 21

Miro embeds include more minimal UI controls within posts
Fix bug where comment text may render overlapping each other in Safari
Updating password now forces logout in all active sessions
Fix bug where upgrading a guest to a standard user was not allowed when at exactly 10 users on the free plan
Editing groups' name, banner, and description are also in-place rather than in a modal, similar to topics
Fix bug where editor for GitHub synced post may be incorrectly attributed in notifications

January 14

Add additional post icons to distinguish its draft, archived, and series states and remove badge
Refresh and consolidate several icons throughout the product
Fix bug syncing Okta group membership would remove ownership status when already an owner on a Slab group
Remove markdown shortcuts from comments for formats not allowed in comments

January 7

Editing topics' name, banner, and description are in-place rather than in a modal
Fix highlighting Asana search results when international characters are included
Improve mention picker's results ranking
Add and improve animations for hover and active states in sidebar
Add admin setting to forbid non-admins from adding top level topics
Move embedding errors into embed frame instead of transient toast

Shopify's highly aligned, loosely coupled

Thu, 09 Nov 2023 20:00:00 GMT

Since its humble beginnings as an online snowboard shop in 2006, Shopify has grown to be the world’s biggest e-commerce platform with over 10,000 employees globally. Editor in Chief, Courtney Symons is keenly aware of the role writing has played in keeping the company on the right path as it grows. “A mantra that’s often repeated here is that we’re highly aligned, but loosely coupled. Meaning, we all know the direction we’re going in, but there’s enough trust so that we can take our own paths to get there. Good, clear writing helps to build the alignment that helps us reach our business goals.”

Growing writing culture over the years

While Shopify’s writing culture is strong today, it wasn’t always. “As we expanded, first beyond our Ottawa office and then beyond Canada, we realized that the quickest, easiest way to communicate was through writing,” says Courtney.

In 2016, Shopify ran a company-wide, month-long work-from-home experiment to test how well they could communicate outside of the four walls of an office. This experiment laid the foundation for Shopify’s asynchronous collaboration today. “We found that working remotely meant having to write down and figure out how to deliver status updates in the best way,” says Courtney. “Learning that has served us well in setting ourselves up to be the remote-first company we are today.”

Welcome to Shopify, where everyone’s a writer

New hires are introduced to Shopify's writing culture on day one with an internal guide and a course, Improve Your Everyday Writing. “The course is built around the ethos that many people may not think of themselves as writers, but we all are,” says Courtney. Everyone can become a better communicator by sharpening their writing skills. The focus isn't on improving spelling and grammar–the writing course and guidelines emphasize organization and clarity of thought. A couple of examples:

A ban on acronyms, since they assume a subject familiarity that may not exist for the reader. The ban, ironically, was announced in a company-wide memo titled “RIP Acronyms”.
Format Slack messages with bullet points, line breaks, and emphasis where it makes sense to avoid the “wall of text”

“Improving people’s confidence in writing is foundational. It helps take away a lot of the pressure that people feel.”

These writing resources send a clear message to new hires: writing is a huge part of Shopify’s culture, and each employee has access to the tools that will help them leverage writing in a way that helps them do their best work.

How writing keeps projects moving

In trying to quantify Shopify’s writing culture, it’s easier to think of the question in terms of its negative space; how much of Shopify’s business isn’t influenced by writing? The answer: not much.

Look at the “vault”—the company’s internal wiki—to see proof of this. The vault is where all internal documentation for any project, current or past, is stored. “Everything is saved in the vault, from conversation transcripts on important decisions, to project boards, to briefs,” says Courtney. “The idea is that anyone can find what they need here.” Having a record of the company’s projects, learnings, and decisions is essential.

“This is a product-oriented company, so sharing the product knowledge we have is baked into the company culture.”

While the vault helps contextualize and justify decision-making, Shopify relies on synchronous communication to keep things moving. Much of the company’s project updates are communicated through Slack. They have dedicated channels for project updates that people can subscribe to. “There’s a push and pull. You have to follow the projects you want, but once you do, we have a number of levers in place to ensure that everyone’s up to date,” says Courtney.

It’s essential that this information is made widely available, both synchronously and asynchronously. “With so many different teams working across so many different products, sharing project updates ensures that we’re not creating redundancies or interdependencies that are unclear,” says Courtney.

Rapid and widespread growth has also driven the need for well-documented project plans. “Having a well-written brief about what you’re doing, why you’re doing it, and who needs to be involved has only gotten more important over time,” says Courtney.

“One missed or misunderstood word can derail productivity, and we’ve realized we can’t waste time by not clearly communicating requirements from the start.”

Shopify employees can quickly get up to speed on anything. “We’ve gotten to a place where when anyone asks, ‘What do you mean by that?’ more often than not, there’s a document they can read that will give them that understanding,” says Courtney.

Documenting the past to prepare for the future

One thing that’s obvious is that keeping projects, decisions, and outcomes well-documented will always be essential to keeping the company moving forward.

This goes beyond documenting the company’s successes. “Our CEO likes to say that failure is the successful discovery of something that did not work,” says Courtney. “Being able to find a product in the vault and read about why we shut it down, what did work, and what didn’t, is a quick way to level up and not make the same mistakes twice.”

The Eisenhower Matrix: Prioritize Your Time on What Matters Most

RC Victorino — Sat, 23 Sep 2023 20:00:00 GMT

Being busy is not the same as being productive. You could spend hours putting out fires and, at the end of the day, be no closer to reaching your long-term goals. This is a costly and emotionally draining way to spend your time.

The issue is poor prioritization. Humans prioritize time-sensitive tasks over any other task, regardless of the long-term payoffs. When you focus too much time on urgent tasks, you neglect the important ones on your to-do list.

It’s easy to get stuck in this reactionary cycle where you constantly put out fires, robbing yourself of the opportunity to work toward your goals. By distinguishing between urgent and important tasks, you can focus more time and energy on the things that matter most. The Eisenhower Matrix helps you make that distinction and improve your time management.

What is the Eisenhower Matrix

“I have two kinds of problems: the urgent and the important. The urgent are not important, and the important are never urgent.” — Dwight D. Eisenhower

The Eisenhower Matrix is a simple decision-making tool that helps you make the distinction between tasks that are important, not important, urgent, and not urgent. It splits tasks into four boxes that prioritize which tasks you should focus on first and which you should delegate or delete.

Also known as the Urgent-Important Matrix, it was popularized by Stephen Covey in his best-selling book, The 7 Habits of Highly Effective People. It was named after Dwight D. Eisenhower, the 34th President of the United States, known for his high output and organization. President Eisenhower is said to have arranged his obligations so that only the important and urgent matters came across his desk.

The Eisenhower Matrix uses this same principle to sort out the less urgent and important tasks on your list, which you can then delegate or not do at all.

The Eisenhower Matrix can help if you:

Run around putting out fires all day, rather than focusing on tasks you want to complete
Are busy, but feel like your work has little impact
Aren’t making progress on long-term goals
Suffer from procrastination
Struggle to say “no” when asked to do something
Have a hard time delegating tasks

The difference between urgent and important tasks

The core principle behind the Eisenhower Matrix is the distinction between important and urgent tasks.

Urgent tasks are time-sensitive and demand your attention. They’re tasks you feel obligated to address. Focusing on urgent tasks puts you in a reactive mindset, which can make you feel defensive, rushed, and narrowly focused.

Important tasks contribute to your long-term mission, values, and goals. They may not yield immediate results (making them easy to neglect). Sometimes important tasks are also urgent — but usually not. Focusing on important tasks puts you in a responsive mindset, which can make you feel calm, rational, and open to new ideas.

Note: If you put off important tasks long enough, they can become urgent.

People tend to believe that all urgent tasks are also important — when frequently, they are not. This misrepresentation may have to do with our preference for focusing on short-term problems and solutions.

But happiness and fulfillment come when we focus on the long-term, not the short-term and urgent.

The quadrants of the Eisenhower Matrix

The Eisenhower Matrix is divided into four parts:

Quadrant 1: Important and urgent / Do
Quadrant 2: Important but not urgent / Schedule
Quadrant 3: Urgent but not important / Delegate
Quadrant 4: Not important, not urgent / Delete

1. Urgent and important tasks

Urgent and important tasks are crises with due dates — such as a critical bug fix for your SaaS tool.

Do these tasks first. They require your immediate attention.

2. Not urgent but important tasks

Not urgent but important tasks help you achieve your goal — and don’t have a pressing deadline.

Schedule these tasks to do later.

Productive and successful people spend most of their time here. For them, this quadrant yields the most satisfaction. Covey called it the Quadrant of Quality.

Most people, however, don’t spend enough time here because they don’t know what’s important to them or because they’re interrupted by urgent tasks.

3. Urgent and not important tasks

Tasks that fall in this quadrant are nearly always interruptions from your preferred course. These are tasks where you help others meet their goals.

Delegate these tasks to others.

Most people spend the majority of their time in this quadrant. They believe they’re working on urgent tasks that are important to them when, in reality, completing these tasks does nothing to inch them closer to their long-term goals.

4. Not urgent and not important tasks

These tasks aren’t pressing, nor do they help you reach your long-term goals. They’re simply distractions from what matters most.

Delete these tasks from your list.

Prioritizing your tasks

First, track your time for one week to assess where you spend your time in the matrix. You can use a dedicated task management tool or simply track your time in 30-minute increments in a spreadsheet.

After one week, organize your completed tasks into the appropriate quadrant using these criteria:

Was this urgent for me?
Was this important to me?

“Me” is the integral word here — you’re organizing these tasks based on your goals, not someone else’s.

Now that your tasks are sorted, take note of the quadrant with the most tasks. If most of your tasks live inside Quadrant 2, congratulations! You have a good grasp of what matters most in your life.

If you’re a mere mortal like most of us, though, here’s how you can rebalance your matrix.

Quadrant 1

To reduce the number of Quadrant 1 tasks you have, invest time in planning to anticipate and prevent problems.

What changes can you make to avoid unexpected problems from arising? This may include collaborating with colleagues, clients, or supervisors to restructure your workflow.

If one person or entity is the source of Quadrant 1 tasks, you may need to find a systemic solution to prevent important and urgent issues from constantly arising.

Quadrant 3

To reduce Quadrant 3 tasks, create a strategy to delegate, eliminate, or limit the amount of time you spend on these tasks.

For example, batch these tasks together to complete in one sitting, or share how much time you spend on busywork with your supervisor. If you’re a manager, let your team know you’ll be delegating tasks to them so you can reprioritize your schedule.

Quadrant 4

If most of your time is spent in Quadrant 4, you likely feel stressed and unfulfilled. Continue to track your time to identify which tasks consume the most time. Then, develop a plan to delete or limit them. Seek advice from a colleague or supervisor — their perspective might make it easier to identify which tasks you can delegate or delete.

Investing time in making time

Repeat the above process every week for a month. Compare each week’s results to see if your efforts result in more time spent in Quadrant 2: the Quadrant of Quality.

Continue using the Eisenhower Matrix to organize your day even as your time and tasks shift towards Quadrant 2. This will often include abstract tasks like strategy development and relationship building. These tasks don’t have deadlines, making them easy to put aside, but they are directly aligned with your long-term goals, values, and happiness.

“The key is not to prioritize what’s on your schedule, but to schedule your priorities.” — Stephen Covey

Most people struggle to find time in their busy schedules to tackle those important but not urgent tasks. Integrating the Eisenhower Matrix into your daily workflow will help you schedule your priorities based on what’s most important to you.

How to Write a 30-60-90 Day Plan to Onboard New Hires to Success

Tue, 05 Sep 2023 20:00:00 GMT

The earliest days of a new employee's tenure, when potential meets process and assumptions from interviews are put to the test, are among the most critical for managers. This is, arguably, when managerial impact is at its highest, when fresh hires need a guiding light through the storm that joining a new company can be. It's a key moment to establish the foundational knowledge and process necessary for success in their new role.

A clear and thorough plan of action can make the difference between your organization's newest superstar and a failure to launch during the first 90 days on the job. 30-60-90 day plans help managers and reports alike set expectations, get aligned, and stay focused on measurable goals. They act as roadmaps for new hires' onboarding period, and are a valuable tool for managers to guide reports through the formative stages of their roles.

These plans are divided into three distinct phases: the first 30 days, dedicated to orientation and understanding; the subsequent 30 days, which shift focus to application and engagement, and the final 30 days, aimed at mastery and optimization.

What is a 30-60-90 day plan?

30-60-90 day plans are about setting clear pathways for your direct reports' journey at your organization. The initial 30 days typically center around learning and absorbing, allowing new hires to familiarize themselves with your product or service, observe team dynamics, and start to understand your company culture. This foundation ensures that they have some grasp of the existing expectations and available resources before they begin to contribute in earnest. Indeed's 30-60-90, for example, sets the simple goals of cultivating two positive personal relationships with coworkers and attending one lunch-and-learn in the first 30 days.

At the 60-day mark, the emphasis shifts towards role-specific knowledge. This involves new hires completing more hands-on tasks, joining ongoing projects, and establishing connections with other teams within your organization. During this phase, managers should identify any additional training or expertise needed to consider new hires fully ramped.

By the third month, the 30-60-90 plan typically assumes that new hires can function with more independence, and that they are becoming more active contributors to the team's projects and goals. To ensure that this progression feels seamless, it's critical that the plan includes specific, measurable, and achievable milestones at each stage. Regular check-ins and feedback sessions are essential to help reports understand how they're progressing and to allow managers to adjust if needed.

Why should you write a 30-60-90 plan?

A well-crafted 30-60-90 day plan ensures that newcomers adapt to their new environment rapidly, allowing them to integrate seamlessly into existing projects and become a valued, contributing member of the team more quickly. It thus facilitates efficient project management and role adaptation, setting everyone involved up for success.

It also helps to establish a foundation of transparency and trust between reports and managers. By communicating openly about progress towards goals, anticipating challenges, and proactively setting a course of action, 30-60-90 day plans reduce the potential for misunderstanding. With increased clarity and alignment, reports can feel safer in taking risks and pushing themselves to reach ambitious goals even during these early days.

Collaborating on these plans can also encourage introspection on the part of your direct reports. By working with you to map out strategies and goals, reports can identify potential challenges or roadblocks based on their own skillsets. They can then more proactively identify the resources they might need, ensuring a smoother process for both you and them down the road.

How to write a 30-60-90 day plan

Set clear goals. What are the primary results you hope to see in each phase? In the first 30 days, this could be simply learning about your product, culture, and tools. Clearbit's 30-60-90 template aims in phase 1 to simply "meet everyone, gain context, figure out how to find answers for different foundational questions and then find them." By 60 days, you might aim for your report to have a project under their belt, albeit a smaller one. By 90 days, though, at least starting on bigger, longer-term projects should be feasible.

Break tasks down. Once you've established broader objectives, make sure to break them down into tangible tasks. Any goal should be SMART — specific, measurable, actionable, relevant, and time-bound. This granular approach will ensure you don't miss any crucial steps and give your report a clear direction so they always know what's coming next. Starting with the smallest tasks first will help set your report up for some easy wins.

Collaborate. A 30-60-90 plan is a two-way street, and its purpose serves both you and your direct report. Although the initial plan will be drafted by you, its progress and ultimate conclusion are a collective effort by you and your report. Ask them what they want to achieve and work with them on how they will do it. The landscape of a job or project can change rapidly, so it's essential to jointly review and adjust your plan together.

Celebrate wins. As you reach the end of each phase, take some time to reflect on what what your report has achieved and what needs re-evaluation. Celebrate their successes with them, taking care to ensure that they feel valued even for these early-days contributions. Talk through any challenges in order to be able to move confidently into the next phase.

30-60-90 day plan templates

Got a new hire starting but don't know where to start yourself? Check out our collection of 30-60-90 day plan templates to kick off your drafting process.

Clearbit's template includes a "goal," "learn," and "do" section for each stage of the plan. The "do" sections are drawn from a list at the bottom called "'Do' list by strengths," which references the Zone of Genius, or the types of tasks that someone excels at due to natural ability rather than learned skill.

Indeed's, by comparison, is more specific, offering a clear and simple 90-day plan for a salesperson's onboarding, complete with both goals and actions broken down into categories of learning, performance, and personal. By 90 days, new sales hires should have made an independent sale and be able lead a sales meeting with colleagues.

Ready to draft a 30-60-90 plan for your newest hire? Click the Use template button to migrate it into your Slab account so you can make it your own!

11 Examples of Core Company Values to Build and Reinforce Your Culture

Fri, 01 Sep 2023 20:00:00 GMT

A company's culture and values are the essence of what it stands for, a guiding light for the way work gets done internally and a proxy for its identity and reputation externally. Identifying your company culture and values can be an intensive process, but that's not where the work ends. Documenting the results clearly and in detail is just as important as the identification process itself. Missing this step can lead to they decay of norms over time, marked by inconsistent decision-making, unfocused goals, and internal misalignment about behaviors and expectations. Without clear documentation, companies may struggle to maintain a cohesive identity as they grow and evolve.

Documenting your company's culture and values, on the other hand, brings clarity, cohesion, and a shared sense of purpose to your team. Writing down critical information about the core beliefs and principles helps to guide employee decisions and behavior, creating an environment of structure and accountability. Free from confusion about expectations about behavior and performance, employees are aligned on how to best make progress towards company goals and can focus their efforts there.

What is a culture and values document?

Culture and values documentation is largely driven by the unique characteristics of a company and therefore will vary quite widely, but it generally contains information about a company's mission and purpose, professional values and core beliefs, and/or operating principles. All of this information has the purpose of guiding decision-making and behavior, collective and individual and day-to-day as well as big-picture.

Netflix's culture and values document, for example, has been viewed millions of times since its publication in 2009 and is now considered by some to be the industry standard. It addresses culture and values in a long-form and wide-ranging fashion, incorporating in each section examples of company policies that arose from the value at hand. Key tenets like innovation and inclusion are described alongside more detailed prescriptive and proscriptive guidelines for behavior. "There are no 'brilliant jerks'" at Netflix, their documentation reads, setting a clear and immediate standard for how employees should conduct themselves.

Google, on the other hand, merely discusses "Ten things we know to be true." These are the ten core values held by the company since its earliest days, presented as a holistic overview with a simplicity that belies the values' deep meaning. That "it's best to do one thing really, really well" may seem obvious, but this value (the second of ten) is what made Google Search the universal daily essential that it is. This simple yet resonant approach makes Google's "Ten things" a particularly powerful entry into the pantheon of culture and values documents.

Why should you document your culture and values?

Writing down your company's culture and values creates a clear set of expectations that everyone, from prospective hires to top executives, can use to guide their decision-making. Existing employees can refer to the document as a source of both inspiration and guidance along their professional journeys at your company, and those who feel a connection to it are more likely to remain productive and happy in the long-term.

Prospective employees can find culture and values doumentation useful too, as a bellwether of sorts as they imagine what their own journeys might look like. Clearly-defined cultures and values help candidates determine whether they align with your company's ethos and norms before they apply. Not only does it help your employer brand stand out in a crowded field, but it can attract high-quality applicants who resonate with your principles, improving the fit of your candidate pool and reducing turnover rates once they come on board.

How to document your culture and values

Start at the beginning. Examining your company's earliest days will provide a starting point for articulating culture and values. Check in with executives or even longtime employees. Why was the company first established? What problems were being solved? What values and principles were motivating factors? Track the evolution of these over time, if relevant, until the present day. Nowadays, what makes your company unique? What are its goals and vision, short- and long-term?

Get input. Though leadership sets culture and values, your rank-and-file employees are the bread and butter—they may not create company culture, but they are immersed in it, and uphold it and can even change it in myriad ways. Employee thoughts and feedback will produce insights very different from those of executives, so this step is essential for creating culture and values documentation that is broadly inclusive. Asking for employee input not only demonstrates that the company values their contributions, but also helps you create a culture that everyone can buy into.

Give examples. Including clear and illustrative examples of company culture and values in practice can help employees understand exactly what is expected of them. Zapier's values document offers "tips on how to apply (and not apply)" each value. To demonstrate how to "grow through feedback," the document offers "I seek out and account for customer feedback," versus how not to: "I avoid customer feedback because it may critique my work, or because I know what's best for our customers."

Consider recruiting. As you draft, remember that prospective employees may one day read your culture and values document. Consider the types of things they'd want to know. How can you attract like-minded workers, and detract those with contrasting attitudes and perspectives, while still putting your company's best foot forward? Be as detailed, accurate, and honest as possible; this will save candidates and yourself more time in the long run.

Iterate. Just as an individual does, as your company grows, learns, and develops over time, it will change in material ways. These changes will inevitably affect your culture and values, so your culture and values documentation must be a living thing. Create a timeline and process for reevaluating your culture and values to ensure that they still feel in alignment with who and where your company is today.

Culture and values examples

Culture and values nowhere to be found in your company documentation? Before you take pen to paper, draw inspiration from influential companies like Netflix, Amazon, Google, and more.

Like Google's culture and values document, LinkedIn's "How We Show Up in the World" is on the simpler side, providing a six-point guide for expected behavior, including things like treating other LinkedIn employees with trust and care and being responsible for embodying diversity, inclusion and belonging.

Ben & Jerry's goes further, detailing not just their economic and product missions but their social one as well, which "compels [them] to use [the] company in innovative ways to make the world a better place." This is underscored less by individual behavior and more by larger business decisions, like using cage-free eggs and working with vendors that provide jobs for people who traditionally face barriers to employment.

Stripe's "Operating Principles" details how Stripe employees work and who they are, and also includes some "classic slogans" that aren't strictly part of company operating principles but convey deep meaning internally, like "We haven't won yet" or "Really, really, really care."

Find anything you want to use for your own team? Click the Use template button to keep working on it in your own Slab account!

Guide to Writing Your Personal User Manual in the Modern Workplace

Wed, 30 Aug 2023 20:00:00 GMT

Imagine having a detailed guide to each individual you interact with at your job—a manual that provides insights into who they are and their daily habits, communication preferences, and working styles. Instead of the usual trial-and-error approach that takes months, if not years, to get results, the dos-and-don'ts of working with them are already neatly outlined for you. How much more efficient—and painless would your day be?

A growing trend amongst people managers is the creation of user manuals to help reports and peers alike better understand how to collaborate and communicate with them. Across various industries, locations, and levels, managers are finding that these documents reduce interpersonal friction and misunderstandings and empower teammates to work more effectively.

What is a user manual?

Just as new gadgets you purchase include guides explaining how to use them properly, personal user manuals help people, particularly managers, share insights into their personality, strengths, weaknesses, and communication and collaboration styles in the workplace. Think of it as a guidebook to navigate the nuances of human interaction, helping you engage with colleagues on a deeper level.

Its basic components are information about your working hours/schedule, how you like to communicate and collaborate, including how you give and receive feedback, and any personal details you want to share to help others get to know you better. When complete, it should serve as a detailed roadmap for working most effectively with you.

Why should you write a user manual?

The goal of a user manual is to reduce the friction by setting crystal-clear expectations for working collaboratively. In an increasingly remote world, without the benefit of regular face-to-face interaction, simple misunderstandings can fester and create a breakdown of more than just communication. The user manual, then, seeks to establish a foundation of trust and clarity that acts as a bolster to daily interactions as well as a fallback if conflict arises.

For new hires, user manuals simplify the onboarding process, allowing for smoother integration into team dynamics and faster ramp-up times. Early-days interactions are clear end streamlined, reducing misinterpretations and resulting tension. But manuals can provide a surefire boost to communication and collaboration at any stage in an employee's tenure, not just onboarding. Continued reliance on them fosters a culture of respect for individual boundaries and preferences. As more and more employees author their own, differences are not just acknowledged but celebrated.

Finally, the process of creating a manual encourages deeper introspection about who you are and how you work, a useful exercise in and of itself even for non-managers. It can reveal patterns in behavior and pinpoint areas for improvement, leading to both personal and professional growth. As you articulate your communication style and preferences, you'll become more attuned to your place within the larger team dynamic, showing you where you could make some adjustments for the good of the group. It's an investment in yourself and in your team.

How to write a user manual

Do your research. Take time to that ensure you understand your own inherent traits, communication style, and preferences. If you could use some help getting started, try a personality test like Myers-Briggs or CliftonStrengths. Use that or your own insights to reflect on how you work best, your strengths, and areas where you might need support. Don't forget to seek input from friends, family, and coworkers, too, since they can provide valuable perceptions that may not be obvious to you. Transparency is key here, but so is ownership. As GitLab founder and CEO Sid Sijbrandij notes as he lists some personal shortcomings in his manual, "I'm fully responsible for improving the things below, listing them is no excuse."

Cover the basics. At a minimum, your user manual should include information on how you like to communicate, collaborate, and give and receive feedback. What are your working hours? How do you structure your day? Do you prefer direct or indirect, written or verbal, formal or casual communication? What tools do you use and for what? If you're a manager, this should also include specific details about meeting cadence and performance reviews. It can also be helpful to include details of exactly what your role is to eliminate any confusion.

Get personal and be personable. While tactical details of working and communicating with you are necessary for a user manual, merely writing them down is not a goal in itself. Rather, as you're writing, keep in mind that the end goal is simply to communicate and collaborate more effectively with colleagues. Demonstrating openness and authenticity by sharing more personal details about your expectations and habits can fast-track effective collaboration in a way that a purely tactical approach can't. Don't be afraid to be specific about your preferences, as Tim Glaser, CTO and cofounder of Posthog, is when he instructs colleagues to "Please don't message me 'hey' and then spend 3 minutes typing your question." When you show up as your real self, quirks and all, it not only helps your colleagues relate to you more deeply, but also creates an environment where vulnerability and authenticity is reciprocated.

Stay flexible. Remember that all human beings are complex and dynamic. Your user manual should serve as a guide, not a rigid rulebook, and should be a living document. Before you share it more widely, have a few trusted friends or colleagues look it over and give their thoughts and impressions. They'll likely have some insights that won't have occurred to you, as will others who use the manual down the line. As time goes on, be open to evolving and adapting your manual as you grow as a colleague and a leader.

User manual examples

Not quite prepared to begin a user manual of your own? Draw inspiration from our collection of user manual templates from people managers at top companies.

Check out Molly White's, whose manual from her time as a tech lead at HubSpot focuses on sharing feedback and communicating clearly, or GitLab CEO Sid Sijbrandij's, who includes personal details such as his favorite restaurants and bars in addition to more tactical details about working with him. Chris Blanchut from Unconventional Route takes a more humorous approach in his user manual, writing as if he were describing how to operate a piece of machinery.

If you find anything you want to repurpose for yourself, or you just want to copy a certain manual's structure, click the Use template button to add it to your Slab account, and you can keep drafting there!

How Refine Labs rewrote the book on culture

Tue, 07 Feb 2023 20:00:00 GMT

When Megan Bowen (COO) joined Refine Labs in 2020, she knew she was in for something different. CEO Chris Walker founded the company in 2019 with a goal of creating a team that would be free from the “hamster wheel” style of work that most marketing companies traditionally rely on. A different philosophy also meant a different company culture. By giving their employees the freedom to experiment with new strategies and the trust to get the job done, Bowen and Walker saw those goals come to life.

The path to establishing values of trust and empowerment had an unexpected bonus along the way: It fostered a thriving culture of writing. This is the story of how Refine Labs rewrote the rules of how creative teams treat each other, from their first page to their next chapter.

Small company, manageable culture

In the early days of the company, Bowen’s work was, unsurprisingly, varied. She managed everything from customers to service deliveries. Unlike most companies in the pre-pandemic world, Refine labs was already remote-first.

“Chris realized early in his career that he was much more effective when he had some quiet time and space to focus on deep work,” explains Bowen. “As he started hiring, he realized the talent wasn’t located in his town.”

This remote-first approach could have become a complication for culture. Conventional wisdom argues that without the ability to connect in-person, morale can suffer. Their solution: regularly-scheduled company off-sites to balance digital relationships with face-to-face events. It worked, adding another win to Refine Labs’ plan to find better solutions to old problems.

However, regular in-person events were built for a smaller team. As the company grew, Bowen noticed their core values were being challenged by their scale. Walker and Bowen both had made a habit of communicating and advocating for Refine Labs’ core values both across the team and on LinkedIn. Values like “having a growth mindset” and “creating a value of psychological safety” were key to the team’s shared identity. Suddenly, they were in direct conflict with each other.

“Up until that forty- or fifty-person mark, Chris and I were pretty connected with everyone in the organization,” says Bowen. “When you start to get above fifty, that connection becomes impossible to maintain with any type of regular frequency or cadence. I knew we had to pivot or evolve our internal comms and employee engagement strategy.”

To move their company culture forward, Bowen decided to look backward.

A new way to communicate company culture

As Bowen was hiring for their Head of People role, she was looking for someone who could help her communicate and maintain their company culture. She knew what other companies would do: Make an employee handbook for new hires, like a driver’s manual for a new car. Many companies focus on signaling their culture through activities and objects rather than threading it through every aspect of how the company operates. (Think ping-pong tables and beer on tap, and that’s what signaling looks like.) But Refine Labs couldn’t champion a new way of treating people while using the same old tricks. Bowen wanted to find a new twist.

Luckily, one candidate, Jessica Williams, had an innovative approach— make a culture playbook. “It was a concept she brought up in our interview together,” says Bowen. “[Williams] was discussing how she hated the concept of an employee handbook and that it felt very legal and boring. Nobody read it.”

And the worst thing about employee handbooks, according to Williams? They don’t do anything to improve the employee experience. A typical employee handbook takes a wide look at every part of a company’s operations. This means little, if any, space is given to talk about culture.

The Refine Labs playbook is 20 pages of just culture. It’s a tool to communicate the team’s shared benefits, policies, and values. But it also shows that they live by those values within the company. When it comes to meeting the expectations of workers in the new world of work, being able to practice what you preach is everything.

“We have a section on why it's hard to work here: We're growing quickly, things move fast, we make changes,” says Bowen. “It's not a book that only looks at the positives of our culture. It describes what it's like to actually work here, what we expect, how we expect people to behave and interact at the company, what behaviors we tolerate, and what we do not tolerate.”

This level of transparency means that employees have a clear expectation of what it’s like working at Refine Labs. If everyone has access to the same rules, they can work and play effectively and efficiently. The playbook’s unapologetic honesty came with a vital, if unintended, side effect: It has helped team members feel safe and empowered to share their experiences at the company with others. This shows up in several ways, from Bowen’s podcast, to the many LinkedIn posts from employees about what it’s like to work at Refine Labs, to testimonials featured in the playbook itself. And because of those examples, Bowen says that new hires are enthusiastic and eager to engage with this culture of sharing and validating their experiences through writing.

“When people join, they’re like, ‘I want to do that, too. I want to build my own brand. I want to get better at communicating my thoughts and my ideas,’” says Bowen. “It's really about showing people the benefits and then giving them some resources and training.”

Far from other rigid corporate policies on employees using social media, Refine Labs gives its workers access to support materials for succeeding on platforms like LinkedIn and Twitter. That way, new hires are empowered to write and share their own stories.

But Refine Labs was built on a culture of innovation. And that means moving forward.

Innovation sparks solutions — and challenges

Embracing change means accepting all that comes with it — the ups and the downs. Despite its success and industry-wide influence, Bowen says the Refine Labs Culture Playbook isn’t a static resource, nor is it a cure-all for culture. It was a single solution to a specific problem, but there are others on their radar.

For example, they’ll be looking to solve problems like providing critical feedback when there’s a culture of niceness within the company. So, how do you solve toxic positivity? With constructive honesty.

“I’m always asking myself one question: How can we maintain a psychologically-safe environment while still providing constructive feedback?” says Bowen. “We need to be able to have these ‘challenging conversations’ that might make people feel a little bit uncomfortable, but are ultimately in their best benefit if they are getting some constructive feedback about how they can improve.” This commitment to constructive honesty isn’t limited to existing employees, either — Refine Labs wants to apply it to their job interview process as well.

“I think we still have a ways to go [when it comes to this approach],” admits Bowen. “As I've been doing interviews, and I've been talking about some of the challenges of the roles. People have been shocked, like: ‘Whoa! You're being really honest.’ I’m like, ‘Well, yeah. But this is the worst of it.’” Bowen sees this as the biggest opportunity in the recruiting and interview process: embracing honesty and the downsides of a job, even if that means the applicant looks elsewhere.

But she doesn’t actually see this as a drawback. Rather, it’s more about both parties identifying the gaps in their shared expectations. That way, they only hire people who actually want to be there and can thrive in the culture they’ve built.

As they continue to change, so does the playbook. In fact, Refine Labs updates the playbook every six months. It’s not set in stone, it’s a living document with a rotating cast of authors and perspectives. This process includes input from volunteers across the company to ensure accurate representation.

“People should know what they’re getting into, with eyes wide open,” says Bowen. “And if you don't do that, you have a good chance of it not working out. And it takes even more time to go back to the interview process to finally find the right person for the role,” says Bowen.

The playbook was built to give everyone at Refine Labs an accessible, flexible, and accurate way to define their culture. By leaning into the value of honesty and stories, they created a culture of writing that is still growing to this day.

For any teams looking to innovate and break out of their own hamster wheel, consider taking a page out of Refine Labs’ playbook to see what a top-down commitment to culture and communication can look like.

Megan Bowen is the COO of Refine Labs and Co-Host of the Talent Destination Podcast.

Path to Startup Profitability

Jason Chen — Tue, 31 Jan 2023 20:00:00 GMT

You may have heard "grow at all costs" echoed across Silicon Valley. Many companies were richly rewarded for that path, forsaking profits all the way to IPO and beyond. The Bessemer Cloud Index tracks emerging public cloud companies, and only 11 out of its 75 companies earn a profit today. Before its collapse, the index more than tripled in value from its debut in October 2018 to its peak in November 2021. Since then, it has given up the vast majority of its gains, ultimately performing no better than the S&P 500¹.

Profitability runs counter to conventional Silicon Valley wisdom because it typically sacrifices growth. But at Slab, our product's purpose is to steward our customers' knowledge long-term, so we need to be built for and remain enduring for the long term. In 2022, we achieved a long time goal of profitability, generating net income for the year while increasing our bank balances and doubling our team.

Profitability is an important milestone for Slab to fulfill our product's purpose of stewarding our customers' knowledge long-term.

While prioritizing growth has its merits, reaching profitability early is a path more startups should consider. So little is shared publicly about profitable startups that many founders are not even aware if and how it is an option. We're sharing our lessons here today, so hopefully, you can get here faster and better than we did. While our lessons will apply best to B2B SaaS startups like us, most will apply broadly across markets and businesses.

Building your first pricing model

Half of the profitability equation is revenue, so you'll need a pricing model and the prices themselves for your product. For your first, go for good, not perfect. Survey your competitors' and adjacent products' plans in your space and construct a simplified version². This approach ensures your prospect will be familiar with what is being charged for. For Slab, Confluence is a close competitor and Slack is closely related in the productivity space. Both charge per user per month as the fundamental unit. Slack considers a user uniquely, and Confluence charges less per user depending on the total number of users. Skip out on most complexities like these for now.

For your first pricing plan, go for good, not perfect. Survey your competitors and construct a simplified version.

Our plans now include a premium plan, named "Business" to contrast our standard "Startup" plan. The main functional benefit of Business is integration with Okta. Surprisingly, our very first Business customer never integrated Okta. Neither did our 3rd or 6th. In such confusing early days, we actively tried to talk prospects out of our Business plan if they did not use Okta. As time went on, we learned many customers simply want the best version of Slab, even if they will not immediately make use of functional benefits. Some also worry their boss might want to use a feature, but they bought too low of a tier. Others believe there are implicit benefits, such as stronger weight to their feedback or more flexibility if they need help.

Regardless of the motivation, you should let such prospects self-select into a higher-tier plan by offering one. You do not need functional feature differences; it is enough to offer priority support and/or an SLA as initial benefits. Priority support can be as simple as a rule in your support tool that sorts those tickets first. The SLA could in practice be for everyone but only guaranteed for premium customers. Offering a premium tier also creates a contrasting price anchor, so your standard plan looks comparatively better.

Let your prospects self-select into a higher-tier plan by offering one. It is enough to offer priority support or an SLA as initial benefits.

Now comes the most delicate part: the prices themselves. The true answer is "it depends" but we're here for practical learnings, so a more actionable offering is this: for your first plan, unless a core value of your offering is being cheaper, price the same or ~20% higher than your direct competitors. Then experiment and iterate for the rest of your company's life. People complain far less about price decreases than increases, and an initial 20% difference is palatable to most prospects. Every negotiation will give you signal on how expensive or cheap your prices are, and once you have strong enough confidence and a big enough price gap, you can and should update³.

Cash flow buys time until profitable

It will take time to grow your customer base and revenue — a race against your bank accounts hitting $0. This movement of money is cash flow and your "runway" is cash divided by cash flow. As it becomes less negative, your runway multiplies, until eventually, it gets to zero, and you will have an infinite runway and infinite time to reach profitability — as long as you keep cash flow at least zero! It is easier to achieve cash flow positivity than profitability, so that should be your intermediate goal.

A simple way to increase cash flow is to offer an annual plan with upfront payment in return for a discount (typically two months free). Discounts reduce overall revenue but the cash flow is worth it to extend your runway⁴. As an added benefit, the annual commitment reduces churn. New financial services like Arc and Pipe can also effectively turn monthly subscriptions into annual upfront payments and are worth considering. But they are more expensive than you might think⁵ and you'll miss out on churn reduction benefits.

Offer a discounted annual plan with an upfront payment to increase cash flow while reducing churn.

On the same coin, don't pay vendors upfront for annual plans, despite their savings. As a startup, change is the only constant and you'll want the flexibility to switch vendors as soon as your needs change. But now, your cash flow is another reason to stick with a monthly plan.

Most startups neither get to cash flow positivity nor profitability. David Sacks of Craft Ventures was one of the first to warn of the impending downturn in May 2022, urging portfolio companies to improve key metrics. Having positive cash flow was so exceptional that it was not pushed as a plausible goal for portfolio companies. Achieving even this intermediate goal will be a major milestone for your company!

Hire contractors before employees

Salaries are almost always the biggest cost for a company. Outside core competencies, first hire contractors or small agencies⁶. This allows flexibility in commitment and needs for all parties, but also easier access to specialists and top-tier talent. You will often not be able to afford top talent as full-time employees, nor will you have 40 hours a week of work for them⁷. Contracting solves both problems.

Contracting allows you to work with top talent while being able to afford them.

In many domains, learnings scale more from exposure to different businesses than personalizing for one. For example, you want your immigration lawyer to have obtained visas for many other clients. In contrast, you want your account executive to be exclusively focused on your company and product because personalizing is crucial for closing sales⁸. Slab saved substantially in salaries by hiring contractors or agencies in numerous domains including brand design, illustrations, animations, video production, SEO, SEM, content marketing, accounting, and more. If needs do grow, the contractor to full-time employee path is a well-trodden win-win as you'll know each other far better than from any interview.

Also look for contracting opportunities in areas of high skill or knowledge curves. For example, even with Slab's very capable engineering team, we contracted experts for specific technologies, including Kubernetes, Electron, and dbt, in some cases the core maintainers themselves. We not only got to quickly adopt these technologies but could also be confident they were set up the "right way" according to their best practices.

Hire contractors especially in domains with high skill or knowledge curves, or where learnings scale more from exposure to different businesses and clients.

Hire senior and remote

Slab embraced remote work in our earliest days simply because we wanted to work with the best and did not believe that every talented person lived in my home city of San Francisco. Top talent in tech has never been more dispersed amongst the rest of the United States and the world⁹. Hiring in lower cost-of-living geographies creates a win-win for employers, who can offer more competitive salaries at lower costs, while employees can command greater purchasing power with those salaries. Remote work is too large and nuanced to fully cover, so I'll simply offer that the salary savings alone can be game-changing and should be strongly considered for profit-seeking companies.

Because of management, more people and salaries lead to even more people and salaries. One way to slow this is by hiring senior individual contributors, who can get more done, even relative to their higher salaries. This further saves from operational overhead and complexities inherent to employing more people, including regulatory requirements but also simply the need to get more people on the same page. One caution is some senior people most prefer to influence or mentor junior people, so not having them can create issues. Some of this preference can be directed outwards through blogging or open source but ultimately you want senior individual contributors who mostly want to build, not mostly want to influence.

More people and salaries lead to even more people and salaries due to management. One way to slow this is by hiring senior individual contributors.

Squeeze savings outside salaries

For most vendors, it will not be worth the effort to find savings, but one exception is infrastructure. All major providers currently offer six-figure credits, including Amazon Web Services, Google Cloud Platform, and Microsoft Azure. You will likely not use all these credits, saving time in your early years from optimizing infrastructure efficiency and costs. When you run into scaling issues, you can literally throw (free) money at the problem. These credits are so substantial that at Slab, we deliberately started with our #2 choice cloud provider and switched to our #1 when credits expired. This is not trivial from a technical perspective, but the maturity of Kubernetes makes it easier than ever to double-dip.

All major cloud providers offer over $100k in startup credits, including AWS, GCP, and Azure.

For all others, savings can be worthwhile only if the effort is very low — on the order of minutes of Googling "{vendor} startup program" or examining discount directories. Some example startup programs include Amplitude, Gem, and Segment, offering tens of thousands in savings, but startups are unlikely to utilize their maximum benefits. YCombinator has an exclusive deals list (many are available to alumni) and I'd imagine many other startup accelerators do as well. One widely accessible discount directory is provided by Ramp to any cardholder¹⁰.

Payroll tax in the United States is 7.65%, and all companies pay this through their payroll provider (Gusto, Justworks, etc). But as of 2016, you can get this refunded by filing additional tax paperwork for R&D tax credits. As with regular taxes for your company, you should use an accounting firm to do this. To use realistic round numbers, if you have an early 10-person team costing a total of $1.4m in salaries, you can extend your runway by over $100k per year with these credits. It was a great feeling to open letters from the government and see a check for such large sums.

Stay profitable and control your destiny

Profitability as a goal requires a mindset that is not typical of Silicon Valley startups. Instead of growth at all costs, the growth needs to be much more deliberate and sustainable, typically over a longer period of time. Instead of acquiring 100 customers one month at a loss, you might spend two months acquiring 50 customers a month profitably. Even successful startups typically exit in a 6-9 year horizon. With this slower, deliberate growth, it will take you much more time and require much greater commitment to your company's mission.

With that greater commitment and time horizon comes opportunity and optionality. To quote Jeff Bezos, "If you're willing to invest on a seven-year time horizon, you're now competing against a fraction of [the competition], because very few companies are willing to do that." Most Silicon Valley startups think in 18-month time horizons, the average time between funding rounds. Grow your costs and your team as fast as your revenue growth will allow, and you will remain in control of your and your company's destiny for much longer.

Thanks to Nicolas Dessaigne, Anurag Goel, Ravi Parikh, Julian Shapiro, and Ilya Sukhar for reviewing drafts of this post.

Notes

If you invested $1000 in Bessemer Cloud Index (EMCLOUD) or the S&P 500 in October 2, 2018, you would have roughly $1300 today (Jan 31, 2023) with either investment.
^
The best way to price is accurately identifying the true value of your product and features, often segmenting across different customers. But for your first plan, this is overkill. To geek out about pricing on your journey, read Profitwell's blog. A quick overview is here, but their numerous examples and case studies are worth studying.
^
This can be done officially by updating your pricing page and sending an announcement but also consider more flexible unofficial options. For sales-driven motions, this can mean what discount account executives are empowered to offer; for product-led, this can mean easy to obtain discounts through various partnerships or referral programs.
^
It is interesting to speculate on how much a company values cash by the size of its discounts. For example, ClickUp offers 45% while Cloudflare only offered us 2% at our last enterprise contract renewal.
^
If your $10/month customer paid you a lump sum of $120 at the end of the year, the discount would be easy to model with division. But since they pay you $10 each month, you'd have to use discounted cash flow to model this more precisely.
^
Large agencies can have the issue where you are sold to by the A-team and then work with the C-team.
^
There can be savings in hiring contractors for full-time work, but additional complexities in geographies, benefits, and others are too nuanced a topic to cover in this post.
^
In fact, even with full-time account executives, you'll want to specialize and focus further with different customer segments and use cases.
^
San Francisco recently lost 6.3% of its population, while New York City lost over 300,000 (-3.5%).
^
Disclosure: Slab and Ramp are happy customers of each other.
^

Super informative, super fun: a look inside Superhuman’s writing culture

Tue, 20 Dec 2022 20:00:00 GMT

Superhuman was built around the question, “What does the best email management experience look like?” and the answer they’ve come up with is to make the fastest email platform in the world. They didn’t stop there. They also built the platform that allows people to get into a flow state and minimize interruptions in their workday.

Anita Isalska, Superhuman’s Content Lead, says this is just one part of the company’s larger goal to help people to be the best versions of themselves. Superhuman aims to add value to the world through software, content, and community. In order to align on these goals, though, it’s been imperative to achieve transparency internally first. This is where the company’s writing culture comes in.

Rule #1: Make it fun

According to Anita, knowledge-sharing at Superhuman answers a “classic startup challenge” of needing to communicate with one another in a way that levels everyone up and helps people align to team objectives. “Without good knowledge sharing, you risk duplication and missteps,” she says.

Thankfully, Superhuman has a strong framework for ensuring that good knowledge sharing can—and does—take place. This framework rests on a simple yet perhaps unexpected concept: “We’ve built our writing culture around the idea that it should be fun,” says Anita.

“People acquire knowledge best when they have an open mind and are not stressed. We can help foster that by making communication delightful.”

Fun writing doesn’t equal insubstantial writing—far from it. “Striking a balance between informative and fun when communicating with anyone is the hallmark of great writing,” says Anita. “Our goal is always to be warm, sincere, and uncluttered in what we communicate, and I see this across the board at Superhuman.”

Internal communication is intentional

Taking the time to carefully craft and document best practices then make them widely available gives the team at Superhuman firepower and speed. “Capturing a process is initially really difficult, but once you’ve documented something, you’re created a toolkit that anyone can use,” says Anita. All process documentation is then kept in a centralized wiki that each employee can view.

“When it’s easy to access information, you’re empowering people to do the best job they can.”

Writing down knowledge to turn it into a company-wide resource can be seen throughout the company. For example, Superhuman’s onboarding is a white-glove process that individually brings customers into the product. “That team is made up of excellent communicators, and when they find resonant ways of communicating our features to new customers, they tend to capture them in written form and share them with everyone," says Anita.

Having this knowledge shared widely is invaluable. “Every customer has different pain points, so lots of knowledge sharing helps us create a bank that makes it easier to reach different types of customers,” says Anita. It empowers the team to use the language of their customers, deepening value.

Documenting processes internally also encourages self-reflection for the person who’s writing them. As Anita describes it, taking the time to write something out for others forces the writer to take a step back and ask, “Is what I’m writing as good as it sounded in my own head? Can I make further refinements?” Writing through this filter allows the writer to clarify any assumptions that seem obvious, which results in a strong finished product.

Synchronous doesn’t mean reactive

How do you get more flow? With fewer distractions. Superhuman has developed frameworks for how to approach different modes of communication. The rules are simple: If an employee needs a response within 24 hours, they should use email to reach out. If they need a response sooner, they can turn to Slack—but no one is expected to answer Slack messages right away. “People can expect a Slack response within three hours,” says Anita.

Having these expectations in place ensures that Superhuman stays away from having a reactive environment. When people know they’re not expected to be reachable all the time, they feel empowered to turn off their notifications and actually get into deep work.

It also means that for employees drafting messages, knowing that they shouldn’t expect an immediate response allows them to be more thoughtful about what they’re communicating and how they’re framing it.

At Superhuman, Slack is also a place to share resources for things that aren’t company-centric, like personal growth. For example, the #allyship channel is a place where people can share and find resources for, “being better humans.”

Delightful and digestible information for everyone

While a great deal of Superhuman’s writing culture can be seen internally, these guidelines and processes ultimately set the tone for how the company interacts with its customers. Superhuman’s communication with customers is focused on being delightful and informative. The best example is the flow of onboarding emails that customers receive after signing up. Each email is “a masterclass in a different feature,” sent over 30 days to build knowledge in a way that feels digestible, encouraging, and helpful.

When thinking about the future, empowering customers is priority number one. “I’m hoping we can massively scale everything we’re doing with our productivity content,” she says, which right now lives on the company blog.

This is just one of many initiatives, however, and for a company that places so much emphasis on knowledge-sharing, there are sure to be more writing-based projects emerging in the future. As Anita tells it, they have the right barometer in place to guide them forwards. “As long as we’re delighting our customers and each other, we’re on the right track.”

Deploying Secure Elixir Apps with Google Secret Manager

Samuel Gordalina — Mon, 19 Dec 2022 20:00:00 GMT

As a company trusted with other companies' valuable content and knowledge, security is a top priority for our engineering team at Slab. We're always looking for ways to improve and one area we identified was how we manage application secrets on a growing team.

Background

When we set out on this journey over two years ago, we were using Elixir 1.11. At the time, the recommended method of managing production secrets was to bundle a config/prod.exs with hardcoded secrets, as this file was included at compile time. We shared this file internally with the engineering team using 1Password.

There were a few drawbacks to using this approach in a Kubernetes environment:

Bundling a file with sensitive data in a docker image is not ideal as it fails the config factor in the twelve-factor app methodology, and if the image is leaked, all secrets have to be considered leaked as well.
We can inject the config/prod.exs as a volume mount, but we would be relying on Kubernetes secrets. We will explain later on why this isn't ideal.
The entire file was shared and updated in its entirety, making it difficult to track and verify which secret was updated. Because of the randomness of values in secrets, it's difficult for teammates to scan or verify they have the latest correct values.

The current recommended method of managing secrets in Elixir applications is to place configurations in config/runtime.exs and have it resolved at runtime via environmental variables.

This is a better approach, as it makes it easier to comply with the twelve-factor app methodology. Relying on environmental variables to store sensitive data creates a credential leakage issue as they can be read by:

Application dependencies
OS applications
Error monitoring tools, e.g., Sentry
Application Performance Monitoring (APM) tools, e.g., AppSignal, DataDog
Container or infrastructure monitoring tools, e.g., Datadog

Some may consider this a good enough compromise, but at Slab, we wanted to achieve a higher standard for our security, especially in a zero-trust security model.

That led us to search for a better solution to manage sensitive data throughout our development, provisioning, and deployment pipelines.

Vault

HashiCorp's Vault is a secure storage system for sensitive data and is widely considered to be the golden standard for secret management.

Its feature set is compatible with our use case, and it would be our first choice for a secret storage service. But we decided not to go with Vault because:

At the time, they only had a self-managed enterprise Vault and no fully managed cloud-hosted offering.
Even their enterprise offering was deployed on Amazon Web Services, whereas Slab hosts all our infrastructure on Google Cloud Platform.
Using Vault, there's also additional complexity in how the application authenticates to it and where that secret is stored.

As a startup, we highly value low overhead and complexity, which led us to search for alternatives.

Google Secret Manager

Fortunately for Slab, Google had recently released Secret Manager in general availability. Like Vault, it's a secure storage system for sensitive data designed for high availability, follows the principle of least privilege, and helps meets audit and compliance requirements, like SOC 2.

Secret Manager, by default, encrypts all secrets at rest using AES-256 and TLS in transit. For an added layer of security, you can use Customer-managed encryption keys (CMEK).

Secrets have versions, which are immutable objects that store sensitive data. A given release may point to a specific secret version or access its latest alias. This makes it easy to manage application secrets, especially when rolling back application configuration.

Since Secret Manager is a managed service, it becomes an excellent choice for startups, and larger organizations, who want an easy and low-maintenance solution for secure secret storage.

Let's see how we can create our first secret using Secret Manager:

# create initial secret
gcloud secrets create DB_PRIMARY_PASSWORD

# create secret's first version with a random password
gcloud secrets versions add test --data-file=- \
  <<< $(openssl rand -base64 32)

# get latest version data
gcloud secrets versions access latest --secret=DB_PRIMARY_PASSWORD

We now have our database password stored in Secret Manager, but how do we leverage it in our application?

Hush

To enable our application to read secrets from Secret Manager, we use Hush, a runtime configuration loader for Elixir applications, which supports multiple providers such as Google Secret Manager.

When hush is configured as a Config Provider in release mode, it resolves the application's configuration during the system boot process and restarts the application with the correct configuration applied to it. Using this method, we can start an Elixir application without writing sensitive data to disk, as all secrets are loaded at runtime.

So how do we configure Hush in our application? First, we add our required dependencies.

# mix.exs

def deps() do
  [
    {:goth, "~> 1.3"},
    {:hush, "~> 1.0"},
    {:hush_gcp_secret_manager, "~> 1.0"},
  ]
end

Secondly, we configure the application release to use Hush as a config provider. When the erlang VM starts, Hush will fetch the configuration from Secret Manager and trigger a restart of the application with the full configuration.

# mix.exs

def project() do
  [
    # ...
    releases: [
      slab: [
        config_providers: [{Hush.ConfigProvider, nil}]
      ]
    ]
  ]
end

If we use Hush configuration in a non-release environment, we'll want Hush to resolve any configuration before our application starts.

# lib/application.ex

defmodule Slab.Application do
  def start(_, _) do
    unless Hush.release_mode?(), do: Hush.resolve!()

    # ...
  end
end

Lastly, we configure hush_gcp_secret_manager to use goth, an Elixir client to authenticate with Google Cloud, and the Google Cloud project to read the secrets from. Make sure you set the GOOGLE_PROJECT_ID environment variable in the application.

# config/runtime.exs

config :hush_gcp_secret_manager,
  project_id: System.fetch_env!("GOOGLE_PROJECT_ID"),
  goth: [name: Hush.Goth]

Now we can use Hush to read configuration from Secret Manager, for example, let's configure our Ecto repo.

# config/runtime.exs

alias Hush.{GcpSecretManager, SystemEnvironment}

if config_env() == :prod do
  config :slab, Slab.Repo,
    hostname: {:hush, SystemEnvironment, "DB_PRIMARY_HOST"},
    password: {:hush, GcpSecretManager, "DB_PRIMARY_PASSWORD"},
    pool_size: {:hush, SystemEnvironment, "SLAB_REPO_POOL_SIZE", cast: :integer}
end

You can read more about Hush and its API on its project page.

Keyless Authentication

A service account is a special type of Google account intended to represent a non-human user that needs to authenticate and be authorized to access data in Google APIs. ― Understanding Service Accounts

These service accounts are used throughout Google Cloud. Some of them are provisioned by default. For example, all Compute VMs are assigned the PROJECT_NUMBER-compute@developer.gserviceaccount.com service account to them as the default service account. This machine can now talk to your Google Cloud APIs using said service account.

You can also create service accounts for specific purposes and only grant them the permissions they need, fulfilling the principle of least privilege.

To interact with Google Cloud APIs, you need a service account and a way to impersonate it. In Google Cloud, there are two ways.

Using a service account key

Unlike normal users, service accounts don't have passwords, they instead use RSA key pairs for authentication. You can generate and download the private service account key and use it to exchange a JWT Bearer token for interacting with Google Cloud. If you used a quick start guide for GCP, there is a good chance you created a service account key file (ends in .json).

On the other hand, service account keys can become a security risk if not managed carefully. Threats related to service account keys include credential leakage, privilege escalation, and information disclosure. The best way to mitigate these threats is to avoid user-managed service account keys whenever possible.

Using Application Default Credentials

Google Cloud API clients that implement Application Default Credentials will always try to locate a service account key, or if the service running the application has an attached service account, can use the metadata server to authenticate to said service account without using a key at all.

One example of this is the compute service account that is attached to a VM by default, any API calls made by an API client running on that VM that use Application Default Credentials will use the compute service account without ever having to use a private key.

Workload Identity in Google Kubernetes Engine

In Google Kubernetes Engine, we can go a step further and use Workload Identity, which enables your Kubernetes cluster to impersonate IAM service accounts to access Google Cloud services.

To do so, we need to have a GKE cluster with workload identity enabled and create a Google Service Account with the roles the app needs, in this case, to access Secrets.

export PROJECT_ID=slab
export GOOGLE_SA=google-sa
export K8S_SA=kubernetes-sa

# create google service account
gcloud iam service-accounts create $GOOGLE_SA

# grant the google service account secret manager role
gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:$GOOGLE_SA@$PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/secretmanager.secretAccessor"

Then we need to create the Kubernetes service account and annotate it to impersonate the Google service account we just created.

# create kubernetes service account
kubectl create serviceaccount $K8S_SA

# allow kubernetes to impersonate the google service account (in default namespace)
gcloud iam service-accounts add-iam-policy-binding $GOOGLE_SA@$PROJECT_ID.iam.gserviceaccount.com \
    --role="roles/iam.workloadIdentityUser" \
    --member="serviceAccount:$PROJECT_ID.svc.id.goog[default/$K8S_SA]"

# annotate kubernetes service account with google's service account
kubectl annotate serviceaccount $K8S_SA \
  iam.gke.io/gcp-service-account=$GOOGLE_SA@$PROJECT_ID.iam.gserviceaccount.com

Now we need to configure our application pods to use the newly create Kubernetes service account.

apiVersion: v1
kind: Pod
metadata:
  name: slab
spec:
  serviceAccountName: $K8S_SA

Any Google client library can access Google Cloud APIs via Workload Identity without using a service account key.

Constantly Learning

Security has always been a top priority at Slab, and we are constantly aiming to push the boundaries for our customers. The use of the best new technologies is one of the ways we strive to meet and exceed their security needs.

We've been using Google Secret Manager and Hush reliably in production for over two years now. We're confident in our choice and usage of them and wanted to share our learnings with the wider Elixir community.

How writing helps Doist's asynchronous setup soar

Tue, 29 Nov 2022 20:00:00 GMT

For remote, global teams, asynchronous communication is a given—and learning how to master it is a must. Since its founding 11 years ago, Doist has been a remote-first asynchronous company. Doist started as a productivity app, Todoist, and launched it's second product Twist in 2017, an asynchronous communication tool. As Fadeke Adegbuyi, Doist’s Senior Marketing Manager of Content, tells it, “Relying on synchronous tools has never been an option for us.”

“When we say that we’re async first, what we mean is that we’re writing first.”

It’s no surprise that Doist has taken the problem of remote communication and turned it into a superpower. It’s a huge part of their culture, and as Fadeke says, it all boils down to believing in the power of writing to get aligned and achieve goals: “When we say that we’re async first, what we mean is that we’re writing first.”

Everything starts with writing

Because Doist relies so heavily on asynchronous communication, it's important that information is always accessible. In terms of deciding what needs to be written down, the criteria are pretty straightforward. “We approach communication from a beginner mindset,” says Fadeke. That means that the goal is to document answers to questions anyone might have who’s new to the company, a role, or a process. “Even if a process seems obvious or has been done many times before, we want to make sure everything’s in place so that someone who’s new to it gets it,” she says.

“Writing extends to everything we do—how we update one another on work, how information is passed down from our leadership team, how we brainstorm, and how we have discussions.” says Fadeke.

Streamlining the writing process

While writing has always been a big part of Doist’s culture, up until about a year ago, a lack of organization prevented the team from fully harnessing its power. According to Fadeke, “We had a lot of writing, but it was dispersed among many platforms. Some of it lived in Dropbox Paper, some was in Google Docs, some of it was in Twist threads. You would have to check in three to four different places to find what you needed, and there was also some duplication.” There was a strong need for a centralized location where each piece of documentation could live. Then, about a year ago, Doist took a page from the book of another company with a strong writing culture. Gitlab documents all their internal processes and knowledge in a company handbook and makes it available to the public.

In an effort to streamline communication and make their documentation more searchable, Doist has developed a handbook that’s housed in GitHub. The handbook includes everything anyone would need to know about working at Doist, and there are years of learning and transparency they can immediately draw upon. Whether it’s reading about the story of Doist, the company’s mission and values, revenue plans for the future, or HR practices and company policies, having access to this from day one lets people know what kind of journey to expect.

“Now, everything is searchable, which contributes to our culture of transparency. If anyone has a question, it’s likely that they’ll find a document for it.”

This initiative has strengthened Doist’s writing culture, and made it clear that having information documented in an accessible, centralized place makes employees more productive and strengthens company-wide transparency.

How writing has democratized Doist’s culture

Fadeke loves the way Doist prioritizes and relies on writing because she believes it makes employees more thoughtful about their work. “Allowing people to take the time to write out their thoughts gives them the opportunity to convey their ideas and express themselves in a way they wouldn’t be able to if they were just talking off-the-cuff,” she says. “People at Doist really have time to think through their ideas and make sure they’re communicating them in the most thoughtful way.”

“Having a culture that prioritizes writing is a great way to allow everyone to contribute more.”

Fadeke believes that having a writing-first culture democratizes communication at all levels. “Not everyone is extroverted, and some work cultures rely on people raising their hand and speaking up in meetings,” says Fadeke. “Having a culture that prioritizes writing is a great way to allow everyone to contribute more.”

Because Doist has always been remote, they've had found a lot of ways to build culture through writing. They do things like weekly Twist threads where people can share highlights from their weekend, or asynchronous, writing-based games of telephone. “Writing extends not just to how we work, but also how we play, and how we get to know one another,” says Fadeke.

The future will be well-documented

As for the next few years, Fadeke is confident that Doist’s writing culture will help the company continue to achieve its goals. “We have a wide range of team members from a range of countries, and being async enables us to maintain and grow that diversity,” she says.

“Other companies are stuck in a pattern where they confuse meetings with work, and that has to change.”

At this point, 80-90% of Doist’s communication is done asynchronously, and Fadeke sees this trend expanding in the future. “Writing is imperative to the sustainability of remote working culture,” she says. “Other companies are stuck in a pattern where they confuse meetings with work, and that has to change. Presence is easy to measure, but it’s detrimental to productivity.”

She predicts that as workplaces opt to stay remote indefinitely, a shift will occur. “Companies will start putting more trust in employees and allow them to communicate asynchronously,” she says. “We can rely on writing instead.” Doist has proven that operating this way isn’t just sustainable—it’s a superpower.

How writing culture helps Loom operate with autonomy and clarity

Tue, 08 Nov 2022 20:00:00 GMT

Vinay Hiremath is the co-founder and CTO of Loom.

Loom co-founders Vinay Hiremath and Joe Thomas have spent the last 6 years obsessing over asynchronous communication. They built an indispensable video messaging tool that empowers teams to communicate more effectively, wherever they are. Along the way, they built their own globally distributed team with a culture that relies heavily on knowledge sharing.

Leading with transparency is a core tenet of Loom's organizational philosophy. While defining a new category of async communication with video messaging, Loom still regards written documentation as a great way to empower their employees to function more autonomously. Writing allows for deep, clear thinking around strategy and ideation, and documentation captures the history of those decisions—giving the team a shared long-term memory that helps everyone make better, more informed decisions.

Here’s what Vinay has learned about building a thriving remote culture through written and asynchronous communication.

Many companies are sold on the importance of knowledge sharing, but it's easy to overlook the importance of first establishing an operational cadence—a rhythm for planning, executing, and communicating work. “I like to start with operational cadence. Write down your company strategy so everybody knows how their work contributes to that strategy," says Vinay.

When you're ready to propose a new idea or initiative, start with why you think it's important. This allows for producing written thoughts faster, for others to then fill in how you will execute this initiative, and eventually what you will do to fulfill this execution at the atomic level. "Plans become more ambiguous as you grow, which is fine because you empower the team to generate their own documents to define the clear, atomic what based on a string of logic that led you to those decisions," says Vinay. "This allows anyone to examine and re-examine that logic to make sure it makes sense."

Vinay understands smaller companies don’t have time to think about operational cadence initially. Survival mode for young companies means just get stuff done, no matter what. "But as you start to grow, you realize that aligning people to do the right thing, and not step on each other's toes, is really hard,” says Vinay. As the team grows and your company evolves, you need to start implementing processes like sprint planning and code reviews—other examples of operational cadence. "Ask your team to write a proposal describing how it rolls up to the company strategy when building something new,” says Vinay. Over time, writing becomes a natural part of the operational cadence.

From building products to building organizations

Vinay believes that establishing operational cadence and knowledge sharing is a sign you're no longer just building products, but building an organization—which is a transformation a lot of founders go through. "Building an organization comes down to information systems. All this valuable knowledge is your intellectual property. And data wants to be free," says Vinay.

Vinay has found that a lack of trust is what leads executives to make more decisions. But the goal should be to offer more strategic autonomy to individual contributors (ICs). If ICs feel more empowered to own part of the company strategy, they'll feel more fulfilled, and there will be more trust and autonomy from leadership.

Building and maintaining a strong writing culture has helped Loom’s employees feel empowered at work. “We’ve found that you can empower people to speak up when they think what they’re doing is BS," says Vinay, "but that requires a strong, clear practice of documenting company strategy.”

Sharing the strategy is just the first step—you also have to explain why the strategic goals exist. By sharing the why, team members understand how their work contributes to those goals, and can explain their rationale when proposing their own ideas. When there’s a clear line of thought behind each deliverable, everyone knows how they’re contributing to the company’s success.

How writing culture shapes Loom’s meetings

Vinay understands that meetings are important for rapid feedback like whiteboarding sessions, or for highlighting an important initiative to a group audience. But for Vinay and team, documentation often spurs meetings—not the other way around. They write pre-mortems and share pre-reads to provide context and avoid wasting meeting time where everyone is still processing the background information.

“The meetings we have now are important and serve a unique purpose,” says Vinay. For everything else, Slack and async communication are the norm. Prioritizing writing—and letting it dictate whether a meeting is necessary—has led to a healthier overall approach to meetings at Loom. "A lot of writing happens in Slack, which has its place, but clear thinking doesn't happen in Slack." With fewer meetings, Loom's team has more time for deep work.

How Loom’s writing culture has evolved

While Loom’s writing culture is now built into the company strategy, Vinay notes that it wasn’t always this way. “Early on, our main concern was survival. For young businesses, writing is low on the list of priorities, but at a certain point, a switch flips.”

For Loom, one of those switches was becoming a remote-first company five years ago. In order to maintain a high level of productivity across time zones they needed better asynchronous communication. But it hasn't always been easy. “A lot of people view writing as something that gets in the way of doing their job. They don’t see that the benefits of writing are compounded down the line,” says Vinay. To encourage knowledge sharing, Vinay recommends starting small and iterating. “Knowledge sharing doesn’t always have to be formalized writing. It can be a Slack message, it can be a Loom. What we’re really talking about is distilling information into an async format, and letting people across time zones benefit from that.”

Loom's iterative approach started with writing down scratch notes, then documenting bulleted lists for sprint planning, which eventually evolved into more strategic doc writing. "Start small, pick things to write about for your team that serve you, build your way up, and then evaluate how this documentation is benefitting your team."

As for the future state of communication and writing culture at Loom, Vinay would like to see writing become democratized more among engineers—not just product managers and designers. “I’d love to see engineers write more proposals. They have so many good ideas," says Vinay. "Seeing more early, small, imperfect proposals would be a sign that more people feel ownership in their roles.” And when people feel ownership over their work, everyone benefits—most importantly, the customer.

“We can’t rely on our memory to tell us why we made a decision," says Vinay. "You need to know why you took certain actions in order to make even more highly-leveraged decisions in the future.”

Salaries at Slab

Jason Chen — Mon, 07 Nov 2022 20:00:00 GMT

Remote work has been a part of Slab's roots since our earliest days. One reason we started Slab was to work with the best people—and we've always recognized that the very best talent doesn't necessarily all reside in one city in California. Two of the most capable individuals we've been able to work with call Poland and Australia home. Not being limited by location has allowed us to build a team that is more capable and diverse.

Working with great people is one way we live our value of "Stay Lean," where we strive to make the greatest possible impact with the fewest number of employees.

Our compensation policy is designed to be transparent, fair, and competitive across geographies. As part of that transparency, we're sharing our salary policy and why we think it's both fair and competitive.

Policy

We benchmark salaries with the San Francisco job market for companies at our valuation range, targeting the 75th percentile. We then multiply this by one of four geographic tiers of job market demand, from 0.7x to 1.0x.

Demand	Location	Multiplier
Highest	San Francisco and New York US tech centers	1.0x
High	Seattle, Austin, Los Angeles London, Sydney, Tokyo, Vancouver International tech centers, major US cities	0.9x
Medium	Barcelona, Beijing, Milan Major international cities, rest of the US	0.8x
Other	Rest of the world	0.7x

Philosophy

San Francisco is one of the largest and most robust job markets in our industry, making it the ideal source of consistent job data and baseline for calculations. We target the 75th percentile to be competitive, but this means we will often not deliver the highest offer a competitive candidate receives. We don't want scant compensation to be a problem, but we also don't want the salary to be the main reason candidates choose to join Slab. We want teammates who identify with our mission and values, are excited by the challenges ahead, and take pride in building and delivering a high-quality solution.

Why we have tiers at all

Perhaps the most contentious decision we made is to scale compensation according to geographic tiers. We acknowledge it can feel unfair for similar work to be paid unequally. But we believe our approach strikes the best balance of practicality and fairness for most people, while remaining competitive for all.

Aside from just the work aspect, taking living conditions into consideration shows the reality that different locations offer drastically different prices. For the cost of a 400-square-foot one-bedroom apartment in San Francisco, a much larger and more luxurious apartment could be found in Charlotte, North Carolina. If we asked for the same work from two engineers living in those places, one would be considerably more comfortable than the other—which can also feel unfair.

By adhering to a budget, paying one person more means having to pay another person less. Companies with uniform salaries across geographies may have unlimited budgets, or are choosing to be uncompetitive in top-tier markets like San Francisco. Since we believe great talent can be found anywhere, we aim to manage our finances with discipline while also staying competitive in top job markets.

Selecting our tiers

We chose four as the goldilocks number of geographic tiers. There needs to be a minimum number of tiers to accurately represent job markets worldwide. However, a high number of tiers is impractical since market data is highly imperfect. Even if it was, it would be extremely fluid and would mean disruptively moving cities between tiers too often.

Companies that accept being less competitive in San Francisco are often more competitive elsewhere. To still remain competitive with them, we set our lowest tier to 0.7x. This artificial floor does skew our competitiveness in some markets, but because our aim is the 75th percentile to begin with, this gives us enough wiggle room to still effectively achieve our competitive aim.

Progress

How we compensate and reward our Slab teammates is one of the most important demonstrations of our core values. Remote work—and even the concept of work itself—has undergone rapid developments in the past short years. We've designed our policy to meet these new realities in order to realize our "Stay Lean" value and attract top-tier talent in today's job market. As work dynamics continue to evolve, we'll continue to observe and adapt to stay competitive and fair.

Building an office for the digital age

Mon, 24 Oct 2022 20:00:00 GMT

If you’ve heard of social media, you’ve probably heard of Hootsuite. The social media management platform has been around for 13 years, operates in 13 regions around the world, and employs over 1,200 people. It was one of the first SaaS companies to exist in the social media space, and it remains one of the most prevalent.

Much of the company’s success over the years can be attributed to its adaptability. After all, which virtual landscape has changed more rapidly or dramatically over the years other than social media? Historically, this adaptability was focused outward: that is, any significant changes were implemented in response to the ever-changing social media landscape.

More recently, Hootsuite has shifted that focus inward. Along with many other companies, the pandemic changed the way the company approached its office environment. The company has committed to a hybrid model that offers both virtual and in-person options to its employees.

According to Hootsuite’s Senior Manager of Internal Communications, Alexis Sheridan, figuring out a hybrid work model that worked meant focusing on the company’s knowledge-sharing infrastructure, "We believe the virtual office experience is as important as the physical office experience."

Hootsuite has always approached knowledge sharing with the employee experience in mind. “We think about how to best set up our people for success by providing them with clear processes and engaging tools that allow them to powerfully connect with their peers and deliver great work,” she says.

In a hybrid office model, this means making communication easier. “Enabling our people to convey their ideas clearly and engage with peers via writing is extremely important.” Alexis knew that she and her team would have to build a framework that would make it just as easy to communicate via writing as it would be to communicate face-to-face in an office setting. The team started by identifying tools in their stack that had overlapping uses, then surveyed the whole company to identify the best channels for different types of communication. “The ultimate goal was to create a framework that would allow us to do less, better.”

In the end, Alexis and her team landed on a three-prong communications system that’s broken down as follows:

Email

Email is used for messaging with external parters and formal internal messaging like announcements, project kickoffs, and company updates. “Email isn’t going away anytime soon, but it is being used differently now than in the past,” says Alexis.

Slack

Slack is a catchall for everything informal. This includes one-to-one messaging, project messaging, and informal companywide communication. Slack allows Hootsuite’s employees to streamline noise, but it also creates a centralized hub for communication. It’s there just as much for casual communication as it is for getting up to speed on what’s happening with a particular project.

Intranet

Hootsuite has built a proprietary intranet that houses important resources and documents that can be referenced collectively. The purpose of this tool is to increase transparency and make information widely accessible to whomever needs to reach it. “We needed a place where each team could keep their information,” says Alexis. “Everyone knows and trusts that what's available here is reliable and up to date. Having this centralized source of truth fosters commitment and trust in the organization.”

Enabling authentic communication

Being clear about which modes of communication should be used in a number of contexts has been important; it’s the foundation that makes it possible for employees to communicate in an authentic and transparent way. As Alexis tells it, “Since the company is focused on social, our people understand the power of content and how to use applications to communicate ideas and information. Our focus is to provide the guidance that helps them do it effectively.”

Having the right communication processes and resources available increases alignment and breaks down silos. “There’s a huge emphasis on engagement, supporting one another, being collaborative, and recognition,” says Alexis. “These are all the result of emphasizing communication across the company.”

The great thing about working in a company that understands communication so well is that the point of communication is never belabored—people get it. “People understand how to write engaging copy in a way that gets people fired up and clearly communicates initiatives. Now they have clear guidelines around where all of that should live,” says Alexis.

Connection, engagement, and recognition—no matter the distance

The adaptability of Hootsuite’s employees has made it possible to adapt to the changes of a hybrid workplace. Employees have found new and innovative ways to stay connected from afar. “Being a global organization means we’ve always done virtual meetings. So from that point of view, transitioning to a hybrid model has been pretty seamless.”

As for the future of internal communications at Hootsuite, Alexis wants to see the focus on writing to communicate become even more ubiquitous. “Seeing people try out new communication formats that are engaging and accessible for all employees is a goal,” she says. “Whether people are in an office or not, we’re a global organization, so it’s critical to us to deliver tools that help all our people feel connected and inspired and do their best work.”

One key, many copies: How Lattice uses knowledge-sharing to find success

Mon, 03 Oct 2022 20:00:00 GMT

Lattice is a tool built to help people succeed. The performance management and employee engagement software gives companies the infrastructure to develop and scale their people management strategy.

It’s no surprise that Lattice views knowledge-sharing through the lens of making employees successful. They’ve gotten to where they are today by documenting and sharing the decisions, processes, and lessons that have helped them grow, as individuals and as a company. If knowledge-sharing is the key to the company’s success, each employee has a copy of that key—and is expected to use it. Emily Smith, as the Chief of Staff, is the master key-holder at Lattice. She facilitates the flow of information, both among leaders and within teams.

“Companies can’t scale when important knowledge only exists in peoples’ heads. Decisions and the context around them get lost if they’re not written down.”

In the spirit of knowledge-sharing, we sat down with Emily to discuss how this ethos is implemented at Lattice—and how it’s helped them succeed.

"The mistake people make when it comes to documentation is they expect documentation exists for people to refer to over and over, forever and always." says Emily. In reality, the documentation should serve as a source of truth. It's particularly helpful for:

Learning a new process (especially helpful when new people are onboarding)
When changing a process, and you need to know the context of why a process is the way it is
Understanding processes in other teams that are adjacent to yours

Emily is quick to add a caveat: “It’s not a replacement for knowledge. If someone needs to refer to documentation every time they do something, that process is too complicated,” she says.

Another challenge that many face when shaping how teams share knowledge: outdated information. According to Emily, it's pretty normal, "I think every wiki has out of date information." It's a part of the ever-evolving nature of knowledge.

At Lattice the whole team shares the responsibility of documenting and updating information, which lightens the load for individuals and gives the team ownership over their content. “There’s no single gatekeeper here. We’re big on using our wiki as a source of truth, and If someone finds something out of date, they’ll either update it themselves or contact the leader of that team to update it.”

Writing fuels decision-making

At Lattice, documentation is crucial to decision-making. “There are often scenarios when we need to go back and revisit important decisions to be able to understand our thinking at the time,” says Emily. When updating the company wiki, everyone is encouraged to keep the decision-making audience in mind:

What context will people need?
What are the main takeaways?
What are the goals?

“When we approach documentation with the mindset that people will be seeking it out when they need help with decision-making, we’re more successful.”

Creating push-and-pull information frameworks

While creating the right information resources at Lattice is important, so is knowing how to distribute it. It’s not as simple as pushing out all new information at all times. All stats and information are useful on some level, but sometimes too much access can be a distraction. Knowing who needs what information to do their jobs, vs. what should be available is key to eliminating noise and empowering autonomy.

“We need to create the right push-and-pull frameworks for the information that’s critical for people in their roles.”

To help the Lattice team distribute knowledge effectively, the team has a few questions they ask before sharing information:

Who is the main audience?
Who may want to reference this information later?

For example: When rolling out a new process to Lattice’s sales team, the process will also influence the customer experience team, but it’s not essential to how they function day-to-day. The author should focus on tailoring the information to the sales team, and then leave it up to the customer experience leaders to decide how they’ll share it within their own team.

Ironing out these details ahead of time makes a huge difference in how knowledge is documented and distributed, and keeps the information-sharing process focused and streamlined.

Lattice's culture of knowledge sharing expands beyond their own team, to their customers and the tech community as a whole. With a library of templates, ebooks, podcasts, and more, Lattice is committed to sharing learnings from their internal teams and customers.

Google popularized the OKR framework in 1999. The tech industry has learned a lot in 23 years about how to set goals, but as Emily points out, "Is that going to be the best way to set goals forever? Maybe not!" Sharing knowledge allows organizations like Lattice to learn together, but it also allows them to challenge their ways of thinking and grow over time.

At Sourcegraph, writing outweighs the “water-cooler mythos”

Wed, 14 Sep 2022 20:00:00 GMT

As a code intelligence platform built for software developers, both Sourcegraph’s employees and customers are well-versed in asynchronous communication. According to co-founder and Chief Technology Officer Beyang Liu, it’s always been more important to work with the best people than to have a workforce who could work from the same location. “Software development has always lent itself well to async workflows,” says Beyang.

Committing to a fully-remote team has allowed Sourcegraph to embrace its strength as a company: using writing to communicate, collaborate, plan, and grow. According to Beyang,

“Writing is the tool that has allowed us to scale with clarity and consistency over the years, especially having a geographically-distributed workforce.”

Sourcegraph’s office culture ditches the office altogether

When Sourcegraph went fully remote in January 2020, the team was already used to communicating via writing first, and it was obvious that working under the same roof wasn’t doing much to enable knowledge-sharing. “I think there’s often a ‘water-cooler mythos’ to office culture, where you run into people in the hallway and have these serendipitous conversations, but that wasn’t the vibe in our office,” says Beyang.

It’s not that meeting up face-to-face was discounted altogether—Beyang found that meaningful in-person interactions occurred outside of the day-to-day rhythm of the company. “All the face-to-face bonds were formed when we were all at an event like a conference together, where there was a source of information and entertainment that gave people something common to talk about,” he says. This discovery led them to devote their rent money to a travel budget instead.

While most companies that ditched their offices in 2020 found that they had to work hard to close the communication chasm that the change exposed, this wasn’t true at Sourcegraph. “Going fully remote was not a big leap for us,” says Beyang. This was due in large part to the writing-oriented tools and process the company introduced over the years.

Have a question? Check the handbook.

While Sourcegraph has always defaulted to documentation in order to share knowledge, the way that documentation was organized and catalogued became unsustainable as the company grew.

“We had a lot of disparate Google Docs floating around in Google Drive,” admits Beyang, which is why their documentation became unwieldy and hard to organize. To solve this, Sourcegraph took a page from GitLab’s book and created a company handbook. The handbook contains a great deal of documentation that lays out the operating system of the company.

“Any fact about how the company operates is committed to the handbook.”

The handbook is used heavily for onboarding, and as the source of truth for background or supplementary information. “Organizing all this helped to show how different policies and processes within the organization relate to one another,” says Beyang. Keeping it in one place ensures that everyone has access to important company information that’s up to date.

In an effort to prioritize transparency, the handbook is open to the public (and even has a section on why the company prefers asynchronous communication). “The open source world values transparency a lot,” says Beyang, so it was important to stay true to that when creating the handbook.

Making decisions, with or without meetings

In Sourcegraph’s early days, the company had a developer-oriented culture, and issues were surfaced and worked out asynchronously via an issue tracker, code review, and over Slack, but at some point, "it made sense to start writing things out more formally in documents, which is how the RFC [request for comments] process came about.”

The RFC process looks like this: if an employee has a proposal for something they’d like to change, they can draft an RFC. After documenting the proposed change, the employee can then tag the colleagues they’d like to receive feedback and approvals from within the document, quite literally a “request for comments.”

Requiring the RFC as the first step in proposing work means that meetings are only called when they’re truly needed. “Generally, if we can get something done without a meeting, we will,” says Beyang. It’s only when there’s some disagreement or tension from different stakeholders that it really makes sense to talk it out over Zoom.

How writing serves Sourcegraph’s customers

As a developer-oriented company, Sourcegraph communicates with their customers the same way they do internally. That means taking the company value of transparency and extending it further than most companies would. Sourcegraph invites customers to join Slack conversations, comment on public-facing documents, and weigh in on the company’s product roadmap, which is available for anyone who wants to see it. While this level of inclusion is rare in the tech world, Beyang wouldn’t have it any other way.

“There’s so much coordinated labor in the open source world that is driven by transparency. Keeping those channels of communication open ultimately lets us do better work.”

Sourcegraph will always default to writing first

Beyang doubles down on the idea that writing is the mechanism that has allowed the company to find its current success. “Talking is a great way to establish emotional resonance, but specifics can get lost,” he explains. “Writing something down helps you clearly articulate what you mean in the same way to everyone. It becomes a source of truth and levels the playing field.”

As for the future, Beyang wants to see documentation used as a default mode of communication even more than it is now. “There are many reasons to prefer the written word over the spoken word, and being able to build that level of clarity into every level of the organization will help us as we continue to scale.”

Beyang Liu is the CTO and co-founder of Sourcegraph, the code intelligence platform helping engineering teams understand, fix, and automate changes across their entire codebase. Many of the world’s leading use Sourcegraph to understand, fix, and automate across their code base, including 3/5 FAANG, Uber, Plaid, and GE. Prior to Sourcegraph, Beyang was a software engineer at Palantir Technologies where he developed new data analysis software for Fortune 500 companies. Beyang studied Computer Science at Stanford, where he published research in probabilistic graphical models and computer vision at the Stanford AI Lab.

Silent meetings and feedback on the count of three: How Ramp uses writing culture to grow

Tue, 30 Aug 2022 20:00:00 GMT

The term “silent meeting” might sound like an oxymoron. At Ramp, it’s one of the many innovative ways writing culture shapes the business.

Over the last three years, Ramp has rolled out its spend management platform and corporate card offering with the goal of helping finance teams understand their spending and grow strategically with a savings mindset.

Ramp’s growth as a business, while rapid, has also been deliberate. This is due in no small part to the writing culture that Megan Yen, VP Business & Revenue Operations, has helped implement since she joined the company in May 2020.

Over the past two years, Megan has overhauled Ramp’s meeting, onboarding, feedback, and goal-setting processes by injecting writing everywhere she can. “In my role, and within my team, I’m heavy on encouraging written documentation,” she says. “It’s the best way to scale knowledge sharing, and it encompasses everything I do and what I try to instill in the team’s culture.”

About those silent meetings...

When she joined Ramp, Megan noticed a lack of documentation throughout the company. While not uncommon for a young startup, it was negatively impacting efficiency. Meetings especially were longer and less focused than they needed to be.

“Things were not necessarily documented [at Ramp] early on. I saw that meetings could be more efficient.”

In addition to introducing meeting pre-reads and agendas, Megan created expectations around taking regular meeting notes—because, “In a startup, if you don’t write things down, you won’t remember.” These changes helped immensely in adding structure and efficiency to meetings. But Megan had some less conventional tricks up her sleeve as well. Enter the “silent meeting.”

Ramp’s Business Operations (or BizOps) functions as an internal consulting team that helps solve the company’s biggest problems. Because the team’s purpose is cross-functional by nature, each team member is working on their own unique problems at any given time. “It doesn’t always make sense to have a big discussion every time,” she says.

Throughout the week, Megan encourages her team to think about any issues or gaps that they notice in the business. Each team member writes out the issue they see, as well as a proposed solution. During the BizOps team’s bi-weekly meeting, the silent portion begins when Megan shares a document that contains each team member’s issues and solutions. Then, for 10 minutes, everyone has the chance to read through, vote on, and leave feedback on the issues and proposed solutions that each team member has documented over the last two weeks. When the 10 minutes are up, the team discusses the issues that have received the most votes.

This tactic has been a great way to speed up problem-solving and prevent the team from wasting time with 30-minute meetings to discuss one-off issues. It’s also helped the BizOps team clarify their ideas and communicate them concisely, and has been adopted by Sales and Sales Ops teams too. Writing out issues ahead of time is “a good forcing function for people to think critically about the message they’re trying to convey,” explains Megan. “It helps people better distill information.”

Writing culture starts on day one

Megan has made it a priority to build written knowledge sharing into Ramp’s onboarding process. New hires are introduced to the now-ubiquitous writing culture as soon as they join the company. “On my team, I always have a 30-minute onboarding session with new hires, and I have a whole doc ready for them with what to expect on day one, week one, and beyond,” says Megan. “Then I give them key documents for background knowledge that they’re expected to read before we meet next.”

“For new hires, it’s always reading first.”

While this practice started with Megan’s team, it’s becoming more prevalent throughout the company. Providing new hires with the information they need upfront helps them understand the company history, their team’s OKRs, and any additional context they need to be successful in their roles from day one.

Ramp uses Slab as a company wiki to house agendas, meeting notes, and team playbooks, all of which serve as references to help new hires get up to speed and get aligned quickly.

Team playbooks have become more common at Ramp. “They make a lot of sense for teams like sales, who can use these resources to learn what they need to know about the company, the product, and the processes they’ll be engaging with, as well as where to find things,” says Megan. The BizOps team is also helping to build out an FAQ database for the sales team, so they can easily find answers to any questions they may have.

Feedback on the count of three

Writing culture doesn’t just touch the day-to-day and onboarding processes at Ramp; it also influences how the company improves.

The way feedback is given in a group setting is often biased; people tend to adjust their response in reaction to what others have said. This can lead to missed opportunities when it comes to gaining valuable, actionable insights. To remedy this, Megan holds monthly feedback sessions to give each team member the chance to share their thoughts on what they’re working on and what could be improved. In an effort to solicit unbiased, straightforward feedback during these meetings, Megan asks her team to write out their thoughts beforehand. During the meeting, everyone pastes their feedback into a shared document on the count of three. They then discuss each person’s feedback and how they can use it to make improvements.

Having the team share simultaneously circumvents the problem of adjusting feedback based on the discussion at hand. Plus, writing out feedback beforehand forces people to lay out their thoughts in a clear, structured way, and focus on the root issue.

A progressive point of view on goal-setting

As Ramp continues to grow and mature, Megan is making sure that the company is able to measure its progress and success the right way—which, sure enough, involves a lot of writing.

Each team is responsible for updating a bi-weekly OKR tracker, which uses a framework to write out their progress, plans, and problems. Goals are measured and set on a quarterly basis, with documentation showing Ramp's continuous progress.

“Without written documentation, knowledge sharing would be very one-off, like a game of telephone.”

As for where Ramp’s writing culture will go in the future, Megan has more innovative ideas up her sleeve. “I’m really interested to see how I can help other teams throughout the company get better through writing,” she says.

She’s also excited to see which ideas her team will bring to the table. “I constantly ask them to look for new ways of working that we could try,” she says. And when they find an idea to try, they can bring it up for discussion in a meeting—but not without writing it out first.

Upcoming CSS Features to Look Forward to

Zihua Li — Thu, 21 Jul 2022 20:00:00 GMT

CSS specs and implementations have rapidly improved in recent years. Engineers are more than ever freed from ancient tricks like clearfix. Instead, they can truly focus on delivering a great user experience. In this article, we will look at some CSS features on the horizon that we at Slab can't wait to use.

Container Queries

You are already familiar with the screen size media queries. We use them extensively at Slab for our mobile web support.

However, querying on screen size is limiting. Taking our post page as an example, to deliver the best reading experience, we expand comments based on the available width. This width is not only determined by the window width but also by the site sidebar's collapsed state.

Today, we rely on additional classes added using JavaScript to indicate the sidebar state along with media queries. This is what a simplified code looks like:

$sidebarWidth: 200px;
$mobileBreakpoint: 680px;

.post-view {
  @include wideStyle;

  &.sidebar-collapsed {
    @media (max-width: $mobileBreakpoint) {
      @include narrowStyle;
    }
  }

  &.sidebar-expanded {
    @media (max-width: $mobileBreakpoint - $sidebarWidth) {
      @include narrowStyle;
    }
  }
}

Container queries, a new CSS feature, will remove the reliance on JavaScript and make code easier to read. Container queries are similar to media queries, except that the former queries against a DOM node instead of the entire viewport.

.post-view {
  @include wideStyle;
  container-type: inline-size;

  @container (max-width: 480px) {
    @include narrowStyle;
  }
}

To learn more about the syntax, check out this demo.

Cascade Layers

"Cascading" is literally in CSS's name. It's a fundamental feature. But managing specificity in a large app is not always easy. We've probably all encountered bugs caused by accidental style overrides.

When overriding external libraries' default styling, we are also often limited by their specific selector choice to match the specificity. Take our own rich text editor, Quill, as an example. It defines styles for list items with the selector li:not(.ql-direction-rtl) to ensure they only apply to languages written from left to right. So if you want to override Quill's list style, you'd need to include the :not(.ql-direction-rtl) part to match the specificity of the original rule:

@import 'quill/theme.css';

li,
li:not(.ql-direction-rtl) {
  /* Our styles go here */
}

CSS cascade layer provides a way to simplify, as it divides the CSS definitions into multiple layers, with CSS specificities isolated inside each layer.

We use @layer to define layers and specify their priorities:

/* Layers are defined from lowest priority to highest */
@layer quill, application;

With all layers defined, we can add styles to each layer and safely assume that, in our case, styles in the application layer will always have a higher priority than styles in framework, without worrying about specificity:

@layer quill {
  @import 'quill/theme.css';
}

@layer application {
  li {
    /* Our styles go here */
    /* Styles defined here ALWAYS take priority over styles in quill ✌️ */
  }
}

`:has()` Pseudo-Class

Many of you know about :has() from jQuery. :has() is used to select a node whose descendants match the supplied selector. For example, $('figure:has(> figcaption)') will find all <figure> that have a caption element as their direct child.

However, developers never had a chance to use it in their CSS code as no browsers supported it until very recently.

jQuery supports :has() because it was in the spec of CSS 3 selectors, and jQuery aimed to support all those selectors. However, :has() was postponed due to performance and complexity concerns. You can learn more about why performance is a concern from this blog post, written 12 years ago 😄.

Safari 15.4 is the first browser that provides :has() in CSS, allowing you to use the pseudo class directly in CSS as you did in jQuery:

figure:has(> figcaption) {
  border: 1px solid #ccc;
}

Without :has(), we would have to determine whether figure contains figcaption in JavaScript, and add different classes to figure to give it a different style.

Accent Color

HTML form controls, outside of text inputs, are hard to customize. The lack of browser support often leads to fully customized checkbox/radio controls. For example, at Slab, we create our pseudo checkbox/radio out of necessity to match our general UI style.

Such a solution adds complexity to the code. It also often leaves out the accessibility support.

The good news is major browsers have recently provided a new CSS property accent-color to set the accent color of controls. If we want to make checkboxes red when they are checked:

input[type="checkbox"] {
  accent-color: red;
}

Isn't that a lot easier? You can take a look at how this property works on different controls:

See the Pen Accent color by Slab (@slabhq) on CodePen.

VirtualKeyboard API

If you're an iOS developer, you're familiar with inputAccessoryView. It is a view that sits on top of the soft keyboard. This UI pattern is extremely common in real-world apps: a messaging app like the one shown in the diagram usually has the send button on top of the soft keyboard. Slab also has a similar view for post comments on mobile devices.

However, it isn't easy to achieve a similar effect with CSS. There is no native positioning rule that puts an element above the soft keyboard. There is also no good API to get the height of the keyboard for manual positioning. The only one that could work is to leverage VisualViewport API, but it would be very laggy because all the calculations are done in JavaScript. During scrolling, the user experience is quite bad.

VirtualKeyboard API provides the proper solution. Luckily, Chrome has already implemented the support. The standard provides not only JavaScript APIs but also a set of CSS environment variables that describe the size of the soft keyboard. The following code uses keyboard-inset-height to make .send-button always stays on top of the keyboard:

.send-button {
  position: fixed;
  bottom: 0;
  margin-bottom: calc(20px + env(keyboard-inset-height));
}

If the soft keyboard is closed, keyboard-inset-height is 0, so .send-button stays at the bottom. When the soft keyboard opens, the value becomes the height of the keyboard, making .send-button the same distance from the bottom as the height of the keyboard.

VirtualKeyboard API is a pure CSS solution, so it works much more smoothly than calculating every frame in JavaScript. You can also add animation effects with transition: margin-bottom.

Scrollbar Gutter

When an element becomes scrollable, as shown in the figure, the presence of the scrollbar affects the available width, which leads to the reflowing of content. Usually, this is a bad user experience. With Slab, this could happen easily as users write out their posts.

If you are using a Trackpad on macOS, scrollbars show as overlays, which don't have such problems. To see this issue, you can set the scrollbar to always show in System Preferences.

A new CSS property scrollbar-gutter can fix this issue. When set to stable, the scrollbar space is reserved even when the scrollbar itself is not needed/visible:

scrollbar-gutter: stable;

It's currently not possible to draw over the reserved space, so it may not look good if there are elements on the page that extend to the full width of the container. You can find more information here.

Closing Thoughts

Delivering a great experience has always been a priority at Slab. We are excited that the above features make it easier to do that for our users.

Although it will be some time before all major browsers support the listed features, we are more optimistic than ever about the adaptation of new CSS technologies with the help of automatically updated browsers and polyfills provided by the web community. The browser vendors are placing increasing importance on Web standards compatibility and addressing developer pain points.

Interop 2022, for example, is a benchmark for evaluating how well browsers support certain key features. Some of the features described in this post, such as the cascade layers, are also included in the evaluation. The major browser vendors agreed on this benchmark and are working together to provide support. You can find the current level of support for each browser here.

Writing: The silent teammate behind Help Scout’s success

Tue, 26 Oct 2021 20:00:00 GMT

Help Scout’s employees are used to reading what their CEO and co-founder Nick Francis has to say. For the past 96 Fridays (and counting), it’s been his tradition to send out weekly notes spanning topics from company updates to whatever is on his mind.

As Suchada Stevens, Help Scout’s People Ops Business Partner, tells it, reading one of these “Friday Notes” solidified the importance of the company’s writing culture for her.

Nick wrote, “Writing catalyzes clarity of thought. When done well, it demonstrates a certain mastery of the information being shared. If you understand every angle and nuance of a deeply complex topic or project, you owe it to others to share it in a way that's clear and easy to understand.”

“It captures a lot of what I've observed coming into this organization,” explains Suchada, who joined the team earlier this year. “Our CEO is a creative, and he’s always going to foster an environment where our vision is communicated and shared through writing.”

Help Scout is a fully-remote organization, and has been for the last ten years. So while most companies are just beginning to discover the nuances of remote communication, Help Scout has quite literally built their company through writing. As Suchada puts it, “We often have no choice but to default to asynchronous communication, and in order to do that well, we have to have a strong writing culture.”

While writing permeates each part of Help Scout’s business, it’s most evident in three key areas: planning meetings, sharing specialized knowledge, and growing the company.

No pre-read, no meeting

Not only is Help Scout a remote company, it’s also a global one, with employees from Australia to Ukraine.

Because of the vast differences in time zones, meeting times that work for everyone are scarce. In order to make meetings as quick and productive as possible, the organizer is expected to provide a pre-read for attendees to review in advance. If this isn’t provided, “people will let you know,” says Suchada.

Pre-reads cover any background context that meeting attendees will need, as well as an agenda and a summary of what the organizer wants to accomplish during the allotted time.

“[Pre-reads ensure that] what’s discussed in meetings is exactly what needs to be discussed. Everyone goes in understanding what we want the outcome to be,” says Suchada. “And if I’m 48 hours out from a meeting and am still missing information that should be included in the pre-read, it forces me to cancel that meeting, and cancel it early.”

"[Pre-reads ensure that] what’s discussed in meetings is exactly what needs to be discussed."

This approach also forces employees to think critically about whether there needs to be a meeting at all. “Sometimes I’ll get started on putting together a pre-read and realize that what I have to say could easily be communicated in a Slack message,” says Suchada.

Documentation: the silent teammate

As Help Scout’s CEO put it in that storied Friday Note, writing culture is a necessary part of “catalyzing clarity of thought.”

Many of Help Scout’s employees are experts in their field, and are the only people who do what they do. In order for these employees to share their knowledge with those who need it, good writing is essential. “You have to provide a lot of information to bring people along with your thoughts,” says Suchada. “It’s an adjustment for people, the amount that you have to write in order to give people the right context. Sometimes you feel like you’re overdoing it, but when you’re on the receiving end of that knowledge sharing, there’s never too much.”

"Writing is how we move things forward. The way we communicate has to capture that clarity and mastery that our experts have."

Because of the amount of writing that’s needed—and expected—in order to share knowledge, Help Scout’s head of customers started calling internal documentation the “Silent Teammate,” and the term stuck.

Suchada has learned to always look for documentation first if she has a question. “It’s been helpful for me to type what I’m looking for into the Slab search bar, and more often than not, the information I need is already well-documented.”

Information that isn’t documented never stays that way for long. Per Suchada, “a good rule of thumb that we use is if someone asks you for something more than once, it should be documented.”

Operating this way isn’t just a byproduct of being remote; it’s an intentional choice that allows Help Scout to truly thrive as a distributed company. “I'm on the west coast, so when I start my day, there are people who are getting ready to sign off, or pick up their kids from school,” says Suchada. “If we didn’t have a really effective system for writing and reading, we just wouldn’t be able to get anything done.”

Help Scout’s future is still being written

Help Scout is growing, and inherent to that growth is a commitment to keep their writing culture strong.

It’s even built into their hiring process. Candidates are given a project to complete, which includes a presentation. While the presentation helps to gauge the candidate's mastery and thoughtfulness, it’s also a great way to get a read on their communication skills.

It’s not necessarily a formal consideration in the hiring process, but the way a candidate communicates over email during the hiring process can provide helpful insight into what it would be like to work with them. “Things like how quickly they respond or the level of thoughtfulness in their response mean something more, given how much we rely on written communication,” says Suchada.

"We don't have that luxury of always being able to meet face-to-face or pop into people's offices."

New hires are immersed in Help Scout’s writing culture from day one. Whether it’s setting up their “Player Roadmaps” with personal and professional development goals or looking through the onboarding material available in Slab, it’s understood and well-communicated that if there’s anything new employees need to know, it’s available for them to read.

Suchada says that writing will always be an outlet for creativity at Help Scout, and a channel for introducing and solidifying processes. She sees the company using documentation to add more guardrails as they continue to grow. For now, though, her team uses Slab to communicate standard employee documentation like handbooks, policies, processes, and action plans.

If anything else changes at Help Scout in the future, Suchada is sure she’ll read about it first.

Short Toes: How GitLab's Values Shape Company Documentation

Rebecca Acree — Thu, 27 May 2021 20:00:00 GMT

While many companies are navigating the challenges of remote work for the first time, for GitLab, it's nothing new. The company has been fully-remote since its inception, and has over 1,300 employees in 65 countries around the world. As the San Francisco Chronicle puts it, "GitLab was remote before remote was cool."

Darren Murph has been GitLab's Head of Remote since 2019, and perhaps unsurprisingly, is now a wildly in-demand resource for advice on navigating the brave new world of remote work. We sat down with Murph to learn how his team has shaped a culture of documentation to match their company values.

A Single Source of Truth

According to Murph, the first thing to know is that companies need a single source of truth to operate effectively. What they do and how they do it must be written down, and it can't be stale or stagnant. Company documentation should be a living, breathing thing, something that employees are motivated to actively invest in, beyond just looking up information when they have questions. "It can't be just this reference thing," Murph says. "It has to be the heartbeat of where work happens."

Now that so many companies around the globe are working remotely — and many plan to do so indefinitely — the need for this kind of deeply-ingrained documentation is stronger than ever.

“You need a single source of truth. If you have multiple sources of truth, organizationally, people will have less faith and understanding that [the information] matters and they can trust it.”

CREDIT Where Credit Is Due

GitLab has six core values: collaboration, results, efficiency, diversity & inclusion, iteration, and transparency (CREDIT). Each of these values drives the company's approach to documentation and ensures that every employee is empowered to do their best work.

Collaboration

Every employee at GitLab is encouraged to contribute. This applies to everything from small daily tasks all the way up to the CEO's work. Team, title, and tenure are all secondary to the spirit of open communication. As GitLab puts it, its employees have "short toes" — meaning it's not possible to step on anyone's toes, because collaboration is always welcomed. Being able to contribute to high-level projects like the company handbook gives employees a sense of ownership and buy-in from day one.

Results

GitLab's commitment to results extends to every aspect of its work, including documentation practices. The team keeps a close eye on when the various sections of the company handbook were last updated, and page maintainers receive regular pings to remind them to keep content fresh. This way, the handbook adapts alongside the company in real time.

GitLab's CEO, Sid Sijbrandij, worked on the earliest versions of the company handbook, including a section that explained how to use it. This section was shown to all new hires — they came in with no deep understanding of the company culture and processes but still could follow the steps in the handbook to start contributing right away. As Murph says, it's helpful to have documentation be a single employee's job, but it's better to be able to make it everyone's job.

Eventually, though, the company grew to the point that an official role was needed to support its dedication to remote work, and thus the Head of Remote role was born. Together, GitLab and Murph pioneered the role to adapt the company's workflows to be remote-first.

As the company's documentation on the Head of Remote role notes, working remotely is too important to leave to chance. For large companies, the benefit of this role is clear, but Murph recommends hiring a chief documentarian for companies that aren't yet ready for a Head of Remote. A chief documentarian will codify the ways the company works, which is essential for a successful remote culture. This person needs strong editorial skills and journalistic thinking, so ex-editors, publishers, or internal communications managers have ideal backgrounds, according to Murph. After all, "a company is a series of stories," he says, so companies need someone who understands those stories and can document them accordingly.

“A company is a series of stories.”

Efficiency

Sometimes, employees don't want to take the time to write because it feels inefficient and slow. This can be true on a micro level, but on the macro level, the value of documentation is hard to understand — it has a "compounding interest," according to Murph. So GitLab spends time helping its employees understand how documentation helps them to share knowledge and "pay it forward."

This is especially true in today's increasingly remote environment — "writing well just went from a 'nice-to-have' skill to an absolute business essential skill in a post-COVID world," says Murph. But what does it mean to write well? Murph identifies effective communication as a key challenge that companies must overcome if they want to invest in documentation. He recommends utilizing a learning and development team to create writing curriculum. In the absence of a dedicated L&D team, an existing employee who demonstrates strong writing skills can lead the way. Resources like Udemy's Better Business Writing Skills or Stephen King's On Writing can serve as a starting point.

Diversity & Inclusion

GitLab's commitment to diversity and inclusion drives the company to hire across the globe, and this makes documentation all the more important. Asynchronous communication is used whenever possible in order to be inclusive of employees in various timezones and on different schedules, and everyone is encouraged to default to documentation above all else.

"People at GitLab are resistant to changes that aren't documented," according to Murph. Decisions and changes may occasionally rolled out via Slack, email, or other communication tools, but they're not real until they're officially documented.

Iteration

Iteration has been key to GitLab's success with documentation. The company handbook is one of the most thorough and high-quality in existence, and that didn't happen overnight. "It's a journey of iteration," says Murph. He recommends starting at the most basic level of company information — mission and values. Investing in this first builds a strong foundation for documentation to come. Then, each team writes down how they work and what they do. This is, and will always be, a work in progress. According to Murph, nothing is assumed, and therefore constant input and iteration is necessary to success. "You want to do all you can to empower people to update," he says, so that "everyone's bought in."

Transparency

From the very first day of their tenure at GitLab, employees opt into a working environment in which everything is written and read. This is clearly communicated throughout the hiring process, so it tends to already be the preferred MO of new employees — like attracts like. As Murph explains, "If it's not in the handbook, it doesn't exist." This ensures that every employee is operating from the same well of information, thus leveling the playing field and making teamwork and decision-making far more efficient.

“If it's not in the handbook, it doesn't exist.”

In fact, GitLab takes transparency so seriously that it publishes its handbook for anyone in the world to access. "Everything we do is public by default," the handbook reads. By documenting everything and being highly transparent with that documentation, GitLab reduces barriers to feedback and contribution not only internally, but externally as well.

Handbook-first documentation is key to GitLab's success

As a company grows, as does the need for formal documentation, along with the cost of avoiding it. GitLab scales by documenting, and the results speak for themselves — their handbook is over 10,000 pages, and the company is one of the largest all-remote organizations in the world.

This achievement requires constant attention and commitment, but it pays off. As Murph says, "The work has to end up in the handbook…if you tie the work to the handbook, it becomes easy. You don't have to force people to do anything. It is where your work happens."

How HashiCorp Makes Writing a Priority

Rebecca Acree — Fri, 07 May 2021 20:00:00 GMT

The start of the COVID-19 pandemic and resulting shift to remote work was a big wake-up call for many companies. With workforces distributed, companies need a better way to share knowledge, and they need it fast. Teams now have a priority to develop a system for documenting their knowledge.

We spoke with Kevin Fisher, Chief of Staff at HashiCorp, to learn how teams can build a culture of documentation that scales as they do.

Good Writing Means Good Work

A strong culture of writing and documentation is increasingly essential for teams to make good decisions and do their best work. Writing helps the HashiCorp team:

Gain clarity. Writing encourages thoroughness and detail in decision making. Information delivered in writing is less likely to be misinterpreted than if shared verbally; you can be more precise with your language.
Provide feedback. In written form, knowledge can easily be reviewed and critiqued. HashiCorp employees are very good at critiquing the written ideas without personally criticizing the author. The full team is dedicated to making the decision as best as it can be without personal attachment to ideas.
Save time. Rather than using endless meetings to debate decisions, proposals can be reviewed in full detail before a meeting. Then the meeting is dedicated to specific questions and making a final decision.
Collaborate across time zones. For companies with a majority of their employees working remotely, especially if they are widely dispersed geographically, it becomes almost unavoidable to write. Fishner sees writing as a way “for people to still be in the loop and contribute and be heard, regardless of what time zone they work in."

Building a Culture of Documentation

If your team has historically struggled with documentation, it may feel like it's too late to turn things around. But don't worry — it's never too late to start investing in a culture of writing. The longer you wait, the more committed you will need to be, Fishner says, but it's always possible to make documentation a priority.

He recommends three main levers to promote writing across a team: leading by example, making documentation an expectation, and defining a process.

Lead by Example

Writing is encouraged and often required within HashiCorp, and it starts at the top. Company executives are comfortable with documentation and execute their primary responsibilities through writing — they serve as role models, demonstrating the very skills they require of their employees. At the same time, their work product serves as an example of the desired quality in documentation.

Fishner makes it clear that leading by example is essential for making documentation a priority. Whether you're an executive or a team member, if you want to instill a writing culture — just start. For the next decision you need to make, propose it in writing. Other colleagues involved in that process will appreciate the effort to write a detailed proposal, and potentially adopt it for the next time they need to make a decision. Good practices that produce good outcomes are easier to spread. He recommends identifying company leaders who can serve as role models for good writing, and have them create examples through their own work. As long as leaders keep writing, Fishner says, a culture of documentation will endure.

“As long as leaders keep writing, a culture of documentation will endure.”

Larger companies should start with one team and make writing a priority within that team. This allows you to experiment and figure out what works and what doesn't before taking your learnings company-wide. Starting with a team that already exhibits good documentation practices will help give you a leg up.

No matter your company size, the longer you wait, the harder it will be to adopt writing-based practices. Lead by example, and others will follow.

Make Documentation an Expectation

Making documentation an expectation for making decisions will help you shift your company culture towards writing. At HashiCorp, important decisions are not accepted unless they're written down, and many teams specifically include writing as an area of evaluation during performance reviews.

Prospective employees are also clued into the importance of writing at HashiCorp. Product manager applicants, for example, are required to complete a written case study, in which they produce a 24-month product strategy and a 12-month roadmap, all in two pages or less. This makes it very clear to prospective employees that writing will be key part of the role.

It's important to note that there isn't just one way to write effectively. Don't over-index on a certain type or style of writing, or a perceived level of quality, as these can be limiting barriers. As Fishner says, “Just because there is a set template that we follow doesn't mean we expect everybody to write the same. People approach problems differently. People communicate differently. So, there's a responsibility on the reader to also put in an effort to understand. It's not just all about the writer.”

“There's a responsibility on the reader to also put in an effort to understand. It's not just all about the writer.”

Create a Clear Process

In Fishner's experience, business writing is a skill that can be continuously improved. Creating (and documenting!) a clear process for internal writing and documentation is an easy way to help your employees learn.

First, decide what should and shouldn't be written down. At HashiCorp, the guideline is relatively simple: if it's a major change within a team or if it's a minor change affecting multiple teams, write it down. Everything else can be discussed verbally or via email or Slack.

For just as under-documenting can waste time and cause confusion, so can over-documentation. If you're unsure where to start, Fishner recommends defining what constitutes a major versus minor change.

Then, outline the process. For HashiCorp, research is the first step, then writing, then feedback. To help streamline the writing step, consider making use of templates. This gives employees a better understanding of the underlying structure that supports effective writing. The the two primary document types used across HashiCorp are the PRD (Problem Requirements Document) and RFC (Request for Comment).

Aim for Improvement, Not Perfection

There's no one-size-fits all solution for becoming a company that practices effective writing and documentation. Be patient, and be prepared to try out multiple strategies to see what works for your company.

Great documentation is not going to spring up overnight, so don't aim for perfection right away, and simply focus on what works. Start with small goals, and celebrate your wins. After all, just by reading this, you've already undertaken the hardest part — getting started.

To learn more about HashiCorp's writing practices and view their PRD and RFC templates, check out the How HashiCorp Works article.

Uber’s 3-Step Approach to Getting More Engineers to Document

Rebecca Acree — Tue, 09 Mar 2021 20:00:00 GMT

Documentation isn’t always a top priority for engineers. That’s a challenge nearly every company experiences, including Uber.

“There are always so many other things on engineers’ plates,” says Stephanie Blotner, Technical Writer at Uber. “How do you make documentation a priority?”

Uber has engaged with this challenge using three methods: cultivating motivation, providing education, and reducing tooling friction.

Cultivating Motivation

Documentation gets written when employees are motivated to write. Uber achieves this in a few different ways.

First, documenting code is a part of software engineers’ competencies, which are used for performance evaluations.

“We're saying documentation is important. Not only for your team, but for your career.”

Company leaders also share messaging around the importance of documentation in emails, all-hands meetings, and other communication.

Proactively, you’ll hear managers tell an engineer: we think it’s important you document what you build to help other engineers. Reactively, leaders recognize and celebrate teams that document effectively. They then set these teams’ approach as the company standard.

Blotner and her team motivate engineers by showing them how documentation can alleviate specific pain points. For example, if she identifies that one engineering team constantly answers questions from other teams, Blotner shows exactly how documentation can solve that problem.

“We want to make it clear that we’re not documenting things just for show,” she says. “We’re doing it to solve a specific problem.”

Blotner and her team could go to each department and encourage engineers to document. But it’s far more effective to have someone from within a team lead by example.

She and her team identify managers and employees passionate about documentation and encourage them to serve as stewards of writing. She then sends a newsletter to teams where she identifies Doc Stars—colleagues who create and update quality documentation.

Teammates have told her how exciting it was to be publicly recognized. She’s seen how it encourages them to continue their best practices.

She’s also seen the number of Doc Stars increase, indicating that this public recognition is inspiring others to document.

Providing Education

Being motivated to write isn’t the same as documenting effectively. At Uber, educating engineers on how to document starts from day one.

All new engineers and engineering managers attend a technical communication course during their onboarding. This course, taught by either a tech writer or fellow engineer, helps new team members know the importance of documentation, when to document, and how to break down ideas for easier consumption.

The onboarding course is about an hour in length, so it only touches the surface of good writing. To compensate, Blotner's team also offers an optional monthly tech writing course.

This course dives deep into how to write effective documentation by focusing on common writing bugs and how to address them.

Two common writing bugs Blotner's seen over the years are:

Lack of empathy—Engineers may not fully consider their audience when writing, which can lead them to confuse the reader with either too little, or too much, context.
Grammar—Many people default to the passive voice, but technical documentation is more actionable when written in the active voice.

While grammar is a concrete concept, empathy is not. That can make it harder to teach others. But at Uber, they’ve made this experience as concrete as possible. They’ve created a checklist of questions engineers can ask themselves to ensure they keep their audience's needs in mind.

Questions like "who is the audience," "what is their workflow," and "what are their pain points" keep the audience top-of-mind. Overall, Blotner hasn’t found too many engineers who struggle with understanding why empathy is important. “I think [that's] because they’ve experienced it themselves,” she says. “They’ve been on the receiving end [of poor documentation].”

Reducing Tooling Friction

Building a writing culture means reducing any friction involved in the process. Education helps—the more confident the writer, the more willing they are to write.

“We don’t need to add more friction to writing. There’s enough friction there, already.”

But friction also occurs within the tools you use, particularly when teams have preferences for where they document. This can create fractured knowledge and writing experiences.

Blotner admits that siloed information is an issue at Uber. The good news is that engineers have contributed a lot of content. But it lives in many different places, making it hard to navigate. That can lead to duplicate and stale information.

“That can reduce the motivation to write,” she says. “Because you may think, ‘Oh if I write this, and no one can find it, what’s the point?’”

To address this, Uber’s Technical Writing team takes a two-pronged approach:

When writing: Her team meets people where they prefer to be. If an engineer wants to draft or collaborate in a certain tool, so be it.
When publishing: When the content is ready for public consumption, it’s moved to a consistent location (either by publishing directly to that location, or embedding it).

A Writing Culture Like Uber's Takes Effort

Uber has made conscious efforts to nurture their internal writing culture. They’ve realized that good documentation doesn’t come through a mandate. People need to be motivated to exert this additional effort in their day. Seeing how documentation can improve their lives gives them this motivation.

The courses and workshops dedicated to tech writing don't just educate employees—they demonstrate how much importance the Engineering organization places on good writing.

And thinking of ways to reduce friction—across the entire writing experience—ensures that the writing culture Uber has built will remain, regardless of changes along the way.

This post describes Stephanie’s personal opinions and does not necessarily reflect the views of Uber.

From Procedural to New Knowledge: Leveraging Your Team’s Know-How

RC Victorino — Wed, 09 Sep 2020 20:00:00 GMT

Employees who master a job-related skill are incredibly valuable to their company.

They require little oversight when performing tasks tied to that skill — meaning they save their company time, money, and resources.

Procedural knowledge is at the core of this mastery.

What is procedural knowledge?

In cognitive psychology, procedural knowledge is the type of knowledge used when performing a task. You can think of it as know-how knowledge. “I know how to drive a car,” “I know how to bake a cake,” and “I know how to debug code” are all examples of procedural knowledge.

This differs from declarative knowledge, often referred to as know-that knowledge (“I know that the sky is blue,” “that rent is due on the 1st,” and “that my cat will randomly attack me today”).

You achieve procedural knowledge through the constant practice of a new skill — until that new skill becomes automatic.

For example, you give your employee, Sarah, a guide on running A/B tests with Google Optimize. She relies on that guide — and feedback from you — to run her first few tests.

After repeating the process a handful of times, she’s able to launch, monitor, and analyze A/B tests on her own. She’s developed procedural knowledge around this task; she can work independently.

How procedural knowledge leads to new knowledge

One limitation of procedural knowledge is that it represents what is, and not what can or will be. If Sarah never strayed from the Google Optimize guide she learned from, she would never optimize her skillset.

Fortunately, most employees who master a skill inevitably broaden their understanding of that skill and introduce new perspectives. They find ways to perform their task more effectively and efficiently.

For example, because Sarah mastered your team’s A/B process, she no longer needs that initial guide. More appropriately explained, she’s no longer limited by it. Her familiarity with the process allows her to broaden her understanding of this new skill. It’s only natural that over time she’ll refine her method to improve its efficiency.

Your team would likely benefit from these refinements — but at the moment, they remain personal to Sarah. And it’s fairly common for employees like Sarah not to share the personal knowledge they develop around a particular skill or task.

Knowledge hoarding is a possible cause, but the more likely culprit is that employees are often unable to see beyond their habits and customary practices.

They don’t realize they’ve created valuable knowledge worth sharing — so they don’t share it. This can create gaps in your knowledge management system.

Sarah wasn’t self-aware of changes she made in her approach. Most employees don’t have this self-awareness.

But self-awareness isn’t necessary for teams to leverage the knowledge employees create around specific skills or tasks.

What is necessary is creating an opportunity for shared experiences.

Using shared experiences to capture new knowledge

Documenting is arguably the most effective way to capture and share valuable knowledge. Writing requires you to think critically and clearly about your process.

However, some knowledge — like the personal knowledge people acquire after mastering a skill — can be challenging to document at first.

Shared experiences can help. They eliminate the friction associated with documenting one’s personal knowledge. They allow knowledge holders to demonstrate (or show) their knowledge before transferring it into words.

It might be easier, for example, for Sarah to first demonstrate her Google Optimize workflow to her teammates. Demonstrating her process allows her to walk through each step naturally, rather than pause to document. Also, by showing her process first, she’s less likely to gloss over steps she’s taken for granted.

The receivers of new knowledge also benefit from shared experiences. They can ask questions for clarification and request support when they’re stuck. They can also offer feedback and suggestions that refine the process even further.

Through this shared experience, both the receivers and knowledge holders can reach a consensus of the critical steps and language required to document this process so it’s replicable at scale.

Tip: Shared experiences don’t have to be synchronous. However, the most effective shared experiences for transferring knowledge allow the receivers to observe the task being performed and allow the knowledge holder to observe the receivers perform that task.

Creating shared experiences in your workplace

Creating shared experiences doesn’t have to be resource-intensive. You can integrate them into your team’s existing meeting rotation.

For example, if you hold a weekly scrum meeting, replace that meeting once every month with a show-and-tell session, where one employee demonstrates a specific task they perform, while her teammates observe and document the process.

This approach works best within teams (rather than across teams) because the audience will likely have a basic contextual foundation for better understanding.

Let’s use Sarah again to demonstrate how this show-and-tell session works.

Sarah showcases her A/B workflow to the rest of her growth team. Her teammates stop her when they’re confused, ask questions for clarification, and provide feedback.

During this process, one teammate — designated as the scribe — documents the steps Sarah showcases. The scribe’s goal is to create a running list of all the elements (and language) that the team agrees make this process replicable.

After the demonstration, the team reviews the scribe’s notes to fill any knowledge gaps and eliminate confusion.

By the end of the meeting, Sarah has the foundation for a procedural document that captures every critical step in her process in a format others can understand and replicate.

Leveraging the true value of procedural knowledge

Most teams know how to share existing knowledge — point someone to the procedural document that lives within your team wiki.

But growth doesn’t happen by limiting yourself to what is. Growth occurs when you tap into the new knowledge that employees develop after mastering a skill. However, employees alone can’t be expected to know how to identify and codify this new, personal knowledge. It takes a village, if you will.

By developing opportunities for shared experiences within your teams, you empower every employee to leverage the true value of your company’s existing procedural knowledge.

How Stripe Built a Writing Culture

RC Victorino — Wed, 02 Sep 2020 20:00:00 GMT

For a company whose product focuses on numbers, Stripe has built an enviable writing culture.

Their quarterly software engineering magazine (Increment) and publishing imprint (Stripe Press) are impressive on their own. But it’s Stripe’s internal writing culture that differentiates the company. Whether it’s an email to a colleague or a memo to an entire team, Stripe employees strive to write with excellence.

Their strong writing culture benefits the organization in several areas:

Time efficiency. Sharing ideas through writing eliminates the need for repetitive verbal updates to disseminate ideas and information.
Knowledge sharing. Documenting important ideas forces clarity of thought and makes information more accessible to everyone in the company, versus slide decks that are ephemeral and require less rigor of thought.
Communication. Clear writing requires clear thinking, meaning employees invest more time shaping their ideas before sharing them.

“Writing forces you to structure your thoughts in a manner just not possible when you verbalize it. When I write, I have to offer structured, precise thoughts.”

The result is that Stripe’s internal and external documentation is a central pillar of the company’s reputation and brand.

How did this happen? We sat down with Stripe’s Documentation Manager, Dave Nunez, to learn more about what it takes to build a strong writing culture.

Leaders must demonstrate quality writing

Getting employees to write more frequently shouldn’t be your ultimate goal. Getting them to write more proficiently should be.

One of the most effective ways to encourage proficient writing is to demonstrate it.

“The first emails I saw from our CEO [Patrick Collison] literally had footnotes,” Nunez recalls. “He structured his emails to be like research papers and put the peripheral information at the bottom so as not to detract from the core information.”

Today, footnotes are a common component of internal emails at Stripe. The CEO set the expectation; employees strive to uphold it. But Collison’s approach to writing did more than demonstrate the value of a footnote. It’s understood that at Stripe:

Writing matters. Make it count.
Everyone’s time is valuable. Make the effort to put together coherent ideas in writing.
The clearer the writing, the clearer your message and intent will be.

Collison isn’t alone in his passion for quality writing. The modus operandi for leadership communications across Stripe is carefully structured narrative documents and emails. You’re far more likely to read a narrative memo during a Stripe project kickoff meeting than to sit through a PowerPoint presentation.

“From leadership on down, we default to writing,” Nunez said. “We don’t really have slide decks.”

How can you lead by example to foster a writing culture? Here are two ideas inspired by the Stripe playbook.

Footnotes might not be right for every company, but strategies anyone can adopt include citing reputable sources, being economical with your words, and ensuring your writing is free from grammar and spelling errors.

As a leader, consider having someone else review your writing for clarity and readability — then let your team know you had your writing reviewed. This transparency showcases just how committed you are to increasing the impact of your words.

“You wouldn’t ship code without having it reviewed; your words are just as important,” says Nunez.

Eschew slide decks for narrative memos. Share new ideas through carefully crafted emails.

When an employee pitches an idea to you, ask them to expand on it in writing.

Show them you value the effort required to convey one’s thoughts into writing by explicitly granting them the time necessary to think through and process their thoughts into writing.

“I’m only a month into my time at Stripe, but I’ve never encountered a tech company of this size where writing is such a center of gravity.”

Give teammates a starting point with sample docs

Nunez and his team create sample docs that other teams can use as inspiration for their own documents.

For example, his team published a detailed guide on the life of a Stripe charge. They walked through every step of the process, from the point of sale with the customer, to the back end, bank transactions, and more.

While the content itself was specific to a Stripe charge, the document serves as a valuable reference to other teams on how to write a guide. Teams use this document to understand what type of language to use, to see what types of visuals are most effective, and to learn how to structure their writing for better comprehension (such as when and where to use subheads and lists).

Stripe has similar sample docs for READMEs, runbooks, and FAQs. Nunez believes these sample documents are more useful than fill-in-the-blank templates, because they provide readers more context and content to work with.

“We create docs that offer some of the basics, so engineers aren’t forced to stare at a blank page — which can be terrifying,” Nunez says.

Not every company has a dedicated documentation department. But creating sample documents doesn’t have to be an arduous task. Identify the types of documents most teams would want to produce — then have your most proficient writers create ambitious documents that can be later used as reference documents.

Know when to standardize and when to give autonomy

Standardizing how your team documents shared knowledge ensures content is easy to understand and streamlines the writing process.

But it’s neither scalable nor empowering to standardize everything.

It’s not scalable because it would take constant oversight to ensure every document met a specific format. Few companies have (or are willing to invest in) the resources for this kind of oversight.

It’s not empowering because what works for one team won’t necessarily work for another. Standardizing your entire documentation process robs teams of creating an experience that works best for them.

Stripe toes the line between control and autonomy by establishing a standardized approach for high-leverage documents only — those with a broader audience (like a document intended for multiple teams) or significant implications (like if it impacts business operations).

This approach ensures that the most widely read information receives the oversight it deserves, while teams still maintain autonomy over how they document knowledge most pertinent to them.

In contrast, each team at Stripe has far greater control over the look and feel of documents with a smaller audience and impact.

Standardization at Stripe isn’t represented by a series of templates employees plop their knowledge into like Mad Libs. Rather, standardization at Stripe is more about ensuring the clarity of the content and the reading experience live up to the company standard of quality writing. To ensure this, Nunez typically gets his team involved in reviewing these high-leverage documents before they’re shared.

Replicating this process is straightforward — establish criteria that differentiate high-leverage documents from low-leverage ones. For example, you could define high-leverage documents as:

Intended to be read by three or more teams
Contains information that will go unchanged for at least one year
Will impact general business operations

Documents designated as high-leverage should either follow a specific format, be reviewed by a dedicated team before publication, or both.

Make your documentation easy to read

The point of documenting something is to get others to read it. Without active readers inside your company, your writing culture will never flourish.

So, how do you get people to read what you wrote?

“I think the visual aspect is super important,” Nunez says, “because the first impression tells someone whether the content is approachable or not.”

A visually appealing document doesn’t always contain images and graphics. Nunez has seen beautiful documents that contain no visuals at all.

“You can look at the document and see, ok, this is super simple,” he says. “The intro is very short, there’s bulleted lists down here, and it just gets to the point.”

But, he admits, that’s rare. Visuals and diagrams simplify documents. They make them more approachable, which is why he suggests whenever you can replace text with diagrams, do it.

Diagrams or not, everyone on your team should consider the visual aspect of their writing. Here are a few items to consider:

Keep paragraphs short (3–4 sentences). If possible, make the first paragraph of a document 2–3 sentences.
Use subheads and bulleted lists to break up walls of text.
Consider your audience when writing. Some audiences value complex words — some don’t. The goal is to find the most compelling language for the audience you need to reach and act on your document.
Edit frequently. Edit your own work, and ask peers to edit it as well. Editing is the key to getting the best clarification of your idea.

Create a support system

Writing well is not supposed to be easy. Writing well requires more critical thinking (than, say, speaking off the cuff), which produces better results.

The payoff is worth the effort, which is why everyone on your team should strive to be strong writers.

However, sometimes the writing process can create significant barriers that prevent team members from ever sharing their ideas.

Employees who struggle with writing, or whose native language isn’t English, may feel less confident contributing their knowledge.

Nunez has seen this throughout his career — he worries that a company does itself a disservice when some employees don’t feel empowered to share their ideas in a writing-heavy environment.

To address this, he emphasizes the importance of onboarding classes for new hires focused on writing and documentation, as well as office hours, and self-service resources. This demystifies the documentation process — but it also emphasizes just how important documentation is to business operations from the outset.

One thing Nunez is starting to experiment with is pairing ESL employees with writing mentors. He’s done this informally over his career, but would love to see companies create more formal programs for writing mentorships.

“The idea here is that you come with your writing, and a judgment-free expert writer will help you as if they were your college English professor,’” Nunez says.

But even your team’s strongest writers need support. Nunez, for example, is the first to admit that his writing can become long-winded and confusing. So, he regularly shares his work with a handful of colleagues he trusts to offer kind but honest feedback.

Many others across Stripe have colleagues review their work, as well.

“Engineers do this with their code,” he says, “and we do it with our writing.”

Building your culture of writing and documentation

When your CEO uses footnotes in his email and your company publishes full-length books, it’s clear that writing matters.

But you don’t have to be Stripe to develop a culture that embraces writing and documentation. Lead by example; know when to standardize internal writing and when not to; make your documents easy to read; develop a support system that encourages and empowers everyone to write. These are the building blocks from which any company can build a culture where writing and documentation become second nature.

Choosing and Building an Internal Wiki for Your Company

RC Victorino — Thu, 25 Jun 2020 20:00:00 GMT

Employees spend 9.3 hours every week looking for information to do their jobs, according to research conducted by McKinsey.

And that was in 2012.

Employees have always had to scour archived email threads and disconnected documents to find critical company knowledge. These days, they also have to search for knowledge in chat tools like Slack and project management tools like Trello.

This makes finding shared knowledge incredibly time-consuming. It also makes it challenging to maintain company knowledge. As a result, work gets duplicated, employees repeatedly ask the same questions, and onboarding new employees is far more resource-intensive than it should be.

A dedicated internal wiki can streamline your team’s knowledge sharing and collaboration.

What is an internal wiki, and why does your company need one?

An internal company wiki is a dedicated space where teams store, find, and share critical knowledge. Think of it as your company’s long-term memory or internal knowledge base. Companies use wikis to document information critical to their business operations, including:

Company policies
Processes and procedures
Common workflows
Technical notes
Training and onboarding materials

A company wiki minimizes repetitive questions and empowers your team to work autonomously. It also protects your company from attrition — wikis document knowledge that might otherwise be lost when employees leave.

Wikis also have a positive impact on company culture. Documentation forces employees to hone their writing — to convey their message clearly and concisely. Through clearer writing, you have clearer thinking, which improves collaboration and productivity.

Below we break down what to look for (and what to avoid) in your company wiki.

The core features your wiki software must have

Your company will customize your wiki experience to your needs. However, the features below are integral to your wiki experience. When choosing an internal wiki for your company, be sure that they contain these features.

Editor’s note: Throughout this article we provide examples specific to our platform, Slab. However, the information should be easily applicable regardless of the internal wiki tool you choose.

Your wiki should work with the tools your team already uses

Your team already collaborates and shares knowledge in chat tools like Slack, project management tools like Trello and Asana, and document editors like Google Sheets. As a result, your shared knowledge is scattered across a handful of apps. Your team has to constantly switch tools just to access important company knowledge.

While an internal wiki can help, the reality is that some of your team’s critical information will continue to live only within the confines of tools that aren’t your wiki.

For example, your design team might use InVision, which allows them to comment on designs. Those comments likely won’t make their way into your team wiki — despite possibly being of value to other teams. By choosing the right tool, your design team can embed that InVision file into your wiki. That way it’s easily accessible by other teams and becomes a part of your team’s history.

Choosing a wiki that integrates with your existing tools makes it easy to consolidate your company knowledge.

The search function should be powerful and robust

A powerful search function makes it easy to find content without searching through folders (or topics, which is what we use at Slab).

At the bare minimum, your wiki’s search function should be as fast and intuitive as it is with Google.

Take the search function in Slab, for example. Teams use Slab to store, organize, and share critical knowledge in one dedicated space. They rely on our platform to help them find exactly what they’re looking for — fast. That’s why when you click on the search bar in Slab, we reveal your most recently viewed posts — because chances are the post you’re searching for is one you’ve recently visited.

We also have Faceted Search, which allows you to narrow your search. For example, here’s how you’d find references for the term ‘writing’ in your Product topic only:

Plus, when you search in Slab, we also show you results from your connected accounts, including Slack, Google Workspace, Confluence, and Dropbox.

A fast and powerful search function isn’t just a way to minimize the hunt for knowledge. It’s also a positive user experience for your team – meaning they’ll be more likely to use and contribute to your wiki.

The ability to create dedicated team spaces

Internal wikis knock down information silos that naturally occur within any company that has multiple teams. But teams should still have their own dedicated space within your wiki.

With Slab, teams use Topics for this (other wikis use folders). Engineering teams have their own dedicated topic, as does Marketing, and so on. Each team can create nested subtopics, too. For example, your Brand team and Growth team could each have their own dedicated subtopic inside the Marketing topic.

Regardless of what it’s called, these dedicated spaces should make it easy to get the right knowledge in front of the right people, at the right time.

A way to keep content accurate and updated

Some wikis make it difficult to determine if your content is updated and accurate.

Look for a wiki that clearly shows key information like when a post was last updated and who is responsible for it.

Your wiki should also allow real-time collaboration editing, meaning multiple people can simultaneously add and edit content without overriding or causing duplication.

Can you use Google Docs or Dropbox Paper for your company wiki?

Google Docs and Dropbox Paper are among the most widely used tools for companies of all sizes. Teams create and collaborate inside these tools — so it makes sense to attempt to use them for your team wiki.

But writing apps like Google Docs make bad internal wiki tools for a number of reasons, including:

Poor organization

Document editors use a standard folder concept to store and organize content. This makes it hard for teammates to know where to find and store information.

While you can add descriptions to a Google folder, that description isn’t always easy to find. Compare that to Slab topics, where descriptions are clearly displayed:

Too many formatting options

Documentation should be simple and straightforward. The more formatting options your team has, the more burdensome the documentation experience becomes. When everyone can format posts however they want, you end up with an inconsistent and confusing wiki experience.

Search is just a second thought

When you have fewer than 10 people in your company, finding documents inside Google Docs isn’t too complicated. But as your team scales, and more people contribute to your internal knowledge base, you’ll discover the limitations of these document editors.

Google Docs and Dropbox Paper aren’t designed to scale alongside your company. Rather than start off with Google Docs and migrate to a dedicated wiki, most teams find it better to adapt to a team wiki from the start.

Which leads us to the next question: self-hosted or cloud-based proprietary wiki?

Self-hosted (or on-prep) vs. cloud-based wiki

Should you host your wiki or subscribe to a cloud-based solution?

Self-hosted wiki. You can host your company wiki on your intranet, server, or online hosting service — if you have the budget and resources. The benefits of a self-hosted wiki include:

You own all your data.
You can create a wiki experience that matches your exact needs and specifications.

But a self-hosted wiki eats up engineering resources. It’s typically best-suited for teams with very specific needs.

Cloud-based wiki. Platforms like Slab allow you to build an internal wiki without dedicating massive engineering resources. You can be up and running within one business day.

The trade-offs are:

You’ll have a recurring subscription cost for the service.
The wiki you choose may not perfectly suit your needs.

Building your internal wiki

It may sound like an ancient Zen Koan, but a wiki isn’t really a wiki until more than one person contributes to it.

Still, before you onboard teammates, we suggest you create at least a work-in-progress information architecture. This ensures there’s an established method of organizing company information before you and others start adding content.

1. Setting up your information architecture

What your information architecture will look like will depend, in large part, on which wiki solution you choose.

In Slab, information exists in two ways: topics (which are like folders) and posts (which house the content itself). So if your team uses Slab, your information architecture is how you organize your topics.

We recommend creating topics (or folders) for:

Company. Use this for company-level information, like all-hands meeting notes or quarterly progress reports.
People/HR. Use this for company policies, benefits information, employee handbooks, etc.
Teams/departments. You can create a top-level topic or folder to contain individual sub-topics for each team — this will work better if you have a larger number of teams. If you have fewer teams, you can create top-level topics for each team.

As you decide how to organize your team wiki:

Focus on clarity. Everyone on your team should be able to navigate your wiki easily — not just those who set it up. Get multiple sets of eyes on your architecture to make sure it makes sense broadly, and that everyone will know where to look for information.
Give teams flexibility. Allow each team to construct their topic or folder in a way that makes the most sense for how they work. A structure that fits one team’s workflow might not fit another’s.

2. Import and add content

Once your architecture is in place, you can add content to your internal wiki. If you have existing documentation (like in Confluence, Notion, or Google Docs), you should import this content into your new wiki before you officially launch. At Slab, we make it easy to import content from a variety of tools, as well as from markdown and HTML files.

You should also add any critical new content into your wiki before your official launch. A few posts that teams frequently launch their company wiki with include their employee handbook and a guide to navigating their new wiki.

3. Set up integrations

As we mentioned earlier, your team likely uses a handful of tools to store important information. Instead of replacing these tools, we’ve found it more helpful to your team to integrate these with your knowledge base.

Consider what information should live in your wiki, and what information should be connected to it. Some content deservedly belongs in a tool other than your wiki. For example, engineering teams that use GitHub can sync markdown files and embed issues and pull requests from GitHub to Slab. That way, they can continue using GitHub for their workflow while easily contributing to their company wiki.

4. Map out your launch

Now you can plan your launch. You’ll need to make a crucial decision: will your initial rollout be to one team or the entire company?

Team-specific. If you decide to launch your wiki to one specific team, that team will have the chance to dive into the product and start building out their own information architecture. Then, as you expand to the rest of your company, the original team can provide valuable insight and guidance.
Company-wide. If you decide to launch your wiki across your entire company at once, make sure that everyone is familiar with your approved knowledge base management process. Otherwise, it’s best to start with a single team. We recommend appointing team ambassadors for company-wide rollouts. They’ll become product experts and can lead the charge within their individual teams.

Launching your wiki

Once you’ve planned your rollout, designed your information architecture, imported your content, and set up any integrations, it’s time to announce the rollout to your team.

This is an especially important step because it sets the tone for how the rollout will proceed.

Your announcement should introduce your new wiki to your team, explain why you are using it, and clarify the expectations and next steps each team member should take.

If you’re rolling out to a single team first, it may help to organize a training session to demonstrate your wiki’s features.

If you’re rolling out to your entire company, you likely won’t be able to conduct live trainings for everyone. Still, we recommend investing time with your appointed knowledge ambassadors — it’s important to set them up for success so that they can empower others to be successful!

Below are two example emails you can adapt for your announcement, one for a team-specific launch, the second if you’re launching your wiki company-wide.

Team-specific launch

Hi all,

We’re excited to announce the launch of Slab as our new internal wiki! In an effort to improve our documentation practices, we’ll be using Slab as our source of truth for team knowledge. It’ll help us ensure that we keep our content accessible, fresh, and useful.

Your team has been chosen to lead the charge — you’ll be getting set up on Slab first! You’ll soon receive an email with instructions for creating an account. Please do this by DATE

From there, we’ll be holding training sessions to start learning the ropes. You can sign up for a session here.

We’re looking forward to building our team’s long-term memory together! 💪

Best,

Rebecca

Company-wide launch

Hi all,

We’ve designed our new information architecture and have begun importing existing documentation. We’ll continue to build it out as time goes on — this is where you come in!

You’ll soon receive an email with instructions for creating an account. Please do this by DATE. Look out for another note from your team lead with the next steps for creating content in Slab!

If you have any questions, please reach out to your team lead. We’re looking forward to building our team’s long-term memory together! 💪

Best,

Rebecca

Your shared knowledge is an investment

Your company’s internal wiki isn’t just a place to store vacation policies. Your wiki helps foster a culture of writing and knowledge sharing.

But which wiki you choose matters. Choose a wiki that makes documentation seamless and straightforward. No one should have to jump through hoops to contribute their know-how and expertise.

Getting Rid of (and Preventing) Information Silos in the Workplace

RC Victorino — Wed, 10 Jun 2020 20:00:00 GMT

The silo mentality creeps into the culture of most companies eventually — particularly as they scale in size.

As a company grows, workers become assigned to teams to make the company more productive. These different teams begin to focus on different priorities, often requiring disparate systems and tools (like a CRM for your sales team, and an analytics tool for your business intelligence team).

Creating departments to focus on specialized tasks is a vital step in scaling an organization; however, this fragmentation can create barriers that block the flow of information across teams.

The more tools a team uses, the harder it becomes to make knowledge easily accessible. That’s how information silos form — when departments within an organization don’t share critical knowledge effectively.

Critical information may flow up and down within silos — but they don’t flow laterally.

What problems do information silos cause?

Your company is less efficient

Information silos create walls around teams, making it hard for employees to know what’s going on outside their bubble. At the most extreme, these silos could lead to multiple departments unknowingly working on the same initiative. More commonly, however, teams fail to connect with relevant stakeholders — or they connect with these stakeholders too late in the process. This can lead to critical mistakes, redundancies, and gridlock.

For example, your product team is building a feature that allows visitors to your website to test-drive a version of your SaaS product right from the homepage. In a siloed environment, other teams may not be aware of this initiative until it’s well underway. They might not hear about it until the monthly all-hands meeting.

But your customer service team may have valuable input on which types of features excite your free-trial users — and which ones cause the most confusion. Having access to this information early on can ensure your product team builds the most effective product from the start, rather than making significant changes late in the process.

Your sales team might have created something similar already as part of their sales deck. Knowing what they created and the feedback they got from prospects can help your product team refine their approach in the early stages.

Growth is slowed

The most successful teams make quick and informed decisions.

But in a siloed environment, teams might not have immediate access to critical data. As a result, these teams have to collect and process data from across the organization before they can make a data-driven decision.

This jeopardizes their opportunity to move first, making them vulnerable to competitors.

Knocking down silos empowers teams to make calculated decisions without delays.

Company culture suffers

An essential part of company culture is inclusiveness. Employees want to feel connected to important initiatives — they want to know how their work contributes to the company’s overarching goals. All-hands meetings help — however, shared knowledge shouldn’t be confined to a scheduled gathering of minds. It should be a part of your culture.

Employees who see their impact regularly become more engaged, motivated, and collaborative. By tearing down information silos and making knowledge and data more accessible, employees can see how their contribution fits within the company’s big-picture initiatives.

The customer/user experience is weakened

Finding the root cause of any issue is a critical part of addressing problems before they become widespread. But information silos can seriously hamper your team’s ability to identify the root cause.

Siloed information also increases the chances of customers receiving inconsistent responses to the same issue whenever they contact your team.

The disconnect between departments — and within teams — makes customer service incredibly challenging. It leaves users frustrated and untrusting of your company.

How to tear down information silos

Three strategies any company can employ to tear down and prevent information silos are:

Consolidate your knowledge and data management systems.
Make knowledge sharing a part of your company’s culture.
Structure your company to foster knowledge sharing.

Consolidate your knowledge and data management systems

This is the first step your company should take. Find out what management systems your teams use as well as who uses them. Then evaluate whether these systems generate relevant data that’s accessible across your organization, or whether these systems create information silos.

Also, find out from your employees what they struggle with when attempting to access and share knowledge. Their input can help you provide a more representative solution.

Your goal here is to identify the systems you should merge or discard to improve efficiency. Ideally, you will move to one unified management system that allows each team the:

Flexibility to assign (and unassign) user permissions
Option to export and import data
Freedom to integrate with other tools (like Slack and GitHub)

Your work is not over once you’ve consolidated your management system. You still have to convince employees to make an effort to share their knowledge willingly.

That can be easier said than done.

Employees, by nature, may hoard critical knowledge:

Because it makes them feel irreplaceable
To avoid negative feedback from colleagues or supervisors
In the hopes of being recognized and rewarded for their individual achievements

Leaders can encourage knowledge sharing through several strategies, including motivation, modeling knowledge-sharing behavior, and creating clear guidelines. We dive deeper into these and other strategies in our article on how to overcome knowledge hoarding.

Making knowledge sharing a part of your company culture may not be enough. You may need to fundamentally change the way your company is structured.

Tip: Only consider this step once you’ve consolidated your management systems and made changes to your company culture — yet still see no progress.

Pull back and analyze how communication flows between the levels of your business. Does it make sense to merge any departments? Should you build knowledge sharing and documentation into your employees’ KPIs as Stripe does?

“We have in our job descriptions that writing and documentation are included,” says Dave Nunez, Documentation Manager at Stripe. “Come performance review time, that becomes part of your body of work.”

Conclusion

No company sets out to intentionally create information and data silos. But as companies scale, different departments and teams are created, and knowledge becomes less laterally accessible.

Tearing down — and preventing — information silos is an important step to ensure you remain competitive and agile in the long term.

The Financial Benefits of Remote Work for Companies

RC Victorino — Thu, 28 May 2020 20:00:00 GMT

Remote work can save employees, on average, more than $4,000 a year. Remote workers spend less on commuting, lunches, and even work clothes.

Does that same cost-savings transfer over to the companies that employ these remote workers?

There are a lot of factors to consider, of course. But data and use cases suggest that yes, companies that do employ a remote workforce do see a positive impact on their bottom line.

Global Workplace Analytics estimates that a company can save $11,000 for every part-time remote employee. These savings can be attributed to:

Real estate and operating cost savings
Reduced turnover and absenteeism
Productivity increase

A fourth factor that can contribute to savings is salary adjustments based on cost of living. In fact, localizing salaries based on cost of living is the primary reason many companies pursue hiring remote workers.

Real estate and operating cost savings

One of the easiest ways to see the impact of remote work on business owners is to look at where costs are lowered — including real estate. When more people work from home, companies need smaller office spaces to house essential personnel.

Ctrip, China’s largest travel agency, saved almost $2,000 annually per employee on rent by reducing the amount of HQ office space after offering telework options.

PGI estimates the average real-estate savings for companies with full-time remote employees to be $10,000 per employee per year.

You can see these savings in action with well-known companies that offered flexible work policies:

Aetna shed 2.7 million square feet of office space, resulting in a savings of $78 million per year.
IBM reduced its real estate costs by $50 million.
McKesson has saved $2 million per year in its real estate costs.

Not all companies will see this type of savings. Companies headquartered in tech and financial hubs like New York and San Francisco have significantly higher rent expenses than companies in smaller urban areas.

But lower costs connected to a remote work policy go beyond rent:

Relocation costs: Nortel estimates it saves an average of $100,000 per employee in relocation costs.
Operating costs: Remote employees also reduce the costs associated with electricity, heating and air conditioning, and other expenses that keep an office running.
Payroll costs: A 2017 study found that the average worker would accept an 8% pay cut for the option to work from home.

Reduced turnover and absenteeism

Turnover decreases by 50% when companies offer a work-from-home option, according to Scott Mautz, a former Procter & Gamble executive. Stanford Professor Nicholas Bloom came to a similar conclusion with his famed 2-year study on remote work and productivity — employee attrition decreased by 50% for remote workers in his study.

But why?

More than 80% of respondents to OWL Labs’ 2019 State of Remote Work report state that remote work makes them feel more trusted at work, less stressed, and more empowered to achieve an ideal work-life balance.

And it just so happens that being trusted, feeling less stressed, and having greater work-life balance equates to happier employees.

No commute

The lack of a commute, alone, can make employees happier and healthier. The average one-way commute time in the U.S. is 26 minutes, according to the U.S. Census Bureau. That adds up to nearly nine days per year commuting. That’s time spent in a car — possibly in stressful traffic jams — rather than with family, for example.

Commuting length can impact health as well, which impacts happiness, productivity — and employer insurance costs.

A study published in 2012 found that individuals with commutes of at least 15 miles were less active and more likely to be overweight. And a commute of just 10 miles was associated with an increase in high blood pressure.

Reduction in unscheduled absences

Having a better work-life balance doesn’t just make employees happier. It also reduces the need for employees to take time off to take care of personal tasks. Nearly 80% of employees who call in sick aren’t sick. They call in sick to attend to family obligations, personal needs, or because they’re stressed.

These unscheduled absences cost employers between $1,800 and $3,600 per employee.

Realizing this, the American Management Association established a flexible telework policy. As a result, they reduced unscheduled absences by 63% per employee.

Productivity increase of remote workers

Managers often worry that remote employees work less or multitask between personal responsibilities and their work.

Data shows the opposite.

Bloom’s two-year study revealed that remote workers were 13% more productive than their office counterparts.

Employee happiness plays a part in productivity. But it’s not the only factor.

Bloom cited two contributing factors to his findings:

Remote employees worked more than employees in the office.

Remote workers don’t show up late to work because of a traffic jam. They’re also less likely to take excessive coffee breaks — many don’t take lunch breaks. Remote workers are also able to run errands and schedule appointments without losing a full or even half-day of work.

The typical office environment is far more distracting than folks realize.

Some workers thrive in an office environment. But not everyone does. It would be nearly impossible — and incredibly expensive — for a company to construct an office that catered to the preferences of all their employees.

Remote workers, on the other hand, can easily create their ideal workspace. They can work from anywhere. If, for example, they’re distracted at home, they can drive to a coffee shop for a few hours (assuming there aren’t any wi-fi network security concerns or, of course, a pandemic like COVID-19 that shutters most commerce).

“When you stop and you look at the data available to us, in almost two-thirds of the cases, every leader that granted the work-from-home option has found productivity has increased by as much as 50%.” — Scott Mautz

Boosting productivity across your org

Some managers fear that allowing employees to work from home could negatively affect communication and collaboration. However, that’s only the case if teams try to make remote teams communicate synchronously.

It’s generally more efficient to communicate with remote workers asynchronously (email, documentation, Slack). As a result, remote-friendly companies benefit when they embrace asynchronous communication.

A culture of asynchronous communication cuts down on unnecessary conversations and meetings. If a point can be made in an email, it will be. If an idea can be pitched in a written memo, it should be. Asynchronous teams communicate more efficiently and clearly. When a meeting is required, teams can use a video conferencing tool like Zoom or Skype.

Salary adjustments based on cost of living

The average 1-bedroom apartment in San Francisco rents for $3,411, while a similar-sized apartment in Raleigh, NC, is $1,177.

Employers who hire within cities like San Francisco and New York City account for this increased cost of living with higher salaries.

For example, according to Glassdoor, the average salary for a Product Manager based in Raleigh is $104,976, while in San Francisco, it’s $129,387.

Hiring remote workers allows companies to retain a headquarters in tech and financial hubs like S.F. while expanding their talent pool to areas of the country (and world) with a lower cost of living. The result? Companies can save on salaries by hiring remote employees who live in more affordable regions, then localizing their salaries based on their cost of living.

GitLab has a publicly available database of “location factors” that adjust salaries from its San Francisco baseline. Buffer uses data from Numbeo to group their teammates into one of three geographic bands (high, average, and low-cost) by comparing the cost of living index of a teammate’s location to the cost of living index in San Francisco. Someone who lives in a low-cost region is likely to be paid less than someone with the same title who lives in a high-cost region.

Facebook chief executive Mark Zuckerberg recently announced that remote work would soon be an option for both new and current employees — but that salary adjustments would apply.

Other remote-friendly companies shun the approach.

Basecamp, a 100% remote company, pays “everyone as though they live in San Francisco and work for a software company that pays in the top 10% of that market,” its founder David Heinemeier Hansson wrote. “San Francisco was our benchmark because it’s the highest in the world for technology, and because we could afford it, after carefully growing a profitable software business for 15 years.”

If you plan to adjust salaries based on cost of living, you won’t be alone. But you will want to be prepared for any potential personnel conflicts that arise from variances in salaries of employees with similar roles. Being upfront with your salary localization policy, like GitLab and Buffer, will help.

You’ll also want to be aware that there are companies (like Basecamp and many SF-based startups) that don’t localize salaries. By offering high-paying salaries regardless of location, these companies may seem more attractive to top talent.

Factoring in the expenses of remote working

There are expenses connected to remote work. For example, are face-to-face interactions an essential part of your company culture? Then you’ll likely be responsible for the airfare and room and board of your remote team.

Remote workers need access to company software and data, as well. And companies need to address how to provide technical support to their remote teams.

Also, remote employees still need internet access, a desk, and a computer. They still eat lunch and drink coffee. Some employees want to work at a coworking space — it’s the next best thing to being in the office. An integral part of any remote work policy is an equivalency code: If you offer perks to office workers, you should find an equivalent perk to provide remote employees. This prevents remote employees from feeling like second-class citizens.

But most companies don’t reimburse or cover these costs for their remote workers. 75% of respondents to Buffer’s 2019 State of Remote Work study said their company does not pay for home internet, and 71% said their company does not cover the cost of a coworking membership.

As remote work becomes more prevalent, a larger number of companies will be competing to attract this diverse talent pool. Those companies that offer to pay for certain expenses of remote workers (like internet access, coworking memberships, and coffee) will have an easier time attracting top talent. And even after factoring in these expenses, remote workers likely still save companies money.

Why some companies are hesitant to hire remote workers

Few things are absolute. While countless companies have saved money by hiring a remote workforce, not every company will experience those same savings.

But the potential expense (or lack thereof) is not even what stops most companies from hiring remote workers. Here’s what does:

The misconception that productivity will take a hit. As noted earlier, the data does not support this claim.
Leaders feel more managerial when they can see their employees. It’s easier to feel more like a leader when your employees are within sight.
Lack of imagination. Many leaders assume that some roles in their organization can’t be done remotely. More often than not, they’re wrong.

Often, the decision to hire remote workers doesn’t come down to economics. It comes down to culture. Once you and your team are culturally ready to embrace a remote mindset, data suggests you’ll be better off financially — and productively.

Launching a Knowledge Transfer System

RC Victorino — Tue, 19 May 2020 20:00:00 GMT

If your lead engineer gave her two weeks’ notice, would you panic?

For many companies, the answer is yes. Losing a key member of their team would be crippling because of the unique knowledge that person holds inside their head.

This is one of the reasons why companies push hard for documentation — to avoid the fallout when a team member leaves. Teams that maintain a knowledge management system (like an internal wiki) are better prepared to handle the loss of colleagues and the addition of new employees.

But personnel change isn’t the only source of critical knowledge loss.

Information silos exist in most companies, particularly those with multiple departments and teams.

These silos can make cross-departmental communication a challenge. Your sales team, for example, may not know where to look — or whom to ask — for API documentation for a potential partner.

These delays and miscommunication can halt projects and harm business.

A knowledge transfer system empowers your team to easily share knowledge throughout your organization, eliminating miscommunication and communication delays.

What is knowledge transfer?

Knowledge transfer is a method for sharing knowledge from one area or person in your business to another.

While both documentation and knowledge management are a part of it, knowledge transfer is more about identifying team members’ skills and converting those skills into organizational knowledge that can be easily shared and used.

Why is knowledge transfer necessary?

Knowledge transfer establishes a culture of collaboration and innovation. It gives your team the context they need to tackle problems and create holistic solutions. To explain further, let’s define the two types of knowledge associated with knowledge transfer.

Types of knowledge

Explicit knowledge is easily shared through written or verbal communication. The steps your engineer should take to submit a pull request is an example of explicit knowledge.

Tacit knowledge is hard to transfer or pass along through communication. It includes real-time decision making, such as knowing what problems to look out for, when to ask for help, and how to apply creative solutions. This knowledge is developed through experiences, observations, and insights. As a result, it can be incredibly challenging to capture, store, and transfer.

A knowledge management system (like a team wiki) contains explicit knowledge.

A knowledge transfer system, on the other hand, helps you transform tacit knowledge into explicit form (a process known as externalization) — so that information can be easily shared. Externalization is one of four modes of the SECI model of knowledge dimensions. The others are socialization (tacit to tacit), combination (explicit to explicit), and internalization (explicit to tacit).

With an effective knowledge-transfer plan in place, your company will have a process to collect, store, and share all your critical information.

Creating an effective knowledge transfer process

There are three methods of transferring knowledge:

Writing (e.g., wikis and blogs)
Verbal (e.g., podcasts, conversations)
Showing (e.g., demonstrations, mentoring)

A lot of factors impact the method by which your team shares knowledge, including:

Access to technology/resources (e.g., you may not have the bandwidth for a mentorship program)
Learning preferences of those receiving the knowledge (e.g., visual vs. audio vs. hands-on)
The type of knowledge to be shared (e.g., documentation is often not enough to convey the full scope of tacit knowledge)

Below we break down the five elements that should go inside your knowledge transfer plan. As you create your plan, be sure to account for each method of knowledge transfer.

But before you create your plan, ask yourself why you want to complete a knowledge transfer. Is it to improve efficiency in your company? Is it to capture knowledge from team members you know are leaving soon? Is it to improve your onboarding process?

Your motivation for your knowledge transfer will help streamline the process and make it easier for you to measure the success of your strategy.

1. Collect your critical knowledge

Establishing a knowledge transfer plan is a daunting task. We recommend focusing on your most critical knowledge first (rather than having everyone across your organization document their expertise).

To do this, each team should hold at least one (if not several) brainstorming sessions where they identify the common problems and tasks they encounter.

Then, each team member provides his or her solution to these problems. A team lead documents these solutions, chooses which are most relevant to the org, and moves on to step 2 below.

If you prefer to include fewer people in the process, you can, instead, seek knowledge from the most critical people in your organization.

Ask yourself:

Who are the go-to people in your company?
What do only they know how to do?

Once you’ve answered these questions, you should have a list of critical team members and the activities and tasks you need to learn more about. You can interview these experts to collect their unique expertise.

2. Store that knowledge in a centralized place

The biggest takeaway from this step is choosing where you store your shared knowledge.

Documenting all the knowledge you’ve collected in countless Google Docs is not going to help you create a sustainable system for information sharing. Document editors like Google Docs are not designed for knowledge management.

An effective knowledge transfer strategy requires the use of a documentation tool specifically designed to work as a knowledge base or internal wiki.

Some of the features to look for in your documentation tool include:

Fast and comprehensive search capabilities.
Authorship (each document should have a single owner, so teammates know who to seek out for questions or input).
Integrations with other tools. For example, Slab integrates with tools like InVision, Vimeo, and Airtable, making it easy to embed spreadsheets, videos, and designs in one centralized place. This is a great way to adapt shared knowledge to every learning style.

Storing your knowledge in a team wiki is a great step toward preventing knowledge loss. Your wiki makes information easily accessible and editable.

But it’s often not enough, for three reasons:

You can’t always rely on employees to reference your wiki
Reading is not the best learning method for everyone
No matter how thorough the documentation, some knowledge is best conveyed through other methods (refer back to our section on tacit knowledge)

A successful knowledge transfer includes a plan for how employees share their expertise beyond documentation. Below are several sharing strategies your company can employ as part of your transfer plan.

Mentorship or work shadowing. This is when a knowledge expert takes someone else under their wings to share their expertise. It combines visual and hands-on learning. Mentorship is typically a more involved process than work shadowing.
Guided experience. The knowledge expert works hands-on on a project, showing his/her process to the individual learning the function. This strategy requires less investment by the expert. It also assumes the learner can acquire this knowledge without the added support of a mentor relationship.
Fire drills. Individuals work on a new task or function — without a mentor. Think of it as sink-or-swim.
Cross-org sharing. This is where workers share their knowledge with colleagues, who may not share the same job function but overlap in a particular area of interest (for example, a customer support rep shares his process for responding to a complaint with your head of lifecycle marketing).

4. Measure the success of your knowledge transfer

You want to know that the resources you invested in your knowledge transfer plan were worth it. Unfortunately, there is no universal benchmark for measuring success. Every company will have a different reason for conducting a knowledge transfer plan.

Measure success by revisiting the initial reason for conducting your transfer plan. Did you want to create a robust knowledge repository that your company will maintain? Did you want to capture the knowledge of key team members you know are going to leave or retire soon? Did you want to create a seamless onboarding experience?

Ask yourself if you achieved the initial purpose of your transfer.

If the answer is yes, then consider your plan a success.

5. Create new knowledge

The most effective knowledge transfer plans are sustainable. How do you know you have a sustainable knowledge transfer plan? The answer is when your teammates apply their new learnings into a process that makes that information easily accessible across your org.

Some members of your team will do this instinctively. Others may hoard their knowledge.

Documenting your knowledge transfer process will help employees understand the steps to take to share their knowledge with colleagues. But knowledge sharing will only be sustainable if it becomes a part of your company culture. That’s why you must overcome knowledge hoarding and empower your team to share their expertise willingly.

Your knowledge transfer system gives you the peace of mind that your company can handle the challenges of personnel changes and growth. Knowledge transfer encourages your team not only to pursue new knowledge — but to share it with their colleagues.

The more accessible your critical knowledge, the more successful your company will be.

How to Create An Inclusive Remote-Work Policy

RC Victorino — Mon, 11 May 2020 20:00:00 GMT

The coronavirus pandemic forced companies to embrace a remote-friendly culture, but remote work was already growing in popularity before the COVID-19 outbreak.

In other words, it’s inevitable that most companies will be remote-friendly, to some degree, eventually.

No matter your reason for embracing remote workers, creating a remote-work policy is an important step to set your team up for success.

What is a remote-work policy

A remote-work policy isn’t just a set of rules and expectations. It’s also a guideline your company uses to help your remote team feel empowered to do their best work.

The granular details of a remote-work policy will depend on a variety of factors. For example, a company that hires international employees will have different communication challenges than companies that hire local remote workers only.

But regardless of the makeup of your team, it's important that you consider the social and cultural challenges of managing remote employees. You can do this by including the following in your remote-work policy:

Communication standard
Equivalency code
Social strategy

Communication standard

How your remote team communicates can offset the negative consequences of isolation.

For the sake of clarity, let’s discern between isolation and loneliness.

Loneliness is an emotional response to a lack of connection. Your local employees can feel just as lonely as your remote employees — although loneliness is far more prevalent with remote workers. We discuss ways to overcome loneliness in the social strategy section further down.

Isolation, on the other hand, is related to a lack of access. Employees feel isolated when they can’t get materials or information they need to do their job well. The result is they feel ignored, under-appreciated, and dispensable. While all employees can experience this — it’s far more common with remote employees.

Creating a clear communication standard can ensure that your remote team has equal access to critical information and conversations. As part of your communication standard, you should answer the following three questions:

What are the normal working hours? This sets the expectation of when employees should be available for calls and meetings.
What is the expected response time for each communication channel? For example, should your team respond to Slack messages within 4 hours, and emails within 24 hours?
What happens when someone is unavailable during normal working hours (on vacation or out sick, for example). Who should be contacted instead, and how?

Your communication standard should also include your cadence of communication between managers and their remote employees.

While scheduled meetings aren’t unique to remote teams, sometimes these planned events are the only communication remote employees have with managers. It’s important to establish a cadence to keep your remote team connected.

One approach is:

Weekly one-on-one meetings. Managers schedule 30-minute weekly meetings with their remote workers. Remote employees should dictate the agenda based on their needs (such as to review priorities, ask questions, or discuss frustrations). This is a great time for managers to check in on the happiness of their workers.
Daily standups. At the start or end of each day, every team member shares a list of things they completed since the previous standup. At Slab, we use a dedicated Slack channel for this. We created a Geekbot alert that reminds team members to submit their daily standup. We find that sharing our standups asynchronously is the best use of our time.

Equivalency code

The equivalency code is pretty simple: If you offer perks to local employees, you should find an equivalent perk to offer remote employees. This prevents remote employees from feeling like second-class citizens.

Even if you’re entirely remote, the equivalency code applies. Your fully remote team shouldn’t miss out on the perks typically given to teams that work in an office. Ask yourself: If I had an office, what perks and benefits would I offer my employees? Or, think back to when you worked in an office. What perks did you have? How can you offer the same to your remote team?

The perks you offer your remote employees depend on many factors (budget, logistics, etc.). Below we list three standard perks local employees receive — and how you might apply them to remote workers.

Commuting expenses

Many companies reimburse local employees for their commute. They pay for parking, public transit, or even reimburse some mileage. Some offer access to the company rideshare account.

Remote employees don’t have to commute — so on the surface, there seems no reason for them to need a commuting perk. However, to ensure inclusivity, you can offer remote employees one or two paid trips to HQ every year, or reimburse their travel expenses when they work at a coworking space.

Office setup

If employees at HQ have access to top-of-the-line desks, chairs, monitors, and other equipment, your remote employees should also have the opportunity to upgrade their workspace. Offer remote workers an office-setup stipend. This gives them autonomy over how best to outfit their home office.

This also applies to network security. If your office has a secure network, that same level of security should be provided to your remote employees.

Lunch

Some companies pay for employee lunches, either daily or on special occasions. If this applies to you, consider giving each employee a monthly lunch credit.

Or, find out their favorite lunch spot and send them a gift card each month. Despite being more limiting than a credit, this personalized approach can help your remote workers feel like they’re appreciated — and noticed.

Loneliness is the second biggest struggle remote workers experience, according to Buffer’s 2019 State of Remote Work report. Plus, loneliness is reaching epidemic levels, particularly in young adults (a segment of the population more likely to work remotely).

So, how do you combat the loneliness your remote workers might experience?

1. Get to know your remote employees

First, not all remote employees feel lonely. Some prefer their solitary workspace. Some are better workers because of it. You shouldn’t force social gatherings based on the assumption that your remote employees must feel lonely.

Secondly, combatting remote-work loneliness is not as easy as, for example, hosting a monthly Zoom mixer. Not everyone is an extrovert. These large (albeit virtual) social gatherings could make some team members uncomfortable.

An important part of building an inclusive remote-work culture is understanding your remote employees. Ideally, this is done on the managerial level. Each manager or team lead should take the following steps to understand the dynamics of their remote employees better:

Identify your remote workers’ strengths and talents. This helps you understand who they are and how they work best.
Study their work patterns. When and how do they collaborate with their peers? Who do they reach out to most frequently? Which of their partnerships delivers the best results? This helps you identify their social circle.
Get feedback from remote employees after the completion of every project or task. This will help you understand when they prefer to collaborate with the team, and when they prefer to self-isolate.

2. Create opportunities for face-to-face meetups

As empowering as asynchronous communication is, face-to-face time is important for building trust and relationships.

If your remote employees are local, encourage them to come in for one day every week. The happiest workers spend about one day a week in the office, according to a Gallup poll of 9,917 employed US adults.

These “mostly” remote workers were also more likely than full-remote or full-office workers to say they had a best friend at work.

Have remote employees who are unable to come to the office regularly? Invest in bringing them to the office monthly or quarterly.

Of course, in-person meetups are not always realistic or viable. You can use communication tools, like Zoom and Skype, to compensate.

3. Create opportunities for casual conversations

All too often, remote workers are only called upon when something is needed. Imagine if that were the dynamic in an office — where the only time colleagues communicated was when they needed something. Morale would take a hit. Your rate of attrition would likely increase.

Of course, in a typical office setting, casual conversations tend to occur more naturally. You walk by someone’s desk, notice they’re wearing a Dave Matthews T-shirt, and start up a discussion around the best DMB songs ever written (for the record, it’s “Crash Into Me.”)

These casual conversations are not as easy to come by for remote employees. But they’re not impossible.

Slack channels help. So do small, voluntary video meetups. Whatever approach you take, the important takeaway is to find ways to engage your remote employees with their colleagues in a casual setting.

But also keep in mind — some remote employees prefer to avoid these types of social gatherings. Give your team autonomy over how they socially interact with one another.

In summary

Most companies understand the importance of a remote-work policy. But far too many policies cover the basic rules and expectations only, like who can work remotely, and what tools they should use. Most policies fail to consider the social and cultural challenges of managing remote employees.

But without considering how you’ll address these challenges, your remote employees are likely to feel isolated, lonely, and, consequently, unhappy.

You can address these challenges by creating a remote-work policy that includes:

Communication standard
Equivalency code
Social strategy

It doesn’t matter if you plan to be 100% remote or a hybrid company — an inclusive remote-work policy is the most effective way to set your entire team up for success.

Creating All-Hands Meetings That Make An Impact

RC Victorino — Thu, 07 May 2020 20:00:00 GMT

All-hands meetings are great for energizing your team and building camaraderie.

Most all-hands meetings, however, don’t live up to their potential. They waste valuable time. Attendees leave feeling resentful, not excited.

There are several reasons why all-hands meetings don’t live up to the hype, including:

Frequency. The more frequent your meetings, the harder it can be to make them impactful.
Format. Often times, all-hands meetings come across like lectures. One person speaks, the room listens.
Preparation. All-hands meetings are arguably your company’s most important meeting. Yet many companies don’t commit the time and energy these meetings deserve.

Below we outline the factors to consider when creating a productive all-hands meeting.

What is an all-hands meeting?

All-hands meetings (also known as town hall meetings) are when a whole company comes together to discuss important matters.

Sometimes, specific departments (like the marketing team) will have their own all-hands meetings. Most commonly, however, the entire organization comes together to discuss business strategies and company goals.

Why you need an all-hands meeting

It’s easy for everyone to get stuck in their day-to-day routines. All-hands meetings help your team zoom out and focus on the bigger picture — your company mission. These meetings are also a great opportunity for team building, and to celebrate the hard work your team has showcased.

Plus, these meetings are likely the only time your entire company or department can gather at one time. This is particularly true if you have a remote team dispersed across time zones.

When should you start holding all-hands meetings?

Most early-stage startups don’t see a need for all-hands meetings. Informal communication (through Slack, at each other’s desks, etc.) suits them just fine. But inevitably that changes.

For example, as your company grows, you’ll start hiring people to fill roles that once didn’t exist. You’ll hire managers that create a layer between senior leaders and direct reports. These new roles and added layers can create information silos. All-hands meetings aim to prevent these silos from ever forming.

The following are signs that your company is ready for all-hands meetings:

Your team has grown beyond 12-15 people (or can no longer fit in a conference room together).
You have teams or departments with more than one person in them.
You’ve built a middle-management layer.
You’ve hired remote employees (all-hands meetings help them feel connected to your team and mission).

How often should you hold all-hands meetings?

You can hold all-hands meetings whenever you want. Most companies meet quarterly, monthly, biweekly, or weekly.

Your company culture will dictate the frequency of your meetings. If your workplace values togetherness, consider holding meetings on a regular basis. If, however, your team has a more heads-down approach to work, less frequent all-hands meetings are likely a better fit.

Is your team distributed? If so, more frequent meetings can keep your team connected regardless of distance.

“Hold at least one all-hands meeting every quarter and, to underscore the startup’s team concept, make sure at least one additional executive joins you in leading the meeting.” — Scott Weiss, Andreeson Horowitz

Presentation: How to incite excitement

When Justin Kan (co-founder of Atrium, Justin.tv, and Twitch) first ran all-hands meetings at Atrium, he admits they fell short of his expectations. The feedback he got from his team was that he didn’t look excited to be there.

“This not only affected the productivity of those meetings but the company’s overall engagement (or lack thereof),” Kan writes. “I found that in order to set the right tone I needed to pump myself up.”

How you pump yourself up is entirely up to you. Kan would exercise just before his presentation. That, of course, isn’t the right approach for everyone. What’s important is to be mindful of your presentation. Do you exude enthusiasm? If so, that enthusiasm will transfer to your team.

Of course, the presentation alone isn’t enough to create a productive all-hands meeting. Preparation is crucial.

Preparation: Creating your all-hands meeting agenda

A compelling all-hands meeting agenda is broken down into three sections:

I. Community

II. Business

III. Live Q&A session with the leadership team

I. Community

Aim to spend 10-15% of your total meeting time on this portion.

1. Unstructured time

You’ll likely cover a lot of material during your meeting — so keeping to a tight schedule is crucial. Regardless, kick off your meeting with a chunk of unstructured time. For example, you could share a funny anecdote.

This unstructured time establishes the tone for the rest of the meeting.

Etsy kicks off their all-hands meetings with what they call an opening act. Members of the team perform standup, play the saxophone, and show off any number of outside-work talents they have.

“You’re allowing a vulnerable exchange among employees,” says Elise Pereira, Former Senior Manager of Etsy’s Internal Communications. “It creates this open and connected space.”

2. New hires

Introduce all new hires and, if possible, have them introduce themselves and share a personal fun fact. An important part of an all-hands meeting is your company culture — recognizing your new hires is a big part of this.

3. Milestones

Celebrate important milestones like work anniversaries and birthdays of the month. This helps your employees feel respected.

4. Shoutouts

Acknowledge the actions and achievements of specific team members. An effective way to do this is to call people out based on how they have represented one of your team’s values.

For example, at Slab, we have six core values. During one of our all-hands meetings, our CEO could acknowledge a team member whose work over the last quarter demonstrated our mission to stay lean.

If your company is large enough, have each department manager acknowledge someone on their team.

II. Business

You’ll invest the most significant chunk of your meeting time (55-65% of it) to business strategies and operations. This is often when all-hands meetings go awry. Team members lose focus and energy because they feel like the presenters are talking at them.

But this is the most pivotal part of your entire meeting! This is when you align your team on your company mission and priorities. You need your team to keep the energy level (and interest) high.

You can do this by making your meeting interactive.

Below we cover the topics to discuss during the business segment of your meeting — and how you can involve your meeting attendees along the way.

Company purpose

You never want your team to lose sight of the bigger picture. All-hands meetings allow you to realign your team on your company purpose.

But rather than create a slide deck for this (that you read from), consider one of the following:

Ask one of your teams to present how they’ve worked through a difficult problem together.
Invite customers to present how your company has made life better for them. If this isn’t realistic, compile testimonials and use-case stories of your most recent customers.
Invite an investor to discuss why he or she chose to invest in the company.

These examples create a more compelling visualization of your company’s purpose and impact — far better than a lecture-based Powerpoint could ever hope to accomplish.

The numbers

Here’s where you share updates to your key metrics and reinforce your high-level strategy.

But numbers alone don’t tell the whole story. So, invite team members to present how an initiative they’ve worked on directly correlates to your key metrics and strategy.

For example, one of your goals may be to increase NPS scores. Your lifecycle team can present the changes they’ve made to your client-survey process, and how these changes positively impacted NPS scores.

III. Live Q&A

Dedicate the remaining time to a Q&A (this should be roughly 20-25% of your total meeting).

Here are some things to consider to ensure your Q&A session is all-inclusive and effective:

Allow your team to submit questions anonymously if they want (Google Forms works well for this). Some people are uncomfortable speaking in public.
Involve your remote and offsite teams. It’s easy to answer only the questions posed by people in the room with you. But answer questions from your distributed teams as well. Video conferencing tools like Zoom allow attendees to virtually raise their hands and post their questions via chat.
Use Slack for follow-ups and questions left unanswered. If your team is large enough, it’s possible you won’t get to every question. Or, attendees might not think of a question until later on. Create a dedicated Slack channel, so your team can ask questions after your meeting.

The logistics

You have your agenda set. You've found a way to exude enthusiasm during your presentation. There are still a few logistical matters to take care of to ensure your all-hands meeting is a success:

Presentation

It’s common to have one presenter throughout the meeting. But switching up your speakers can keep things more engaging. Invite other executives and department heads to the stage throughout your meeting.

Tech challenges

Consider all of your technical needs — and the challenges they may present. For example, will one camera and microphone be enough? Likely not if you want your offsite team to be able to see who in attendance is asking a question – and hear what’s being asked.

You should also create one master template of your slide deck. Then have all speakers upload their slides to that master template before the meeting.

Not only will this give you time to review the content, but it will make the entire presentation run smoother.

Make all-hands meetings a team affair

The easy approach might be to take complete ownership of your all-hands meetings. That way, you have fewer people and moving parts to manage. But these meetings shouldn’t resemble a university lecture hall. You are not a professor. Your employees are not your students. Everyone on your team has something to offer. Make sure your meetings reflect this concept by designing them to be fully inclusive.

And, when it’s all said and done, get feedback from your team. Every meeting can be improved. Feedback will help you design the most impactful all-hands meeting for your team.

Embracing Asynchronous Communication in the Workplace

RC Victorino — Tue, 07 Apr 2020 20:00:00 GMT

Knowing you can reach out to a colleague and get immediate feedback is incredibly convenient.

But that convenience can come at a cost: productivity.

It takes the average person 25 minutes to return to their original task after being interrupted, according to a University of California, Irvine study.

Now imagine getting back on task amidst dozens of daily interruptions (Slack and inbox notifications, calendar invites, visits to your desk by colleagues).

It’s nearly impossible.

Sure, we can make personal adjustments to limit our distractions. We can check Slack and email twice every day. We can block off time in our calendars. We can wear noise-canceling headphones at our desk, meaning leave us alone.

But these personal adjustments won’t go very far if your company’s culture is built on an expectation of synchronous communication.

If you want to build a more productive workplace, it’s time to embrace asynchronous communication.

The problem with synchronous communication in the workplace

When companies build their culture around synchronous communication, employees value quickness over thoughtfulness. Immediately responding to a Slack message is seen as a quality of a good teammate — even if the response lacks depth or quality.

“Wherever possible I try to communicate asynchronously.” - Elon Musk

But except for time-sensitive matters and team-building activities, this isn’t the most effective way to communicate in the workplace.

Yet companies embrace synchronous communication because they mistakingly associate constant connectivity with quality collaboration, when, in fact, asynchronous communication often leads to better collaboration, clearer communication, and improved productivity.

Advantages of asynchronous communication

Below we break down the positive impacts an asynchronous culture can have on your team.

Inclusive collaborations

Teams hold real-time meetings (like brainstorming sessions) as a way for colleagues to collaborate. However, these synchronous meetings often lead to production blocking.

Production blocking occurs when one person prevents others in a meeting from contributing ideas (whether intentional or not). It’s a natural consequence of synchronous meetings — one person speaks, others listen.

Asynchronous communication eliminates production blocking by allowing everyone on the team to contribute their ideas without fear of interruption or negative feedback.

Example: Rather than hold a brainstorm session, share a prompt with your team. Then, have each teammate summarize their ideas in a memo that they share with the group (use a collaborative writing app like Dropbox Paper or Slab). Encourage every team member to read and respond to their colleagues’ memos.

“There is no way to write a six-page, narratively structured memo and not have clear thinking.” — Jeff Bezos

This way, everyone contributes — and there’s a record of these contributions. This is the strategy Jeff Bezos adopted at Amazon. Bezos asks his senior leaders to submit narratively structured memos before any meeting. These memos force his team to carefully think through their ideas, rather than just spit out the first thing that comes to mind. As a result, discussions are more fruitful. Debates offer more value.

Meetings are more productive.

Productive conversations

Some people are naturally gifted at contributing meaningful insights off the cuff. Ask them a question, and they’ll surprise you with the quality of their response.

Most people, however, benefit from time. They need time and space to process the information, formulate their ideas, and construct their ideas in a clear and sensible format.

Asynchronous communication gives your team this gift of time.

For example, Jamie has an idea for an upcoming feature. In a synchronous workplace, he’d feel comfortable walking over to Tina’s desk to get feedback on his idea.

Feeling obligated to respond immediately, Tina shifts her attention to Jamie. But she has her own deadline to stick to. She can’t afford to give Jamie too much of her time. So, rather than contribute a meaningful response, she tells Jamie it’s a great idea, then returns to her work, feeling like she did her due diligence as a good, supportive teammate.

In a workplace that embraces asynchronous communication, however, Jamie would write a memo that outlines his idea. He’d then share it with Tina via email or Slack. Tina, who’s working on a deadline, doesn’t check her inbox until later in the day. When she sees Jamie’s message, she responds that she’ll review his outline and offer some feedback by the end of the next day.

Yes, Jamie now has to wait a full day for feedback. But the feedback he’ll receive will be far more useful to him than any hasty response Tina could offer in real time.

Greater autonomy

Synchronous communication limits an employee’s ability to choose when and where they work.

Even if you have a flexible work schedule, synchronous communication comes with the expectation that employees should be available when their colleagues are.

But not everyone is as productive at the same time. Robin in HR might like to work early in the morning. Cameron in Engineering might prefer to work late nights.

While there are exceptions, your team should have the freedom to work when it best suits them.

For those times when a colleague must be reached (like to report a bug), a simple phone call or text will suffice.

A good rule of thumb is to have team members add their phone numbers to their Slack profile. Or, create a document in your company wiki with everyone’s pertinent contact details. Another approach is to create an emergency phone tree list. This list identifies who to call, and how to reach them, based on the emergency and time of day.

Better records

Most asynchronous communication happens in writing, meaning there’s a clear record of conversations and decisions. This clear record creates a more transparent workplace culture. It makes it easy for everyone on your team to get the context they need on their own.

Sure, you can assign someone to take notes during a synchronous meeting. But these notes don’t tell the whole story. They’re snippets recorded by a second-hand source — they lack context, clarity, and perspective.

In an asynchronous workplace, teams create a shared internal document that records the comments and contributions of every teammate — in their own words. These documents can replace your meeting entirely, or be used in addition to your meeting.

Tip: Email chains and Slack channels can also be used in lieu of real-time meetings.

Now, you have a truly representative record of the meeting. Teammates looking for context behind a decision made from this meeting know where to go — that shared document.

More accommodating

Remote workers can feel isolated from the rest of their team, particularly if they’re left out of meaningful conversations.

For example, Jamie and Alex run into each other in the hallway. They start discussing design ideas they each have for an upcoming landing page. By the end of their conversation, they’ve come up with an entirely new mockup that they send to the developer, Theo, who works remotely.

Theo has his own ideas for the landing page, but, at this point, feels two steps behind the group. Is it worth it to share his thoughts and slow down progress? Or should he just go with Jamie and Alex’s idea?

On the other hand, here’s how asynchronous communication democratizes critical information: Jamie and Alex run into each other in the hallway. Jamie proposes a new idea for the landing page. Alex tells Jamie to write these ideas up in a memo so that Theo can contribute his feedback.

Jamie formulates her ideas in a memo, then shares it with Theo and Alex. They, in turn, read through and comment on Jamie’s memo. After a series of asynchronous collaboration, they schedule a conference call to discuss next steps.

In this scenario, Theo is involved from step one — despite missing out on that initial hallway conversation between Jamie and Alex.

Creating an asynchronous workplace

Creating an asynchronous workplace isn’t just about choosing specific tools to communicate. Case in point: Slack and email can be used asynchronously or synchronously. Many teams, unfortunately, use these tools for synchronous communication. For example, Yahoo Labs found that the average response time for most emails is 2 minutes.

Teams need to make a cultural shift in how they communicate if they want to succeed as an asynchronous workplace.

Squash the ASAP mentality

As mentioned earlier, there are scenarios when time is a factor. That should be the exception, not the rule. Your team should avoid phrases like “Can I get feedback ASAP” or “I’d love your input within the next hour.” Asynchronous communication only works if teammates know they have time to process and respond.

Create a clear set of expectations for when teammates should respond to messages. For example: Respond to Slack within one business day and email messages within two business days.

Hold silent meetings

Before your meeting, prepare and share an agenda with a narrow focus. Ask your teammates to review the agenda and draft a well-written memo of their ideas, questions, and comments. Then, set aside time at the start of your meeting for a table read (this table read is the silent meeting portion of your meeting). Attendees read the memos shared by their colleagues and record their ideas and notes on index cards.

Once the table read is complete, engage in a facilitator-led discussion. During this discussion, the team synthesizes the information read, as well as the comments that stemmed from the reading.

Promote strong writing

Strong writing reduces confusion and frustration. A well-written memo, for example, is easy to understand. There is no need for a teammate to follow up for clarity. Strong writing is a core component of asynchronous communication. Of course, not everyone on your team is comfortable writing. Fortunately, there are ways to empower everyone on your team to be better at writing.

Turn off notifications

We all fall victim to notifications. We can’t help check Slack or our inbox the moment we see a new message arrive. It’s Pavlov’s classical conditioning for the 21st century.

That’s why asynchronous workplaces should encourage workers to set aside time blocks during the day to check and respond to messages (email, Slack, etc.). For example, encourage teammates to check Slack first thing in the morning, just after lunch, and at the end of the day.

Need to get in touch with someone immediately? No problem. As we mentioned earlier, have teammates add their phone numbers to their Slack profiles for emergencies only.

Go remote-friendly

If your team can work wherever and whenever they want, they should. No one should feel forced to come to the office — unless their job requires them to. No one should feel obligated to work certain hours — again unless their job requires them to. Studies show remote work can boost productivity.

Be ahead of the curve — embrace asynchronous communication

Eventually, asynchronous communication will be standard practice. Remote work is becoming widely accepted — and asynchronous communication is often the most efficient way to work remotely.

By adopting an asynchronous culture now, you prepare your team for the inevitability that comes from working with remote and distributed employees.

But even if you’re not remote, or have no plans to go remote, embracing an asynchronous culture empowers your team to work more efficiently and communicate more clearly.

Remote Work Can (And Does) Boost Employee Productivity

RC Victorino — Mon, 30 Mar 2020 20:00:00 GMT

Remote workers don’t sleep until noon, wear pajamas all day, and slack off because no one’s watching. Studies suggest the opposite: remote workers are more productive than employees who work in the office.

And although remote work is not new (telecommuting was an option for employees as early as the 1970s), it wasn’t until a 2012 two-year Stanford study that we saw so clearly how remote work impacts productivity and employee satisfaction.

How China’s largest travel agency increased productivity — by going remote

This groundbreaking study, involving 16,000 participants, was conducted by Stanford professor Nicholas Bloom. He enlisted the help of his graduate student (James Liang, co-founder and CEO of Ctrip, China’s largest travel agency).

Liang was interested in developing a work-from-home policy as a way to reduce:

Overhead (the rising cost of Shanghai office space was becoming crippling)
Attrition (employees could not afford to live in the city, resulting in long commutes that impacted their happiness and work/life balance)

Before establishing a work-from-home policy, Liang wanted evidence that remote work would not destroy productivity — and his business.

Enter Bloom. He conducted a study where every six months over two years, he split 500 employees into two groups: 250 employees continued to work in the office, 250 worked from home.

He anticipated the results to be a wash — remote work would not have a profound impact (good or bad) on productivity.

What the study revealed instead took Bloom by surprise.

Remote workers were far more productive.

“We found massive, massive improvement performances,” Bloom recalls in a 2017 TEDx talk. “A 13% improvement in performance from people working at home. That’s almost one day a week.”

Bloom cited two reasons for this boost in productivity.

1. Remote employees worked their full shift

Office employees were more likely to arrive late and leave earlier than remote workers for a number of reasons (they were stuck in traffic; their car broke down; they had to go home to let the cable guy in, etc.).

Bloom’s study revealed that remote workers were not only more likely to work a full shift, but they also took shorter breaks, had fewer sick days, and took less time off.

In other words, they worked more. But working more does not necessarily mean you’re more productive. Working more hours can provide the opportunity to be more productive. This leads us to Bloom’s second finding.

2. Offices are far more distracting than we want to admit

Remote workers in the study reported being able to concentrate more while at home, compared to when they worked at headquarters.

“You hear stories, you know, the person at the desk next door to me, her boyfriend’s just left her, she’s in tears. There’s a cake in the breakout room, Bob’s leaving, come join,” Bloom says. “Whatever it is, the office is actually super distracting.”

Remote workers were able to spend more time working in an environment more conducive to deep work.

The result is an increase in productivity.

But what’s missing here is the human element. Yes, working more hours in a quieter environment can boost productivity in the short term. But employees are not automatons. To remain productive for the long-term, employees need to like what they do at work.

What Bloom discovered was remote workers did enjoy their work more than their HQ colleagues — despite working more hours. Employee attrition decreased by 50% for the remote workers in the study.

Why are remote workers generally happier at work? Autonomy. Remote workers have a greater sense of freedom and control, which makes them happier.

Happier workers are more likely to sustain higher levels of productivity.

The power of autonomy and remote work productivity

In their 2019 State of Remote Work report, OWL Labs surveyed 1,202 full-time workers (62% of who work remotely at least in part). More than 80% of respondents (both remote and on-site workers) stated that working remotely would make them:

Feel more trusted at work
Feel less stressed
Better able to manage work-life conflict

Each of these represents a sense of autonomy. More trust at work equates to a sense of ownership over how you approach each workday. Being able to manage work-life conflict means having control over how you balance your schedule.

This sense of autonomy that remote workers feel is also evident in the State of Remote Work-2020 report published by Buffer and AngelList. In this report, 3,500 remote workers were asked what they viewed as the most significant benefit of working remotely:

Each of the responses centers around autonomy. Autonomy over your schedule. Autonomy over your workplace setting. Autonomy over how you balance life with work.

With this autonomy comes a sense of fulfillment. Fulfillment at work can lead to increased productivity. Employees are inspired to reach their potential because their work experience enriches them in more ways than just monetarily.

But remote workers don’t automatically feel empowered — or fulfilled. Remote work can be isolating, which in turn can negatively impact productivity and morale.

For context, despite being allowed to work remotely full-time following the Stanford study, more than half of Ctrip workers chose to come into the office at least part of the time.

They cited feelings of isolation as their reason.

These Ctrip employees were fortunate that they had the option to come into the office. Not all remote employees have that option. Some employees live hundreds or thousands of miles away from HQ. Basecamp overcomes this obstacle by flying their employees to their Chicago HQ each year. Other remote-friendly companies, like Zapier and Webflow, arrange annual retreats to get their employees together in one space.

But that’s not a practical solution for everyone. You may not have the budget for annual gatherings or retreats, your company may be 100% remote, or the logistics of scheduling such a retreat may be too much of a burden.

That’s why companies must implement a remote work policy that empowers their remote employees to feel connected professionally and socially with their colleagues.

Helping your remote team feel connected

Although offices are distracting, they do make it easy for colleagues to interact and touch base (both professionally and casually).

By not being in an office, remote employees may:

Be unintentionally excluded from meaningful conversations and decisions held offline
Feel socially disconnected from their teammates

The tools your team uses can help you overcome both of these challenges.

Keeping your remote employees informed

Project management apps like GitHub, Jira, and Trello democratize critical knowledge. They serve as a centralized place to record tasks, conversations, and upcoming projects. Project management tools make it easy for everyone on your team to stay informed.

When used appropriately, chat apps like Slack and Microsoft Teams make real-time communication possible — regardless of where your colleagues live. But beware, tools like Slack can make remote workers feel even more isolated. Creating a Slack etiquette guide can help ensure your team uses Slack effectively.

Video conferencing apps (Zoom, Hangouts), in particular, can be incredibly powerful tools that combat feelings of isolation. Plus, they can add the necessary context that virtual communication needs.

According to anthropologist Ray Birdwhistell, as much as 70% of human communication is non-verbal. The crossing of arms, the nod of a head — these cues inform us of how our colleagues think or feel at a given moment. Video conferencing tools make it possible for remote employees to pick up on these social cues as if they’re in the same room as their teammates.

Keeping your remote employees socially connected

Tools like Slack and Zoom are great for getting work done. But they can also be used to help your remote teammates connect socially. You can use Zoom for virtual happy hours. Or, you can do what we do here at Slab. The first 15-20 minutes of our weekly planning meetings (held on Zoom) are dedicated to non-work topics. This is a voluntary part of our weekly meetings where teammates can catch up on each other’s lives.

You can also create dedicated Slack channels for non-work topics. Encourage your team to create their own channels. For example, if Lauren is obsessed with Star Trek, she could create a channel where she and other Trekkies at work can socialize.

Whatever polices you choose to implement, what’s important is making remote employees feel like they’re more than worker bees. It’s far too easy to only reach out to a remote employee when you want or need something related to work.

Be intentional with how you and your team interact with remote workers.

Remote workers can be more productive — if set up for success

Since the 2012 Stanford study, remote work has steadily been on the rise, and that trend will continue. Upwork surveyed more than 1,000 hiring decision-makers for its 2019 study on the future workforce. 73% of all teams surveyed intend to have remote workers within the next decade.

And while the COVID-19 pandemic accelerated that decision to go remote for many teams, this shift seems all but inevitable for a majority of workplaces.

As you prepare your team to work remotely, refer back to the key takeaways from Bloom’s study:

Remote workers are often more productive than in-office workers
When possible, give your remote team the option to come to HQ periodically, so they feel less isolated
Remote work does come with its own challenges — challenges you can overcome by creating a culture of open and transparent communication

Can Silent Meetings Make Your Team More Collaborative?

RC Victorino — Mon, 23 Mar 2020 20:00:00 GMT

Meetings are incredibly unpopular these days. The phrase “meetings suck” doesn’t just have more than 8 million page hits on Google. It’s even the title of a book.

Meetings consume calendars. They disrupt daily agendas. They are one of the most common workplace nuisances cited by employees.

Companies have begun to wonder whether teams could be just as productive and collaborative without meetings. This thinking is particularly prevalent in the startup and tech industries. As Basecamp founder Jason Fried has said, “Meetings should be like salt — a spice sprinkled carefully to enhance a dish, not poured recklessly over every forkful. Too much salt destroys a dish. Too many meetings destroy morale and motivation.”

But the solution to a more productive workplace isn’t eliminating meetings. The answer is to embrace silence.

The problem with “vocal” meetings

Vocal meetings are the conventional meetings teams have, where typically three or more people gather and take turns talking.

Vocal meetings have their place in the workplace, particularly when person-to-person interaction is important. An example is a team-wide meeting designed to inspire employees about an upcoming launch.

But teams default to vocal meetings out of comfort and familiarity without considering the potential repercussions.

Research suggests, for example, that participants who engaged in a vocal discussion during brainstorming sessions produced significantly fewer ideas, of lower quality than those who participated in a silent meeting.

The more participants at these meetings — the more profound the differences in both quality and quantity of ideas.

There are several reasons why vocal meetings hinder idea generation:

One or a handful of people dominate the conversation. This causes introverts to sit back and allow their ideas to get overshadowed.
Attendees zone out or half-listen. They check email, Slack, or last night’s score — often because they’re not actively engaged in the conversation.
Side conversations pop up. Many of these conversations could benefit the meeting-wide discussion, but attendees feel more comfortable sharing them in smaller circles.
Meetings progress to new topics or focal points before everyone has had their say. This is particularly true when teams have an extensive agenda to wade through.
Teammates feel an unspoken pressure to conform to one person’s (or group’s) ideas. This type of social pressure is common in team settings where supervisors attend or where there’s a consensus from the majority.

Each of these factors is the result of a larger issue caused by vocal meetings: production blocking. Production blocking is when a person prevents others in a meeting from contributing ideas. While production blocking can be intentional, more often than not, it’s a natural consequence of the construct of vocal meetings.

Silence can help.

How vocal meetings hinder your team’s productivity

In vocal meetings, one person speaks, then another, making it difficult for a productive exchange of ideas to occur.

For example, James is the facilitator of a meeting where he and four colleagues will brainstorm how to market the team’s latest feature.

He kicks off the meeting by sharing his ideas. By sharing his ideas, he unintentionally blocks the four other meeting attendees from sharing their insights.

When James is done talking, Marie contributes her ideas on marketing, which unintentionally leads to a debate on whether the team should continue spending cash on Facebook ads.

Andrew has a lot to say about this topic, so he speaks up. Now the meeting has shifted focus to an area with which Angela has no experience. By the time she has the floor, the team is no longer talking about marketing the new feature, so she has nothing to contribute.

Her lack of contribution gives James, Marie, and Andrew, the green light to continue debating the value of Facebook ads. Doug has been entirely left out of the discussion thus far. As an introvert, he doesn’t interrupt. Besides, his views on how to market the feature contradict the ideas James shared earlier. And James has been on the team longer, so Doug is uncomfortable opposing him.

By the end of the meeting, Doug doesn’t contribute — at all.

How silent meetings make your team more productive (and happy)

Now consider how a silent meeting empowers each team member to contribute their ideas without the effects of production blocking or social pressure.

As the facilitator, James sends an email to his colleagues a week before the scheduled meeting, requesting they each summarize their marketing pitch in writing.

At the meeting, James hands out copies of each summary — having hidden the names of each colleague on these copies (anonymity can encourage more productive collaboration). The group engages in a silent table reading.

After the table reading, James asks his team to identify the main ideas presented in each summary. He then lists these ideas out on a whiteboard and asks his teammates to place a star under each idea they think is worth discussing. The result looks like this:

Tip: For remote and distributed teams, use a collaborative tool like Lucidchart for these brainstorming sessions.

James uses the outcome of the whiteboard exercise to prioritize the discussion portion of the meeting. The idea with the most stars is discussed first — and likely gets the most attention.

In this scenario, the meeting is broken up into three parts:

The pre-meeting preparation, where individuals brainstorm ideas on their own, in writing
The silent meeting table read, where attendees review their colleagues’ ideas in silence
The discussion portion, where attendees now have the context needed to exchange ideas

This silent meeting approach has precedence.

Jeff Bezos requires each member of his senior executive team to read lengthy memos before he opens meetings up for discussion. That way, they come to the meeting prepared. Companies like Twitter and Square have also adopted silent meetings.

Silent meetings eliminate production blocking by giving everyone equal time to share their ideas and process the ideas of their colleagues. They also remove the peer pressure and social humiliation some people experience in vocal settings.

“Attendees often hold back in meetings, waiting to hear what others say and what their boss might say out of fear of being perceived as difficult, out of touch, or off the mark,” write Steven G. Rogelberg and Liana Kreamer for Harvard Business Review. “Silence can be a solution to this problem, allowing space for unique knowledge and novel ideas to emerge.”

In silent meetings, introverts gain more confidence. Subordinates don’t mute their opinions to appease their superiors. Individuals don’t conform their thinking to the majority.

Silent meetings empower attendees to brainstorm and ideate on their own terms.

Using silent meetings at your workplace

The scenario we presented earlier is an effective use of silent meetings — where silence serves as a preamble to a more focused vocal discussion. If your team is new to silent meetings, this is the most effective approach to apply. It slowly introduces your team to the concept of silence.

You can also hold entirely silent meetings. Using our scenario above, James would not have held the vocal discussion with his team. Instead, that discussion would take place later on, in an asynchronous channel like email or Slack.

Embracing a full silent meeting can be a challenge for teammates new to the concept. We suggest easing them in, first.

When holding a silent meeting, use these guidelines offered by David Gasca as part of his Silent Meeting Manifesto:

Prepare an agenda with a narrow focus. One topic is ideal.
Choose a facilitator. Don’t always default to the same people. Show your entire team that you trust them with this responsibility.
Create a “table read” for attendees to digest at the start of the meeting. In our example above, the table read is made up of each teammate’s marketing pitch.
During the table read, teammates will surely have ideas or comments come to mind. Have them write those out (on index cards or post-it notes, for example).
Engage in a facilitator-led discussion where the team synthesizes the information read, as well as the comments that stemmed from the reading.

“I’ve expanded Silent Meetings for my teams to make it our default approach. The largest forums in which I’ve used Silent Meetings are day-long 70-person planning sessions but I also regularly use them for meetings with 4 to 40 people.” — David Gasca

Adding silent meetings to your arsenal of options

Some meetings are unnecessary. For example, can the topic you intend to discuss at the meeting be resolved asynchronously? Then don’t call the meeting.

But when you do want to assemble a group of people in one place, at one time, vocal meetings are not your only option.

Silent meetings can empower your team to be more enthusiastic about brainstorming and collaboration.

Empowering Your Team to Regulate Their Emotions at Work

RC Victorino — Tue, 10 Mar 2020 20:00:00 GMT

Many companies strive to cultivate a culture where emotions are anything but volatile. Having an even-keeled demeanor is seen as a formula for cohesiveness. Even-keeled teammates don’t lash out at colleagues. They don’t create a hostile workplace.

But an even-keeled demeanor does not come naturally to everyone.

Humans are emotional. We get anxious at an impending deadline. We get angry when someone critiques our work. We get stressed when stuck in traffic, then we bring that stress into the office.

The most challenging problems managers and executives struggle with are tied to emotions, according to Rachel Green, Director of the Emotional Intelligence Institute of Australia.

“The technical problems can be solved,” Green says. “But the people problems are the hardest to deal with.”

Managing these “people problems” requires empowering your team to learn how to regulate their emotions — so that they can respond to any scenario at work in a constructive, positive manner.

The power of emotion regulation

Knee-jerk reactions can lead to adverse outcomes. If you’ve raised your voice, snapped at a colleague, or hammered away an angry Slack message, you’ve experienced how challenging regulating your emotions can be.

Our need to react is a primal response that occurs when our amygdala, which regulates fight or flight, is triggered.

While some people are naturally gifted at resisting the urge to “fight,” others are not. Fortunately, the power to pause and reflect — rather than react — can be learned. Recognizing that you can choose how to respond to something, despite how you feel, is the foundation of emotion regulation.

“When we buy time, we then have access to the frontal lobes of our brains, where we have access to reasoning, better problem solving and perspective,” explains Dr. Kris Lee in her 2018 book Mentalligence: A New Psychology of Thinking: Learn What it Takes to be More Agile, Mindful and Connected in Today’s World. “We never have to take the bait of primitive emotions.”

Your upstairs brain vs. your downstairs brain

J.J. Gross, in his 2015 Handbook of Emotion Regulation, defines emotion regulation as “the process by which individuals influence which emotions they have, when they have them, and how they experience and express these emotions.”

In other words, emotion regulation empowers you to know what you’re feeling and what to do about it in any environment. It can influence:

The type of emotion you experience
The intensity of that emotion
When the emotion starts (and how long it lasts)
How you express that emotion

None of this is possible until you identify your emotions. Author and psychologist Dan Siegel refers to this as the need to name it to tame it.

To understand the effect of name it to tame it, consider this simple analogy Siegel uses:

You have an upstairs brain — or cortex — where you do all your thinking and planning. You also have a downstairs brain (subcortical), responsible for emotions, motivation, and the fight or flight response.

Your downstairs brain becomes active when you feel a specific emotion, like anxiety or fear. This reptilian part of your brain cannot reason through this emotion. Its job is to assess the scenario in an instant and tell your body to fight or leave.

But you have control over this instinct. By simply identifying (and naming) the emotion you’re feeling, you trigger your upstairs brain — the part of your brain that does use reason.

According to Siegel, studies show that when you name the emotion your downstairs brain generates, your upstairs brain will pass “soothing neurotransmitters” to the downstairs brain to calm it down.

When the instinct to react is kept at bay, you have the opportunity to pause, reflect, and choose how to respond to what you’re feeling.

This name it to tame it strategy is a common theme in each of the four branches of the widely referenced Mayer-Salovey Four Branch Model of Emotional Intelligence.

Mayer-Salovey Four Branch Model of Emotional Intelligence

The four branches of the Mayer-Salovey Four Branch Model of Emotional Intelligence are:

Perception, Appraisal, and Expression of Emotion
Emotional Facilitation of Thinking
Understanding and Analyzing Emotions; Employing Emotional Knowledge
Reflective Regulation of Emotions to Promote Emotional and Intellectual Growth

These four branches are arranged in order of complexity. The lowest level branch (Perception, Appraisal, and Expression of Emotion) focuses on more basic skills — the ability to perceive and express emotion. People who struggle to control their emotions should start here.

The highest level branch focuses on a more complex skill: the conscious, reflective regulation of emotion. People who are naturally inclined to control their emotions will find an easier time achieving this higher-level branch.

It is possible to progress through each branch to evolve into a highly emotionally intelligent person — someone who can regulate their emotions and use them to better themselves and others.

Below we break down each branch. When reading the first three sections, keep in mind the following scenario:

Your boss emails you to express disappointment in a project you spent a considerable amount of time on. Your body tenses. Your heartbeat quickens. You’ve clicked ‘reply’ to the email and are ready to respond...

1. Perception, Appraisal, and Expression of Emotion

This is your ability to identify and label specific feelings in yourself and others — just like Siegel’s name it to tame it example.

But this branch takes things one step further. Not only is it important to label emotions to control them. You have to be able (and willing) to discuss these emotions.

Using our workplace scenario above: You recognize that your tense body and hastened heartbeat are symptoms of getting upset. You explicitly say out loud, “I feel upset right now.”

Rather than immediately reply to your boss to defend your work, you reach out to a trusted colleague and share how you feel. This gives you enough time to tamper down your emotions and respond to your boss in a non-confrontational tone.

Tip: You don’t have to discuss your emotions with a colleague, or anyone else. You can also express your emotions in writing that you don’t share with anyone — meaning explicitly write out that you feel angry, for example. Often this is the most productive path to take.

Also, having a list of emotions on hand can make it easier for you to identify how you feel. Use this list below, courtesy of Harvard Business Review, for reference:

2. Emotional Facilitation of Thinking

This is the ability to use your feelings constructively; to let these emotions guide you to what is most important for you to think about.

Using our workplace scenario, while sharing your emotions (whether with a colleague or in writing), you try to understand your boss’s perspective.

Effective communication occurs when you can empathize with your audience. What was your boss’s expectation of the finished project? Where, in her eyes, did you fall short?

When we react on impulse, we don’t give ourselves enough time to separate our emotions from the bigger picture. We fail to consider others’ needs. But when you pause, identify your feelings, and connect your emotions to the bigger picture, you’re more likely to offer solutions in your response to your boss — and not merely an emotional defense.

3. Understanding and Analyzing Emotions; Employing Emotional Knowledge

This is the ability to understand the meanings of emotions and how they can change. Those who achieve this level of emotional intelligence understand how emotions are connected to our basic psychological needs.

Using our workplace scenario, you not only recognize that you’re getting upset. You can identify why you feel this way. Your boss’s approval is important to you. To you, her disappointment in this one project equates to her disappointment in your overall contribution to the team. This leads you to question your value at work, which leads you to worry that your career is in jeopardy.

By processing all that, you’re able to take a step back and realize this is just one project. There are countless times when your boss sang your praises. This empowers you to respond to her with calm confidence, knowing you are more than capable of exceeding her expectations as you’ve done before.

Achieving this self-awareness equips you with the skills necessary to help others — which we discuss in step four below.

4. Reflective Regulation of Emotions to Promote Emotional and Intellectual Growth

This is the ability to turn negative emotions into growing opportunities and, specifically help others identify and benefit from their emotions.

For this section, let’s introduce a slight alteration to our scenario:

You and your colleague work together for two months on a project. After presenting your project, your department head expresses his disappointment in the outcome. Your body tenses. Your heartbeat quickens. You notice your colleague looks as tense as you feel...

First, it’s important to accept that you can’t help others until you help yourself. It’s why flight attendants instruct you to put your oxygen mask on first. And it’s why this — the final branch— is considered the most challenging to achieve. You need to be the master of your domain before you can empower others to master their own emotions.

After identifying you feel upset, you understand that the only person responsible for you feeling that way is you. It was not your department head’s intention to upset you — he does not have that much control over you. No one does.

This puts you in control of the situation. Rather than respond to your department head immediately, you ask if you and your colleague could take the afternoon to reconvene. You do this because you know your colleague is still in fight-or-flight mode. His “upstairs brain” has not triggered. Removing him from the situation eliminates the potential of him lashing out at your department head, causing irreparable harm.

Because you’re capable of identifying your emotions and understanding why you feel how you feel, you are able to help your colleague walk through the necessary steps — starting with name it to tame it. You help him see your department head’s critique isn’t personal. It’s just one isolated incident.

Then, you ask your colleague to put himself in your department head’s shoes. What was he expecting from the project? Where could you do better? What can you do that would surprise and delight your department head?

Now, by the time you and your colleague respond to your department head’s criticisms, you have an action plan in place to improve the project — and buy-in from your colleague.

The common thread: learn how to react on your own terms

Your team is likely made up of people with varying degrees of emotional intelligence. Regardless of one’s emotional intelligence, the commonality here is the ability to react with intention.

But reacting on your own terms doesn’t just occur because you simply held your tongue for a few moments. If you want to improve how you respond to specific workplace scenarios – regardless of how you feel — you need to rehearse your desired reactions. For example,

How would you like to react to a stressful situation?
What would you prefer to say when confronted with an idea you don’t like or agree with?

Encourage your team to create a personal response document for how they want to respond to common workplace scenarios. It’s particularly effective if these documents incorporate each employee’s unique triggers.

For example, Dotty in HR gets annoyed when someone misuses the general Slack channel. Her response document should include a script for how she would prefer to respond to her colleagues when they misuse Slack.

“Research shows we are capable of building a positive emotional repertoire and redirecting our energies to help us from being stuck in negative emotional states.” — Dr. Kris Lee

Just remember, before you can respond on your terms, you need to pause long enough to name and tame your emotions.

Creating an environment that fosters emotional regulation

1. Asynchronous communication

There is a growing number of remote and distributed teams in the workforce. At the same time, there’s a push for these teams to embrace synchronous communication through tools like Slack and Zoom. Synchronous communication can be useful — sometimes. Real-time conversations help teammates brainstorm and build camaraderie.

However, synchronous communication also makes it harder for people to practice control over their emotions.

As a distributed and remote-friendly team, we here at Slab have embraced an asynchronous culture. We share and respond to critical knowledge inside Slab — and use Slack for ephemeral topics.

But asynchronous communication isn’t reserved for remote and distributed teams. Centralized teams can benefit from it as well. It’s challenging to work through the steps of the Mayer-Salovey Four Branch Model of Emotional Intelligence in a real-time conversation. Shifting communication to channels such as email (and even Slack, when used as an asynchronous channel) can empower your team to practice the skills necessary to become highly emotionally intelligent.

You can learn more about our approach to asynchronous communication, as well as tips on how to create a healthy Slack etiquette guide in our article, Creating a Slack Etiquette Guide for Your Workplace.

2. User manuals

Many teams — including ours — have teammates write a user manual. These manuals, or user guides, help colleagues know what makes each of us tick (and what makes us lose our mind). There is no formal template to creating a user manual — although we’re particular to the approach by Chris Blachut.

We also think it’s a good idea to add those personal response document scripts discussed earlier inside these user manuals.

These manuals can empower teammates to identify colleagues’ triggers and steer their teammates to their desired responses, rather than knee-jerk reactions.

For example, if you notice the tone of Dawn’s voice becoming a little sharp after a conference call, her user manual is a useful tool to help her pause, reflect, and choose her desired response.

Emotions are unavoidable — but manageable

As complicated as we make emotions to be, they are little more than energy built up inside our bodies. This energy seeks some type of release — in the form of expression.

We all have a choice: We can let our “downstairs brain” dictate how we respond to our emotions, or we can trigger our reason-driven upstairs brain, and set forth a series of events that leave us empowered by our emotions — rather than at their mercy.

By simply naming how you feel, you take responsibility for your emotions and make it more likely that regardless of how you feel, you can make the most out of any scenario.

Creating a Slack Writing Etiquette Guide for Your Workplace

RC Victorino — Wed, 04 Mar 2020 20:00:00 GMT

Teams misuse Slack just as frequently as they use it. This misuse often leads to hostile workplaces, overstressed workers, and the degradation of productivity.

The public ouster of former Away CEO Steph Korey, after a revealing Dec. 5, 2019 article published in The Verge, is an extreme, albeit temporary example. But it demonstrates just how influential Slack has become in shaping modern workplace culture.

The misuse of Slack has led to its villainization. Countless published articles reveal Slack’s negative impact on work productivity and social civilities.

“Office gossip is as old as the office,” writes Molly Fischer for New York Magazine. “But [Slack] made that gossip searchable and public to anyone who knew where to look. It was a very, very stupid way to air grievances. And yet, at the same time, Slack was also the obvious place to do it.”

But Slack is not the culprit here. Slack can be an incredible messaging platform — particularly for remote teams distributed across time zones. The root cause of all this hostility, distraction, and anxiety is how teams use Slack.

When used effectively, Slack can unite remote teams, make organizations more transparent, and simplify your workplace communication.

Misuse Slack and the result could be, as Zoe Schiffer wrote in her article on Away for Verge “… a company culture people fear, and a cadre of former employees who feel burned out …”

How teams misuse Slack

We’ve begun creating our own Slack etiquette guide (which we share later in this article). Our unspoken understanding has worked for us as a small team. But as we grow, we believe a documented communication style guide is the most effective way to avoid confusion, anxiety, and misuse.

Based on our own Slack usage, we’ve identified two common misuses:

Lack of context in messages
Attempting to use Slack as a synchronous tool

Below we dive deeper into each misuse.

Lack of context in messages

Written content has always endured challenges because of a lack of context. It’s reasonably easy to misinterpret a written message based on one’s frame of mind at a given moment.

Some studies suggest an overwhelming amount of communication comes in the form of body language. Unfortunately, body language does not exist inside Slack.

Teams struggle to provide necessary context in longer form messaging, like emails. Slack makes it even more challenging, because conversations happen in real-time, often in the heat of the moment.

Few people take a moment to reread their Slack message to ensure its clarity. They type and send as quickly as the thoughts enter their minds.

Since Slack has become a primary communication channel for teams, any misunderstandings and assumptions can lead to severe bottlenecks — or worse

“Context adds specificity to your writing and directs the reader’s attention to a particular train of thought. Thus avoiding, to a certain extent, unwanted interpretation.” — Julien Samson

In our article, “Why Everyone on Your Team Should Strive for Good Writing”, we share a list of four criteria that can help everyone on your team create better context around all of their writing — including Slack messages.

Expecting Slack to work as a synchronous tool

Slack’s real-time communication makes it easy for teammates to write what’s on their mind and share it with their colleagues as quickly as the thought comes to life.

There are benefits to this. For example, Slack is a convenient place to relay and repeat important decisions that have been made, to a broad audience. However, many teams spend so much time inside Slack that they make critical decisions inside the chat platform.

But Slack isn’t conducive for in-depth, analytical work that requires ongoing conversations lasting days or weeks.

We’ve found it far more useful to use Slack asynchronously. Slack is our dedicated space for ephemeral communications — conversations that don’t need to be preserved for future reflection or action. This prevents any important information from getting lost in the Slack void. If knowledge shared on Slack is important enough, it’s moved into a Slab post.

For example, our CEO, Jason, recently published a year-end-review post inside Slab. These types of posts have a long shelf-life, allowing future teammates to benefit from reading these reviews.

In our team’s #general Slack channel, Jason posts a message to the team, directing our attention to his end of year report:

“Hey team, I wrote our Year-End Review. Please take some time to read it, and I look forward to beginning the new year with you all!”

This short message was purposely crafted to ensure no one on the team felt compelled to respond quickly (or at all) via Slack. And because Jason crafted the end-of-review post inside Slab, we were able to make comments directly inside that post, rather than inside Slack, where messages get lost in the shuffle.

“This form of communication is sometimes useful (e.g., in emergency situations) but presents significant downsides when it becomes your team’s primary way of communicating.” — Fast Company

Slab’s Slack etiquette guide

Our 10-point Slack etiquette guide specifically addresses the lack of context that plagues Slack communication. It also aims to minimize anxiety felt by your teammates due to excessive notifications and unrealistic expectations. You’re welcome to use the guide below for your own organization.

1. Create channel descriptions

Create clear channel descriptions to establish the channel purpose and to prevent conversations from going off-track. Then ensure all channel members read them. Revisit these descriptions periodically and update them as necessary.

2. Review channels regularly

Each quarter, archive channels that no longer serve a purpose or that have grown stale. It's good practice to split busy channels (those with an overabundance of notifications) into new channels.

3. Use Slack for ephemeral communications only

Ask yourself, does this conversation need to be preserved for future reflection or action? If not, continue using Slack. If so, transfer the important elements into Slab.

Pro tip: Use the Do Not Disturb to prevent unwanted notifications and distractions. This feature is turned on by default outside of work hours. But you can turn this on at anytime.

4. Review and edit messages before sending

Resist the urge to send Slack messages the moment a thought enters your mind. Ask yourself: How can I simplify and clarify my message so the reader isn’t overwhelmed and confused?

A Slack experience without review and editing

8:34 AM Hey Jason, I didn't find a good source to quote for our article on Slack Writing Etiquette. I'm thinking we can't poll our customers?

8:34 AM Wait, sorry, I mean we can poll our customers.

8:35 AM Maybe we can poll 100? See what we get?

8:35 AM While I wait for your input, I'll keep looking for other good sources.

8:36 AM Let me know if have any sources you want me to reach

A Slack experience after review and editing

8:36 AM Hey Jason, for our Slack Writing Etiquette article, we need some social proof and I can't find a good quote. I'm thinking we can poll 100 of our customers, what do you think? I won't take any action either way until 11 a.m. tomorrow, so you have time :)

5. Don’t overuse group DMs

Private conversations held in group chat aren’t readily available to anyone else on the team. Instead, create public channels for projects and invite key stakeholders to each of these channels

Once the project is complete, archive that channel. Conversations from an archived channel can be recovered at a later date.

Tip: You can turn a group chat into a channel anytime.

6. Use threads

Respond to messages inside threads to:

Minimize unwanted notifications, and
Group relevant conversations together

7. Designate a non-work channel (or a few!)

Casual conversations build trust and teamwork. Create a #random channel and encourage teammates to share their non-work musings there.

8. Know when to use @here and @channel

@channel notifies everyone inside a channel, meaning, if a member of a channel isn’t active on Slack right now, they’ll get notified of your message when they become active.

It should be used for emergencies or channel-wide announcements — messages you want everyone to get, no matter what.

Example: If you need the owner of a car to move so your delivery trucks can pass, @channel makes sense. So does notifying engineering about a problematic bug.

@here notifies people in the channel who are active at the moment you send the message, meaning those not active won’t get notified.

It should be used for non-urgent announcements.

Example: If you want non-urgent feedback from anyone in a channel, use @here.

9. Offer context with emoji reactions

Emojis can help you clarify the tone of your message when words fail. For example, the following message could be construed in several ways:

“I’ll get to the report this afternoon.”

How that message is received often depends on factors outside your control, such as the emotional state of the targeted audience. If, for example, your colleague is having a bad day, then this message could come across as dismissive.

Minimize confusion with emojis. By adding one below, it's clear that you are not annoyed, or at least do not want to come across as such:

“I’ll get to the report this afternoon 👍🏾”

10. Use reactions as an acknowledgment

Below are a few examples:

Use a checkmark to acknowledge receipt of a message
Use eyes to acknowledge that you’re reading or looking into something
Use a thumbs up or smiley face to show your approval

This approach minimizes notifications and discourages an infinite back-and-forth loop of ‘thanks’ and ‘you too’.

Creating a saner Slack

Many people wrongly attribute Slack as the source of their workplace hostility and frustration.

But Slack is just a tool. Any negative effects your team experiences with Slack can be traced back to how you use it.

Creating an etiquette guide ensures your team feels more empowered and less anxious while using Slack. A guide dispels ambiguity and gives you a single resource to point to if and when confusion arises.

Slack doesn’t have to be a source of anxiety. Your etiquette guide can bring it back to the tool it was always intended to be.

Why Google Docs Falls Short for Internal Documentation

RC Victorino — Wed, 26 Feb 2020 20:00:00 GMT

Teams have dozens of options to choose from for their internal documentation. They often choose the wrong tool to get the job done.

There are tools like Slab, designed explicitly for team documentation. And there are tools like Google Docs, Dropbox Paper and Quip designed primarily for word processing.

Many teams initially gravitate toward these more general purpose document editors for logical reasons:

These editors are familiar to most people, meaning they can be easier to adopt across an organization
Most companies already use (and pay for) at least one of these tools
Teams realize the need for documentation, but aren’t thinking of how their documentation tool will scale alongside their business

But over time, most teams find the issues associated with these tools outweigh their benefits — particularly as these teams scale. These limitations (like poor organization and unreliable search capabilities) frustrate users and slow down productivity. As a result, most internal documentation tools becomes stale, underused, and irrelevant.

Using a tool specifically designed for internal documentation can help. And while not every team needs a dedicated tool for documentation, every team should know the limitations they’ll experience by using document editors like Google Docs, Dropbox Paper, and Quip.

These limitations exist because document editors prioritize personal writing and editing over team reading. In other words, document editors work great for writing blog posts and school essays. They become problematic when multiple teams across a company contribute to and search for shared knowledge.

Below we break down the issues teams inevitably face when they use document editors like Google Docs, Dropbox Paper, and Quip for their internal wiki.

Lack of context

Document editors use a standard folder concept to store and organize content. These folders work fine for someone working alone or in a small group.

But when a growing number of team members contribute more content to your wiki, the lack of context associated with the standard folder structure gets confusing.

Take a look at the image below as an example:

Besides the name of the folder itself, there’s nothing telling team members what type of content belongs there. Teammates make assumptions — or spend time parsing through the folder contents — to get the context they need.

This wastes time and frustrates teammates. And still, without context, there is no surefire way of knowing what type of content belongs in a folder. As a result, it’s not uncommon for teammates to save documents in the wrong place, or unknowingly create a duplicate version of a document they never found.

No clear owner

Once a teammate opens a document, they have no idea who to connect with to ask a question or suggest a change. If an engineer needs clarification in a code-review document, who do they reach out to? Document editors don’t provide that kind of context.

As a result, teammates hesitate to ask for clarification or suggest changes. This stifles collaboration and compromises the accuracy of team wikis.

Duplicated posts

A standard folder structure is also restricting. Not everyone on a team agrees on exactly how and where documents should be stored. Team members conform to an existing structure that may not align with their preferred method of organization.

To get around this, many people duplicate Google docs, for example, and save these duplicates on their own Google Drive space, outside the confines of the team wiki. Yes, this gives these individuals more control over the structure of their documents — but it destroys the intention of your team wiki, which is to be the single source of information for your company.

Now, compare this to the topic structure we use at Slab.

Descriptions

Teams can add a description for each Slab Topic (much like Slack channel descriptions) explaining the purpose of the topic. For example, our team has a topic called Blog. The description for this topic is Discuss new content before it’s published to the official slab blog.

Teams can also pin posts inside Topics, and arrange these pinned posts however they want. Inside our Blog topic, we’ve pinned the essential posts team members should read — and arranged these posts in the order that team members should read them in.

Post Maintainers

Every Slab post has a designated maintainer. Everyone who visits a Slab post can see who is responsible for that post, as well as anyone who has contributed to it. This makes it easy for team members to know who to ask for clarification or follow-up.

Post Maintainers and team members who have contributed to a post are notified of any changes made to that post. This ensures the content of your knowledge base remains accurate.

Customized organization

Slab Topics work like labels. You can assign as many topics as you want to a post.

For example, a Slab Post documenting your postmortem process can be assigned to topics including Engineering, Marketing, Product, and Operations (since each of these departments likely use or reference postmortems).

Going even further, individual teammates can add this document to other topics or subtopics. For example, Jim in Sales can add this postmortem doc to a topic he created for himself, known as “Jim’s Critical Docs.”

Adding a Slab Post to one topic doesn’t remove it from another. That is often not the case with folder structures used by conventional document editors.

Too many formatting options

Being able to align text, change the background color, and move images anywhere across a page are nice features to have. But they’re detrimental to the documentation process.

Humans are easily distracted. If your teammates have the option to format their documents, they will. In fact, they’ll likely spend more time formatting their document than they will focused on the quality of the content.

But distraction isn’t the only issue — excessive formatting options create disorder inside your wiki.

Teams rely on internal documentation to help them make critical decisions fast. A new member of your team should be able to look at any document across your knowledge base and identify the essential information, without stumbling over formatting.

That’s why dedicated documentation tools include only the most essential formatting options, including:

Headers
Blockquotes
Bold/Italicize
Linking

Anything else is distracting and disorienting.

Search is just a second thought

When you first create a team wiki, search capabilities may not be at the top of your needs. The organizational structure you put into place can handle the few documents you’ve created.

However, as your company grows and more people contribute to your knowledge base, you can no longer rely on this approach. Even if teammates know what folder to go to, that folder may contain dozens of documents. Parsing through these documents to find the right one not only eats up valuable time — it also frustrates your team.

The more frustrated your team is with your wiki, the less likely they’ll use it.

That’s why with Slab teams can search for content using keywords, rather than hunting around different folders.

Plus, we realize critical information lives outside a team’s knowledge base. Slack, for example, is home to some of your team’s most important conversations. Slab Search integrates with tools like Slack, Dropbox, and Google Drive — so teams can easily search for content across all their tools from one dedicated space.

We built Slab’s search function to be fast and scalable while populating results with the most relevant answers, based on how you and your teammates consume your content. This depth of search-result prioritization filters out the noise and helps team members find what they want — fast. In the end, your team will view your knowledge base as a valuable tool rather than just another app.

Make decisions for the long-term

A considerably large number of teams that switch to Slab do so after initially using a document editor tool like Google Docs. Over time, they grow frustrated with the shortcomings of their existing tool.

Fortunately, we make migrating to Slab simple. However, teams can struggle to adapt to another tool when they’ve already adapted software into their workflow.

When searching for a solution for your internal wiki, consider where your team will be one year from now. Will multiple teams contribute to your knowledge base? Will you add new team members who’ll need access to a variety of procedural documents?

If you answered yes, then a document editor is likely not your ideal choice for documentation.

Overcoming Knowledge Hoarding in the Workplace

RC Victorino — Wed, 19 Feb 2020 20:00:00 GMT

Knowledge sharing is critical to a company’s success. It makes onboarding easier and gives every team member the context they need to work autonomously and excel at their job.

Plus, knowledge sharing helps your teammates stay connected. The more knowledge you share, the more you shape and define your company culture.

That’s why we built Slab, to make knowledge sharing more accessible.

But Slab isn’t a magic bullet. No software is. Just because your team uses a company wiki doesn’t mean team members will share their expertise willingly. Their natural inclination may be to hoard their knowledge.

Knowledge hoarding — when employees purposely keep critical knowledge to themselves — is a fairly common phenomenon found in companies of all sizes. It’s an uphill battle to create a culture of knowledge sharing if you don’t address knowledge hoarding head-on.

As our team grows from our initial product and engineering teams to content, marketing, customer support, and beyond, we’ve looked for ways to prevent knowledge hoarding from finding its way into our own company culture.

To do this, we first had to identify why employees hoard knowledge.

Why employees hoard knowledge

Our research suggests that employees keep critical knowledge to themselves for typically one of three reasons:

Leverage: If an employee hoards their knowledge, they may feel like they are irreplaceable.
Fear: Putting yourself out there can be intimidating. What if colleagues or supervisors respond with negative feedback?
Competition: If your workplace rewards personal triumphs over shared victories, employees are less likely to want to share their “secrets.”

Regardless of the reason behind the behavior, research shows that motivation may be the answer to helping your team embrace sharing their knowledge.

Motivate employees

Research done by Harvard Business Review, published in the Journal of Organizational Behavior, found that employees are far more likely to share knowledge if they are personally motivated to do so — not when they’re explicitly rewarded for it.

That could be because personal motivation has the power to overcome one’s fear of giving up leverage or being critiqued by colleagues.

Employees who are motivated to share knowledge are likely to engage in internal dialogues like:

“I love getting to share what I know with others.”
“It’s really important for me to share what I know with my team.”

The result is an autonomous knowledge-sharing culture, one that sustains as you scale.

But how do you motivate your team to share critical knowledge?

Create clear guidelines

No one on your team should have to guess what’s worth sharing. There should be clear instructions and context, otherwise, you risk inaction.

For example, a Customer Support rep on your team creates a new process for identifying bugs in your product.

Does she create a document in your knowledge base for this, and if so, where?
Should she edit an existing bug report document, and risk offending the teammate who created that existing doc?
Should she ping her team lead for clarity, and risk being seen as incapable of making decisions on her own?

Faced with these scenarios, she’s most likely to keep the new process to herself. It’s the least risky of her choices.

That is not the result what you want. This behavior creates siloed thinking within your team and robs your colleagues of potentially valuable information.

Every team should have clear guidelines on what goes into a knowledge base and what doesn’t. On our team, we use Slab’s topic descriptions feature for this.

Here’s an example:

The image above shows the subtopic Importing Content, which lives inside the Support Team’s topic section. The description, “How to automatically/semi-automatically import content for our users.” explains what types of posts belong in that subtopic. If it has to do with important content for our users, it belongs here.

Here’s another example of a topic description with even more context:

The description above provides specific instructions on what a teammate should do if/when they need to update our integration pages.

Nurture collaboration

Employees like to be recognized for their work. Writers want to know their content style guide is useful. Engineers want to hear that their local development guide is seamless and easy to follow.

But employees aren’t typically recognized when they share knowledge with their colleagues. Often, they’re provided little to no feedback, leaving them unsure if their content is useful.

They also question whether it was worth the effort.

Recognition and appreciation are positive reinforcers that shape behavior. And, it’s an effective way to reinforce to your team that sharing knowledge is as important as any other contribution they provide to the team.

Even a simple thanks is an easy and unambiguous way for teammates to show their appreciation for the effort and transparency of one of their colleagues. That’s why a core feature inside Slab is the ability for teammates to thank post owners for their contributions or give accolades via emoji.

We also deliberately make the list of contributors and maintainers associated to a post highly visible (at the bottom of every post, as well as listed in the associated topic). That way teammates can easily see who to ask, thank, or mention in response to a specific post.

Why knowledge hoarding is so damaging

Before the digital revolution, an organization’s knowledge had a longer shelf life. Processes remained intact for years, if not generations.

That is no longer the case. Today, relevant knowledge expires at an alarming rate. And employees remain with one company, on average, for just over four years.

Having an organization that actively shares its expertise keeps your team from falling behind.

Knowledge hoarding = productivity drain. Knowledge sharing = employee empowerment.

What we’ve discovered is it’s not enough to say you want your team to share knowledge. You need to practice what you preach and demonstrate just how important shared knowledge is to you.

For example, we make knowledge sharing a regular part of meetings. We open up and update key documents during meetings, so our team members visualize the connection between exchanging ideas and preserving them in Slab.

Your goal is to tear down any preconceptions your team has about documentation. Reduce the fears they may have about giving up leverage or being judged by their peers.

These steps should drastically minimize the likelihood that your employees will purposely keep their critical knowledge to themselves. They have certainly helped us to keep the fallout from knowledge hoarding at bay here at Slab.

Why Everyone on Your Team Should Strive for Good Writing

RC Victorino — Fri, 03 Jan 2020 20:00:00 GMT

Writing is an essential method of communication, no matter the role someone has on your team.

A designer may need to persuade both an engineer and UX writer to buy into her project proposal. How she writes her email or abstract could set the tone for her colleagues’ level of enthusiasm.

An engineer may need to explain to a customer support rep the inner workings of a particular feature. How clear that explanation is can dictate how well the support rep does at educating the customer.

Hiring managers often write narrative summaries of their candidate interviews to share with colleagues. A compelling narrative will help others see what these managers saw in a candidate. Dry, confusing narratives can have an adverse effect.

Writing has become even more essential with the rise of chat tools like Slack, as well as the increase in remote work. Remote teams depend on writing and asynchronous communication. And if the upward trajectory over the last decade is any indication (as released by the U.S. Census) remote workers will become more ubiquitous. So, too, will the need for clear written communication.

Tools like Slack make it easy for folks to get by with half-thoughts, jargon, and emoji some of the time. But writing well is still the foundation of how people connect with and influence others — whether or not your team is remote.

Of course, not everyone on your team writes well. Some people loathe it, others fear it. You can’t expect to have wordsmiths across your organization. At the same time, you can cultivate a culture of good writing that empowers your team to be mindful of their messages.

To do that, let’s first address an existing preconception.

Good writing isn’t perfect grammar

Perfect grammar has its place. The fast-paced environment of your workplace likely isn’t one of them.

Few people on your team should be expected to confidently identify a split infinitive.
No one should fear being critiqued for using the passive voice.
And no one should be judged for starting a sentence with and.

Your goal in fostering good writing is to help employees communicate effectively. Grammar, in the end, is just a set of rules designed to ensure folks understand your writing.

David Ogilvy, known as the father of advertising, agreed.

“I don’t know the rules of grammar,” Ogilvy once said. “If you’re trying to persuade people to do something or buy something, it seems to me you should use their language.”

Good writing executes on its mission

Every piece of writing has a purpose. This article’s purpose, for example, is to:

Educate readers on how to develop their team’s writing culture
Inspire others to write more
Introduce a specific audience to Slab

A social media post’s purpose is to grab attention and (more often than not) illicit a click, comment, or share. An email from a CEO to investors aims to provide a progress update and get investors excited about the company’s prospects.

If a person’s writing achieves its intended purpose, chances are it’s good writing. So, how do you help your team’s writing meet its intended purpose?

This list below can help. We encourage you to share it with your team. It’s applicable, even when it comes to something as brief as an email:

Identify your audience and message. Besides your journal, all writing has an audience. Who’s yours? What action do you want that person to take? What key points do they need to know about in order to take action?
Outline your writing. It doesn’t have to be complicated. Create a framework where each key point has its own section, arrange each section in a particular order, and add a few sentences about what each section is about.
Write your first draft. Fill in the holes of your outline with supporting sentences for each section. Use short sentences and paragraphs. Bullet points make writing easier to read, as can subheads (when they make sense to use).
Review and revise your writing. Good writing needs room to breathe. Employees should be encouraged to sit on their writing for at least a few hours (if not a full day) before reviewing it. That fresh perspective can be powerful. This is a great time to reach out to a colleague for a second set of eyes.

Good writing requires good tools (and feedback)

Earlier we said good writing doesn’t mean you need perfect grammar. But excessively poor grammar and errors can be problematic.

Poor writing forces the reader to invest additional time and energy into deciphering the intended message. They’ll likely have to follow up with clarifying questions, which can lead to frustration and delays.

Writing clearly, on the other hand, demonstrates that the writer respects the reader’s time. This can lead to better working relationships and more fruitful project outcomes.

Fortunately, there are simple steps anyone can take to improve their writing without becoming overwhelmed. Here are a few of the tools and resources we use at Slab to improve our writing:

Grammarly — Checks for spelling and mechanical issues. Our resident content writer has the premium version, but most folks can get by with the free version.
Hemingway App — Similar to Grammarly (and also free). While Grammarly is the king of grammar and spelling, the Hemingway App shines as a tool to make writing concise yet clear.
Merriam-Webster — Your go-to resource for defining words and finding synonyms.
Strunk and White’s Element of Style — The gold standard of writing mechanics. This book is easy to read through (it’s very short!) and makes a great desk reference. It’s worth giving every new employee.

While these resources help, feedback can be even more valuable. Here at Slab, feedback comes in two forms: peer reviews and self-reflection.

Peer reviews

We have two writers on our team who regularly review their colleagues’ most important written communication (like job postings or emails to investors).

Our writers don’t just revise the copy and move on. They provide specific feedback so that their teammates can apply those learnings in the future.

You may not have writers on your team, or your writers may not have the bandwidth for this work. In that case, hire a freelancer to review your most critical documents.

Finding good and reliable freelance writers isn’t easy. To save you some time, we recommend you check out The Writer Finder or Copyblogger Certified Writers. Both of these sites work only with writers with proven talent and credentials.

Writer Access is also worth checking out. You can find writers based on your ideal budget.

Self-reflection

We touched upon reflection earlier on. Self-reflection has the power to improve well-being and performance. In a study published by researchers from Harvard, UNC, and Bocconi University, employees who spent 15 minutes reflecting on their day performed 23% better after 10 days than those who did not reflect.

“Follow effective action with quiet reflection. From the quiet reflection, will come even more effective action.” Peter Drucker

Chances are not many people on your team reflect on their writing. It’s not easy to schedule that into a busy day.

Here are a few ways you can establish a writing process that includes self-reflection:

Be flexible. Give your team the freedom to reflect in a way that suits them. Some people prefer to write in a journal. Others prefer to collaborate with a colleague.
Schedule time. Designate a specific time for your team to review their recent writings.
Start small. Self-reflection can be uncomfortable. Don’t force your team to spend an hour every week picking apart their words. Start small, with 20-minute sessions every two weeks, for example.

Mindful writing leads to better communication

With more teams hiring remote workers and using chat tools (like Slack), project management tools (like Asana), and email, there’s no escaping the value of good writing.

Give your team the tools they need to be better writers. And demonstrate to them how much you value clear communication. The result will likely be higher morale, improved collaboration, and an increase in productivity.

Crushing Your Fear Of Failure: Using Stoicism To Thrive At Your Startup

Ben Bashaw — Wed, 24 Apr 2019 20:00:00 GMT

The ancient philosophy of stoicism, originally used by ancient leaders to help endure the hardships and anxieties of daily life, is experiencing a resurgence among today's tech leaders and startup employees.

Working in a startup is inherently risky. When you are building new products, testing new ideas, and operating in an environment where a mistake could mean the end of your company or job, the “what ifs” can easily overwhelm you. However, a great paradox is that you need the courage to take risks and need to learn to conquer your fear of failure in order to succeed in a startup or as a startup leader.

From CEOs to investors, people across tech and the startup ecosystem have turned towards stoicism to find comfort in the face of fear and actually thrive in spite of it.

Face Your Worst Fears

There are many ways to negotiate with and mitigate the effects of fear, but stoicism offers one of the clearest methods for dealing with your fear by pushing through what you fear most — an essential heuristic for a startup where postponing decisions out of fear of failure is even more dangerous than making a risky decision.

The ancient stoics constantly reminded themselves and their followers that we are all mortal and only have a short time to make an impact on the world. Confronting the fear of death head-on and accepting, rather than denying, it allowed the Stoics to be more productive and courageous in their daily lives.

“Let us prepare our minds as if we’d come to the very end of life. Let us postpone nothing. Let us balance life’s books each day,” Seneca wrote. “The one who puts the finishing touches on their life each day is never short of time.”

By confronting the fear of death, Seneca proposes, you will be more productive and never run out of time to accomplish your goals and tasks. For people who fail to confront their fears, Seneca writes that “life is very short and anxious.” You can't accomplish your goals if you continuously put off action out of fear and anxiety. The first step to reaching the goals you set is confronting your fears.

Ancient philosophers aren't the only ones who have found the value in contemplating death and facing their worst fears. CEOs such as Steve Jobs and Jeff Bezos also take a stoic approach to putting their fears in the perspective of either personal or company mortality.

In 2005, Steve Jobs gave a commencement speech at Stanford in which he discussed how reflecting on his own mortality allowed him to conquer his fears of failure. “Remembering that I’ll be dead soon is the most important tool I’ve ever encountered to help me make the big choices in life” Jobs said. “Because almost everything — all external expectations, all pride, all fear of embarrassment or failure — these things just fall away in the face of death, leaving only what is truly important.”

Steve Jobs giving his famous Stanford Commencement address in 2005

As the founder and CEO of Apple, Jobs had to take on considerable risk and build wildly ambitious products in order to succeed. To overcome his fears that these products and initiatives would fail, Jobs relied on the old stoic practice of contemplating his mortality to help put those fears in perspective. In the context of impending death, the outcomes of mistakes and failures at Apple didn't seem as serious or scary. As a result, Jobs was able to focus on executing projects without being distracted or hindered by fear of failure.

During an all-hands meeting at Amazon, Jeff Bezos once calmly stated that “Amazon is not too big to fail… In fact, I predict one day Amazon will fail. Amazon will go bankrupt. If you look at large companies, their lifespans tend to be 30-plus years, not a hundred-plus years.”

Bezos went on to explain, “If we start to focus on ourselves, instead of focusing on our customers, that will be the beginning of the end… We have to try and delay that day for as long as possible.” The thought of Amazon going bankrupt wasn't meant to send employees into a panic. Instead, Bezos used Amazon's ultimate end as a way to motivate his employees to look past all their other fears and anxieties about competitors and focus only on what matters most — keeping a customer-first mentality.

If you can come to grips with the existential risks you face at work, whether that's your company going out of business or your job being eliminated, the other risks that stand in your way to success will seem easily surmountable by comparison.

Preparing For Failure

Like startup founders who knew that their companies could find themselves in a crisis at any moment, the Stoics believed that their wealth and stature could be stripped away from them at any time. However, the Stoics believed that a wise person would always be prepared for such drastic swings of misfortune because they'd visualize the events that could lead to what they fear and prepare themselves in advance.

The Stoics used times of peace and tranquility to prepare themselves for failure. “It is in times of security that the spirit should be preparing itself to deal with difficult times” Seneca wrote. “while fortune is bestowing favors on it then is the time for it to be strengthened against her rebuffs.”

For people like Seneca this oftentimes meant preparing for the event of loosing all wealth and becoming poor. Even though he was one of the richest men in all of Rome, Seneca would walk around in worn-out clothes, eat simple meals, and spend very little money. By visualizing and practicing poverty, Seneca was able to gain confidence in his ability to withstand the event he feared.

The act of visualizing and preparing for failure is something that people across the tech industry have taken up as a part of their own daily lives and as a part of their companies' standard practices. Tim Ferris, an entrepreneur and angel investor, urges people to document their fears as meticulously as they document their goals.

When Tim was starting his first business, he had a tough time delegating responsibility. He was overwhelmed by stress and anxiety about taking any time off and the need to control projects; as a result, he worked around the clock without ever taking a day off.

Drawing strength from Seneca and the Stoics, who he knew found value in visualizing their fears, he began to document all the “what ifs” that ran through his head every day, followed by all the things he could do to prevent those “what ifs” from happening, and all the things he could do to recover from those events if they did happen.

Taking a vacation and letting his team take on more responsibility in his absence was something that Tim could not have done without this practice of documenting his fears. By writing out his fears and thinking through ways to address all the things he feared about taking a vacation, he made himself comfortable enough with the idea to go ahead and do it.

Many business leaders use the same practice to prepare for failed projects and disaster events. One technique many companies use is something called a premortem meeting. Before a product or project even launches, teams will imagine that weeks down the road the project turns out to be a huge failure. From there, the team lists all the events that could bring about failure, what they could do to better prepare for that failure, and how to recover.

In one study of various fortune 500 companies who use premortem meetings, researchers found that the structured format of these meetings coaxes out worries and anxieties that had previously gone unmentioned. A lot of these worries, such as not having enough time to build a well functioning feature before the launch deadline ended up being incredibly important and also controllable. Moving back a deadline or accounting for review and testing time is a worry that is better when addressed at the beginning, rather than the end of a project.

In the competitive and fast-paced world of tech and startups, there is always the ever-present threat of new companies and new technologies putting your own out of business. Rather than letting these fears go unaddressed though, entrepreneurs employ the stoic technique of visualizing failure, and in the process become better prepared for it and less likely to encounter it.

Finding Value In Failure

Regardless of how well you prepare for failure, setbacks and roadblocks to success are inevitable. Especially in a startup, where best practices are still being uncovered and unforeseen challenges arise on a regular basis, failure is an experience you need to become comfortable with.

Of all the small businesses started in the U.S. in 2014, only about half were still in business by 2018. Among all startups that survive, only about 1% become “unicorn” companies. The odds are stacked against founders, and avoiding failure at some point is largely unavoidable.

When a business is starting out, they need to figure out how to build a product that successfully addresses a need their user base has, they need to compete with existing players, they need to build a team, and they need to secure investments to grow. Along this journey, there is a lot of room for error and usually the only way to get through it is to learn and adapt on the fly.

No one builds a business without encountering setbacks and failure. There is a learning curve as entrepreneurs search for the right product-market fit, the right marketing and sales strategies, and learn the ins and outs of their industry. Failure is a key part of that journey. Stoicism offers today's startup leaders a way to reframe how they relate to failure so that they can find value in it rather than dread it.

According to the Stoics, the anticipation of our fears is more harmful than the actual outcomes of the events we fear. Seneca, summing this viewpoint up nicely, wrote, “We are more often frightened than hurt; and we suffer more in imagination than in reality.” Separating your perceptions and emotions from the reality of a situation forms a core principal of stoicism.

The Stoics believed that you could control your reaction to a problem by simply repositioning your perception of that problem. Marcus Aurelius went so far as to say, “Choose not to be harmed — and you won’t feel harmed. Don’t feel harmed — and you haven’t been.” Through this lens, you could even view failure as something to be embraced rather than feared.

Entrepreneurs take a similar approach to talking about failure. It's commonplace now for business owners and managers to talk about how much they value failure. Muhtar Kent, the former CEO of Coca-Cola, said in a commencement speech that companies should celebrate their failures and that he regrets not doing so during his time at Coca-Cola.

“If I would do anything different in my 36 years of career, then it would be to create an atmosphere which allows mistakes, as you learn so much from mistakes” Kent wrote. “We are not bold enough to take enough risks, and risk is critical for success. We don't make enough mistakes.”

Jeff Bezos is another CEO who famously values failure. In his 2015 letter to Amazon shareholders, Bezos almost brags about the failures Amazon has had writing that “One area where I think we are especially distinctive is failure. I believe we are the best place in the world to fail (we have plenty of practice!), and failure and invention are inseparable twins”

The list of CEOs who talk about failure in a positive light could go on and on. The more important thing to note, however, is how positive framing of failure has helped each individual and each company stay resilient and motivated in the face of repeated failure.

Amazon, by Bezos's own admission, has experienced billions of dollars worth of failures. Bezos could have perceived these failures as serious impediments to success and as indicators that the company didn't have the potential to make the impact he had envisioned. Had Bezos taken this approach, he likely would have given up on projects like Amazon Marketplace, which only came about after two previous iterations — Auctions and zShops — failed.

Instead, Bezos chose to perceive his own failures and his company's failures as learning opportunities and necessary steps towards innovation. By reframing how he thinks about failure, Bezos makes every seemingly large setback an event to be embraced rather than ashamed or afraid of.

Within every failure a startup makes, there is a silver lining that can be used to make that business stronger. Something that separates the businesses that fail from the businesses that succeed is their leaders and their employees' ability to reframe how they think about failure. Those who can, like the Stoics, consciously control their reactions to problems by tweaking their perceptions will be able to find a silver lining. Those who can't will lose confidence and lose the courage they need to take necessary risks.

A Philosophy Tailor-Made For Startups

The hard facts of working at a startup or leading a company of your own is that failure is an inevitable experience. Not just small setbacks and mistakes, but big failures that threaten the viability of your company and your job security.

Within this setting you can either:

Ignore your fears and likely miss indicating factors that you should pivot your plans and adjust to threats accordingly.
Let your fear of failure paralyze you from taking action, and live in a constant state of anxiety
Take a note from the stoics and learn to overcome your fear of failure

Stored within the ancient philosophy of stoicism, are helpful tips and practices any entrepreneur can take advantage of to thrive in a startup environment. Facing your worst fears puts failure in a manageable perspective, visualizing your fear better prepares you for the event of failure, and changing your perception of failure can help you learn and become stronger because of it.

We Analyzed How 38 CEOs Send Emails—Here's What We Found

Ben Bashaw — Tue, 19 Mar 2019 20:00:00 GMT

With the decentralization of the startup economy and the increasing prevalence of remote and distributed teams, clear, asynchronous communication has never been a more important skill for executives to master.

This is evident with the rise of team wikis and tools like Slack. Still, email—the oldest and most durable of the digital communications tools we have—has lost none of its importance.

With potential partners, the way you email (or don't) can help you close or lose deals. With your team, it sets the tone. And with your investors, it can either inspire confidence or questions.

Finding a Method to Maximize Productivity

One of the traits that most differentiates great CEOs is their decisiveness—and their ability to recognize when to act fast.

“You can always course-correct if things don’t work out,” the CEO of Alibaba, Daniel Zhang, wrote. “The real fear is in the state of paralysis that results when you can’t make a decision at all.”

What Amazon’s Jeff Bezos calls “high-velocity decision-making” relies upon the realization that, in most cases, even a bad decision is better than making no decision at all.

Great CEOs apply this mentality to their email inboxes with ruthless efficiency, responding to emails at lightning speed, avoiding over-communication, and setting clear expectations for the people they interact with.

1. CEOs Reply to Emails Immediately

A lot of CEOs respond to their emails as soon as they see them. As former Google executive Eric Schmidt wrote, “there are people who can be relied upon to respond promptly to emails, and those who can't. Strive to be one of the former. Most of the best—and busiest—people we know act quickly on their emails, not just for a select few senders, but to everyone.” Even when Schmidt doesn't have a clear response or answer to an email, he makes sure to send a confirmation of receipt saying “got it,” so he can move on to the next thing without keeping the sender wondering or waiting.

A promise from Warren Buffett's 1982 shareholder letter.

Time kills deals, so the CEO who is quick to see a good offer is usually quick to snatch it up. As Warren Buffett knew, establishing a reputation for emailing back quickly sends a message to co-workers and potential customers that you're always at work, eager to work with others, and don't shy away from unpleasant but necessary challenges.

2. They Send Fewer Emails to Receive Fewer Emails

While a lot of CEOs are known to respond to emails quickly, they are not often the most active emailers in their company. CEOs need to be accessible but cannot be constantly weighed down by email.

Karl Iagnemma, the CEO of nuTonomy, sends no more than 25 emails a day because spending any more time than that on email means he is taking time away from more important tasks.

Jeff Weiner, the CEO of LinkedIn, has a similar practice. His began after two high-profile communicators he worked with at a previous company left, and he suddenly realized that his inbox volume had dropped by 30%.

It wasn't simply their emails that were creating so much activity for Weiner to respond to—it was the cascading effect of replies and responses that each email created.

While they worked hard and communicated well, their flurries of activity created exponential growth in the amount of messages that Weiner and his other teammates needed to respond to—collateral damage caused by the structure of email itself.

3. They Are Clear With Expectations

A lot of CEOs also cut down on the amount of time they need to spend processing and interpreting the emails they receive by being upfront with the people they work with about what they expect in an email.

Katia Beauchamp, CEO of Birchbox, is a perfect example of this. To help her prioritize her inbox and quickly process which emails are most urgent vs. less urgent, she insists that her employees include a specific time they need a response by. Instead of wasting time and energy trying to infer from the content of the emails which ones are most urgent and forming priorities from there, she front-loads that work onto the sender.

Mark Cuban makes his inbox more predictable by instructing the people he works with on how frequently they should email him and what they should email him about. In a blog post about working with Cuban after Shark Tank, the founders of Guardian Kids Bikes explain that Cuban expects a weekly email letting him know what advice or help they need and where they are struggling in a short, concise manner.

As the co-founder Brian Riley writes: “We only send him questions that we are really struggling with, like a strategy question of going this way or that way. We keep our emails as concise as we can, without going into the weeds too much”...“If he can get email updates from us every week and have a pattern of our condition and what’s going on, it enables him to give really great advice.” Consistent and predictable content allows Cuban to minimize the time spent on understanding the context or purpose of the emails he receives.

Using the Right Language to Send the Right Message

The effectiveness of an email largely comes down to how it is interpreted. As a result, CEOs are very deliberate about using the right words—or lack thereof—to create the desired effect. Interestingly, they often use common techniques in wording and phrasing.

4. They Say 'We' Instead of 'I'

In an interview published in the New York Times, Jonathan M. Tisch, co-chairman of the Loews Corporation, cited one of the most important lessons he has learned in his years of doing business to be “never start a paragraph with the word 'I,' because that immediately sends a message that you are more important than the person that you’re communicating with.”

In looking through emails from CEOs to their employees, it seems that most leaders agree on the power of using collective pronouns like “we” and “us” and “our.”

In a 184-word email Philippe von Borries, the co-CEO of Refinery29, sent to his employees after Donald Trump was elected president, the word “We” appeared eight times and began three out of the five paragraphs. In a pivotal moment in the email, von Borries writes, “This is a moment for us to rally together, to be even more ambitious in the impact we can have, to produce our best work. We are a company in which we can live our passion and move our collective mission forward every day.”

The use of the words “we” and “us” in this example helps employees see themselves as part of a supportive community rather than an individual within a company. If you look through emails and letters from CEOs, you will see a lot of “Our mission,” “Our code of conduct,” and “We are making progress” phrases because these phrases spread ownership of goals and achievements to everyone, making them feel like a part of something important.

In 2015, Satya Nadella sent an email to Microsoft employees discussing the company's strategic plan for the coming years. To help his employees feel more invested in this plan, he uses “we” and “our” to make the wider company feel included. “I believe that we can do magical things when we come together with a shared mission,” he writes. “Our mission is to empower every person and every organization on the planet to achieve more.”

5. CEOs Use Brief, Standardized Responses

CEOs are notorious for sending brief, standardized responses to emails and know exactly how to get their point across as quickly and succinctly as possible. Jeff Bezos and Elon Musk are the most extreme, and maybe the best, examples of this.

An Amazon customer who emailed Jeff Bezos directly receives a response from a member of the Tech Support Executive Customer Relations team “on behalf” of Bezos himself.

Whenever Jeff Bezos sees a concerning email from a customer, he forwards the email to the person in charge of the department at fault with nothing added to the email but a question mark. Bezos explained further in an interview that the question mark is “shorthand for, 'can you look into this?' 'why is this happening?'” Elon Musk uses almost the same tactic except, instead of a question mark, he uses the three-letter acronym WTF. Both approaches reportedly send the recipient into an all-out scramble to right the problem and report back.

6. They Put an Emphasis on Empathy

While the examples above seem a bit curt, CEOs also know how to make their emails more empathetic, and they often use language to communicate empathy and understanding. This is a much-needed skill for CEOs, especially when they need to address something particularly unpleasant that happened in the company.

In the spring of 2018, a high-ranking employee at Netflix was fired for using offensive language on more than one occasion. To acknowledge the situation, Reed Hastings, the CEO, wrote an email to employees reassuring them that the company's values do not line up with that type of behavior, and it will not be tolerated.

After explaining the situation, Hastings writes, “As I reflect on this, at this first incident, I should have done more to use it as a learning moment for everyone at Netflix about how painful and ugly that word is, and that it should not be used.”

After accepting a piece of the blame himself and acknowledging the harm it caused, he also goes on to empathize with the people who worked closely with the fired employee: “Many of us have worked closely with Jonathan for a long time, and have mixed emotions.” Hastings then ends the email with another sentence reassuring and supporting the employees who were most affected by the fired employee's actions by saying, “Unfortunately, his lack of judgment in this area was too big for him to remain. We care deeply about our employees feeling safe and supported at Netflix.”

By writing with an extra emphasis on communicating empathy, Hastings prevented the situation from snowballing into widespread discomfort and distrust throughout the company.

Content Specific to the Function of a CEO

In addition to commonalities in email management methods and language, CEO emails often touch on the same themes and messages. As the visionary leaders of their companies, CEOs are responsible for creating a narrative around the company's mission and values, as well as responses to any threats to those missions and values. As a result, the content of many of their emails tends to skew towards these larger concepts and to confronting threats to these ideas.

7. They Start With the Bad News First

When a direct threat to a company's well-being presents itself, there is no use in avoiding it or tiptoeing around it. CEOs instead prefer to confront problems head-on.

In 2015, the New York Times published an article that painted a very hostile picture of the work culture at Amazon. Knowing that this was a widely read and high-profile piece with the potential to turn the perception of Amazon, both externally and internally, for the worse, Bezos wrote an email to employees responding to the threat.

Instead of tiptoeing around the purpose of the email, Bezos starts off by providing a link to the article and encouraging his employees to read it. He then goes on to write, “Here’s why I’m writing you. The NYT article prominently features anecdotes describing shockingly callous management practices, including people being treated without empathy while enduring family tragedies and serious health problems.”

After getting the bad news out of the way, Bezos uses the rest of the letter to make his case that the article is more fiction than fact and that he is committed to creating a healthy and productive workplace culture. The very act of confronting the bad news head-on showed employees that the threat could not be all that credible as the CEO had no hesitation in bringing it up and talking about it.

8. They Always Talk About Customers

A common theme in CEO emails is an insistence on prioritizing customers above all else.

Take Satya Nadella, CEO of Microsoft. In a 2018 email announcing two new engineering teams and the reasons behind creating the new teams, Nadella writes, “Having a deep sense of customers’ unmet and unarticulated needs must drive our innovation. We can’t let any organizational boundaries get in the way of innovation for our customers.”

In an email to Deutsche Bank employees announcing himself as the new CEO, Christian Sewing also focused the content of his email on customer needs when he wrote, “We should focus less on ourselves and more on our clients. They are our reason to be. And our approach should be to offer them convincing solutions and not just products. If we add value for our clients, we deserve our share of it – but only then.”

CEOs have more power and influence over creating a narrative around the company's values and larger-picture priorities than anyone else in the company, so it is common to see them focus on ideas like customer centricity in their emails.

9. They Bring Crisis & Failure Back to the Mission

Most businesses experience setbacks in their growth and significant failures, which force leadership to make tough decisions. This often comes to a head with an announcement about large-scale layoffs or cutbacks. It's an announcement that employees dread receiving and CEOs dread giving. However, many CEOs also use such announcements as an opportunity to bind the team closer together by putting the layoffs and cutbacks in the framework of a larger picture of success.

In 2016, Brian Krzanich, the CEO of Intel, announced they would need to lay off 12,000 employees in the coming months. After announcing the news and thanking all the employees who will be laid off for the work they have done for the company, Krzanich goes on to write, “Today’s announcement is about accelerating our growth strategy. And it’s about driving long-term change to further establish Intel as the leader for the smart, connected world.”

By bringing the focus back to how the decision to cut 12,000 jobs fits into the larger mission, the CEO frames a negative event as a step forward.

Leading Through Email

The “CEO style” of emailing has become a well-known and widely adopted trope: terse declarations, short responses, and often cryptic messages that leave the recipient struggling to interpret the point.

In reality, the ways that CEOs email are diverse and varied, though there are similarities across the board: generally quick response time and high decisiveness when communicating with the outside world, systematic efficiency when communicating inside the team, and a customer-first mentality when writing (implicitly or explicitly) for the wider public.

Even as Slack and other similar tools rise to earn a greater share of the intracompany communications market, email (with its universality and familiarity) is likely to remain—at least for CEOs and those they communicate with—the most important communications medium out there.

How Andy Grove's Writing Formed The Basis For Modern-Day Startup Culture

Ben Bashaw — Wed, 27 Feb 2019 20:00:00 GMT

When Andy Grove, former CEO and cofounder of Intel, passed away in 2016, the outpouring of tributes to his memory from the tech world's leading CEOs, such as Tim Cook and Bill Gates, showed just how appreciated his teachings were.

The further you look into the leadership tactics of some of the most successful tech companies of our generation, the more apparent Grove's influence becomes.

In his books High Output Management and Only the Paranoid Survive, Grove laid out the elements of the management strategies that propelled Intel from a tiny startup to the most successful tech company of its day and then led the company through a drastic realignment in the 1980s.

The ideas Grove made accessible to the world through his writing were readily adopted by leaders for years to come to come. With his ideas, these leaders built cultures within their own companies that enabled them to thrive in the fast paced world of tech.

Paranoia As A Motivator

One of the most enduring pillars of Grove's legacy is his idea that paranoia can be a valuable tool for an executive. Prior to Grove, no one touted paranoia as a trait worth generating in your business, but that all changed when he published Only The Paranoid Survive.

Since then, leaders such as Bill Gates, Michael Bloomberg, and Jeff Bezos have made their particular blend of paranoia central to their company cultures and used it to drive their companies to success.

For Grove, paranoia was a central feature of his life from childhood on. Having survived Nazi occupation of Hungary, followed shortly after by Soviet occupation, Grove's survival depended on expecting and preparing for the worst at all times. Being born into a Jewish family, Grove had to be in survival mode constantly. That meant hiding out with a Christian family and adopting a Christian name. Grove's mother reminded him that forgetting to use his Christian name could be disastrous.

Intel employees, similarly, recount that Andy viewed competition as Soviet tanks coming down the road. His famous slogan, “Only the paranoid survive,” became a common mantra within the company, and it became so central to Grove's management philosophy that he wrote a book titled Only The Paranoid Survive. On the first page, Grove explains the basic reason why paranoia is so important in business: because someone else will always want to take what you have, whether that's market share or capital.

“Business success contains the seeds of its own destruction,” he writes, “The more successful you are, the more people want a chunk of your business and then another chunk and then another until there is nothing.”

One of the moments at Intel where Grove's thinking about paranoia came in use was in the 1980's when Japanese manufacturers started cutting into Intel's profits by making their products cheaper and cheaper. Grove foresaw a future where Intel would eventually be drowned out by these manufacturers and, instead of waiting for that to become a reality, decided to change course and abandon the very product that had built Intel into a global behemoth. Within the company however, resistance to change was heavy.

At Intel, the belief that the company lived and breathed memory had ascended to the point of “religious dogma.” But their customers had already seen how short-lived their dominance of the memory space would be in the future:

“In fact, when we informed them of the decision [to switch to microprocessors],” Grove wrote, “some of them reacted with the comment, 'It sure took you a long time.' People who have no emotional stake in a decision can see what needs to be done sooner.”

For Grove, constant paranoia about your business's odds of survival given the constant onslaught of competitors enabled by the free market was essential to “seeing what needed to be done.”

Since then, CEO's have openly and readily espoused Groves ideas on paranoia in business. Although not mentioning Grove directly, Michael Bloomberg closely mirrored Groves thoughts in his book Bloomberg by Bloomberg when he wrote, “Every day at Bloomberg, we face challenges that jeopardize our comfortable life. We constantly have to fight competitors trying to take food out of our children's mouths. And then there are start-ups that want to destroy everything we've built.”

In 1995, Bill Gates wrote a paranoia-inflected memo of his own to all Microsoft employees. In the document now known as the “Internet Tidal Wave” memo, Gates reflects on how disruptive the internet will be and how easy it could be for their competitors to take advantage of its power to make Microsoft insignificant.

One competitor Gates calls out in particular, Netscape, was, at the time, only at ~$5 million in revenue vs. Microsoft's $8 billion. Even though the the company was only a small fraction the size of Microsoft, Gates imagined a future where they could overtake and even commoditize Microsoft. No competitor was too small to be considered a threat. If they had a good product in the internet space, they had potential to cut into Microsofts business. With that in mind, Gates then went on to outline a plan of attack to this threat, saying, “I want every product plan to try and go overboard on Internet features”.

In the following years, Gates waged a famous internet-browser war, in which he drowned out his competition and made Microsoft's product, Internet Explorer, the king of internet browsing. Although Microsoft's strategy for winning this war ultimately landed Gates in trouble with the FTC, for the time being, the commitment to responding to every challenger as a threat propelled Microsoft to dominance.

Comments from Jeff Bezos suggest that Amazon also grew on paranoia to a certain degree. In a 1999 shareholder letter, Bezos writes that he warns his employees to wake up terrified of customers because they could, at any moment, switch their loyalties to someone with a better service.

Although it sounds a bit extreme and fatalistic, this paranoia is, by all accounts, providing the right motivation to the Amazon team. Today, Amazon is synonymous with customer centricity and is consistently ranked as the top of customer-satisfaction reports.

Confrontational Management

A somewhat controversial element of Grove's management style was his proclivity for confrontation. Grove believed in the power of debate and conflict to refine and harden ideas into their most effective form. Every idea and proposal was meticulously picked apart and debated, with little regard for feelings, and Grove made sure to deter any laziness or low standard work by berating the offender. This management style is what landed Grove the title of “world's toughest boss” in 1984, but it's also what allowed him to get the highest standard of work out of his employees.

Since then, elite CEO's such as Steve Jobs, Jeff Bezos, and Elon Musk have followed suit: pressing tough standards on their employees and, while sometimes at the cost of looking like jerks, ultimately producing the best possible products because of it.

Before Grove started publishing his books, his confrontational style was something of an urban legend, leaking out through stories of his severity from Intel employees. One Intel employee described meetings with Grove like “going to the dentist and not getting Novocaine. If you went into a meeting, you’d better have your data; you’d better have your opinion; and if you can’t defend your opinion, you have no right to be there.” Other stories that leaked out to the world contained vignettes of the CEO yelling and slamming his fists on the table.

Grove confirmed these stories as fact in Only The Paranoid Survive when he discussed the importance of debates in making managers decisions easier. “Debates are like the process through which a photographer sharpens the contrast when developing a print,” Grove writes. “The clearer the images that result permit management to make a more informed—and more likely correct—call.”

When asked about the potentially hostile work environment this commitment to debate could create, Grove said in an interview with the Chicago Tribune, “We encourage our people to deal with problems without flinching. At its best, the method means that people deal with each other very bluntly.”

This style of pushing employees and inciting debates made Grove a tough person to work for, but many employees acknowledge that he was demanding but also fair. He held himself to the same standards as everyone else and even sat in a cubicle like everyone else, indicating that his style really was about getting results rather than about flexing his CEO power privilege.

In the past decade, Steve Jobs was one of the more obvious examples of this confrontational management style. Jobs was known to fire employees in public meetings and resort to angry tirades to get his point across. Surely this sometimes bordered on irrational or even crossed the line and became too personal, but often it also led to the incredible innovation Apple became known for.

The first iteration of the iPod, for example, was too clunky for Jobs's taste. He told his engineers to make it smaller and slim it down. When they told him that would be impossible, he took the prototype they had been working on for months and dropped it into a fish tank. When bubbles came out, he pointed and said, “Those are air bubbles. That means there's space in there. Make it smaller.”

In the end, they came up with smaller and slimmer prototypes until, eventually, the first iPod, which became a staple Apple product and sold over 300 million units by 2011.

Steve Jobs might have been one of the more extreme cases of confrontational CEO's, but he was far from being alone in the tech world.

When presented with work that doesn't live up to his high standards, Jeff Bezos is known to go on the attack, reportedly rebuking other executives with comments like the following:

“Are you lazy or just incompetent?”
“We need to apply some human intelligence to this problem.”
“This document was clearly written by the B team. Can someone get me the A team document? I don't want to waste my time with the B team document.”

“Amazon’s culture is notoriously confrontational,” writes Brad Stone, author of the Bezos-profiling The Everything Store, “and it begins with Bezos, who believes that truth shakes out when ideas and perspectives are banged against each other.”

One of the core principles at Amazon—as enshrined in Amazon's 14 leadership principles—is to “have backbone; disagree and commit.”

According to Stone, Bezos despises the idea that coworkers should always try to get along and maintain strong social bonds. “He’d rather his minions battle it out backed by numbers and passion,” Stone writes.

The best way to avoid an unpleasant confrontation at Amazon is to make your proposals and ideas as thoroughly thought-out and airtight as possible so you can defend them against criticism. Without the threat of ridicule, it's not likely that the CEO of Amazon Web Services, Andy Jassy, would have written 31 drafts of his idea proposal for Amazon Web Services before presenting it to Bezos. While you can argue with his methods, it's hard to argue with the success of AWS today, which generated over $25B in revenue in 2018 alone.

“To the amazement and irritation of employees,” Stone adds, “Bezos’s criticisms are almost always on target.”

Embracing Risk And Change

Entrepreneurs today pride themselves on building “nimble” companies and taking risks to carry out successful “pivots.” Andy Grove was one of the original proponents of this mind-set, and his writing is one of the main reasons it has become such a commonplace philosophy among startups. In his book Only The Paranoid Survive, Grove laid out the logical framework for embracing risk and how doing so will help you adapt and change your business. This framework gained credibility through the years as CEOs like Elon Musk, Jeff Bezos, and Bill Gates have embraced it to great effect.

The biggest pivot in Intel's history was their exit from the memory-chip industry and entry into microprocessors. In hindsight, this decision to switch to microprocessors was the obvious choice. At the time, however, the decision jeopardized Intel's entire foundation and made a lot of other executives and board members uneasy. The thought process behind Grove's decision became a core lesson of Only the Paranoid Survive.

“I learned how small and helpless you feel when facing a force that’s '10X' larger than what you are accustomed to,” Grove wrote, “I experienced the confusion that engulfs you when something fundamental changes in the business, and I felt the frustration that comes when the things that worked for you in the past no longer do any good. …And I experienced the exhilaration that comes from a set-jawed commitment to a new direction, unsure as that may be.”

Making these risky decisions became a point of pride for Grove, and something he urged others to do as well. “Companies don't die because they are wrong,” Grove writes. “Most die because they don't commit themselves. They fritter away their valuable resources while attempting to make a decision. The greatest danger is in standing still.”

All companies need to change and evolve, and every decision about how to change comes with a degree of risk. By extension, an essential part of leadership, according to Grove, is embracing the risk of change and making these decisions quickly and confidently.

Since Grove put this theory into writing, many CEO's have followed suit and committed themselves to making risky decisions to move their companies into unchartered territories. When you look at leaders like Elon Musk, Jeff Bezos, and Bill Gates, you will notice that they never focus on just one product. They are always expanding the scope of their businesses and taking risks on new products.

In his first shareholder letter, Jeff Bezos outlined “bold rather than timid investment decisions” as a central principle of Amazon's business plan, and he also established his commitment to resisting complacency and embracing change with his “Day 1” mentality. Staying in “Day 1,” Bezos explained further in his 2016 shareholder letter, meant keeping “customer obsession, a skeptical view of proxies, the eager adoption of external trends, and high-velocity decision making”. The resulting company culture was one in which risk-taking was acceptable in pursuit of innovation and change.

Bill Gates was also outspoken about the importance of risk and change in business. He famously noted, “To win big, sometimes you need to take big risks.” For Microsoft, that meant expanding their product offerings and their functionality constantly. In an interview with BBC, Gates cited this constant adaptation as a competitive advantage, noting that the companies Microsoft beat out were “one-product wonders” and that “they did not think about tools or efficiency. They would therefore do one product, but would not renew it to get it to the next generation.”

When it comes to embracing risk and change, however, Elon Musk is an unparalleled example of what Grove preached. After Musk's first major success in creating PayPal, he easily could have hedged his bets and lived off of that money for the remainder of his career. Instead, he put his neck on the line again and again to start companies as ambitious and risky as SpaceX and Tesla.

In 2008, Musk invested every cent he had made from PayPal into Tesla and SpaceX, both of which were on the brink of failure. For the next few months, Musk lived off loans from his friends, and his entire personal fortune rested on the success of two companies that were both attempting to do things that no other company had ever done. This decision fit into Musks's ethos, however, as he is known to say, “It's OK to have your eggs in one basket as long as you control what happens to that basket.”

Musk's gamble paid off as both companies were able to stay afloat and grow into established, successful companies in their respective industries. A further indication of the CEO's commitment to risk is his insistence on always expanding his companies into new areas.

Even as far back as 2006 when Tesla was still struggling to succeed in the automotive industry, Musk was openly setting his sights on moving into more industries and expanding the company's products. In a letter to the public announcing his “Master Plan,” Musk wrote that Tesla would be more than just cars. Tesla's purpose was “to help expedite the move from a mine-and-burn hydrocarbon economy towards a solar electric economy.” This meant that in addition to high-end sports cars, Tesla would eventually shift focus to affordable family cars and even expand outside the world of automobiles to build solar-powered home batteries.

By 2016, Tesla had built itself a strong foothold in the automotive industry, so Musk followed through with another piece of his Master Plan and acquired SolarCity for $2.8 billion so that they could begin building and selling solar home batteries. This move threw Tesla once more into a struggle to prove a largely untested concept and tied the company's success to the success or failure of a new investment.

To an outside observer watching Tesla succeed in making and selling electric cars, it might seem like an unnecessary risk to invest billions of dollars into a completely new product line when the company had only just started to succeed with its electric car manufacturing. But to Musk and other CEO's influenced by Grove, embracing the risks of realigning and transforming their businesses is absolutely essential and seen as a much better alternative than resting on past success.

A Lasting Legacy Starts With Great Writing

Andy Grove likely wasn't the first CEO to ever see the value of being a bit paranoid, of getting the most out of employees through confrontation, and of embracing risk and change. His value to current startup culture and current tech companies isn't necessarily that he invented these ideas; it's that he made them easily accessible to anyone who wanted to learn.

At the time Andy Grove was writing his books, he had built one of the most successful tech companies ever and had proved himself to be a smart and capable leader. Rather than holding onto the secrets of his success, though, he diverted from a lot of other CEOs of the past by putting all of his knowledge into writing and making it accessible to the wider world.

You didn't need to be a close confidant of Grove or work under him to learn from him, and you didn't need an MBA to understand his theories. Grove's ideas were explained clearly and simply enough for anyone to grasp, and as a result they spread like wildfire and worked their way into the cultures of upstart tech companies for years to come.

How Jeff Bezos Turned Narrative into Amazon's Competitive Advantage

Ben Bashaw — Tue, 05 Feb 2019 20:00:00 GMT

There's probably no technology company that values the written word and produces written output quite as much as Amazon.

At Amazon, meetings to present ideas start not with PowerPoint slides but with narratively structured memos. Quality writing in the workplace isn’t a luxury at Amazon — it’s a cultural necessity.

Years have proverbial themes—like the Year of Getting Our House In Order—that guide the Amazon's priorities and decision-making for that year.

And every year, the company's chief executive, Jeff Bezos, writes a long annual letter to his shareholders—the only such investor letter, besides Warren Buffett's letters for Berkshire Hathaway, to take on official “must read” status for not just Silicon Valley but Wall Street as well.

Bezos is Amazon's chief writing evangelist, and his advocacy for the art of long-form writing as a motivational tool and idea-generation technique has been ordering how people think and work at Amazon for the last two decades—most importantly, in how the company creates new ideas, how it shares them, and how it gets support for them from the wider world.

Creating Good Ideas: Clear Thinking Is Clear Writing

At Amazon, instead of asking his senior leaders to brainstorm great ideas for the company, Bezos asks them to submit six-page, dense, narratively structured memos. He then often holds a silent meeting, where senior leaders table read these memos, prior to starting a discussion.

Writing memos forces his team to think through their ideas in high-resolution detail. Instead of wasting time with impromptu brainstorming sessions, writing memos ensures that group discussion is based on the critical review of the relevant ideas, not on hypotheticals.

Most importantly, it makes it impossible to hide any logical inconsistencies in the ideas that people put out there. By imposing a rigorous, standardized template on the process of idea generation at Amazon, Jeff Bezos raises the bar and raises the quality of his team's thinking.

The email in which Jeff Bezos officially banned the use of PowerPoint at Amazon and insisted that people with ideas come to meetings with “well structured, narrative text.”

Bezos's obsession with memo writing became law at Amazon on June 9, 2004.

In the now-famous email, he explained that no Amazon team members would be allowed to bring PowerPoint presentations or even lists of bullet points as documentation for meetings: all ideas were to emerge from densely written, narrative memos:

“The reason writing a good 4 page memo is harder than 'writing' a 20 page powerpoint is because the narrative structure of a good memo forces better thought and better understanding of what's more important than what, and how things are related,” he writes, “Powerpoint-style presentations somehow give permission to gloss over ideas, flatten out any sense of relative importance, and ignore the interconnectedness of ideas.”

The memo-style of presentation is designed—contra forms like PowerPoint—to make presenting new ideas difficult for the presenter but easier for their audience.

Businesses need a repeatable process that helps generate good ideas consistently. Many companies do this by brainstorming—holding meetings for all involved to kick in ideas as a way to spur creativity by getting a diverse set of minds together.

But research has shown not only that humans are better at thinking creatively as individuals rather than as groups but also that inviting criticism and analysis is beneficial to creativity—not harmful, as some brainstorming advocates would claim.

A 2003 experiment at the University of California–Berkeley, conducted by Charlan Nemeth, set out to examine the effects of different kinds of group idea generation on idea creativity. One group was asked to answer a problem with no other instructions; one group was asked to brainstorm, with no criticism of others' ideas allowed; and one group was asked to debate one another. The last group outperformed the other two by a significant margin when it came to coming up with diverse solutions.

At Amazon, the memo format allows every meeting where ideas are presented to turn into a deep debate of the idea's relative costs and merits. This kind of criticism is even built into the memos themselves. Each memo is designed to be a full logical argument, complete with a reflexive defense of potential objections:

The point or the objective being discussed
How teams have attempted to handle this issue in the past
How the presenter's attempt differs
Why Amazon should care (i.e., what's in it for the company?)

If you’ve ever been in a brainstorm meeting, you've probably noticed that a few people can dominate the conversation. The nature of the format rewards quantity over quality and breadth over depth. The result is a lot of ideas from a few people that were all thought of more or less on a whim, many of which might not withstand even the slightest scrutiny.

Amazon involves the group, but only once the ideas are out there. Research tells us that while individuals are better at developing ideas, groups are much more efficient than individuals at recognizing the best ideas and figuring out how to implement them.

Often, the even bigger challenge, once the group figures out that they want to implement an idea, is getting that idea to spread among the wider team. Writing a six-page memo and thinking through every dimension of a new idea for the company is one thing; getting everyone in a company of hundreds of thousands to understand and live that idea is a different kind of problem entirely.

Spreading Good Ideas: Amazon Original Proverbs

Inside Amazon, Jeff Bezos's use of proverbs to get his entire company aligned behind goals is legendary.

By packaging his ideas about how Amazon should work into short, simple, and easy-to-remember phrases—“It is always Day 1,” “process as proxy,” “high-velocity decision making,” and others—Bezos ensures that his ideas not only spread and get understood but also become an influential part of how people actually act inside Amazon.

The “Day 1” metaphor first appears in one of Jeff Bezos's first shareholder letters—it was so influential inside Amazon that at Amazon's new Seattle HQ, Bezos named the building that he worked in “Day 1.”

Getting employees at all levels and in all departments on the same page often poses a difficult problem for senior leadership in companies. Messages get ignored or diluted and obscured as they pass from person to person and team to team. Instead of having a unified direction, the company then ends up with different departments prioritizing different things for different reasons.

All CEOs have to repeat themselves. But with the right kind of writing, you can improve comprehension and reduce the amount of time you have to spend explaining yourself. (Source: Lighthouse)

Packaging a message into pithy, aphoristic form is not only likely to make it more memorable; it's also likely to make it more powerful. It's less likely to be miscommunicated as it spreads from person to person, and it's more likely to encourage the kinds of behaviors you want it to encourage.

At Amazon, the year that the company first approached $1 billion in revenue was the year they chose to title “Getting Our House In Order,” or GOHIO.

Being concerned that Amazons processes wouldn't hold up to the pressure of the projected increase in volume they expected that year, Bezos knew that the focus of the company had to be on improving internal structure and process.

[source]

GOHIO became the pithy, memorable calling card of that entire year: a constant reminder that, as the company grew, everyone needed to be thinking about how the company would handle the increased scale of customer service complaints, web traffic, logistics issues, and more.

But probably the most influential proverb inside Amazon is the idea of Day 1.

Jeff Bezos's first annual shareholder letter as CEO of Amazon, sent at the end of 1997.

Jeff Bezos's 2016 annual shareholder letter, revisiting the idea of Day 1 and expanding on it.

The most important message a CEO needs to spread throughout a company is about culture: what types of mind-sets are valued, and what types of behaviors are encouraged. At Amazon, the entire cultural code is communicated in a two-word phrase: “Day 1.”

For Bezos, “Day 1” harks back to the first years of Amazon, when it truly was “Day 1” for the internet. With the internet age just beginning in earnest, Bezos knew Amazon was at an exciting juncture. There were no established playbooks for success on the internet. There were few successes to point to at all. All the company could do was try to deliver as much value as possible to their customers. Bezos's instinct was that focusing on that, over the long term, would bring about the best possible results.

In his 2016 letter to shareholders, Bezos reviewed some of the forces that could lead a company to forget that it was in “Day 1” and lose that customer-centricity, and discussed how Amazon has held those forces off. In it, he expounds at length about what Day 1 still means to Amazon—customer-centricity, resisting proxies, always looking for ways to deliver values to customers.

Few memos can guide an organization's thinking and behavior for nearly two decades straight. The only ideas that can survive for that long are the ones that are packaged memorably enough—and memorably packaging his ideas in just a few choice words has long been one of Bezos's strengths.

It's a strength that, clearly, he's used not just internally but also in his communications with the public—and most importantly, with the public shareholders of Amazon Inc.

Getting Support for Good Ideas: The Language of a Leader

Bezos's main form of communication with Amazon's shareholders and customers comes in the form of an annual letter. In these letters, Bezos explains Amazon's year, talks about what the company has learned and been challenged with, and gives hints about the future.

One reason Bezos's letters are interesting is that, for the majority of its life as a public company, Amazon was not the darling of Wall Street, as it is today. For much of its lifetime, Amazon has been criticized for refusing to turn a profit, for being too ambitious, for spreading itself too thin, and for various other reasons. In his letters, Bezos hasn't shied away from his critics—ironically, by addressing his critics head-on and at times professing his controversial decisions as Amazon's chief executive, he has built up more trust among the true believers in his shareholder pool and removed doubters.

From Bezos's first shareholder letter in 1997.

In his first public letter to shareholders, Bezos outright told his new investors that he would “make investment decisions in light of long-term market leadership considerations rather than short-term profitability considerations or short-term Wall Street reactions.” For tech-crazy shareholders in the late '90s hoping to see exponential, immediate returns on their new stock investment, this wasn't the most reassuring message to hear. And Amazon wasn't struggling by any means—by that point, the company was already generating about $148 million a year in revenue and had grown by 838% year over year. Many Wall Street analysts bucked at this clear defiance of shareholders' supposed supremacy, but Bezos was confident that the gains Amazon would make from a long-term strategy would far eclipse the losses from a few Wall Street speculators selling the stock early.

Another habit of Bezos throughout his shareholder letters is not holding back about his and Amazon's failures, and professing that Amazon would keep seeking out opportunities to boldly experiment regardless of how many failures they faced.

In his very first letter he wrote, “We will make bold rather than timid investment decisions where we see a sufficient probability of gaining market leadership advantages. Some of these investments will pay off, others will not.” In his 2017 letter, Bezos acknowledged the ”billions of dollars’ worth of failures” they'd had ”along the way”.

The shareholders who balked at this strategy, thanks to this letter, had the opportunity to leave the company behind—but those who chose to stick it out and hold on ultimately benefited.

Part of it is Bezos's style and his use of language—cool, calculated, and logically articulate. Like an air traffic controller talking down a scared pilot, Bezos doesn't shy away from discussing disaster and failure and explaining his controversial ideas for how to run a company. Instead, he explains them thoughtfully and makes you understand from his point of view.

It's also not uncommon to find Bezos strengthening and moving his points forward by posing questions to himself that a skeptical reader might bring up. In mirroring and then addressing readers' concerns, Bezos makes the tone of his writing all the more calm and confident by showing that he knows the issue inside and out and can refute any doubts.

The question Bezos poses in the introduction of his 2015 letter, “Is it only coincidence that two such dissimilar offerings grew so quickly under one roof?” challenges the assumption upon which his previous point was supported: that the success of Amazon and Amazon Web services was by design rather than coincidence. The act of posing the question in itself indicates that Bezos has thought deeply about the information and is confident in what he is saying.

How Amazon Really Wins

Amazon and Jeff Bezos have become reference points for business leaders of all types looking for guidance on how to create and manage an innovative company. While CEOs and managers are quick to adopt Bezos’s ideas and put his best practices to work, few are likely to adopt the most influential and important practice inside Amazon itself: writing.

It's not exciting or sexy, but as Jeff Bezos and Amazon have proved over the last two decades, the same skills involved in writing clearly, logically, and memorably are the same kinds of skills needed to build a company that is constantly able to deliver value to customers and reinvent itself.

Why Obsessive Documentation is Key to Being a Great Product Manager

Sam Holis — Fri, 12 Oct 2018 20:00:00 GMT

To be a great PM, you need technical prowess, deep customer context, and enough creativity and discipline to bring a new product idea to life.

But the highest-leverage skill that a product manager can develop has nothing to do with programming or design—it's the ability to write well.

As a PM, the main bottleneck in your effectiveness is how well you can communicate your thinking to the rest of your team.

Your job isn't to put out fires, micromanage every aspect of your product's development, or run stand-ups. Your job, as Ben Horowitz of Andreessen Horowitz puts it in “Good Product Manager/Bad Product Manager,” is to take the hard questions at the heart of your project and think through them in an exhaustive fashion, and then crisply and cleanly communicate your thinking to everyone else on your team. And for articulated, rigorous thinking, there is no better medium than words.

Written communication to engineering is superior because it is more consistent across an entire product team, it is more lasting, it raises accountability. —Ben Horowitz

Writing is key across every big product area that a PM has responsibility over at your typical startup:

Vision: The act of explaining the “why” behind a project in written form forces product managers to make the hard decisions early and gives the rest of the team a clear North Star to orient their efforts around.
Planning: Breaking down that vision into clear, well-articulated stories, goals, and sprints makes projects achievable and keeps them aligned with customer needs.
Execution: PMs who can communicate in written form quickly and efficiently with designers, engineers, and others are the ones who most ably clear roadblocks, resolve disputes, and shepherd their ideas to completion.

In general, the better your ability to communicate your thinking in words as a product manager, the more your thinking will be accessible to others. That means less time and energy spent course-correcting or explaining yourself, and more time spent working on problems that matter.

A narrative PRD means a more complete product vision

Good product managers think through every aspect of their product and its context when they start a new project. They find out what kind of customers would want the company's product, and why. They figure out what the other companies in a space are doing and how they might do it better. When they don't know something, they seek information, and they test their assumptions and theories against that information.

Great PMs use the above to tell a story about the customer and their needs that galvanizes everyone on the product team to work toward the same cohesive goal.

The classic piece of PM documentation is the product requirements document (PRD). The PRD is there to set out exactly what a product should do for the end user—the “job” that it's going to be “hired” to perform:

Product vision: A top-level summary. This explains the overarching vision and answers these questions — Who is the product for? Why are we building it? and What does it do?
Points of contact: The product manager's information, as well as that of any relevant stakeholders.
Resources: Any market research, competitor analysis, prototypes, and mock-ups the team can reference as they move forward with building the product.
Timeline & Dependencies: A breakdown of how long it will take to complete the project, including specific deliverables. This will illustrate the time and work needed to take a product from idea to completion.
Goals & success metrics: The specific problem a product will solve, and how the team can measure its success.
Use cases: Specific examples of how the product will solve a problem for the customer—“As a user/customer, I want…”

PRDs have a tendency to spiral out of control and become massive, constantly-in-need-of-maintenance documents.

As a PM, your PRD doesn't need to be long. It does need to explain what your product is supposed to help people do; make crucial architectural decisions early on; and clarify—for everyone on the team—what their role is in making it happen.

In the excerpt below, from Bolt's PRD, close attention is paid to describing the exact market need the product is responding to—not “cheaper small-business staffing optimization” or “foot-traffic analytics,” but:

Small and medium business owners can optimize staffing and marketing costs if they can predict foot traffic and corresponding sales conversions. Currently-available tracking solutions are expensive and difficult to install.

Within a couple of sentences, this tells you who needs the product, why they need it, and what main opportunity Bolt is interested in. Crucially, it does not prescribe exactly how they should seize that opportunity.

Writing long-form keeps you honest. It makes you grapple with logical inconsistencies earlier and can uncover issues you hadn't seen while just mulling things over in your head. It also helps ensure that you think cohesively about who your customer is and what they actually need your product for, rather than just putting together a list of features you think should be included.

As Jeff Bezos says, “There is no way to write a six-page, narratively structured memo and not have clear thinking.”

And clear thinking does not always mean tidy, objective goals. Writing articulately about the vision behind your product means setting expectations for how the end result will feel and be used, not exactly what it will look like or how it'll work. A great example of this is the original requirements doc/outline behind Product Hunt.

In the intro, Ryan Hoover doesn't prescribe a format or look for his site—instead, he focuses on defining the sensibility that he wants Product Hunt to have:

It would be easy to say you wanted to build a Digg for product people or that you wanted to build a rankings-based aggregator for new products—and these would be more precise definitions of the product—but those descriptions don't get across the important thing behind the idea of Product Hunt: most importantly, the fact that it is, above all, a community.

You could build a thousand different types of products that would accomplish Product Hunt's stated goals, and they might all look different. If they followed this document, however, they would all achieve the right end result.

A good test of a product manager is for someone outside the product team to ask 5 different people in engineering, QA, and doc what their product is supposed to do and why and get the same answer. —Ben Horowitz and David Weiden, Good Product Manager/Bad Product Manager

Context-driven user stories make sure customer needs are met

One of the most important—if not the most important—job for a product manager is to define clearly and in as much detail as is necessary what the product should do, how fast it should be, etc… Written communication is superior because it is more consistent across an entire product team, it is more lasting, it raises accountability. —Ben Horowitz and David Weiden, Good Product Manager/Bad Product Manager

Bringing a product to life isn't just building a roadmap and then cranking out a bunch of features. As a PM, your highest-leverage activity is thinking about exactly what each feature needs to help your customer accomplish and then distilling that into the clearest possible form for your team.

It may take longer to write an airtight user story that sets your delivery team up for success—one that more or less makes it impossible for them to build the wrong thing—but you save an exponentially greater amount of time in the execution phase. PMs who skimp on this save time in the short term but pay it back later.

The problem is that “Build a feature that does x” is simply a lossy medium of communication because it doesn't account for the customer context behind the request.

When you simply ask your delivery team to build a list of features, you're inevitably going to get slippage between what you envision and what they envision.

Obsessive documentation is what will make sure your team is building the product a customer needs.

This is why the user story is such a common tool among product managers. Instead of simply mapping out the functionalities a new feature needs, you organize everything by user need:

As a x (persona), I want to y (action), so that z (result)

These kinds of narrative feature requests don't prescribe a form. They keep the work your team is doing in line with the larger vision.* *They embed the user's need in the task itself, so when the delivery team is done building the feature, they have an easy way to check whether or not it's accomplishing what it's supposed to accomplish.

This gives everyone—engineers, salespeople, marketers, and customer support—immediate understanding of what truly needs to be built.

But even the simple user story can benefit from better, deeper articulation.

The user story vs. the job story, from Intercom.

Intercom's concept of the “job story” is a more detailed and more context-driven implementation of the user story. Instead of tracking who wants to do a particular action and why, the job story asks you to track:

the situation someone is in when they do a particular action,
their motivation for doing that action, and
what they expect to see or get when they're done.

The job story is intended, in part, to solve a problem with the way user stories are structured: the difficulty of disentangling your idea of the user from your implementation of the feature. If a user story-driven feature doesn't get used or it tests poorly, it's hard to know if it was your implementation or your understanding of your user's desired action that was the culprit. It's possible that the action you thought was important wasn't really important at all.

When you organize by job story, on the other hand, you produce a more context-rich task that takes into account only the factors crucial for getting the right end result: what someone is doing, what they want to be able to do, and what the outcome should look like.

Written communication keeps people accountable and projects moving

A bad product manager hoards their knowledge and needs to take time explaining their decisions to the team. This kills product momentum—individuals end up spending their time talking to the PM instead of getting work done, and the PM spends all of their time fighting fires rather than doing the work that matters.

A core piece of any great PM's job is to ensure that every member of their team has ongoing, unfettered access to a plethora of information about the product they're building: FAQs, marketing collateral, style guides, customer interviews, market research, presentations, and so on.

When your engineers and designers and marketers have both clear deadlines and full access to all of the data and information they need to complete their jobs, your projects can move along at a much faster pace.

When a product manager is obsessive about internal documentation, and maintains this information on a regular basis, it also keeps the whole team accountable.

The product manager is accountable to the VP or the CEO because their vision of the product and their ideas about how it should be executed are written down in public view.

The engineering, design, and other team leads are accountable because the vision for their team's contribution to the project is similarly outlined.

Everyone knows the standards they and others are expected to meet, increasing team knowledge and keeping everyone headed in the right direction.

Lastly, as projects progress, new information always creates the need to change the plan. Whether it's from market research, customer interviews, or changing business goals, being able to illustrate the reasoning behind any updates to the PRD helps ensure that the team understands the “why” behind these changes.

A great PM's job is as much about updating the PRD as it is about creating the initial version—Ben Horowitz advises PMs to make changes to theirs on a daily or, at minimum, a weekly basis. As teams come with new questions, competitors change their approach, or technical obstacles crop up, you need to account for these in the PRD and ensure that the state of that “living document” doesn't lag behind reality. When a PRD begins to lag behind, team members stop taking it seriously and are less likely to consult it the next time they have a question.

Writing is your product team's secret sauce

All teams have to reckon with the problem of managing information, but product teams face a special type of challenge when it comes to managing their collective understanding of their task.

Products live and die on their cohesiveness. It's not assembling widgets—it's about many different units orchestrating the delivery of one united customer experience.

Writing your plans and thoughts out—and being meticulous about what you say and how you say it—is the most powerful lever that you have as a PM for making sure that a cohesive experience is what your product delivers when it's done.