As a first-time CTO, it is important to realise you are primarily responsible for everything technology in your company and your number one responsibility is to enable your company win, using technology.
Your job will be very different at different times, dependent on the stage that your company is at. It has helped me to outline what the possible roles are and it is by no means exhaustive. I like to see it as generally divided into 2: Individual Contributor — IC and Management.
When starting out or when your company is just being formed (assuming you are a founding team member), you will primarily be an individual contributor and that means different things at different times: one term that best describes it is a Full-stack Developer(frontend, Backend and IT Ops — Some call it DevOps).
Assuming your company is successful enough and achieves Product-market fit, you need to hire more folks, meaning you’d start to play the role of a technical lead. You’d still be very much hands-on but in addition, you will also be responsible for other team members and that includes recruiting, mentoring and being a technical architect on the team, leading software design sessions.
As you grow, you’d get to the point where you would function more as an Engineering manager. In this role, you’d have one or more Tech leads reporting to you. I’ll dwell on this a bit more. At this capacity you’d primarily be responsible for:
- Project /Product Management (Dependent on if you have a dedicated product Manager) and some of what you'd would be doing are:
- Requirement Elicitation/Customer Development
- Aspects of Software Architecture in collaboration with Tech leads.
- Acting as Scrum Master
- Performance Management
- Defining Career Ladders
- Carrying out performance reviews.
- Mentorship — Holding 1-on-1s, Career Improvement plans.
- Communication — Communicate up, Down and Across.
- And an Individual Contributor, E.g Devops/QA dependent on if you have a dedicated resource.
As with most things in this role, you are to provide guidance without micromanaging. And as a manager, you should be aware of your management style. I favour Task-Relevant Maturity(TRM) or what some people call situational leadership where you either show and tell; play a more communicative or delegative role dependent on how mature your report is with respect to the task at hand. It is important to realise that TRM varies with task. So it has nothing to do with how great the person is. Your goal with TRM is to get to the point where you are able to delegate. That’s where you get the greatest leverage. And it’s important to always know the line between Delegation and Abdication. A book I found really helpful is High Output Management by the legendary Andy Grove.
As an Engineering Manager you need to be looking for areas of greatest leverage and hire or delegate out less-leverage areas as much as possible.
You will not start out being great at all these areas. So you need to go out of your way to read, take courses, learn and get feedback on your progress as these are typically different from what is required of a Software Engineer who is an individual contributor. But I think, if you are a great software engineer and you are interested in people management, you will be great at this too. Why do I think so? Because a lot of the Software Engineering skills are transferrable; the greatest of which is your ability to continuously learn. In this role, you realise what you don’t know and go out of your way to deliberately learn. If you were able to really learn and become great at Software Engineering, then I believe you could be great this too.
One thing I find could be painful, is when for any reason you want to contribute individually as an Engineer in a project, and you realise that your Engineering skills may have become somewhat 'rusty'. That may not be a problem, depending on what your career plans are. But if you are looking to be able to start up a company not too long in the future as a CTO, then you may need to stay relevant there as well. And one way I have found to stay relevant is to have a side project. Your side project at the minimum, should be relevant to the technology stack your company uses if you do not have hands-on experience in it, or one you think your company may benefit from in the not-so-distant future.
Then there's VP Engineering, Director of Engineering and so on, dependent on the scale your company. Other responsibilities of a CTO that may not look urgent, but are extremely important are Business Continuity Planning, IT Security and Compliance.
In conclusion, I find that a lot of books not necessarily related to any technology have been very helpful. Some of the most impactful ones include:
- Peopleware: Productive People and Teams by Tom Demarco
- The Mythical Man-month by Frederick Brooks (I’ve had Hard Copy versions of this and Peopleware since 2013)
- The Manager’s Path by Camille Fournier
- High Output Management by Andy Grove
- The Hard Things About Hard Things by Ben Horowitz
There are several other books too, especially if you will play an IT Ops role or have an IT Ops staff report to you as part of your core CTO Responsibilities.
I’ll like to learn about the technical management/management books that have helped you, so I could also learn from them.
Yours in the business of creating and capturing value using technology :)