Building Cortex as a remote company

Remote work presents unique challenges for innovation, execution and iteration – all of which are key to building a product that people love. These challenges are even more pronounced when building a company from scratch! Here’s how we navigated building a remote-first company at Cortex.

Ganesh Datta
February 2, 2022

Cortex is a fully-remote company, and has been since the very first person joined the team! As many other companies founded over the past two years have learned, building a company from scratch in a fully-remote world has its challenges. There’s lots of content out there around transitioning to a remote culture, but not so much on what to do if you’re building a company remote-first from the start.

Cortex went from Seed to Series A in a remote world – here’s how we’ve thought about remote work and maintaining a high performing, tight knit culture.

It’s useful to first understand the challenges of remote work for an early stage company. Why is early-stage important to call out? There are a few unique requirements that have specific emphasis:

  1. High trust: an early stage startup requires autonomy, ownership, and trust between everyone on the team. Maintaining a high level of trust is challenging – doubling a team of 3 is actually 5x-ing the number of relationships. 
  2. Iteration speed: the frequency of iteration is orders of magnitude higher in the earliest days. Abrupt stops, pivots, release cadence, etc requires everyone to be on the same page all the time lest part of the team be left behind.
  3. Innovation: this one is probably the most self-explanatory. Creativity and execution are the only things an early stage startup has. Responding to feedback, seeing insights in the market, and making quick (and correct) decisions is how a company innovates to product-market-fit.
  4. Culture-in-flux: the culture of a company isn’t set in stone in the early days. The culture you define has long-lived implications, so it’s important to continually shape it to reflect the values you care about.
  5. Human bonds: Similar to trust, but fundamentally, the team needs to like each other. It’s natural for humans to work well with teams they know and trust – we are social creatures, after all, and a high performing team that’s willing to take on the difficult work of building a company is one that enjoys spending time with one another.

Keep these challenges in mind – the following is somewhat of a brain-dump that outlines all the things we’ve been doing that have helped us build a strong remote culture. I’ll highlight which one of these challenges each item solves for as we go through the list.

Synchronous work

I’ll start off with what may be one of the most controversial ideas in the remote-work world. Proponents of “true” remote work are in many cases also believers in asynchronous work. In theory, working asynchronously through docs, written communication, etc can unlock a distributed team. Hiring can become easier, letting teams find individuals across the globe.

However, we’re strong believers in a balanced approach that involves synchronicity. Some examples:

  1. Standup at 10am PST: Enables high iteration speed and trust, making sure we’re all on the same page. Non-engineers and engineers currently show up to the same standup, since all functions come together at our stage.
  2. Technical design reviews: Going over tech specs, design decisions, etc happens on synchronous calls, improving knowledge transfer and iteration speed
  3. Pairing: Engineers pair frequently on gnarly issues, helping build trust, bonds and improving speed
  4. Slack: Yes, Slack can unlock an asynchronous work-style. However, having the whole team online lets us unblock each other quickly, make last minute changes to products and implementation details, and move like a well-oiled machine.

We’re aggressive in grabbing each other’s time, just as you would in an office setting. This doesn’t work for everyone, but we’ve found it to be the most effective way of keeping everything moving at full speed.

Quarterly Offsites

Meeting people in-person is an easy way of building trust and bonds 100x faster than spending time remotely. 

We do offsites every 3-4 months, where we fly out the whole team to a single location that changes every quarter. We’ve done San Diego, San Francisco, and Miami’s coming up next!

These offsites include time for work but also to just hang out and get to know each other better. Spending dedicated time with the team leads to connections across the organization, not just between folks who work together frequently. If the sales org gets to know the engineering team and vice versa, there’s a higher level of trust that everyone is on the same side.

This helps us build better trust and relationships, and we can feel the difference when we go back to our home bases. These in-person interactions also help shape and define the culture of the team. As the team grows, these offsites will also help us drive innovation by being an opportunity to kick off major initiatives, host all-hands meetings, and make sure everyone has context on what we’re doing as a company.

And of course, offsites are fun :)

Weekly Retros

We run full-company retros every Friday. This is a strong enough example of synchronous work that I wanted to call it out specifically. 

Each Friday, we go over the following:

  1. Did we meet our goals set last week, across all functions?
  2. What did we accomplish this week? Celebrate the wins!
  3. What went well? Are there things we’ve experimented with, initiatives we took on, etc that are worth calling out?
  4. What could be better? What were the losses this week, how could we prevent them, what processes are breaking down? Talk about the losses as a team. To founders: don’t believe that you have to hide the down moments. Lean on your team to propel the company forward – everyone is on this journey for a reason.
  5. Kudos: Everyone spends a few minutes with our retro document open and shares kudos to each other. It’s always great to know you’re appreciated and even the small things are being noticed.
  6. Goals for next week: We talk about what we want to release, what goals we have across the org, and share general company updates.

All of this is defined in a Notion template that we work off, making it easy to go through the list in 30 minutes. We’ve started tracking the output of the Goals section in JIRA to make it easy to track rolled over work and check in during standup.

This helps with almost every challenge outlined at the start. We've made minimal iterations over the past 2 years, but always welcome input from the team members to improve our retros – in fact, that’s always a good thing for the “What could be better” section!

Tech Spec Reviews

One of the things I missed most from being in-person as an engineer was whiteboarding sessions, where the team got together in a room with a whiteboard and jammed on architecture or implementation details for a new feature. 

It’s difficult to do in a remote world – interruptions are harder to gauge with body language hidden on Zoom calls, not everyone has the gear to doodle on the screen to recreate a “marker hand-off”, and as a result, exploratory tech discussions can involve a lot of thrash.

To work around this, we break down the process:

  1. Product kick off: Get the team on a call and talk through the product requirements. What are we trying to build? Are specific customers asking for this? What will it unlock for the company? This step helps build context/trust and improves innovation+iteration since the entire team is on the same page.
  2. Tech spec: One member of the team is tasked with coming up with a short tech spec, to serve as a starting point for an actual discussion. It doesn’t have to be extremely in depth, but enough to discuss in a meeting. This can feel like overkill for an early stage team, but it actually speeds up iteration time and builds a culture of engineering quality and rigor from day 1.
  3. Spec review & follow ups: The member who wrote the spec presents their findings to the team. This spec provides an initial starting point for the conversation, so the review session is jamming on something in specific rather than debating endlessly on just where to start. Even if you have to go back to the drawing board from scratch as a result of this conversation, on average this process speeds up the overall time-to-code.

This is another example of a synchronous process that has been invaluable to the team.

Interview Shadowing

Throughout the interview loop for every role, we make sure that we try to maximize how many folks on our team can meet the candidate. This can even just be by having people shadow interview rounds, just to double the number of people who get to know their potential new coworker.

We also ensure that the engineering team meets non-technical hires as part of this process. At the end of the day, engineering is core to everything we do and serves essentially as the hub connecting different parts of the company.

After the interview is complete, everyone joins the debrief call, and everyone’s input is taken at the same level – even if you only shadowed the round. This lets everyone have a hand in shaping the culture and making sure that the team maintains a high-trust environment.

Friday Cooldown + Personal Wins

What’s the point of working hard all week if you can’t enjoy some downtime with the team? Building a lasting company is a marathon, not a sprint – slow down for a moment and have fun with the amazing coworkers you’re on the journey with.

Every Friday, the team spends 30+ minutes just hanging out on a zoom call, playing games like Skribbl or Secret Sith (we all get very competitive 😅). 

At the end of cooldown, we spend a few minutes going around the team and sharing a personal win from the week. These can be things like “I made a wonderful dinner this week” to “I started learning the violin” (h.t. Anish). Getting to see a small glimpse into the lives of your coworkers helps build trust and bonds – and starts interesting conversations too!


To other folks thinking of joining or starting an early stage company, think about what you value the most on this journey. Make sure you’re building a working style and set of processes that solve for the challenges that you think are the most important.

These are ways that we’ve solved for the challenges that we prioritized, but your approach may be different! Our own approach will adapt as the kinds of challenges we face start to change – the main thing that matters is being cognizant of the challenges and advantages that remote work provides, and shaping it to work for you.

If our working style at Cortex sounds interesting to you, join us! We’re hiring for every role possible :)

Ganesh Datta
What's driving urgency for IDPs?