Public by default: How we manage information visibility at Get on Board

By

I’ve been obsessed with managing information, and communications in a remote team since Get on Board started growing. Reducing the bus factor is a primary motivation — but another just as important is diminishing reliance on synchronicity. When what I know is documented and accessible to others, I’m less likely to be a bottleneck for anyone else in the team. So if I’m busy, minding family matters, on vacation, or sick, I won’t be blocking anyone.

This, in turn, gives everyone in the team the freedom to build their own work schedules according to their needs, work from any time zone, or enjoy more distraction-free moments. As I write these lines, most of the world is under quarantine, relying on non-stop video calls to continue working. Needless to say, that is not a sustainable long-term work schedule.

That’s why we adopted some principles that help us make information more resilient, so we don’t have to be continuously picking each other’s brains. Of those principles, Public-by-default is the most important.

Take a look at the following visibility rings we defined for our information:

These are the visibility rings we defined in Get on Board. Every time we create a piece of information, we start with the Public ring by default.

⭐️ Public-by-default means: all information belongs to the outermost ring possible, and we only move it inwards if we have a compelling reason to do so.

This very article is an example of this principle put into action. It exists primarily for our internal use, but given there’s no reason why the general public can’t benefit from it as well, it lives in our most public ring.


Why Public-by-default

  • Knowledge made public is more resilient and findable. Information in public channels is easier to find (you can even use Google or archive.org to retrieve it) and less prone to accidental loss. More people will know about it — and will remember it — than if it’s private.
  • Knowledge made public is more robust. It is open to others’ scrutiny, validation, correction, and supplementation. We can test the quality of our assumptions more broadly if others can give feedback on them. If we are wrong, we will know it sooner.
  • The public eye makes us work harder. Having information subject to open scrutiny motivates us to make it high-quality from the beginning: better written, better referenced, better reasoned.
  • Easier decision-making. If we all have access to the same information, we will have a shared context that, in turn, will help us make better decisions and with less friction.
  • Public knowledge helps more people and adds more value. For instance, if others share this article, it benefits new readers and helps us make our brand more visible. A new team member joining the company in the future might have already read this piece, accelerating their onboarding.


Some examples

We try to make the information live in the outermost ring possible:

  • Ask questions in public channels, not DMs. Even if you intend to ask one specific person, putting the question in an open channel allows others to chime in and avoids bottlenecks. You don’t necessarily know who has the answer to your question!
  • Put our technical findings and learnings in our dev blog (public) instead of Notion (org-wide). By putting these learnings public, we increase the chance that others suggest better alternatives or give new ideas.
  • Discuss/make decisions over Slack or Notion (org-wide) rather than over a Zoom video call (team-specific). Text-based channels are always more accessible and shareable than video calls (even with auto-recording).
  • Put our moderation criteria for jobs easily accessible for anyone to see. Our users and customers' document is the same one we use internally to moderate jobs. Perfect transparency!
  • Maintain product documentation in our live help center (public) rather than internal manuals (org-wide). When a new team member wants to learn about how Get on Board works, they use our publicly available information. This helps us stress-test it and improve it for the benefit of all our users.
  • Drafts, WIP, and unfinished files live by default in our shared files and tools (org-wide) instead of in a private folder “until they are ready.” We are not ashamed of unfinished work. That’s the “progress” in work-in-progress!
  • We give the whole team, not just the decision-makers, access to our financial metrics. If everyone in the team understands how we are doing financially, our decisions require less explanation and are implemented with a lot less friction — everyone understands why we are doing it.

Caveats of public-by-default

We are mindful of the following perils when embracing public-by-default:

📣 Excess of noise

When everything is public, it means any given person will have access to tons of information. If poorly managed, this will mean teammates drowning in lots of noise, permanently distracted, and struggling to find what’s important.

We see this quite frequently when using teamwork tools such as Slack. Yes, maybe everything we have ever discussed is in a Slack channel — but good luck trying to find it. And hope you get used to having those pesky bottle-open notifications every 15 minutes.

How do we curb noise?

  • Distinguish between making something visible to everyone and notifying everyone. Just because something is public, it doesn’t mean everyone has to be interrupted and made to pay immediate attention to it. Mind the use of notifications and @s. Public-by-default does not mean everything has to go in the #general channel; using a non-private channel (so anyone can join and search the info later) is more than enough.
  • Search first, then create. Assume that it’s very likely that the information you are about to create already exists elsewhere (including the Web). If it already exists, link to it or build on it.
  • Be brief. Summarize, reduce words, make simpler sentences.
  • Provide context and clues. We should try to answer the question, “do I really need to keep reading this?” in less than 5 seconds. A longer page title, or an introductory paragraph, go a long way in informing the reader if they should continue spending time reading this piece.
  • Make information findable by tagging and classifying it appropriately
  • . Information Architecture is fundamental here. Knowledge is only useful if it’s accessible when you need it. Take time to organize and describe information. Like you would do with SEO, add keywords that help this article be easily found.
  • Make information friendly and easy to navigate. If necessary, break it down to several pages, provide a table of contents, use links generously, and include illustrations and charts.
  • Prefer asynchronous, longer-term channels. Our blog has a longer shelf-life than in Notion, and knowledge in Notion has a longer shelf-life than in Slack. The longer-lived a channel is, the less immediacy it demands. You can read this article tomorrow or the next year if you prefer, and it will continue to be timely.

😱 FOMO

It’s easy to get carried out by the fear of missing out and trying to be on top of every single new piece of information that is created. If you are the kind of person that likes to join ALL Slack channels, reads or participates in ALL conversation threads, and reads ALL articles that the team shares, you know what I’m talking about.

Just as we are mindful of others’ FOMO and try not to distract them unnecessarily, we need to be aware that we have only a limited amount of information we can consume daily. We need to spend that amount wisely.

Reducing FOMO long-term requires building trust that the information will be easy to find when you need it, so you don’t need to be on top of it. Good information architecture is paramount in building that trust — information must be well-tagged, well-classified, searchable, and easy to navigate.

🤐 Disclosure of confidential or sensitive information

Public-by-default still demands discretion and tact. It does not mean no one can keep secrets, nor that all discussions should be held publicly. It does not require us to disclose everything. We still need to care about privacy and information security. So we still need to be careful and appropriately protect information that if disclosed:

  • Might compromise the safety or privacy of any team member, user, partner, or customer;
  • Might harm trust (for instance, sharing a secret confided to us by someone else or a screenshot of a private talk without permission);
  • Might violate an NDA, the law, or a handshake agreement.

Personal information generally belongs to the most private ring.


To conclude: mindset.

Most of us tend to be naturally wary of sharing information with the outside. We fear others can copy our idea or our strategy, we fear to look bad if someone takes a look at that unfinished draft, we fear looking silly to ask basic questions, we fear receiving public criticism.

We aim to build a safe space where everyone is encouraged to share, both internally and publicly. We welcome questions, criticism, and healthy debate because it allows us to confront our ideas. We are more concerned about finding the truth than looking good.

That’s why we go public — so we can learn faster.

Latest on Blog