There has been a lot of hand-wringing and discussions about what a CTO does on the interwebs. Does a CTO write code? Does a CTO’s calendar look like it is on the maker’s or the manager’s schedule? Does a CTO sit in on interviews? And so on.
Let me explain. A CTO is not expected to write code, per se, but is expected to solve the business need using technology. For some businesses, technology is the differentiator, while in others, it is an enabler. For example, technology is a differentiator for a company like Hasura or Uber. But for companies like Atlassian, HomeDepot or Walmart, technology is an enabler. As you can see, there are big and small companies in both these categories.
So, in an organization where technology is a differentiator, I believe the CTO should have a hand in creating the product. On the other hand, where technology is an enabler, the CTO should actively engage the business stakeholders to maximize the impact of technology. So, it is sufficient to take a hands-off perspective. That said, a CTO who has never written code or is out of their groove will have to base their judgement on second-hand information. It will be fatal in a technology-differentiated organization.
Broadly, the CTO has to do the following:
- Decide on what to build and what to buy
- Grow the team
- Establish a culture of learning
- Balance product and tech priorities
- Act as an arbiter for architecture decisions
- Setup software delivery processes
Making Build <—> Buy decisions
What I cannot create, I do not understand. — Richard Feynman
One of the primary things that the CTO does is make Build<->Buy decisions.
Should I build this piece of technology in-house, or use an existing piece of hosted or open source technology? What would be the impact on timelines? What would it cost to license and operate? Should I run the ElasticSearch cluster myself? Or should I use AWS’s hosted service? Should I use AWS Cognito, deploy KeyCloak, or roll our own authentication?
Questions like these have a large impact on the architecture and operational plans. Depending on the size and maturity of the company, the answers to these questions might be different.
Growing the team
இதனை இதனால் இவன்முடிக்கும் என்றாய்ந்து அதனை அவன்கண் விடல் — Thirukkural 517
Figure out the best person who can get the job done, and get out of his way. — Tiruvalluvar, a Tamil poet
Hiring is an essential role of the CTO. As a CTO, you would have to hire people smarter than you. You might not able to hire the people with the skills you want outright. You might have to scout for agencies who can help you get things done the right way while you focus on your hiring pipeline. You also have to empower the people you hire to ensure that they do the right thing.
This means that you should be okay with letting people make decisions that you would not personally take and allowing them to fail. This is probably one of the hardest things that I had to learn. Not everything has to be done your way. Think of it as an exercise in humility.
Setting up a culture of learning
கற்றது கைமண் அளவு, கல்லாதது உலகளவு
What you’ve learnt is but a fistful of sand, what you are yet to learn is as big as the world. — Avvaiyar (Tamil Poet)
It is very easy in a fast-paced organization to use up people for the organization’s growth. Allowing the people to sharpen their skills as a routine exercise creates a sustainable and happy work environment. There are several tools that can be used. Lunch n’ learns, dedicated training programs, subscriptions to learning platforms, books, conferences and so on.
Leveraging such multiple resources helps create a team that not only keeps learning but also enjoys the journey of their growth. This will do magic for your team’s retention.
Balancing tech and product priorities
The problem with quick and dirty…is that dirty remains long after quick has been forgotten. — Steve C McConnell
I have seen organizations where there has been a very strong technology co-founder who focused on the minute details while letting the business fail. I have also seen companies where the developers are on an eternal death march since all the tech debts were left unaddressed and the product is held together with bubblegum and scotch tape. Most organizations that I met were somewhere in between.
As a CTO, you have to keep the business priorities first but also ensure that the tech debt is paid off in time. In a financial debt, you can pay off the interest if the principal creates more value for you than the interest payments. Similarly, if the tech debt enables the business to meet market needs and grow your revenues/users, you can pay off the tech debt before the inflexibility of your system stalls your growth. Tech debt is not a bad thing, if it enables you to move fast and break as little as possible.
Establishing software delivery processes
You can do agile or be agile. — Me (Vagmi Mudumbai) :-)
As a CTO, you will oversee the project management practices, CI/CD pipeline, QA, and DevOps/Site Reliability Engineering. Setting up these delivery processes and automation ensures that a business need can be quickly turned around to working software. The exact details of these will differ based on your business, your team’s knowledge and the environment in which you operate.
For some businesses, you can get away with hosting something on Heroku with a self-managed Kanban-style board. But for others, you would need a more involved setup where you’d have to coordinate across multiple projects and programs.
Architecture and System Design
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. — C.A.R.Hoare
These are some of the most talked about yet overlooked parts of the CTO journey. As an organization grows, its architecture needs to reflect the needs of the business. What might work for a startup with a few users may not be appropriate while the solution scales.
Case in point, one of our clients in the insurance telematics space started off by writing trip-related information to a PostgreSQL table. This worked fine until a point. But once the organization became successful, it needed another way to organize its data. We still used PostgreSQL but we lifted the data and shifted to multiple shared structures. We replaced the trip model with service calls to another microservice that was running out of band. We also set up message queues to process these asynchronously into aggregated tables. We reengineered the reporting dashboard queries to use this data. While all of these individual actions were entirely logical, it would not have made much sense to take on this complexity in the first version of the product.
A CTO can help identify what is essential vs accidental complexity and how that complexity should be addressed.
CTO-as-a-Service (CaaS)
In most successful organizations, the process of ensuring continued excellence can leave the CTO feeling overwhelmed. You are simultaneously pushing the limits with your differentiator while your competitors are catching up fast and have probably learned from your mistakes and are proceeding faster than you can innovate. In those cases, you need more ammunition. You need to grow your technology team and avail CTO services for different segments of your business.
Tarka Labs can be that ammunition. Our team specializes in providing CTO services. We will help your organization by helping you with all the concerns stated above. Drop us a line at hello@tarkalabs.com.
