I am an engineer who has founded three startups in the last 10 years. The first two were funded by Sequoia Capital & YCombinator. The current one is backed by Accel Partners. I have also worked at three other growth stage tech startups.
Having seen multiple product lifecycles, I have experienced the pain of creating & scaling products from scratch. Most of my experience and expertise comes from Distributed Systems.
On the non-tech side, I love building teams and going through the zero-to-one phase in a startup.
Feel free to ask anything about the YCombinator application process, entrepreneurship, building engineering teams, scaling products or anything else you are wondering about.
Latest comments (21)
Thanks for the AMA.
Great questions @kp . Thanks for asking!
In an ideal world, I'd bootstrap but in a practical world, I'd raise VC money. Imagine sitting at a poker table carrying $10 while everyone else is carrying $10,000. Winning at that table is not impossible, just very low probability.
It depends on what you need from YC. Clearly, not product development advice. IMHO, YC gives you a network of kickass alumnus, a peer group that pushes you, access to VCs on demo day & most importantly, an early distribution channel for your product (your own batch). That last one is invaluable to get early product feedback.
I don't think I've come across a dev.to for PMs. In fact, the other day, our product manager asked the same question. If Design == Dribbble, Programming == Dev.to, Product Management == ? I think there's definitely potential there.
Biggest learning has been; "It's all about the people". Do right by your team, vendors, partner and they will reward you many-fold over your lifetime. Optimize for completing the marathon v/s winning a sprint.
Thanks @mohanarpit this is super helpful. I especially liked "Optimize for completing the marathon v/s winning a sprint." You can never go wrong with long-term thinking.
1 - what 3 books would you gift to a friend of yours?
2 - how did you verify that your ideas had market value?
3 books that I would definitely recommend reading:
Verifying the problem is a lot more valuable than the solution. This has been a combination of multiple strategies:
I hope this helps you whittle down your ideas to "the one".
Do you feel the equity YC takes is worth the connections and the funding you get from them?
Let me preface this question by Paul Graham's post on this very subject here.
I agree that they take a lot more equity than usual VCs do. But, in return, they provide a solid alumnus network, access to investors during Demo Day and most importantly, early customers. There are plenty of companies that have grown by simply selling to their own YC batch or just other YC startups. In my books, access to early & friendly customers is worth their weight in gold.
That post is exactly why I asked that question, do you feel that formula he proposes is applicable? It's one thing reading a blog-post and another thing getting the hands-on talk from someone who went through the whole experience 😛
Hi Arpit, how does the role of a CTO change as a company scales? Also, any tips on how to go about finding product market fit and how to position engineering to assist that? Should founders build, iterate and learn or do thorough research before diving in, whats better/optimal?
Really good questions! Thanks for asking.
Please refer to my comment here on the role of a CTO changing as per company scale.
Finding product market fit is the holy grail of starting up. As an engineer, in the early days, I would suggest that you design for change instead of scale or code-cleanliness. Even if you are copy-pasting code, that's fine as long as you can quickly pivot the product based on business needs. This generally goes against everything that we are taught, but unless you have found the product-market fit, don't listen to Uncle Bob and his clean code mantras :)
Each founder is different in their approach to building startups. Personally, I'm more of a doer than a thinker/researcher. There's definitely a lot of value in research before you build. I generally operate better once I have a prototype/MVP that I can demo to people and garner feedback. These days, I'm relying more on no-code / low-code solutions to prototype ideas before actually writing Java/Python code to bring that idea to life.
As someone who doesn't know a lot about Distributed Systems - what are some basics that I should keep in mind while I'm developing? Are there things I can do to make things easier or harder to scale later? (or: when should I start worrying about that?) Thanks!
My biggest learning while dealing with Distributed Systems has been that everything fails (especially the network). Most of the products that I build now are not focused to prevent failure but instead to work inspite of failure. Some keywords to read up are Chaos Engineering and Crash First Development.
My second biggest learning ( & potentially unpopular opinion) is that if you can avoid a distributed system, avoid it. A monolith is hundred times easier to reason with and test against. :D
Great points, thanks; Yeah - I think "everything fails" is one of the reasons I've really tried to avoid it so far :)
That, and nothing that I've built has enough traffic that can't just be solved by "increase the number of web processes" on a monolith app. Maybe if I build something popular enough, then I'll have to worry 🤣
How successful are your startups, did you have any near misses with going out business or running out of funding?
And if so, how did you handle those situations? :)
I've had a couple of exits with my previous company and learnt very different things through the acquisitions and failures. Even though my last company shut down (because we were burnt out as a team), I learnt how to scale a product growing at 15% day-on-day for 4 months straight.
As a founder, there have been 2 occasions where we couldn't pay ourselves salaries for 3 months straight. At both those times, what helped us the most was:
How did YC help you position and set yourself for the next gig/s?
YC was an incredible experience that taught us the value of growth. I think their mentorship has helped me startup better this time around.
I think I'm better at cutting through the chaff and simplifying problems to their essence now. Most times, the solutions aren't big & dramatic but are small things staring at you right in your face.
Also, the YC founder network is super helpful & has been invaluable to get early product feedback or just act as a support group whenever I feel down.
Hey,
I'd love to hear the highs & lows that you've gone through as an entrepreneur! What were the key takeaways?
The highs of entrepreneurship have generally remained the same as my robot hardware hacking days:
Lows:
My biggest takeaway from this journey has been that entrepreneurship is a marathon. Maximizing short-term gains doesn't make sense. If you do right by your team and other people you work with, you'll reap exponential benefits in the long run.
What are main responsibilities of a CTO?
I think the responsibilities of a CTO changes based on the stage of the company. In the early stage, it's imperative for the CTO to have a hacker mentality and be able to quickly iterate the product towards product-market fit.
As the product & startup starts to scale, the CTO needs to transition towards being the visionary on the technology front. This involves juggling thoughts between the business folks and the tech team at the same time. It's usually at this juncture that a VP Engineering steps in to take care of the people problems and help scale the team & maintain the culture.
At an enterprise (read: Amazon, Juniper), the CTO cares about what will make the business successful. Since enterprises move slowly, the CTO needs to be able to see multiple years ahead and focus on the tech & ops to ensure the business continues to succeed.
I hope this answers your question.