Lessons from My First Startup
Leadership Lessons
Embrace Chaos
It’s chaotic all around - product direction changes frequently, tasks and projects are not well defined, processes have not been setup yet. The only way to navigate this is by learning to thrive in chaos.
Accept Rejection
Rejections are also common in a startup (even for an employee) - your ideas could get rejected, the client you’re working with might not like the product you’re building, the deal you’re working on won’t go through, the potential employee you’re trying to hire might say no. This is common and don’t let this bring you down.
Indecisive
I heard this from Bipul Sinha (CEO of Rubrik). Speed is one of the biggest strengths of a startup and you don’t want to spend too much time deciding the ideal/perfect next step. Keep failing but fail fast and improve. The goal is not to get all your decisions right - as long as the number of right decisions > number of wrong decisions, you’re doing great!
Feedback
Try to ask questions instead of providing statement based feedback - especially questions that makes the other person introspect. Avoid direct feedback (especially if it is immediately after an outcome or a result) - it comes from the position of I know / I think I am right. Also, in some cases frame the question as a group feedback - what could we have done better (if you’re doing that start the conversation about one of the things you could have done better).
Conflicts
The first step to navigate a conflict is to find out if you’re aligned on the ‘why’. Once you’re aligned on the why, try to understand their point on the ‘how’, ‘when’, ‘what’ etc and discuss the pros and cons.
Single Point of contact
Have a single point of contact for all tasks and projects - they take responsibility for failure or success. Communicate the tasks and roles of everyone involved to everyone in the project.
Energy
I read this in a @pmarca blog. It is natural to go through an emotional rollercoaster in a startup - one week, your company has raised a new round of funding, you had a great idea to improve the product and you’re working on the cutting edge technology and pushing the limits of what is possible. However, the next week your company could potentially lose a big client, your colleagues are WFH often and could potentially be interviewing at another place and your metrics have gone down this week and you don’t know why (or even worse is when you know why but don’t know how to fix it).
Quickly A/B Test whenever possible
If it takes less time for you to build 2 versions of the product and A/B test them than for you to investigate and decide which might be the best version of the product, you’ve probably taken it too far :)
Separate facts from judgement or intuition
This is especially true when communicating with your colleagues while discussing potential design options. Be prepared to be wrong when it comes to non-factual statements (and communicate it clearly).
We vs They
It is important to note how you refer to your company - whether you’re including yourself (we) when talking about your company or referring to the company in 3rd person (they). Ideally, you’d want to do the former as much as possible in a small company.
We before I
Put the company before yourself - interests are aligned more in a startup (if the company does well, you do well).
Hiring
This is based on @pmarca’s blog. Ideally, you’d want to hire for drive, curiosity and ethics. Talent is important but only to a certain extent.
Drive - Not GPA. Ask for struggles where they had to find the solution and solve. Curiosity - Test if people are curious about their field (stay current) Ethics - Pick a topic you know intimately and ask the candidate increasingly esoteric questions until they don’t know the answer. Check if the candidate BSs.
Technical Lessons
Constant refactor
Don’t avoid code refactors - this becomes much harder for you to maintain systems in the long run and lead to technical debt. I’ve found somewhere around 5% to be a good number.
Don’t over-engineer
The easiest way to achieve this is to believe that you’ll spend x% of your time in the near future refactoring the code (above point). You’ll have more knowledge of how the system is used and this will help you iterate on the code.
Incremental Progress
Make incremental progress - don’t go in a rabbit hole and come out after 3 months completing the project. In my experience, tracking and making progress every 2 weeks has worked.
Build systems that can get better over time
This is more applicable for ML/NLP systems. As much as possible, avoid black boxes where you can’t make improvements to the system. Also avoid solely depending on hacks (whitelists or blacklists) as they don’t help you get better over time.
Adopt Coding style, measure code quality and Test Coverage
I’m sure there’s some correlation between refactor time and code quality - it doesn’t take a LOT more time to write clean code but it takes a LOT of time to refactor ugly code.
Measure
Measure whatever you want to improve - if you can’t measure it you can’t improve. If you want to improve your clustering algorithm, find ways to measure the quality of the clusters. If you want to improve the stability of the systems, come up with good metrics to measure that.
Kaushik Rangadurai
Code. Learn. Explore