I am not going to go into details about the company itself, what we were doing, how many times we pivoted, to what, from where or why. I am also not going to talk about personal details.
Our initial team consisted of a junior technical cofounder, a non-technical cofounder and myself (senior technical).
Inherently there wouldn't be specific issues with this setup, but I found that technical cofounders tend to be much more pragmatic and like to see the cause and effect of everything. I assume this is due to the fact that software engineering is a logic-based profession and thus people following this path has a higher chance of applying this discipline in their general thinking practices. Add to this some brainstorming and collaborative decision making and the result was some heated arguments where the technical founders couldn't convince the non-technical founder because logic by itself was not sufficient enough to convince him.
So Lesson#1: find cofounders who, regardless of being technical or not, accepts logic as the ultimate proving ground for ideas.
While the non-technical cofounder was lacking logic-based thinking, he was really efficient in building and maintaining relationships and finding ways into networks that he seemed important to be part of. In hindsight, these networks were not useful at the moment and would have been useful in later stage of the company when we already had market share.
Lesson#2: find your niche as early as possible to avoid being exhausted by potential clients who wont actually use your product tomorrow/next week.
Working together with others is hard. To do it efficiently, it requires you to leave your ego behind and focus on the problem at hand as objectively as possible.
Lesson#3: People following Stoicism is a good filter for co-founders as the main point of it is that your ego is the enemy and you should focus on what you can control here and now.
Working in-person automatically generates a lot of opportunities for interaction and just by the sheer numbers of micro-interactions, a work culture will emerge fairly quickly. This culture is usually dominated by the attributes of the loudest individuals of the group and lacks any intentionality, mostly because the culture will emerge without conscious thought, so its easy to miss the need for it. So having a good work culture in this case is highly dependent on finding the right people to be culture leaders of the group (which I assume most people don't filter for during hiring/cofounder matching).
Remote work on the other hand forces you to think about all these stuff because its not going to happen just by itself. And if you don't think about it, or don't define it, or people are not following it, there will be no work culture because it is just going to be a group of individuals working alongside instead of working together.
Lesson#4: If you don't spend time defining and enforcing remote work culture, there wont be any.
Lesson#5: If your cofounders are not following agreed upon processes, find new people.
A really important factor in effective remote work is communication. You have to actively put effort into giving status on what you are working on and what you have achieved. These status updates happen organically in-person. If they don't get reported to each other, the other person will think it never happened and because the true emergence of a group comes from effective collaboration, not communicating these things will stunt the whole group, making it much harder to achieve any milestone and ultimately lead to failure.
Lesson#6: Start with at least a daily call and revisit cadence once you have a healthy communication culture.
Lesson#7: If, after 6 months of working together, you still haven't built out a good working culture where all of you feel comfortable and in-flow most of the time, find new people.
My technical cofounder was effectively a junior engineer. He built small apps before, worked on small projects but has minimal to no knowledge about backend, infrastructure, good coding practices, testing, etc. As a senior engineer I've raised several juniors throughout the years but almost always did it in person and doing so was much easier. They could always come to me, I could just lean over and help them out, then continue with my work. Doing this remote is much harder because it is much harder to ask help on slack then in person. If you also add in the fact that I was working only during nights and weekends, when there was little overlap between our coding hours, its even worse. It makes it really hard to guide a junior engineer toward responsible coding practices and by the time you get the question, there are 3000 lines of spaghetti generated in a single file.
This also raises another point in resource management: As I only had ~20 hours a week to work on this project, how efficient it is to spend half of that educating a junior engineer and fixing easily avoidable bugs?
Lesson#8: Find senior technical cofounders so both of you can focus on learning the problem space and building the product instead of teaching/learning the profession and fixing/collaborating on trivial bugs.
There was a conceptual misunderstanding in responsibilities and resource allocation that I think ultimately lead to where we are now. My co-founders were both full-time on the project, while I was working about 20 hours a week on this project and spent the rest of my time working on my full-time job, with my family or tending to responsibilities around the house. In the first month of our journey together, I suggested that the best use of my time is hands down coding and building because I wont be able to talk to customers as I'm working nights and weekends, when most people are not working. So any task that requires real-time presence with people working 9-5 is out of question. However, overtime this agreement faded into the void and there was more and more expectation from my cofounders toward me to understand everything they understood based on their talks and calls with our potential customers, without them clearly communicating these things to me. This led to a point where my cofounder specifically stated that everyone in the team should be doing everything and be able to run the company alone.
I think this is an anti-pattern and negates any and all advantage of people collaborating together. I understand that in an early startup the roles are not that clear and there are a lot of tasks that just have to be done without us being able to categorize it into any specific responsibility circle. But I think our job as entrepreneurs is to collect all the necessary tasks that needs to be done into a chaotic mass and then slowly organizing it into a well defined, reproducible process that can be delegated to employees. This reproducible process describes the actors and their actions, aka the responsible parties and their responsibilities.
Lesson#9: Responsibilities should be revisited often and agreed upon to make sure that expectations are clear and we are marching forward instead of flailing around.