Your First 90 Days as CTO: What to Ignore, What to Fix, What to Watch

The moment you become CTO, everyone expects you to know things you couldn't possibly know yet. The board wants your technical roadmap. The CEO wants your assessment of the team. The engineers want to know if you're going to rewrite the platform. Sales wants to know when the feature they promised to an enterprise client will ship.

You've been in the role for three weeks. Damn it.

The instinct — particularly if you were hired externally, or promoted quickly — is to act. To demonstrate competence through visible change. To show that you're not just another person in a chair, but someone with opinions and the authority to act on them. That instinct will cost you.

The first mistake: moving before you understand

The most common move is a technical audit. Dig into the codebase in week one, identify the debt, present a cleanup plan before month one is out. It feels decisive. Engineers often appreciate that someone finally named the problem. The board nods.

And then six months later, the original delivery timelines are blown. The cleanup turned out to be more complex than the audit suggested. The engineers who knew where all the bodies were buried have left, taking that knowledge with them, but leaving the bodies there. The features that customers actually needed are still not shipped.

The problem wasn't the audit. The problem was acting on it without understanding the context that created the situation in the first place. Technical debt doesn't exist in a vacuum. It exists because of decisions made under specific pressures at specific moments. Understanding those pressures tells you whether the debt is reckless or survivable, whether it's getting worse or has been stable for two years, and whether now is actually the moment to address it. Often the answer is: not yet. "If it ain't broken, don't touch it" is not a cop-out — it's a surprisingly powerful tool in a new CTO's first 90 days.

You don't learn that from the codebase. You learn it from the people.

There's another reason to slow down that nobody says out loud: the opinions you form in the first 30 to 60 days tend to stick. You'll update them, but the shape of your initial read — who's doing good work, where the real problems are, what the culture actually rewards — stays with you longer than you expect. Those first months are the last time you'll have genuinely fresh eyes. The person who just joined and has no idea why things work the way they do is an asset. Use it to look, not to act. You are that person now. But only now.

What the first 90 days are actually for

The first 90 days are not a performance. They are an investigation.

Your job is to understand what you walked into. Not just the architecture (that is almost the easy part), but the culture — the unspoken rules about how decisions get made, who actually has influence, what subjects are politically untouchable. The things that won't appear in any document but that explain every decision that confuses you. And that is the hard part.

This requires talking to everyone. Not in formal structured interviews, but in actual conversations. Ask engineers what frustrates them. Ask the product team what they wish engineering understood. Ask the CEO what keeps them up at night — and listen carefully to whether the answer is tactical (this quarter's revenue) or existential (whether the product is the right bet). Those are very different situations to be walking into.

One question I've found cuts through faster than most: "What do you think will surprise me when I go deep?" It makes people think past the obvious answer. The response is almost always either something remarkably novel, or something remarkably broken.

And ask what they didn't try — not just what failed. That question sparks more than the backwards-looking version, and it tells you something about the imagination of the team.

What to ignore in the first 90 days

Ignore the loudest voices in the room. Not because they're wrong, but because volume is not a proxy for importance. The person who corners you in week one with a laundry list of things that need fixing has an agenda. That's fine — most people have agendas. But you should hear the agenda before you act on it.

Ignore the first version of the technical debt story. There's always a first version: "the codebase is a disaster, the previous team made terrible decisions, we need to start over, it's the product managers!" There's always a more complicated truth underneath it. The truth comes out in the second and third conversation, not the first.

Ignore the pressure to prove yourself through visible change. Lasting credibility comes from making good decisions, not fast ones (although fast ones sometimes are needed). A CTO who understands the situation before acting is more trustworthy than one who ships a restructuring plan in week two. The people who will matter most to your success are watching how you learn, not just what you do.

What to fix in the first 90 days

Fix the things that are actively getting worse. Not the things that are bad but stable — those can wait. The things that are spiralling: a team that is losing members faster than it can hire, a deployment process that is causing multiple outages a week, a relationship between engineering and product that has devolved into open hostility.

Fix broken trust where you can. If there is a specific, concrete thing that is making the engineering team feel unseen or undervalued, and you can address it without overcommitting yourself, do it early. Not as a political gesture, but because trust is the medium through which everything else in your job happens. You can have a technically brilliant strategy and fail entirely if the team doesn't believe you.

What to watch

Watch who the informal leaders are. I call them kingpins. Every engineering organisation has them: every decision goes through them somehow, they are always consulted, they know what is happening before it happens. They're at the coffee table and people come to them to whisper things. They're not always the most senior — often they're not. Find them. Understand their perspective. Don't try to co-opt them — they'll see through it — but make sure they're not working against you before they've given you a real chance.

Watch the relationship between product and engineering. This is where most execution problems live. If product and engineering are in sync, you can fix almost everything else. If they're not, nothing else you fix will hold for long.

Watch the CEO's relationship with technology. Whether they trust it, fear it, or ignore it will shape your political reality for as long as you're in the role. Understanding this early gives you a head start on the managing-up work that is a much bigger part of your job than you expected.

And do the same for the whole management team. Understand what each person wants from you, and what they can offer you in return. Are they allies or quietly working against you? Are they on your side or protecting their own territory? Does the CFO need a shoulder to cry on about infrastructure costs? Does the Head of Sales have one thing that, if engineering fixed it, would change their quarter? These are not political games — they are the map. The CTO who knows this in month one moves faster in month four.

And watch what's going well — actively. When people tell you something works, listen, but stay curious. Sometimes you're hearing genuine pride. Sometimes "our project management is really solid" turns out to mean full waterfall. The more important signal is what nobody mentions at all: the things the team takes completely for granted. Your job is to see those things and name them. I was once in a role where the whole team seemed lukewarm about a recent app rebuild. Nobody flagged it as a win. But it had let the team adopt completely new technology and ship dramatically faster than before. That was good. Someone needed to say so.

The undocumented things are almost always about relationships — between people, between teams, between organisations. I used to joke that at Nokia I could trace any bug between two teams back to two people who weren't talking to each other. Architecture follows organisation. Bugs follow internal conflict.

The thing nobody tells you

Your first 90 days will feel slow. You will want to do more than you should. The pressure to act — from others and from yourself — is constant.

Go slow to go fast later. But don't wait for certainty. In my experience you reach about 80% confidence on your initial read faster than you think — and that's enough to act. Waiting for 100% is how you stay in investigation mode forever. Form the opinion. Test it. Move.

The platform will still be there to rewrite in month four. The relationships you need to make it go well are built in months one through three.