You just got the title. CTO. Chief Technology Officer. The first thing that crosses your mind is all the things you want to fix. The legacy system that should have been replaced two years ago. The deployment process that makes everyone nervous on Fridays. The team structure that doesn't quite make sense.
But here is the thing I see over and over again: the CTOs who stumble hardest in their first quarter are the ones who showed up with a plan on day one. The ones who succeed? They show up with questions.
As Will Larson puts it in his framework for new engineering executives, the core principle is simple: understand systems before changing them to ensure durable improvements, not ephemeral fixes. Real credibility, as Jason Hood wrote in CIO.com, "isn't earned by rolling out a sweeping 18-month transformation plan. It's forged in the first 100 days, one deliberate and well-communicated victory at a time."
I believe this framework is worth internalizing whether you are stepping into your first CTO role or your third. Here is the playbook, broken into three phases.
Days 1 to 30: The Listening Tour
Your first 30 days are for discovery. Your mission is to understand the landscape, not to change it. I know that feels counterintuitive when you were hired to lead change. But every experienced CTO I have studied or spoken with says the same thing: resist the urge.
Will Larson's recommendation is practical and specific: if your engineering org is under 30 people, do individual one-on-ones with every single person. For larger orgs, mix individual and team meetings. But don't stop at engineering. Schedule time with sales leaders who hear customer complaints firsthand, finance partners who understand the real budget pressures, and the senior engineers who hold institutional knowledge.
Jason Hood discovered during his own listening tour that the company's real documentation "lived in the heads of three people" rather than in official records. That is the kind of insight you only get by asking questions and actually listening to the answers.
What to focus on during the listening tour:
Business fundamentals - Revenue sources, cash position, and the value drivers for the year ahead. You cannot make good technology decisions without understanding the business.
Culture and decision-making - Who really makes decisions? What are the unwritten rules? Who thrives here and why?
Technical quality - Tool effectiveness, technical debt hot spots, and the actual developer experience. Build and deploy a trivial change yourself to feel the friction firsthand.
Team health - Morale, inclusion, sustainable pace. Shadow support tickets and sit in on customer meetings. Attend existing forums without trying to change them.
Stakeholder needs - What do your peers in sales, product, and finance actually need from technology? Understand their pain before conflicts arise.
One tip from Larson that I think is underrated: share your observations through weekly emails. It demonstrates that you are listening and processing, without passing judgment. Think of it like a doctor doing a full physical before prescribing anything.
Days 30 to 60: Align and Find the Burning Platform
By day 30, you should have a solid map of the terrain. Now the work shifts from listening to aligning. But "aligning" does not mean rolling out your grand vision. It means finding the one or two pain points that everyone already agrees need fixing.
Hood calls this "finding the burning platform." The key distinction: you are not inventing problems. You are identifying the ones that already keep people up at night. Maybe it is a slow development environment that wastes 30 minutes every morning. Maybe it is a manual report that takes three days to generate. Maybe it is a buggy checkout flow that sales keeps apologizing for.
The alignment phase is also where Larson recommends you implement at most one or two changes to the organization. Not ten. Not five. One or two. This is incredibly disciplined, and it is what separates experienced executives from eager ones.
During this phase, your job is to:
Request explicit expectations from your manager (and your board, if applicable)
Document existing processes before proposing changes to them
Identify 3 or fewer key missing roles on your team (not everything is a hiring priority)
Pick one clear, visible project you can deliver within 30 days
Days 60 to 90: Deliver the Win and Tell the Story
This is where the payoff happens. You have listened. You have aligned. Now you execute one small, visible, and unambiguous win.
Hood gives a perfect example: "When you automated that painful manual report, you didn't just save a few hours. You showed the Head of Sales that you listen, and you deliver. When you sped up the development environment, you showed your engineering team that you understand their daily friction."
But delivering the win is only half the job. The other half, and this is where many technical leaders stumble, is telling the story. Hood puts it bluntly: "You must be the chief storyteller for your team's success. It's not enough to deliver the win; you have to amplify it."
Stuart Kelly, Principal Engineer at Zego, reinforces this from a different angle: "Good presentation skills are the number-one skill every tech leader must have, as most of the responsibility will involve communication." I see a lot of technical leaders who think the work should speak for itself. It doesn't. Not at the executive level.
Share concise, business-focused updates. Something like: "Automated the QBR report, cutting generation time from three days to two minutes." That is a sentence your CFO will remember. That is how technology stops being seen as a cost center and starts being seen as a business driver.
The Two Mistakes That Sink New CTOs
I want to highlight two specific failure modes that keep coming up in the research, because they are subtle and they are deadly.
Mistake 1: Thinking you are still a technical leader
Sergio Visinoni, writing in the Make Me a CTO newsletter, nails this one: "All C-level roles are business leaders, each one with their specialties. This means you are now a business leader." Your entire career trained you to solve technical problems. But the CTO role is about enabling the business through technology. That is a fundamentally different job.
This does not mean you stop caring about code. It means you stop hiding behind it. Learn how the product is marketed and sold. Understand the competitive landscape. Stop using technical jargon in strategy discussions. Your value to the executive team is translating between the technical reality and the business opportunity.
Mistake 2: Treating the exec team as your secondary team
This one is natural. You came from engineering. Your people are in engineering. So you spend all your energy there and treat the C-suite as something you attend rather than something you belong to.
Visinoni's correction is direct: "The executive team is your primary team, where you set the example and the conditions for the rest of the organization to succeed." If you want your engineering org to collaborate well across departments, that starts with how you collaborate with the other execs. You model it at the top, or it never happens below.
Build Your Support System Early
One pattern I see in every successful CTO transition is this: they do not go it alone. Larson recommends building three pillars of support from day one:
An external peer group of people in similar roles. Slack groups, breakfast meetups, whatever works. You need people who understand your problems without needing context on your company.
An executive coach. Some leaders recommend starting with a coach immediately; others suggest waiting until after the first 90 days when you have enough context to make sessions productive. Either way, get one.
Self-care practices. This is not soft advice. Multiple sources cited burnout as a top risk for new CTOs. The STX Next guide specifically warns against "working all day and night, leading by day and coding by night." That pattern leads to mistakes, strained health, and diminished impact.
The Takeaway
Your first 90 days as CTO are not about proving you are the smartest technologist in the room. Everyone already knows you are technical. That is why they hired you. The real question is whether you can lead.
The playbook is deceptively simple: listen for 30 days, align for 30 days, deliver one visible win and tell the story. Along the way, treat the executive team as your primary team, resist the urge to make more than one or two organizational changes, and build a support system so you do not burn out before the real work begins.
Think of it like moving to a new city. You could rearrange the apartment on the first day. But you would be smarter to walk the neighborhood, learn the shortcuts, and figure out which coffee shop actually makes a good espresso. Then, and only then, decide where to put the couch.
Written by
Bruno Bonando
Fractional CTO and technology advisor. 23+ years shaping platforms for many companies across Europe and Latin America. Has had leadership roles at REWE, MediaMarktSaturn, Cazoo, and some others.
