…You produce software for some time. In most cases it even works.
Other developers tend to care about your opinion.
Damn, you even wear some fancy title like senior\principal\architect.
And here it is – suddenly you were offered to wear really posh title – CTO…
This is moment when real troubles get started.
I did mistakes by myself. I fought with others to prevent them from repeating of my past vicious moves.
And I wish list below appear every time I was about to make game changing decision.
A lot of challenges are awaiting for new CTO. How they can be avoided?
1. Claim-to-be-universal tools suck. Always.
Do not make assumption based on bright hello-world example at promo web site.
In your case – it would be necessary to have some tricky functionality that this mega-framework does not support by design.
2. Be suspicious to any black-box like solution that promise all and everything at no price.
Never-ever expect that you are aware of the deep technical details.
In production, during important demo or pitch – impossible cases tend to jump out regardless of claims from probabilistic theory.
Listen to your team – they are your experts who (should) know about tiny nuances about setup, implementations and limitations.
3. Start simple. Focus on creating _working_ prototype fast.
Forget about speed, scalability, cluster, gpu-computing or “best practices” declared by yet another guru.
In 99.99999 percents of cases you do not need load balancing or advanced caching strategy.
You will iterate if it necessary.
4. Trendy stuff sucks.
Do not waste your time in fighting with bugs of another pre-alpha release of some looks like promising tool.
New database engine \ fresh from research lab language \ trendy paradigm – should be out of your list of consideration.
You need get stuff done. That’s it.
Good old bullet-proof solution are your choice.
Especially if you and team have experience of delivering some product with it.
Otherwise, year later you will realize that your repositories contains complicated workarounds and dirty hacks in desperate efforts to build initial DSL.
5. Listen to your team.
Measure & prototype. Be open-minded for their approach for solution.
Do not abandon idea only because you are not author of it. Encourage them for think out of box (even if it mean be contradicted to your opinion).
6. Books are your friends.
Inspire your team to learn new things and professional growth. Make your habit to read every day – in long run it will make a huge difference.
Short articles from HN do not help you to build foundation of knowledge – it is just a tip of iceberg.
You never can be sure that you know enough – treat with suspicious any “undisputed” statements (and those who dare to make them).
7. Take it easy.
World of IT and software development is hilariously small.
You do not know whom you will be interviewed by next time.
Who will be contacted for additional reference.
All makes mistakes. Not everyone learn from them.
Avoid any illusions from QA department – in most cases software will not work as you expected in first version.
Positive vibes during stern fuck-ups is what makes our profession truly awesome and memorable.
Humor is your best way to deal with burnout, pressure and broken coffee machine.
Sprinkle usual working day of your team with few bits of laugh to remind everyone that programming is fun! 😀