I became a CTO accidentally. After I had flunked a startup, I was wandering and wondering for about six months. Meanwhile, I was also experimenting with a few ideas for my next venture.
Sameer Jain, CEO of Net Solutions, a boutique IT services company, asked me to build a project management office on a part time basis. That seemed a nice little challenge and I took it. Few months into the engagement, he asked me to become a CTO. So I did.
Life is what happens to you when you're busy making other plans. I have been a CTO for about a year now. Becoming a CTO was never one of my goals, yet, I enjoyed the last year because of the team around me.
I have learnt a lot over the last year. If I had to summarize all my learning in the last year, it would be:
What one can accomplish alone is limited; what one may achieve by leveraging the ability of many is almost unlimited.
In this article I am going to elaborate what each word in my job title means to me. I will also outline a few actionable insights that you can practise in order to become a better CTO.
As an officer, a CTO has to be proactive and accountable, much like every other employee.
How do these traits manifest in day-to-day life?
Proactive employees coordinate and collaborate to create value for themselves and the company. At a strategic level, they grok the "why" and "what". They then figure out "how" and go do it.
They are the Rowans who can take the letter to Garcia.
They don't excuse themselves from accountability to be proactive. We can bypass processes and systems here and there to succeed in one or two initiatives. That’s not the way one should build a company.
Proactive and accountable officers build institutions; they don't become indispensable superstars. If a CTO is not a proactive and an accountable officer, that company will become stagnant and eventually slide down.
This is an essential attribute of the job. Other two are just adorning attributes.
Much like the letter ’T’, a CTO should have expertise in one or two technology areas but develop broad understanding of other areas of technology and business.
I can code in Python, Go lang, and Node.js fairly fast; but I can appreciate the strengths and weakness of PHP, Java, and few other languages; I have deep understanding of customer relationship management domain, but understand e-commerce, healthcare, and publishing. This is true even in the aspects of business. I am a technology guy, but strive to understand marketing and sales.
When you have expertise in a certain domain, you can identify trends and prepare the company to take advantage of the coming wave.
As an example, we started experimenting with chatbots last year, when it was still nascent. We created a dedicated team and built an unofficial Facebook bot for Narendra Modi, the PM of India. Now it has become a differentiator for us.
As I mentioned in the previous point, a CTO should build a strong institution with other technologists. This isn't a one-day or a short-term activity. It is almost a daily exercise.
Building an institution means forming a team (either from within the company or by recruiting), setting the agenda, following up frequently, and correcting the course if required. This is easier to write than making it real. That's a challenge I struggle daily.
A CTO should be technology agnostic. This doesn't mean I don't have preference. It just means that I don't pick up a hammer and view everything as a nail. Since I'm a CTO of an IT Services company, I should choose the suitable tech stack for the client rather than force-fitting every project into my preferred stack.
As an introvert, this is the toughest part of the job; but this is also the area I have grown a lot this year.
There are three aspects to "chief" component of the CTO.
Staring at failure all the time
As a chief, you are always making a bet - Identifying trends, recruiting, and building a certain competence are all bets. Betting on a trend is an opportunity cost. If you bet on wrong trends, or you don't build competence quick enough, then the company loses.
Same goes for recruiting. Building a competent technology team is a challenging job in a Tier-II city (like Chandigarh) than in a Tier-I city (like Bangalore). If you bet on wrong hires, the team suffers. You go through an emotional roller-coaster correcting hiring mistakes.
Despite the odds, you have to learn to move forward.
Grooming a team
"If you want to go fast, go alone. If you want to go far, go together", says an African proverb. Many "chiefs" expect all their employees and teammates to be Rowans who can take the letter to Garcias overcoming all challenges, but they won't invest their time and resources to groom a Rowan or when they find one they wouldn't care to take care of them. If you want to go far, you need company of competent people. Competent people are ever in demand; they stay if you provide an ideal job environment. Stimulating work, appreciative boss, pleasant peers, and competitive salary are just few aspects that make a job loveable.
There are certain specific ways I strive to build my team.
I take a walk with members of my team at least once a quarter. We discuss their aspirations, their achievements, and their goals. I ensure I give specific feedback rather than generic ones. Specific feedback helps a person to grow; generic feedbacks are from lazy minds and thus useless. Even when I appreciate, I ensure to appreciate for a specific event or contribution. Talking of appreciations, not all appreciation has to be monetary but all appreciation can't be just words. Appreciation has to manifest as one or more of salary, promotion, benefits, or gifts or other aspects of the ideal job I talked about in the above para.
We started Wednesday Wisdom sessions. My team gathers for one hour a week. One of us presents a relevant topic and then we discuss more about the topic. We talk about ways to build 12-factor apps, implementing Devops, identifying and correcting OWASP top 10 vulnerabilities and so on. We also share some specific work we did in a project, such as DB optimisation. Technology work is predominantly knowledge work. Sharing of knowledge benefits the company as well as the individuals.
As a CTO, you are at once an evangelist and a sales engineer. In both roles, you need skills of a master story-teller.
When you identify a trend, you need to convince the team that it is a good bet for the company and for them. It isn't going to happen over a single talk. They aren't going to follow, because you, a chief, said it. They will have to feel it. If they "feel" it, they will take it further, else it will always be drudgery for you.
In the same way, you need to sell the new trend. You need to sell to your own sales team. They might dismiss it as a passing fad. If you believe the trend is a wave your company can ride on, then it is upto you to sell internally and externally.
If you want to get better at talking to your team members, here is an unconventional book recommendation: How to Talk So Kids Will Listen & Listen So Kids Will Talk. Read it, practice it. You will become a better parent and a better leader.
I always thought that changing the world is not for me. I was happy coding and blogging in my own corner of the world. But then when I am a CTO, I’m changing the world, at the least the world of those people around me in my own small way. I'm grateful for that privilege.
Hope you enjoyed reading this article. Please feel free to leave a comment or ask any questions you may have.
About the author: Joseph Jude is a chief technology officer of Net Solutions, a boutique IT services company in Chandigarh, India. He is always interested in the intersection of technology, psychology, and story telling. He blogs regularly at https://jjude.com.
A very interesting story. I completely agree with the following statement:
A CTO should be technology agnostic. This doesn't mean I don't have a preference. It just means that I don't pick up a hammer and view everything as a nail.
A CTO should always strive to have an understanding of different tech stacks, paradigms etc. When it comes to real-world projects, a CTO should carefully evaluate every possible detail and choose the right stack.
IMO, imposing their preferred stack onto every project is the most dangerous thing a CTO can do.