On Being a CTO at 20
I started working on building EventMobi when I was just 20 years old — a time when my trips to SF would result in me trying to get into bars with other engineers with my fake ID. I just turned 26 (2014), and only recently have I been able to raise my head from my keyboard to realize the incredible journey it has been bootstrapping our way from just two of us founders to over 55 employees in Toronto & Berlin, and I’ve learned tons of lessons along the way.
As an incredibly young software engineer, you don’t realize the daunting task in front of you when you embark on building a startup. What seems like a fun side-project will completely change you and turn your life upside down in a journey to build something amazing. I’ve gone through the ups of seeing our product become widely successful worldwide, and the downs of the arduous amount of stress and burnout when you have no cash and need to argue product decisions vs risking not paying out salary.
Two of the biggest lessons I’ve learned through this experience has been how to really manage people in a startup and how to build the best engineering teams and code when you yourself don’t have the experience.
On learning to manage people and culture in a startup
As a green executive who had no real work experience aside from a few internships, I will be the first to admit I had extremely idealistic views on how a company should run. Make work all about fun and games, relax and take it easy, creativity will just flow into creating a good product and let people do whatever they want! While these are ideals we should always strive for, they tend to fall apart as soon as the team hits a few bumps.
Startups in nature are hostile environments. It is literally about the life and death of a belief that the early team holds dear. Hard decisions need to be made and they play an immense role in how the company functions down the line. ‘Playing nice’ is counterproductive to this. Apart from the founders, employees don’t have the same drive and insight into thinking about the consequences as someone who has been living and breathing every aspect of the business. While you need to trust the word of all of your employees, agreeing for the sake of keeping an idealistic culture will backfire on the growth of the company.
As best said on http://qr.ae/meyaK :
Don’t expend extra cognitive load on making what you say agreeable or considerate, because you need to spend that brainpower on figuring out the truth, since getting the truth wrong can result in the death of your startup… Ultimately, this can only be done in the same way that every successful relationship does it: maintain respect while still being brutally honest.
This took me a while to wrap my head around and it’s something I’m still working on. I initially felt I either have to make everyone agree or instead just do it myself but this held us back in the reducing our speed of delivery and reducing delegation of responsibility / ownership respectively.
On building the best tech when you’ve never seen it be done
You Know Nothing.
The best part of being a green executive is admitting you know nothing and seeking to build knowledge from only the best avenues. If you ever assume you know more than nothing, your ego will surely get in the way of success. Even after 6 years, I approach every argument assuming I am wrong and hoping that I will learn something from the other individual — I strongly believe that this is how we should approach every argument.
So if you know nothing, how do you learn?
Immediately find a senior engineer to learn from (or make them your first hire in our case). Yes they may not know how to use Mongo or Node but they’ve been practicing the art of programming for years and they have valuable war stories. Stop spending time with your college buddies and spend more time with real people who have seen it and done it. It will accelerate your software engineering maturity immensely.
Find your engineering values and align them with other companies you can learn from. See how they do things. Talk with their engineers. Feed yourself with their learning and take in as much as you can. What you deem as being important will naturally flow into your code and consequently into the culture of your engineering team. So find solid principles to base your values on.
Read, Talk, Watch, Learn. Spend at least 30% (arbitrary stat of the day) of your day reading and learning about everything. I would generally spend an hour or two between work hours and when I was burnt-out creatively and couldn’t code any longer, I would read as much as I could from 6 PM until midnight when I fell asleep. Throw yourself into the deep-end on portions and areas of the industry that you know nothing about.
I attended Velocity Conference without knowing anything about server orchestration, web performance, logging, monitoring, etc and it was an incredibly eye opening experience. Even after the event, I still was completely lost but by immersing myself in that space, I knew where I should start looking to understand how to lead the appropriate infrastructure changes we needed.
And The Single Most Important Lesson?
Explicitness
It’s taken me 5 years to realize how important explicitness is in building a startup. As much as you may think you’re wrong in your decisions and don’t want to forever embed it into the future, as much as you may be busy doing other things, make absolute sure that you are explicit in everything that you do and document it well.
Why do you align to certain values? Write it down. Why did you pick certain tech? Write it down. Do you think someone should own this new project? Tell them explicitly! Things like a “manager’s blueprint” are great examples of being explicit.
I would constantly bring up discussions of performance / testing / deployment practices and no one would ever take action. I just assumed that no one actually cared and would take it on myself to accomplish these tasks. It took me a while to realize that I just wasn’t being very clear and explicit on what people’s responsibilities were. Again no one is as invested as the founders, don’t expect them to work like founders either. Make the path clear for your team through explicitness and your team will do amazing things!
