Ask HN: CTOs/VPS of Engg, what lessons you wish you'd known before? I posted this earlier on Saturday, but it seems that CTOs don't hang around here over weekends. Making second attempt. |
Ask HN: CTOs/VPS of Engg, what lessons you wish you'd known before? I posted this earlier on Saturday, but it seems that CTOs don't hang around here over weekends. Making second attempt. |
Team level - Supporting individual engineers working collectively to solve a relatively narrow set of business and technical problems. Lots of short term focus.
Org level - Supporting multiple teams of engineers solve bigger, hairier problems and learn to both identify and solve their own problems. More long term focus.
Exec level - Represent the needs and capabilities of the every engineer at the company, and be a strong advocate for them. Support the needs of the larger business and strategy. Super long term focus.
Depending on the company, there are some half steps in between each level, and you may have responsibilities that span multiple levels.
The most important thing to evaluate (and constantly re-evaluate) is at what level you are currently working at and what level you need to be working at for the good of the company. Hire accordingly.
If you find yourself working at all three levels, it won’t be sustainable and the payoff simply won’t be worth it in the end.
Some things that come to mind while thinking about this:
- Work on having an overview of the product + market you are building, but also be able to dive into the nitty gritty details
- Never forget that in the end you work for the customer, not for the engineers in your team, and find the right balance between technical debt, building technical amazing solution and feature building
- In the best moments you can combine those things; built a great solution that is future proof, uses the best technologies and provides great value to customers, but that's definitely not a given, and one of the skills I still try to excel in every day
- To capture market share, sometimes you don't need the most fancy technical solution, only a solution that is good enough, and a solution that competitors do not have (yet) but you are earlier on the market with it. It might go against your engineering heart to be so pragmatic, but it is what is
- Talk with customers wherever you can to keep you focused on the market, and find the balance between what the market wants, and what technology can provide
- The role of a CTO differs widely. So figure out quick what your take on the role is and how you can provide best value to the company. Are you the technical visionary that writes blogs, present webinars etc? The architect that builds the core of your product? The team builder that can built up the best team?
- The role also changes enormously depending of the size of the company and growth over time, so if you're feeling great about the current position, cherish that as it might change soon :)
I am fairly successful (!?) (though the perspective is my own and satisfied with the mix of life I'm into and whatever I'm!) in my career and have enjoyed a good and competent technical team with me all the time.
I mentor my team mostly from ground-up and have found that anyone can become a fantastic and a dependable competent resource provided enough freedom and directions. Also worked as a startup coach. Been into startups since early 2000s
Obviously, this handle is my pseudonym and not my real name. Extremely sorry for that as I value privacy more than anything and people call me that I'm a paranoid. I'm still not in a position to divulge much personally.
I'll try to list down common issues faced and lessons learnt by startup a CTO as much possible.
- Having to deal with a non-technical founder is very hard
- Technical work could be very challenging if you are one of the few who takes cares of many things or try to play multiple roles
- Getting competent resources could prove to be a very tough task if you are in a third world country. (I'm not talking about the Bay Area types)
- Have a process right from day one. Do everything in a documented manner and work like what will happen if you get run over by a truck (it could happen to anyone on the team). Then what?
- Technical stack identification for an initial MVP will take time until one gets it right considering a 360 degree view covering all the aspects
- Having business knowledge / outlook is a must and without that, however technical one could be, he/she will not bring value on a long run. There could always be a better one who will replace you
- Strike the deal from the day one. There is no free lunch. Negotiate hard and properly for what you are worth. No slack or compromise on those aspects
- There are no shortcuts for anything
- Everyday is a learning day
- There are newer ways of doing things which gets into the mainstream and some might even come from you!
- Keeping the team together and motivated is an extremely tough thing to do if you are in a non-commercial decision making role. Try to vest some powers towards that direction if you are joining a team (not as a part of core founding / decision making team, but just playing a CTO / VP of Tech or something akin to it)
- Pleasing everyone is not possible all the time. Learn to cope with frustrations and take decisions based on long term goals
- Never get driven by emotions
- Be ready to adopt to any situation, and be adept at many things. Learn, learn and learn and put to use
- Have a birds eye view on everything and have the vision of an ant on specifics (up close!)
There is much more to write (it's my part time passion and mostly use it for internal communications, mentoring and teaching), but seriously considering it towards a book of experience in (near?) future.
Though the above is incomplete in many ways, would like to hear the thoughts / views from other technical people. Thanks for reading so far!