Democratizing Context

BLUF

At Metaview, our default visibility scope in every medium of communication is 'Metaview-public’. In other words, as a strong default, everything should be public to the company unless explicitly, consciously, and deliberately needing to be private. We shorten this philosophy to Public Unless Private, or PUP.

In this post we talk about the rationale behind this approach, and a high-level overview of some of our processes and conventions.

Rationale

It’s autumn 1998, and computer scientist Eric Brewer first speaks of what soon became known as Brewer’s theorem, or CAP theorem. The CAP theorem is a fundamental theorem in distributed systems that states any distributed system can have at most two of the following three properties:

1. Consistency: Every read receives the most recent write, or an error.
2. Availability: Every request receives a (non-error) response, without the guarantee that it contains the most recent write.
3. Partition Tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes.

CAP theorem is about distributed systems — systems whose components are located on different networked computers, which communicate and coordinate their actions by passing messages to one another. With sufficient squinting, something else that looks like a distributed system, swims like a distributed system, and quacks like a distributed system, is a company. CAP theorem can be a useful mental model when thinking about how we operate companies. When building a team, Partition Tolerance (i.e. Bus Factor) is often non-negotiable. So, you can then take your pick between Consistency or Availability. At Metaview, we picked Consistency from inception.

We believe that after hiring the right people (necessary for Partition Tolerance), those individuals not having all the context they need is the biggest existential threat to our company. In other words, communication channels and processes become the next most existential threat to our company. In a perfect world, everyone always automatically knows what is happening and coordination becomes completely fluid and painless. In this perfect world, due to everyone’s context-awareness, we’ll also be able to encourage autonomy, rigorous debate, and avoid knowledge silos — there’s no dictatorial control over the flow of information. As such, we think an ambiently open flow of information is the best way to provide all of us with the context we need to choose useful things to work on.

The way we achieve this is by ensuring our default visibility scope in every medium of communication is ‘Metaview-public’. In other words, as a strong default, everything should be available to everyone in the company unless explicitly, consciously, and deliberately needing to be private. We shorten this philosophy to Public Unless Private, or PUP.

This isn’t a new invention, but it is a very deliberate choice — one that requires a set of new habits. We formed this philosophy from first principles, but, we’ve learnt a lot from others who have taken a similar approach. Amongst other influences, we’ve formed this philosophy from our time building teams at Palantir, from conversations with our friends at Stripe, and from studying the strengths and weaknesses of Gitlab’s approach to communication.

Like every decision, this isn’t right, wrong, or for everyone. It’s a deliberate navigation of many trade-offs with the intention of empowering us to do the best work of our lives, fast. As we grow, we’ll continue reflecting and iterating.

Execution

We currently have three formal channels of communication: Slack, email, and meetings. For each of these channels, we have a set of default PUP conventions to help us avoid information silos. As you can imagine, PUP results in a firehose of information so we also need to have well-defined channel-specific defaults for how to route information so that we're not overwhelmed. Having too much information at once is indistinguishable from having no information.

PUP on Email

We use Gmail for email and Google Groups for distribution lists. Our emails are either on-list or off-list. On-list emails have a group (e.g., engineering@) on the To, CC, or BCC line. Whereas off-list emails only have people as recipients. By default, an email should be on-list unless there’s an explicit and deliberate decision for it not to be — like personal feedback. As such, the overwhelming majority of emails we send are on-list.

PUP on Slack

Applying PUP to Slack conversations is straightforward. There is rarely a reason to Direct Message (DM) someone on Slack — instead, we use Threads on public Channels. We also default to only creating public Channels. This improves context discoverability (e.g., via search) and increases serendipity.

PUP in Meetings

Meetings are either internal or external. As we've grown, formalizing PUP for meetings has become increasingly critical, especially for external meetings. Our default conventions for external meetings are to:

1. Use Gong (it’s like Metaview but for customer meetings). This ensures zero context is lost as every team member can asynchronously experience exactly what the participants experienced. This doesn’t mean it’s a good use of time to watch all meetings. But, the conversation becomes searchable, “truth snippets” can be used when talking about customer pain, and full context is available for new folks as and when they onboard.
2. Write Meeting Reports (MR) to synthesize customer interactions. These are short documents with a BLUF, detailing who was present, action items, and synthesized notes on what was discussed and what we learned from the meeting. The MR is then sent to the meeting-reports@ list, which every person in the company receives.

We're still experimenting with different ways to make this work for internal meetings, and it's not yet become a huge pain point. We've considered using products like Rewatch, or Vowel to make these meetings searchable and the context globally available, but we've not yet committed to any one route.