The CTO’s Guide: Welcome to a World of Responsibilities

17 min readSep 23, 2024

When you transition into a CTO role for the first time, your world changes. You have a bunch of new responsibilities and new things that you are supposed to worry about. In this article, I want to help you make sense of that new world.

I should note that I am writing this from the perspective of a startup CTO rather than a CTO in a large enterprise — but many of the lessons here should apply regardless. A CTO might also be a co-founder, in which case you will have a bunch of additional things to worry about. This article is about wearing the CTO hat, not the co-founder hat.

The CTO’s Journey

I am also going to venture a guess (albeit an educated guess) that the career trajectory that led you to a CTO role started with some kind of specialist role — perhaps as a software engineer working on a specific tech stack (e.g. Java). Early on in your career, your focus was narrow — you had a very particular set of responsibilities all focussed around this one thing that you were expected to become really good at (e.g. Java, again). At some point, you probably moved to a more senior technical role — senior developer, architect, or something else — and when that happened, your area of expertise had to grow. The hard technical skills you started with were still relevant, but things like architecture patterns, knowledge of databases, networks and communication protocols, and other concepts also started to feature. You would also have had to learn how to understand the business domain within which you operate much better (e.g. if you develop insurance systems, you have to learn how the insurance industry works). In other words, your world became broader.

Then, at some point, you probably transitioned into a leadership or managerial role of some sort. When this happened, your world kept on expanding — in addition to a broad range of technical skills (which remain relevant, although you might not apply them every day), you now had to learn how to lead and manage people and projects. This was yet another set of skills you had to learn and context you had to understand.

It all comes back to the idea of “T-shaped” people (or the “generalizing specialist”) — a versatile skillset helps you to succeed in your career. As you make your way up the rungs of the career ladder, every rung requires a range of new skills, new context to understand, and new stakeholders to engage with. The further up the ladder you go, the broader the range of things you need to understand and/or worry about*.

* This does not mean sheer terror — but there is probably always going to be something sitting in the back of your mind, bugging you. That is a good thing; it means you are paying attention.

The CTO’s Responsibilities

As an individual contributor in a technical team, you have a defined set of responsibilities that often come back to technical/delivery related goals. In other words, your job is focused on functional components — you build software that meets some kind of business need, you build CI/CD pipelines, or you design systems. Ultimately, you do something that produces some kind of defined, usable outcome for someone else (whether that’s a customer or another developer).

As a CTO, your context suddenly expands well beyond the functional elements of delivering something that has value to someone. That is still important, but it is only a small part of what is important. As an executive, you are no longer just responsible for working in your organization; you become responsible for working on it. Your job is to build an organization that can build systems; not to build systems.

Let us look at what that entails. Of course, I cannot give you all the answers, as that is often very subjective and dependent on your context. I can, however, offer some guidance as to the questions you should be asking. If your organization is larger, you might have an engineering lead, CIO, CISO, or CPO to worry about some of these.

Also, you cannot worry about all things equally at all times — there are simply not enough hours in the day. Context dictates what is important. For example, if you are building your first MVP and you do not have any customers yet, you should worry about performance — but not right now.

People

The technology team is your responsibility now, but it is no longer exclusively your team. You are no longer primarily a technologist, but an executive. You have to build and manage a team that has the right capabilities and the right support to deliver. This has a couple of different elements.

Hiring

What skills do you need in your teams? If you are building a team, you need to understand what you expect the team to be able to do? Also, keep in mind both leadership skills and tech skills — you need to have both in your teams.
Where do you find candidates? You can find candidates via recruitment agencies, direct ads, LinkedIn, or referrals — each of these options have a cost associated with them. Referrals are great (good people tend to know good people), but for this to work, you need to create an environment that people are proud of, and that they want to share with their friends.
How do you screen candidates? Remember, if you interview, you take time away from other work for people who are often quite senior — there is a cost associated with that. You need to have an efficient screening process.
What salaries and benefits can/will you offer? As a CTO, you might not always have the power to directly influence this — but you have to be able to create a compelling employee value proposition (EVP) to attract the right people.

Growth & retention

How do you ensure you build the skills you need? If you cannot hire new people, you have to upskill the ones you have already. Before you can blindly send everyone on training, you need to understand what skills you need — and then base your training and development plan on that. Training does not necessarily have to be expensive — if your training budget is limited, you could curate a list of Udemy courses for your team, for example.
How do you stay close to your teams? One-on-ones with your direct reports, and if need be, with the layer below them, allow you to keep an ear to the ground. As your role becomes more strategic, you will naturally lose touch with some of the details — but you should not be so far removed that you end up in an ivory tower.
How do you address team performance issues? If anyone is not performing at the level they should, the hard conversations become your problem. Do not ever sit on it and hope it goes away. If someone has a performance review once every 6–12 months, and that is the first time they hear that there is an issue with their performance, you are failing as a leader (see the additional resources at the end of the article for a great book to help with this — Radical Candor by Kim Scott).
How do you set expectations? If you want people to thrive, they need to know what is expected of them. This does not mean you need formal, rigid KPIs — you can decide what is appropriate within your context, but make sure people know what you expect.
What kind of culture are you creating? As CTO, you set the tone for the culture of the technology teams within your company. Ask yourself what kind of culture you want, and how to create it? Personally, the kind of culture I strive for is one where transparency and learning are encouraged — people should not be terrified of making mistakes, and when they do, they should be able to discuss them and learn from them.

Process

Here, we come back to running a department in your organization. Processes should enable people to do their best work — and since you are not the one doing all the work yourself, it is a good idea to seek input from the people who are. Once you have defined your processes, make sure they are readily available to anyone who needs to understand them. Documentation is important.

Development and the Software Development Lifecycle (SDLC)

What your delivery process and how do you define success? In modern organizations, this often tends to be some form of Agile. However, “we are Agile” is a poor process definition. Ask yourself why you follow a particular process. Standups, for example, have become ubiquitous. However, standups are (IMO) just one of many ways of collaborating — so do not run daily standups only because a process says you should. If you can find a better way of working, do it.
What is your “definition of done”? This relates to setting expectations — if there is an agreed standard, your teams know what is expected of them and it helps to get everyone onto the same page.

Quality Assurance

How do you test and what is your QA strategy? You have to decide whether you focus on manual testing or automation. If you have a large and complex application with a multitude of functions and permutations, a strategy focussed on automation makes sense (which takes us back to hiring/training for the right skills).
Which tools do you use? The tooling you use plays a role not only in supporting your team, but also, as CTO, you need to make sure tools are appropriate. This means that they conform to whatever industry standards are applicable to you, and that they strike the right balance between cost and benefits.
How many bugs are in your application and are they increasing or decreasing? You should have a view of the number of bugs in your application, and whether they are increasing or decreasing. If bugs are decreasing, that is good. If they are increasing, you will have to investigate and figure out why. They key thing is here is that you need find and track the right metrics.

Continuous Integration & Continuous Deployment

What CI/CD stack will you use? Make sure the stack is aligned with the skills you have, and that it is appropriate to your organization. Do not overcomplicate it and get distracted by shiny toys.
What is your code branching strategy? Make sure your branching strategy aligns with your needs, and that it does not hamper your development team or cause unnecessary pain (e.g. long-lived feature branches that result in painful merges).
How often do you deploy? If you want frequent deployment cycles, do you have the technology to enable that? If not, set the goal (e.g. “deploy once per month”) and then define a plan that will allow you to do that.
How do you ensure that deployments are successful, and if not, how do you roll back? You cannot assume that everything will always go well — you also have to prepare for the scenario where it does not. Hope is not a strategy.

Operations

What monitoring tools will you use and who is responsible for monitoring? If you run a production system, you are responsible for what it does. If it goes down, there can be real impact to your customers, so you have to be able to detect issues quickly and respond to them.
Who is responsible for support and how do you meet your SLA? If your monitoring tools do detect any issues or if a customer contacts you, who deals with it? This needs to be a well-defined process — you do not want to risk a scenario where everyone assumes someone else will do it (and thus, no one does) or where you have multiple people stepping on each other’s toes.

Technology

As the Chief Technology Officer, technology is what sets you apart from your peers in the executive team. Your technology decisions, therefore, should be appropriate and make sense within a business context. Technology is a means to an end — it exists in an organization to serve a business purpose.

Stack

What technology stack will you use, and why? As the CTO, you are responsible for technology decisions — including your tech stack. Again, easy to get distracted by the latest and the greatest shiny new tools and frameworks, but make sure you use what is appropriate for your organization. Bleeding-edge tools have not necessarily been proven in the industry and they may not last, so if you use them, make a conscious decision and understand the trade-offs.
How do you keep your stack up to date? New versions of software are released all the time, and the further behind you are, the harder the upgrade path becomes. Make sure you have a strategy for managing version updates.

Architecture

What architectural styles of patterns will you use, and why? Again, technical decision-making authority sits with you. Architectural decisions are a huge responsibility, simply because they become very difficult to change after the fact. A library can be replaced with some effort, but a fundamental architecture change could mean almost a complete rewrite. Architectural styles have trade-offs, e.g. microservices are scalable, but introduce complexity. Make sure you choose wisely and that you consider the context and the trade-offs. If you want scalability, you choose a particular style. For performance, you might choose another. Mark Richards and Neal Ford have a great guide to help with these decisions.

Infrastructure

Where do you deploy your software? You have options of either on-premises or cloud-based deployments. Cloud allows for relatively easy scalability and converts what would’ve been significant upfront capital expenditure (“CapEx”) to operational expenditure (“OpEx”). However, if you deploy do the cloud, you have to consider the implications — will your software ever run in countries where regulatory constraints prevent you from running in the cloud (e.g. financial services systems in some African countries)? Also, consider the difference between “cloud native” solutions that run on underlying tools like K8s that you can move from one cloud provider to another with relative ease vs. proprietary tools from specific vendors (e.g. AWS Lambdas). The latter can add significant benefit and speed up your development and delivery process, but with the trade-off that migration to another cloud provider becomes harder.
What is your disaster recovery (DR) strategy? Things can go wrong — systems go down, data is lost or corrupted, someone runs a SQL query without a WHERE clause on production. When this happens, as CTO, you need to make sure your organization is in a position to deal with it. You need to define both your recovery point objective (RPO — how much data you will lose) and your recovery time objective (RTO — how long it will take to get your systems back online). You have a variety of options, again with trade-offs — a simple backup/restore DR strategy will be relatively cheap but risk losing more data than running an active/active environment with immediate fail-over to DR, but at much higher cost. As part of this, make sure that you have a strategy for running DR tests and that you have the right data to back it up.
How often do you deploy? If you want frequent deployment cycles, do you have the technology to enable that? If not, set the goal (e.g. “deploy once per month”) and then define a plan that will allow you to do that.
How quickly can you spin up a new environment? Using infrastructure as code (IaC) will allow you to spin up new environments fairly quickly, while servers that are manually (and painstakingly) configured are a lot harder to replicate or replace. This is the DevOps concept of cattle vs. pets.

Technical Debt

How much technical debt do you have? Technical debt refers decisions that we make to speed up delivery over the short-term. This is another key metric. Technical debt is not necessarily a bad thing — but it’s a trade-off and you should treat it as “debt” that needs to be paid, before it comes back to bite you. You might incur some technical debt in order to deliver an MVP — maybe some shortcuts around performance that will not be noticeable with a smaller number of users. However, you have to be deliberate about the decision — record it and prioritize addressing it, before you have 100 000 users and a non-performant system.

Regulation and Compliance

Some industries, such as financial services or healthcare, are more heavily regulated than others. As CTO, it is your responsibility to make sure that your systems play by the rules.

Data

What data will you store and how will that data be accessed? From an architecture perspective, this speaks to separating your operational and analytical data stores — if you run analytics on transactional systems, you risk degraded performance. From a regulatory perspective, there are certain laws that you have to abide by — this includes things like the Protection of Personal Information Act (POPIA) in South Africa, or the GDPR in other countries. If you get this wrong, your organization can find itself in hot water. Depending on your industry, other regulations might apply as well (e.g. HIPAA in healthcare, financial services regulation, etc.).

Standards

What standards are you expected to abide by, and do your processes align with that? If you engage with certain large enterprises as potential customers, they might require you to be compliant with standards like ISO27001. As CTO, you need to make sure that you align to the standard if you ever want to get certified.

Cybersecurity

How are your applications secured? From an application-design perspective, make sure that data in your system is appropriately locked down — some data might be publicly accessible, while other endpoints will require that users be authenticated and authorized. This could take the form of OAuth or some other mechanism. Things to look out for include Broken Object-Level Authorization and SQL Injection vulnerabilities.
How is your infrastructure secured? If you run in the cloud, make sure you have multi-factor authentication enabled, that you apply the Principle of Least Privilege, and that you have appropriate logging and monitoring in place. If an attacker gains access to your administrator portal, they can wreak havoc. Your cloud provider will also have tooling to help you monitor compliance with best practices (e.g. the Azure Advisor or AWS Trusted Advisor).
How are backups protected? The fact that you have backups in place does not mean that it is sufficient — if your backups are stored in the same place as your primary data store and an attacker gains access, they can destroy both the source data and the backups.
How is your network secured? This applies where you are on-premises or in the cloud, and it does not speak to protecting data only — a DDoS attack can render your application unusable.
How do you manage your external dependencies? Nowadays, your code is not something that exists in isolation — it is built on layers upon layers of tools and frameworks produced by third parties. That is great, in the sense that it allows us to speed up our development cycles because we do not have to reinvent the wheel. It is not great in the sense that you do not always know what is sitting in your codebase — an outdated library with a critical vulnerability or a piece of malicious code that someone snuck into a seemingly useful tool. Make sure that you have the right tooling in place to alert you if your dependencies introduce risk.

Business

As an executive, you play a business role — this means that you need to develop and understanding of both finance and strategy. This is where things really deviate from what you were used to in a technology-specific role.

Finance

How efficient are your IT operations? As a CTO, expect to spend time with your CFO. In order to communicate effectively and bridge the gap between their world and yours, you have to grasp some finance terminology, like return on investment (ROI) — what are you getting for the money you are spending? Make sure your investment in tools is appropriate, and that your software development effort is going to the right things — spending weeks to optimize a minor feature is a poor use of time (and money).
Is your infrastructure spend optimized? Your cloud provider (if you are running in the cloud) will likely offer recommendations on cost optimization — make sure to review these and see where opportunities exist for cost-savings. If you use virtual machines on Azure or AWS, for example, reserved instances can save you 30%+ over a year at the click of a few buttons. Also, consider actual resource utilization and whether your infrastructure is appropriately sized or overprovisioned. Given the elasticity of the cloud, it is relatively easy to scale it down and ramp it up again when the need arises.
What are you investing in? If you are building a product, such as a SaaS solution, that product is an asset to your company. As such, it can be capitalized on your balance sheet. If you are doing work for customers and running software for them, that is an expense that is part of your cost of goods sold (COGS). I am not a CFO, so I am not going to go into deep detail here — but, what this highlights is that you should be able to show where your time (and your team’s time) is going, as that has a monetary value. I know timesheets are frustrating but look beyond the process at the value it can add.

Strategy

What does your business strategy look like, and how does your technology roadmap support that? As CTO, you are probably not responsible for defining the strategy of your entire organization. However, you should have a seat at the table and a voice in the process. Your technology roadmap should then be aligned with the strategy. If the strategy focused on breaking into new markets, how do you make sure that your application can be used in those geographies (back to the point around regulators and cloud-friendliness)? If your strategy is to capture more of an existing market and triple your user volumes, how do you make sure your system’s performance will be adequate?

While this is a whole bunch of questions, it is not an exhaustive list — feel free to add anything else that applies in your context

Summary

Whether you are a newly-promoted CTO or someone who has been in the role for a while, your role will be broad and span across a variety of concerns: people, process, technology, regulation and compliance, and business. In order to succeed as a CTO, you need to pay attention to all of these — exactly how much attention is something that you will have to determine based on your own unique context.

I hope, nonetheless, that I have helped you to ask the right questions and to consider the many different dimensions of the CTO role.

Please share your thoughts in the comments — what other lessons or questions did I miss?