Ask HN: Founding a remote-first startup – takeaways and tips?

11 points by soroushjp 2 years ago | 10 comments

I'm currently considering founding a new startup in a fully distributed fashion, where the first team members would be located across geographies and (to a less broad extent) across timezones.

A lot of the tips online about remote-first orgs are targeted towards orgs at a later stage where they already have a mature product and are focused on maintenance/growth. This new startup would be in the early discover (pre-product market fit) stage.

I'd like to hear experiences & tips from startup founders/employees that started from team member #1 as remote and before they found product-market fit.

What worked for you? What didn't? Would you found a remote-first startup again given the chance?

Other details, in case helpful to think about:

* NewCo's product would be in AI space and purely digital * NewCo's customers would be globally spread out, with a decent concentration in San Francisco but otherwise very globally spread out

Thanks and keen to learn from the HN community!

AlexITC 2 years ago |

We did it and I'd definitely do it again but my whole team is in the same timezone.

Our situation is a bit particular because we sell software development services while using the funds to create our own product.

I'd suggest you to think again about being fully distributed, getting it right is hard and you may want to invest such a effort in the product itself.

cushpush 2 years ago |

If you can find someone like-minded who knows the stack you want to use to build the product and you can get along with them well, consider doing weekly (or more frequent) zoom calls. Globally distributed means somebody's gotta take one for the team for timezones. But maybe that's fine in this situation. It's just hard to vet people and be sure that your intentions are connected and calibrated unless you spend a lot of time together, so if you can bridge that via Discord and Zoom and texting you might be able to make it work. But you'll need a fairly clear vision of what you want to bring into the world, and be able to convince other people it's your strongest idea and you wanna roll forward with it all the way. I have had varying levels of success making cofounder friends in online slack programming channels for <language you like>

soroushjp 2 years ago | |

Super helpful take, thanks!

__d 2 years ago |

I worked with a small (4 to start, then up to 20-ish) group of people for about 20 years, starting at a university research group, moving to a startup, through prototype, early product, pivot, and finally to mature products. Always spread over multiple continents: Europe, US, and Australia.

You need some facilitating technology:

* A good chat system. Slack is ok, but its message threads are terrible. And threads are really good for context, which is really important if conversations need to spread out over time.

* A shared whiteboard. Lots of people think well while diagramming, and it's a great way to communicate ideas and evolve them. There's a lot of bad whiteboards out there. It's probably worth buying a big iPad and pen for everyone just for this: if you have to use a mouse and draw like it's Visio, you've killed it before you start.

* Integration between your repository (git?), your CI system, and your chat tool. When people aren't in the same room, or at the same coffee machine, this is a great way to build peripheral awareness of what's being done.

* A wiki, but ... it's useless unless the culture is built to make curating it part of everyone's responsibilities. Given timezones, you need information to be available in written/drawn form. A badly manged Wiki is just a dead zone, but a good one is a fantastic resource for coworkers (and your forgetful self!).

* A final tech thing: we found that keeping a daily, public log of what we'd done and how we'd solved issues was useful. Just a few bullet points, a few cut'n'pasted command lines, and some text explaining what and why. Aside from documenting solutions to problems, it's also a great resource for seeing how things developed to where they are, and why. If you keep it in the wiki, it can be easily searched, and becomes part of the shared knowledge.

So far as timezones go, there's advantages to being far apart: Asia/Australia and east-coast US for instance means you get two chances to catch up in real-time every day, whereas Asia/west coast is usually just one. Realistically, you need to be flexible about work hours: a quick check of messages when you wake up (possibly logging in to resolve urgent stuff), early calls, then a break before work proper, then a break in the late afternoon before a late evening check, answer questions, and maybe another quick call. Everyone kinda needs to be committed to this, while realizing that it can't be _every_ day.

Calls/video/meetings are productivity killers if they happen too often, or run too long. Treat them like they're costing you a lot (and they are).

So far as early-stage customers go, having folks in different timezones can help a small company to be super responsive: someone can work on a customer query or issue overnight, and you can get back to them first-thing the next day. It really helps you look professional.

__d 2 years ago | |

I should add one thing:

It's really far, far better if there's no "head office". Once you do that, everywhere else becomes second-class by default, and suddenly it's up to them to bend their schedule to fit with call times that suit head office, or people have meetings at head office that don't include remotes, and so their opinion isn't considered and often they're not even told what was discussed or decided.

It's hard to do, but making sure that everyone is treated the same is really important to making remote team members work effectively. This is much easier when you're super small, but maintaining it as you grow is crucial.

soroushjp 2 years ago | | |

Amazing concrete, thorough advice -- thank you so much for taking the time to share it with me and others in the same boat!

nivertech 2 years ago | |

> Integration between your repository (git?), your CI system, and your chat tool. When people aren't in the same room, or at the same coffee machine, this is a great way to build peripheral awareness of what's being done.

Can you please elaborate? I mean technically do you mean just something that takes git PRs. CI statuses, error traces, etc. and sends push notifications to Slack/Teams/etc., or something more sophisticated like GitHub Actions committing realtime meeting transcripts and their AI geenerated summaries to a git repo?

__d 2 years ago | | |

The former.

We found it really useful to see, in a way that you could read and ignore, who was committing what to where. It helped you keep up with what was going on, who was working where in the codebase, when things that might impact you changed, etc, all without any explicit effort save for writing decent commit messages.

Particularly when you're all in different timezones, that kind of casual background knowledge is really useful for keeping everyone on the same page. You can scan through the messages to see what's happened in the code overnight in a few minutes.