One of the most integral parts of any organizations success is how you communicate internally. This is especially true for startups, because what you build and how fast you move is highly affected by how you communicate and organize ideas. The important parts:

• Prioritizing major projects, tasks, issues and assigning responsibility

• Knowing who is doing what / when, bot now and in the future

• Sharing general information and keeping everyone on the same page

• Methods for doing so synchronously (meetings) vs. asynchronously (messages)

As a founder, communication is something I’ve thought a lot about recently. Especially as our priorities have changed, I’ve realized the systems we’ve used to communicate probably haven’t been optimal. So I’m working on redesigning our systems and tools to better accommodate us going forward, which I’ll outline below.

Importantly, one of the most crucial pieces when establishing communication systems and protocols is making sure everyone is on the same page with how communication should take place. The worst thing you can do is establish a system that’s used improperly, or doesn’t get used at all.

So, here is how I am designing our effective communication within my startup, hopefully this helps anyone reading this looking to do the same :-)

Pursuit of the Ideal Comm’s System

1) Project Management / Task Tracking:

The most important part of any productive business comm’s is keeping track of high-level projects / initiatives, directly linking them to individual tasks and issues, and assigning ownership to each of them.

We have tried many ways of doing this over the years: Trello, Notion, Github Issues + Notion, etc., and have ultimately landed on Github Projects for it’s structure and ability to do things like assign to people, connect to projects, prioritize, and link directly to code.

The crucial piece here is having ONE source of truth for all your task management. In the past we used Notion to keep track of high-level projects and Github to track the component tasks and issues, but the disconnect caused things to not get updated or be avoided. Github Projects keeps everything we need in one place.

2. File Management:

Separate from keeping track of who’s doing what and when, you need a file system to keep and organize any documentation, links to resources, or general knowledge.

We have long used Notion as our knowledge base system. It is extremely modular and flexible, which is nice for making doc’s, but can be a bit overwhelming and easy to lose things if you don’t have a Standard Operating Procedure.

The goal here is to simply bucket different files into folders / structure (like you would in your Documents or Google Drive) and use it as a place to keep things that you’ll want to look back on later. So for us that’s things like our Data Room, any SOPs and explanations of how to do things, and any notes or high-level thought that goes beyond simple tasks / messages

3) Messaging (Async Comm’s)

For anything that doesn’t fit into a task management system or filing system, we generally use a messaging platform for. Historically we’ve used Discord, but we are in the process of migrating things over to Slack.

Messaging is NOT for keeping track of tasks/issues. It’s for thing like one-off questions, sharing extemporaneous thoughts & reference items, scheduling things, quick huddles, and automated notifications (ex: new user sign-ups)

The goal is to have these messages in one platform (vs. email + text + etc.) and use channels to direct conversations into relevant clusters. You must be deliberate about how you set up channels — for us it’s a main channel, a to-do’s channel, some ‘department’ specific channels (ex: marketing, finance, etc.), some project-specific channels, and some automated notifications channels. Pretty simple.

4) Meetings (Synchronous Comm’s)

While we are a default-async company (given we are in all sorts of different locations and time-zones), we do schedule a few light meetings regularly to make sure we are all on the same page and have a chance to connect. We have two types of regularly scheduled meetings:

1. Weekly Standup

   This is held once per week (as implied) in the middle of the week (which we’ve found is better than doing it at the beginning so ppl can get into their groove) for about 45min each time. These follow more-or-less the standard L10 framework: 5 minutes chit-chat, 5 minutes of metrics / headlines, 5 minutes going through everyone’s current to-do’s, and 30 minutes discussing (and solving) our most important issues as a team. We use Google Meets and go through our GitHub projects board (with different views), and at the end everyone rates the meeting.

2. Daily Standups

   We do a daily 10min(!) standup at around 10:15am every day, with the explicit goal of simply telling everyone what we’re working on and quickly acknowledging any issues / headlines. By default we try to do these synchronously on Mon, Tue, Thu, Fri, but if things come up and >50% of folks are busy then we will do it async as a back-up

5) Monthly/Quarterly Admin Meetings

Over the longer-than-a-week time horizon, we have a few sync’d meetings per quarter. My cofounder and I do a monthly finance call to be intentional about reviewing our expenses, discussing any accounting issues, and planning ahead any financial forecasts. For me it’s really more of a reminder to check on those things than anything.

We also do a quarterly “audit” of the business, looking over everything we spent time and money on over the past 3 months, rethinking priorities, and discussing ways to improve. This entire Comm’s SOP came out of having one of those calls this quarter. Quarterly audits are also a good spot to simply check with eachother on how we’re feeling and address any interpersonal concerns — if you don’t have that time and space then those things can get forgotten and build up into some turmoil.

6) Availability and Out-Of-Office

Lastly, it’s important to have some standards in place about how your team is available. Generally (especially with part-time folks) it’s good to set an explicit ‘working schedule’ throughout the week.

For some part-time folks that may be Wednesday afternoons and Friday mornings. For others it may be after 5pm each night. Whatever it is you should have everyone state it and be intentional about sticking to it, and if things change they should notify the group. This way you can all know when someone is available to chat generally, (and when you shouldn’t expect a response).

Use a shared Google Calendar or something to have a source of truth for all of the team. You can also use Slack’s “Status” functionality to keep other people up on whether you’re currently available or not. And make sure if people are going to be out for extended periods (like Holidays) that you keep tabs of this in your group calendar.

Overall, for a software-focused async-first startup I’d say those are really the big buckets that you need to have straightened out and planned intentionally to be successful.

This may evolve over time based on your organization’s size and needs. Generally I find it helpful whenever we make a decision to think not only of our current needs, but what our needs will look like if we expand the team later on.

Foresight is crucial. Communication is everything :-)

Peace,
Ramsey