Part 1 – How to Efficiently Operate a Fully Remote Startup

Over the past 3.5 years of running a startup that’s raised millions of dollars in funding, we’ve iterated a lot on how we operate as a fully remote crypto startup (across 6+ timezones). Whenever I showcase to my friends our internal processes and tools, they eventually ask me to write an article to summarise everything. This article is a result of countless requests from founder/operator friends.

As a baseline, there’s a few key principles we operate by when thinking about our internal operations:

1. Extreme transparency. Unless there is a clear reason something should be private, most things should be public. Including comms.

2. Automation and tooling. Rather than scaling with people or rigid processes, find the right tool for the job or invest in building automations which take care of it for you forever.

3. Documentation, documentation, documentation. Not just for developers but for everyone in the business. Things that aren’t documented eventually become lost knowledge.

4. Leverage. Knowing how to build towards leverage rather than brute-force scaling.

I’ll go through the actual methods we adopt one-by-one, but they’ll tie back to the above operating principles.

At the start of every week, each team member (including myself) spend ~20 minutes writing a team update that includes:

• What they did last week

• What they’re going to do this upcoming week

• Any challenges they faced

• Fun fact about their own personal life

Without fail, this happens every week and is part of our culture. Once you write your update, you simply copy a link of it and paste it in Slack in the `#updates` channel. This serves as a reminder for others to post their updates since everyone else has followed on. To make it easy, we use a Notion database for our team updates and when you create a new entry, it pre-populates with this template making it extremely easy to populate and get started. The fun-fact section is a favourite and builds culture/trust async without taking lots of meeting time.

While this may sound simple, it’s quite critical as it enables the following:

1. Everyone is aware of what everyone else is doing immediately. It takes about 20 minutes at the start of the week to know everyone’s priorities and where they stand.

2. No meeting time is spent asking “so, what did you do last week?”. Everyone is expected to read the updates (but they’re also fun to read). This means that when we do organise meetings, they’re more for understanding challenges, blockers or future planning.

3. It creates a strong written record of what people say they’re going to do versus what actually happens. This is helpful to understand how everyone has been progressing over multiple weeks/months and any higher order patterns that we need to uncover/learn from as an organisation.

I’m pretty anti-OKRs. We’ve tried them multiple times and they’re bad for multiple reasons that I believe below:

1. You spend more time trying to figure out the right OKR than just doing the work. The goals of any organisation come down to building the product, acquisition, retention or monetisation. Any unit of work that contributes towards those goals is probably fine depending on what your current focus is.

2. People will optimise to get the OKR done rather than doing what’s best for the business. “Get 10 sales leads a week” could be a great key-result, but if the product is sub-par and the correct answer is to pause, spend time on product development and then revisit outbound sales. OKRs can create a rigid framework for an entity that is very fast moving.

3. Measuring the OKRs is a nightmare in itself. Not everything can be measured and that’s part of the startup process. Before you say that’s wrong, I’ll preface it with the fact that I love data. However, not everything can be qualitatively measured. If we could, robots could run the world. Feelings, intuitions and instincts are worth far more and it’s critical to listen to them. A “good” OKR is “improve product stability defined by less than 5 customer bug reports per week”. But what if you have more customers and they find more minor bugs, what if you have one major bug that brings down your entire system and the real fix is a 3 month refactor? OKRs like to present an image that everything is clean and can be measured. It can’t.

Now, at the same time I get the intent of OKRs which is really just a way of saying “figure out what you’re going to do on a quarterly basis and make sure you can look back on it to understand how you’re tracking”. With that, what we did was something called “Monthly Retros” instead.

The idea is similar to OKRs but allows more flexibility and agility while offering similar benefits. On the first week of a new month, rather than writing a team update, everyone writes a monthly retro. This too is a Notion database which prompts the user with the following questions:

What’s really nice is that we link each individual team update for the “Last Month’s Recap” so you can see a chain of progress on a weekly basis, rolled up to a monthly basis. It offers a zoomed out perspective of what work was done with the benefit of hindsight.

I have 1:1s with everyone on the team on a weekly or fortnightly basis. My job is to explain the business objective we’re trying to achieve, their job is to figure out the implementation details that will get us there. If this is out of sync, then it’s very easy to address and course correct. It’s also empowering to the people doing the actual work to set when they think things will be done. I don’t believe in enforcing deadlines since it always lead to poorer standards of work due to shortcuts being taken. Instead, it’s better to ask when things will be done by and then adjusting scope to meet the timelines you want. Key, yet subtle difference. If you’re not sure if the estimates are correct then you either have a skill issue or a trust issue.

As you may have noticed in this article, I’ve gone from micro (team updates) to macro (monthly zoom outs). One thing that you may have wondered is how do we set our strategy in the first place? How does everyone stay on the same page & how do we ensure they’re aligned? This is something we’ve spent so much time thinking about, mainly because we’ve gotten it wrong way too many times. Our solution to it has been memos.

A memo is typically invoked when someone has a complex idea/change/thought they want to express to the team do drive an action or direction. Whenever I have insight into our strategy and where we want to take things, I write a memo that will explain my entire train of thought and each point links to each other. They can easily be 1,000 words. This then allows everyone on the team to comment on every part of the thought and give me insight as to where I need to spend more time refining the strategy. Sometimes other team members will write a memo to explain a situation they think is causing us to be suboptimal and what we need to do to fix it. Here’s an example of what a memo might look like summarised.

I can’t share too many other examples since they go pretty deep into our internal strategy. More than happy to share an example 1:1 with any founders that would like to know over a call.

The bottom line is these memos serve as a very effective way to align and coordinate about strategy async. Usually after a few rounds of comments we’ll have a meeting and use that time to resolve ant outstanding issues or points of contention. We’ve found this works very effectively and once again cuts down on meeting times. It also gives everyone in the team the chance to feel heard and provide their input. It’s not uncommon for a memo to have 20-25 comments. It helps:

• Avoid the loudest person in the room always presenting their arguments

• Gives people time and space to carefully understand the intricacies of the idea

• Prevent people talking in circles as writing forces you to be articulate in your train of thought

I realised I’ve still only covered about half of what I wanted to cover and I’m reaching the limit of Substack’s post/email length.

What I wanted to highlight with what I’ve shared above is that with simple systems in place you can do things that:

1. Save people’s time by avoiding pointless meetings

2. Allow a more meritocratic way of discussing and promoting ideas

3. Create a strong written culture that can be used to look back on

There’s so much benefit that we’ve derived as a team from these systems that there’s no way we’d go back to our old feudal ways. Another big benefit is that anyone new who joins has so much they can read/absorb by themselves and almost instantly get up to scratch rather than having to have endless conversations (also impossible at remote startups where you meet twice a year at most).

If this article gets traction or proves to be of value to founders/operators out there, I’m more than happy to write a second part!