Your First 90 Days as a CTO - stop starting with the technology

Understanding the role

Over the years I've read countless articles about the first 90 days as a new CTO, and they almost always follow this same pattern:

1. Meet the team
2. Review the architecture
3. Create a roadmap
4. Win CTO of the year

I'd argue that's not the right starting point for success as a CTO - it stays in the senior engineer lane, and the CTO role is not just about improving engineering.

Most new CTOs spend their first 90 days understanding the technology. The successful ones spend their first 90 days understanding the business. I'd go so far as to say that a new CTO needs to first stop thinking like a senior engineer and start thinking like a business leader.

The part of the promotion nobody explains

There are many different routes to CTO - promotion, job change, or even being the technical founder of a growing startup who just wanted to build something great but then finds themselves with 100 employees and being responsible for things they know little about.

The point is, many CTOs land the job because they are excellent engineers and they start the role assuming they're now "just" the most senior engineer.

That means the first things they do revolve around engineering;

• An architecture review
• A technical debt review
• An analysis of cloud costs
• A process review
• etc

The problem with that is they're solving problems before they understand whether those problems matter. The framing of initiatives for an engineer is about the technology, the framing of initiatives for a good CTO is about the impact to the business, and to understand that, they need to understand the business and how impact is measured.

Forget the code for a minute - build relationships

Your responsibility as a CTO is to align engineering and technology to the goals of the company. Before you can think about the technology, you need to fully understand the operations, goals and objectives of the business and its customers. To put it extremely bluntly, you need to understand how the business makes money.

To understand that, you need to build relationships with the rest of the C-Suite, the product team, the sales team, support team, people team and finance team to name a few. Here's some examples of the relationships you need, why you need them, and what you need to learn from them to inform your initiatives and prioritisation.

CEO — where are we going?

The Chief Executive Officer (CEO) is usually the keeper of the vision. They know where the company is trying to get to, what opportunities they’re pursuing, what threats they’re worried about, and how they’re positioning the company in the market.

As CTO, your job isn’t just to understand the technology strategy - it’s to understand how the technology supports the company strategy. It's to realise the implementation of the vision from the CEO.

In the first few days, try to understand;

• What are the company's top priorities this year?
• What keeps the CEO awake at night?
• What does success look like in 12 months?
• What assumptions is the business making about growth?

Whilst those questions have little to do with engineering, you'd be surprised just how much technical prioritisation becomes obvious once you understand these answers.

CFO - How do we make money?

Build a solid dialogue with your Chief Financial Officer (CFO). You don't need to become an accountant, but you do need to understand key financial elements of the business. In the first week look for detail around topics like these;

• Where does revenue come from?
• Where is that money spent?
• What drives margin?
• What are the biggest costs in the business?
• How do investors and the board view performance?

Every technology decision you make eventually appears in a spreadsheet somewhere in the CFO's domain and the relationship with the CFO can help you understand if you're optimising initiatives for something that actually matters.

CRO - How do we sell?

I've always found that engineers and sales teams mix like oil and water - they rarely spend meaningful time together and often eye each other with borderline suspicion. The engineers think the sales team oversell promises, the sales team think the engineers underplay their own capabilities to deliver. Regardless it's a missed opportunity that mostly, these two teams rarely interact meaningfully.

You'll want a relationship with the Chief Revenue Officer (CRO) and the sales teams because they're going to give you useful info about what's happening with real customers to help inform your decisions on product and technical direction.

At the very least you'll want to understand early answers to questions such as;

• Why do customers buy our product/service?
• Why prospects don't buy?
• Which competitors keep appearing?
• Which features are helping deals to close?
• Which objections appear repeatedly?

You might discover extremely strong signal here such as finding out that a feature the engineering team have spent six months building isn't mentioned once during sales conversations, meanwhile a tiny missing capability is costing deals every week!

CMO - Why do people pay attention to us?

We, as engineers, often underestimate marketing because we're thinking about products, while marketing is thinking about awareness, positioning and perception.

The Chief Marketing Officer (CMO) can help you understand;

• What messages resonate with prospects?
• How does the market perceive the company?
• Which competitors are you being compared to?
• Which customer problems generate the most interest?
• Which stories are helping create demand?

Understanding how the product is positioned in the marketplace, how the market reacts to it, who our competitors are and their products, can all help inform and drive the decisions we make on feature priorities.

Be warned though - the CTO role isn't for wallflowers if you've got a great marketing team - they love access to technical leaders who can explain the thinking behind products and innovations and will often push you in front of a crowd, or a camera, at every opportunity!

CPO (Product) - What should we build?

The Chief Product Officer (CPO) is usually the closest relationship a CTO has outside of engineering. Sometimes the CPO is the CTO, sometimes it's the CEO - and sometimes, in more mature/larger organisations, it's a dedicated role. Regardless of who holds the role or is the proxy, the CPO and CTO work hand in hand to define and deliver the product roadmap

Whilst the CTO brings technical feasibility, architecture, delivery strategy and reduction of technical risk, the things you'll regularly need to learn/understand from the CPO includes;

• Customer needs.
• Market opportunities.
• Product strategy.
• User behaviour.
• Roadmap priorities.

It's important that this relationship is established quickly and maintained - it's most definitely two peas in a pod and the best product and technology leaders operate as partners rather than competing for ownership.

CPO (People) - How do we build a healthy organisation?

Many a first-time CTO assumes they're responsible for technology. Whilst that's true to a degree, they're actually responsible for people who build technology.

The Chief People Officer (CPO) is a key person to lean on to help you build a successful engineering organisation. You're going to want to attract the best talent, you're going to inevitably deal with under-performance and want to do so humanely and fairly, you're going to want to plan for hiring to expand the team to meet objectives and even plan for succession for your own role.

Early on, the people team can help you understand (or define):

• Recruitment.
• Retention.
• Performance management.
• Compensation.
• Career progression.
• Organisational design.

A great CTO will spend as much time thinking about people systems as software systems - how the team hangs together, it's ethos, nurturing it's culture, keeping people happy, engaged, and growing the engineering org.

COO - How does the company actually operate?

The Chief Operating Officer (COO) is usually responsible for the machinery of the business. Where the CEO defines where the company is going, the COO is responsible for making sure everyone gets there.

The COO is a good early port of call to understand the operating mechanics of the business overall and give you a picture of its:

• Operational bottlenecks.
• Manual processes.
• Business scaling challenges.
• Internal inefficiencies.
• Cross-functional dependencies.

To be honest, aside from customers, establishing dialogue with the COO will often uncover some of the highest ROI technology improvements simply by following operational pain.

CCO - Why do customers stay?

Where the sales teams tell you why customers buy, the customer success team, led by the Chief Customer Officer (CCO), tells you why they stay.

Or leave.

The information held within the CCO's team is a gold mine that you should look to absorb into your plans and initiatives for beyond the first 90 days. The CCO can help you identify;

• Sources of churn.
• Adoption challenges.
• Customer frustrations.
• Support trends.
• Expansion opportunities.

Some of the most valuable product improvements you’ll ever make come from understanding why customers struggle after the sale.

When I was CTO of Sharedo, like many software companies, we had a backlog chock-full of major initiatives, strategic projects and large roadmap items that were all competing for attention and overflowing with perceived "value".

Meanwhile, the CS team kept encountering dozens of tiny frustrations from customers - things that weren't individually serious enough to justify a roadmap discussion, but collectively, they were creating a surprising amount of friction and support cost.

To tackle it, we created a dedicated, super simple, and streamlined "Quality of life" channel on Slack. Customer success could raise small improvements directly as one or two sentence descriptions (avoiding the pain of raising a full enhancement request ticket), engineers would periodically review and route them through to a lightweight delivery process rather than forcing everything through the normal planning machinery.

In a matter of weeks, we'd delivered hundreds of tiny enhancements - nothing was glamorous, nobody was going to write a conference talk about any of them, but collectively they removed friction, reduced support effort, improved customer satisfaction and generated enormous goodwill with customers.

I don't think we'd have discovered that opportunity by reviewing architecture diagrams or debating design patterns. We discovered it because we had strong relationships with the people speaking to customers every day.

CIO/CISO - How do we stay compliant and secure?

This one varies massively by company and is often confused with the CTO role. The Chief Information Officer (CIO) usually owns internal IT in most organisations. In others they are responsible for information governance, compliance, security, risk and data management - and in others again, that will be done by a dedicated Chief Information Security Officer (CISO).

The important thing in the CIO - CTO relationship is to gain a solid grasp and understanding of the business's obligations for the markets they operate in. These can be:

• Regulatory obligations.
• Security expectations.
• Audit requirements.
• Data governance.
• Risk management.

The CIO or CISO is often the person explaining why your technically elegant solution is about to create a compliance nightmare. 😂

Customers - Why do we exist?

I left this towards the end, but it's the most important relationship of all. Without customers we don't exist. If customers churn out, revenue goes down, the business sinks. Customer first should be a mantra for every organisation as obvious as that sounds.

It's amazing how many technology leaders spend more time talking about customers rather than talking to customers.

Make connections with your customers, not only will they appreciate the personal attention of the CTO, they will give you first party feedback on your product and service. Yes, you'll get some of this from the other relationships I've described, but it's all second hand - being able to pick up on a pain point with the customer and delve as deep as needed is priceless.

Customers will tell you:

• What matters.
• What doesn’t matter.
• What frustrates them.
• What delights them.
• What competitors are doing better.

Whenever possible, sit in on demos, customer calls, user groups, support reviews and account reviews. The further you get from customers, the easier it becomes to optimise for things that don’t matter.

The former CTO

This one is a bit of a curve ball, but assuming you're promoted into or switching jobs to a CTO role that already had one, and assuming the opportunity exists, speaking with the former CTO can be extremely valuable. (Failing that, you should also be able to glean this information from existing directors of engineering, or other senior technical leadership).

I include this because, whilst I'm focussing on understanding the business first as being the key to success as a CTO, you should and will, still take those commonly accepted technical initiatives forward - review the architecture, the code, technical debt, cloud costs, etc etc - and every CTO inherits decisions they disagree with.

Before changing anything, understand:

• What problem were they solving?
• What constraints existed at the time?
• What trade offs were accepted.

Having access to the former CTO would help you understand the levers affecting a decision - a surprising number of "bad decisions" turn out to be entirely reasonable decisions given the information and constraints at the time.

It's common for the first instinct of many senior engineers moving into their first CTO role to want to start a rebuild. First off, don't do that - it's almost always the wrong decision - losing momentum and therefore market position, second system syndrome and so on - but secondly, every new CTO sees things they would have done differently - but that's not the same thing as things that need changing.

Focus first on understanding the business to understand what holds value.

Learn the language

Once you understand how the company operates, who owns what, and how revenue flows through the business, you need to learn how the organisation measures success.

Every function in the business has metrics. Engineering has velocity, cumulative flow, defect escape, deployment frequency. Production engineering has uptime, availability, response times, error rates.

The rest of the business have their own metrics and its own language. When you're working with the other C-Suites, when you're in management meetings you're going to hear acronyms you're perhaps not familiar with. You don't have to be a finance expert, but you do need to understand what these metrics are telling you and why they're important because sooner or later, someone will ask you whether your latest initiative improved any of them.

ARR - Annual Recurring Revenue

ARR is the total value of recurring subscription revenue normalised to a year. It's one of the most common ways SaaS businesses measure growth because it provides a relatively predictable view of future revenue.

If you have 100 customers each paying £1,000 per month, your ARR is £1.2 million.

As a CTO, ARR matters because many of your initiatives ultimately exist to grow it. New features can help win new customers, platform improvements can support larger customers, and reliability improvements can help retain existing customers. Understanding ARR helps you connect technical decisions to commercial outcomes.

NRR - Net Revenue Retention

NRR measures how much revenue you retain from your existing customers over time, taking into account upgrades, downgrades and churn.

A company with 100% NRR is retaining exactly the same revenue from its existing customers. Above 100% means existing customers are spending more over time through upsells, cross-sells or expansion. Below 100% means revenue is shrinking.

Investors love NRR because it indicates whether customers are finding increasing value in your product. A company with strong NRR can often grow significantly without constantly replacing lost customers.

As a CTO, NRR is often influenced by product quality, customer experience, reliability, scalability and your ability to deliver valuable new capabilities. The best technology teams don't just help acquire customers - they help customers grow.

Churn

Churn is the flip side of the NRR coin. It measures how many customers, therefore revenue, you lose over time. Every business loses some of its customers over time - the important question is why?

Are customers leaving because they don't see value? Because competitors have a better offering? Because onboarding is difficult? Because the product is unreliable? Because you're missing critical functionality?

As CTO, churn should be one of the most interesting metrics in the business because it often reveals where technology, product and customer experience are failing to meet expectations. If customers are leaving for reasons you can influence, understanding those causes is usually far more valuable than debating architectural purity.

EBITDA - Earnings Before Interest, Taxes, Depreciation and Amortisation

EBITDA is a measure of the underlying profitability of the business before financing decisions, tax arrangements and certain accounting treatments are taken into account. You don't need to understand every accounting nuance behind it, just that what matters is that EBITDA is often used by leadership teams, boards and investors as a high-level indicator of operational performance.

Almost all of your decisions as CTO will ultimately flow into EBITDA - and that's the point of this article.

• Reducing cloud costs improves EBITDA
• Reducing support effort improves EBITDA
• Improving engineer productivity improves EBITDA
• Automating manual processes improves EBITDA
• Helping sales close more deals improves EBITDA

The goal isn’t to optimise EBITDA directly. The goal is to understand that technology doesn’t create value in isolation. It creates value by increasing revenue, reducing cost, reducing risk or improving retention - all of which eventually show up in EBITDA.

Final thoughts

The biggest mindset shift moving from engineering leadership to CTO is realising that every initiative you kick off should be traceable to a business outcome. In most organisations, that outcome eventually moves the needle somewhere commercially - revenue, retention, margin, cost, risk, or ultimately EBITDA.

Every technology decision eventually appears in a spreadsheet somewhere.

That’s the first lesson I wish somebody had taught me early in my CTO journey. That’s the difference between thinking like a senior engineer and thinking like a CTO. The CTO who doesn’t understand the business asks:

• Is this architecture elegant?

The CTO who understands the business still asks that question, but they also ask:

• Will this increase revenue?
• Will this reduce churn?
• Will this improve margin?
• Will this reduce operating cost?
• Will this help us acquire customers?

The first 90 days as a CTO aren't about proving you're the smartest engineer in the room, they're about understanding the room.