Former SaaS startup co-founder and growth-stage SaaS CTO with nearly two decades of experience. I've helped many organizations improve scalability, accelerate innovation, enable enterprise sales, get buggy releases under control, reduce OpEx, and much more. Specialties include: application architecture and security, cloud architecture and security, DevOps, DevSecOps, SRE, and compliance (SOC2, FedRAMP, GDPR, CCPA, HIPAA, PCI). How can I help you?
I'm a former early-stage SaaS co-founder and growth-stage SaaS CTO.
Many tech startups - including the ones I've been personally involved in - are co-founded by one person who focuses on business and operations and another who focuses on tech.
You should definitely focus first on gaining validation. Early validation doesn't usually require technology. For example, it is easy to conduct surveys and interviews, it is easy to deploy ads and landing pages, etc. Once you have some meaningful validation, you should ask *yourself* some key questions:
- Why are you and your team uniquely suited to grow this business?
- Why now?
- Why isn’t anyone else already doing it or why do you have the upper hand on them?
If you can answer those questions - fairly and confidently - then you have every right to consider yourself an important half of a co-founding equation. You will - of course - at this point need to bring in someone more technical. You will be reliant on them for the tech, but they will be reliant on you for everything else - business acumen, inside knowledge, connections, the things only you can bring to the table. A good technical co-founder will understand that an idea is just a seed, but it takes the right business partner to make it come to life.
Check out this recent blog post I wrote on the role of an early-stage CTO, how to find one and compensate one, etc:
If you have any further questions, let me know!
With the exception of the "extended" qualifier, I believe the answer is yes. I have extensive experience growing remote engineering teams. As somebody else here mentioned, extended offsites are difficult because schedules are tough to coordinate, people have families, etc. However, it is very common for remote teams to have anywhere from 1-4 offsite meetups per year - anywhere from 3-7 days in length - where a combination of work and play occur. The more the better, but the frequency and length tends to be dictated by budget. These are great opportunities to build culture and rally around big projects. As more companies go remote, I suspect they'll find the same types of offsites and cadences making sense for them.