I’m a CTO, over the past few years I’ve mostly been an interim CTO working in a mixture of part time and full time roles 3–6 months in length.
Often hiring managers don’t know exactly what to expect from a CTO or what a CTO actually does. This is totally understandable. They’re not technologists, their focus is usually on commercial matters.
I’ve decided to document here what I consider to be the key aspects of a CTO role to give non-tech folk a deeper understanding whist hopefully answering a common questions I hear.
My main considerations on starting a new role:
- Who does the CTO report to? Does their voice get a sufficient hearing at board level?
- Does the CTO ‘own’ the product?
- Is the team outsourced? and can I move it in-house?
- What level is the team at?
- Do I have the right people in place?
- Is it a greenfield or legacy codebase?
- Is the codebase well architected?
- What is the level of the technical debt?
- What processes, methodologies and practices are the team using?
- What’s the hosting situation?
- Is the app/infrastructure/codebase secure enough?
- Who is supporting the software 24 x 7?
- Is the language / framework right for the application?
Looking at this in more detail and ongoing:
Creating and managing your team
- Hiring & org structure, what the ideal team structure?
- When to hire Senior/Mid/Junior developers
- Do I need a test team? /Hiring a test team.
- Creating and maintaining a relationship with the developer community
- Should my team by made up of contract, permanent or mixed?
- What’s our policy on Remote working?
- Outsourcing & Offshoring staff, how to make this work if needed
- Creating and ensuring a good staff culture
- Empowering the team
- What working hours should we have?
- Staff appraisals & ongoing monitoring
- If B2B, How to we support a sales process (pre/post)
- Creating a technology strategy for the business
- Working with other teams: sales, marketing, finance, managing upwards etc
- Budgeting accounting & fundraising responsibilities (What involvement should a CTO have in a fundraising exercise?)
- Working with the board
- Management reporting
Methodologies and practices
- Assessing the current level of Agile implementation
- Implementing Scrum & XP e.g.
- Running Sprints / stand-ups / meetings / roles / training
- TDD/BDD — time consuming but productive (avoids technical debt)
- Pair Programming
- Outside In (design first)
- Buy don’t build
- Refactoring practices
- Code reviews
Product and Technology
Depending on the structure of the company, the product management and ownership may fall under the CTO’s purview.
- Product VS development team
- Does the product management / ownership sit under tech?
- How to work with a separate product team
- Scrum master VS product manager
- Creating/understanding users, Journeys and Wireframes (Oh My)
- Writing stories / features
- Working closely with the customer to iterate on the wireframes, stories and code releases
- Product design and user experience (UX)
- Creating and maintaining a product roadmap
- Creating a maintaining reports and business analytics
- Finding and implementing product management tools, software and web apps
- Technology implementation plan / roadmap
- Database and data structures, sourcing, input, strategy
What stack (language and framework)?
- Choosing a tech stack
- Moving stack
- Which modules, api’s third parties should we use?
- Software architecture
- Keeping third party software up to date
Hosting, Devops & Operations
- Where to host?
- Hosting internally VS Cloud hosting
- Security / security testing
- Continuous Integration / Deployment and source control
- Platform and application support (24 x 7?)
- Staff resourcing and training
Securing the application(s)
- secure design patterns in development
- auditing legacy codebases
Finally, I’m often asked to code as a CTO. Given all the responsibilities about, I don’t think it’s a good idea unless you’re part of a very small team that is unlikely to grow. In this case, I’d argue that you’re not actually a CTO. At the start, code reviews and sometimes pairing can be useful to give you a good feel for the codebase.