I’m staring at my screen, and Brittany Cotton’s face mirrors my frustration. As Chief Coaching Officer at 7CTOs, she spends literally thousands of hours coaching CTOs in peer groups - which is what 7CTOs is all about if you don’t know that by now. If anyone understands the confusion and chaos around the CTO role, it’s Brittany. She’s heard every interpretation, every struggle, every identity crisis from hundreds of technology leaders.
We’re two hours into what was supposed to be a 30-minute working session, and we’re no closer to answering the question that’s been haunting both of us: What exactly is a CTO?
“Let’s try again,” Brittany says, her voice carrying that mix of determination and exhaustion I’ve come to recognize in our partnership. She’s just come from a peer group session where three CTOs spent an hour debating whether they should be coding, and she’s had enough. I pull up the shared document where we’ve been capturing every definition we can find. McKinsey says one thing. Harvard Business Review says another. ChatGPT suggests something completely different. It’s a mess.
The snap comes when I read aloud the fifteenth different definition we’ve collected. “The CTO’s role evolves based on company stage, from hands-on coding in startups to strategic planning in enterprises.” I slide deep into my office chair, hands covering my face long enough for Brittany to ask me what’s going on.
“That’s the problem right there,” I say. “Every other C-Suite role has a clear, immutable definition. The CFO manages finances whether the company has ten employees or ten thousand. The CEO leads the company regardless of whether they’re pre-revenue or Fortune 500. But somehow, we’ve accepted that the CTO’s role is this shapeshifting mystery that changes every time the company hits a new milestone.”
The struggle intensifies as we dive deeper. We pull up job descriptions from companies ranging from seed-stage startups to Google. The variance is staggering. One wants a “coding architect,” another seeks a “strategic visionary,” and a third needs a “people leader who doesn’t code.” It’s as if we’re looking at entirely different professions that happen to share the same three letters.
The shift happens when Brittany asks a simple question: “What if we’re thinking about this backwards? What if we stop trying to capture all these variations and instead define what’s unchanging?”
That’s when it clicks. We spend the next hour stripping away all the situational noise, all the stage-specific requirements, all the industry variations. What remains is surprisingly elegant. The CTO - at any company, at any stage, in any industry - does three fundamental things that never change.
By hour three, we have it. Twenty-six words that capture the immutable essence of the CTO role. Success feels like finally solving a puzzle that’s been sitting on your desk for years, pieces scattered everywhere. When we read it back, we both know we’ve found something important.
The Role of CTO
The CTO first and foremost grasps a company’s business growth engine. They have a vision for the technology needed and the financial savvy to bring it to reality. The CTO assembles a team and leads them with precision to build the technology that fuels the engine.
High Five! You’re either struggling with this or you’re loving this. I’m here for all of it. Read ‘till the end.
Why the World Needs to Stop Overthinking the CTO Role
Let’s start with what everyone already knows but somehow forgets when it comes to technology leadership. The CEO’s role is crystal clear: provide vision, make strategic decisions, and be ultimately accountable for the company’s success. Period. It doesn’t matter if they’re running a lemonade stand or leading Apple. The core role remains identical.
The CFO? They ensure financial health and compliance. Whether they’re managing $100,000 or $100 billion, whether they’re at a nonprofit or a investment bank, the fundamental role doesn’t change. They might use different tools, have different team sizes, or face different challenges, but the role itself is immutable.
The COO ensures operational excellence. The CMO drives market presence and customer acquisition. These definitions have been stable for decades. No one writes think pieces about how “the CFO role is constantly evolving” or publishes surveys showing that “COO responsibilities vary wildly by company stage.”
Now you might be thinking:
“Etienne, why can’t we just say the CTO manages technology? Isn’t that the same elegant simplicity?”
Here’s why that definition fails spectacularly: “Managing technology” is like saying the CEO “manages the company” or the CFO “manages money.” It’s technically true but functionally useless. More importantly, it perpetuates the dangerous myth that technology is something separate from the business that needs to be “managed” rather than what it actually is - the fundamental engine of business value creation.
When you say a CTO “manages technology,” you’re implying that technology is this separate thing that exists independently and just needs oversight. That’s 1990s thinking. Technology isn’t some department you manage - it’s the capability that makes everything else possible. It’s the product. It’s the operations. It’s the customer experience. It’s the competitive advantage.
This is why our definition is necessarily more comprehensive. The CTO isn’t managing some abstract “technology” - they’re grasping how the business works, envisioning what technology needs to exist to make it work better, and building it. That’s fundamentally different from “managing” something that already exists.
Yet when it comes to the CTO, we’ve collectively lost our minds.
I’ve collected over 50 different CTO role definitions from respected sources. The Harvard Business Review alone has published at least six contradictory articles about what a CTO should be. Gartner’s definition conflicts with Forrester’s, which conflicts with McKinsey’s. And don’t get me started on the startup ecosystem, where every accelerator seems to have its own special snowflake version of what a CTO should do.
This chaos isn’t just academic navel-gazing. It’s actively harmful to the technology leadership profession and the companies we serve. When a role’s definition changes based on company size, industry, funding stage, or the phase of the moon, it becomes impossible to:
Hire effectively (how do you evaluate candidates for a role that shapeshifts?)
Develop professionally (what skills should you build when the target keeps moving?)
Measure performance (how do you assess success when success means different things at different companies?)
Build peer communities (how do you share best practices when everyone’s job is supposedly different?)
Breaking Down the Immutable Definition
Let me dissect each component of the definition Brittany Cotton and I crafted, because every word was chosen with precision.
“First and foremost grasps a company’s business growth engine”
This is non-negotiable. A CTO who doesn’t understand how their company makes money, acquires customers, and creates value is just a senior engineer with a fancy title. This understanding doesn’t change whether you’re at a B2B SaaS company or a consumer hardware startup. The specifics of the growth engine vary, but the CTO’s need to grasp it remains constant.
I’m tired of CTOs who hide behind technical complexity as an excuse for business ignorance. “I’m not a business person,” they say, as if the C in CTO doesn’t stand for Chief. You’re not a senior architect. You’re not the VP of Engineering Plus. You’re a chief officer of the company, and that comes with the responsibility to understand and contribute to the business strategy.
“They have a vision for the technology needed”
Vision isn’t about predicting which JavaScript framework will be hot next year. It’s about understanding the technical capabilities required to execute the business strategy. This vision must bridge the current state to the future state, whether that future is next quarter or next decade.
Let me give you some real examples of how CEOs catastrophically misunderstand this, especially when it comes to AI:
Misunderstanding #1: “Tell me which AI will win” Last month, a CEO friend called me in a panic. “My board is asking why we’re not using Claude instead of GPT-4. My CTO couldn’t give me a straight answer about which one is better. I need a CTO with better vision!”
This is like asking your CFO which bank will have the highest interest rates in 2027. The CTO’s vision isn’t about predicting winners in the AI model wars. It’s about understanding what capabilities your business needs and architecting systems that can leverage those capabilities regardless of which provider delivers them. A CTO with actual vision builds abstraction layers and switching costs into their architecture, not crystal balls.
Misunderstanding #2: “Just sprinkle some AI on it” I’ve sat in three board meetings this year where CEOs proudly announced their “AI strategy” - which was essentially “the CTO will figure out how to add AI to our product.” When pressed for specifics, they’d turn to their CTO expecting magical use cases to materialize from thin air.
This fundamental confusion about ownership is killing companies. The business strategy question “How can we serve customers better?” belongs to the entire C-Suite. The CEO should be obsessing over customer problems. The COO should be identifying operational inefficiencies. The CMO should be spotting market opportunities. Only then can the CTO provide vision for how AI capabilities could address those opportunities. But somehow, CEOs have decided that “AI strategy” is a purely technical concern that their CTO should divine from the ether.
Misunderstanding #3: “You’re the tech expert, you tell us what to build” The most dangerous misunderstanding is when CEOs completely abdicate strategic thinking about technology. “You’re the CTO, you tell us what AI products we should build.” This is like a CEO asking their CFO, “You understand money, tell us what business we should be in.”
The CTO’s vision for technology must be grounded in business strategy, not the other way around. If your business strategy is to reduce customer churn, then the CTO can envision how predictive models could identify at-risk accounts. If your strategy is to expand internationally, the CTO can envision how language models could break down barriers. But asking the CTO to create business strategy from technical capabilities is backwards and doomed to fail.
A seed-stage CTO needs vision just as much as an enterprise CTO. The scope might differ - one might be envisioning the initial architecture while the other plans a multi-year transformation - but the fundamental requirement for technical vision remains unchanged.
“And the financial savvy to bring it to reality”
This is where most CTO job descriptions fail spectacularly. They either ignore the financial component entirely or relegate it to “nice to have.” Bullshit. Every CTO decision is a financial decision. Every architecture choice has ROI implications. Every hiring decision affects burn rate.
The CTO who says “I don’t do budgets” is like a CFO who says “I don’t do spreadsheets.” Financial savvy isn’t optional - it’s table stakes. You need to understand unit economics, infrastructure costs, team productivity metrics, and technical debt as a financial liability. This doesn’t change whether you’re managing a $100K budget or a $100M budget.
“The CTO assembles a team”
Not “manages developers.” Not “oversees engineering.” Assembles a team. This acknowledges that building technology at any scale beyond a solo project requires bringing together the right people with the right skills. It’s true at a 5-person startup where you’re hiring your first engineer, and it’s true at Microsoft where you’re organizing thousands.
The assembly might look different - hiring directly, reorganizing existing teams, partnering with vendors, or building remote teams - but the core responsibility to assemble the right team never changes.
“And leads them with precision”
Precision matters because technology is unforgiving. You can’t hand-wave your way through system architecture. You can’t approximate your way through deployment procedures. Leading with precision means setting clear technical standards, making decisive architectural decisions, and ensuring the team understands both what to build and why.
This precision requirement doesn’t vary with company size. A startup CTO needs precision to avoid building themselves into a corner. An enterprise CTO needs precision to coordinate across massive distributed systems. Different scales, same fundamental need.
“To build the technology that fuels the engine”
The feedback loop closes here. Technology isn’t built for its own sake - it’s built to fuel the business growth engine that the CTO grasped in the first place. This connection between technical output and business outcome is what separates a CTO from a talented engineer.
Whether you’re building a simple CRUD app or a complex AI platform, whether you’re at a nonprofit or a unicorn, the technology must fuel the engine. That’s the job. That’s always been the job. That will always be the job.
How the CTO Levels Framework Proves the Point
Here’s where it gets interesting. We’ve spent years developing the CTO Levels Framework, which maps out how a CTO’s challenges evolve as their organization grows from 1 to 200+ engineers. Critics might say, “See? You admit the role changes!”
Wrong. The role remains constant. What changes is the complexity and scale of execution.
Think of it like being a pilot. The role of a pilot is to safely fly an aircraft from point A to point B. This doesn’t change whether you’re flying a Cessna or an Airbus A380. What changes is the complexity of the systems, the size of the crew, the number of passengers, and the regulatory requirements. But the fundamental role - safely piloting the aircraft - remains immutable.
The CTO Levels Framework doesn’t redefine the CTO role at each level. Instead, it maps out how the unchanging role manifests at different scales:
At Level 1 (team size 1-2), you grasp the growth engine by talking directly to customers
At Level 5 (team size 20-40), you grasp it through product metrics and strategic planning sessions
At Level 10 (team size 200+), you grasp it through executive dashboards and board presentations
Different tactics, same fundamental responsibility.
The Dangerous Myth of the “Evolving Role”
The tech industry’s obsession with depicting the CTO role as constantly evolving is more than just annoying - it’s actively harmful. This myth creates several specific problems:
It enables incompetence. When the role definition is fuzzy, it’s easy for unqualified people to hide behind situational excuses. “I’m not good at strategy because we’re still a startup.” “I don’t understand the business because I’m focused on scaling.” These are cop-outs enabled by fluid role definitions.
It prevents professional development. How do you grow in a role that supposedly transforms every 18 months? Young CTOs waste time trying to figure out what they’re supposed to be doing instead of getting better at the actual job.
It creates hiring nightmares. I’ve seen companies spend months searching for a CTO because they’re trying to find someone who matches their specific evolutionary stage instead of looking for someone who can execute the fundamental role at their scale.
It fragments the profession. We can’t build a strong CTO community when everyone thinks they’re doing a different job. This fragmentation weakens our collective voice and influence.
Role vs. Function: The Critical Distinction
Let me be crystal clear about something that trips up even experienced executives: role and function are not the same thing.
The CTO’s role - as I’ve defined it - never changes. But the functions you perform to execute that role vary dramatically based on context. This is true for every C-Suite position:
A CFO’s role is ensuring financial health. Their functions might include everything from basic bookkeeping (at a small company) to managing investor relations (at a public company).
A CEO’s role is leading the company to success. Their functions range from direct sales (early stage) to board management (late stage).
Similarly, a CTO might perform functions like:
Writing code (early stage)
Recruiting engineers (growth stage)
Setting technical strategy (scale stage)
Managing vendor relationships (enterprise stage)
These are functions, not role definitions. The functions you perform on Tuesday might be different from those you perform on Thursday. But your role - grasping the growth engine, having technical vision with financial savvy, assembling and leading a team to build technology that fuels that engine - remains constant.
The Time to Align Is Now
We’re at an inflection point in the technology leadership profession. As software continues to eat the world, the need for competent technology leadership has never been greater. Yet we’re handicapping ourselves with this ridiculous notion that the CTO role is somehow uniquely indefinable.
Enough.
It’s time to stop writing blog posts about “What Kind of CTO Are You?” and “The 5 Types of CTOs.” It’s time to stop accepting job descriptions that read like a random collection of technical and business buzzwords. It’s time to stop pretending that the CTO role is any more mysterious or mutable than any other C-Suite position.
The definition exists. It’s 26 words. It applies whether you’re at a pre-seed startup or Google, whether you’re building hardware or SaaS, whether you have one engineer or one thousand.
I’ve laid out this vision in more detail at ctomanifesto.org, where I’m building a movement around professional standards for technology leadership. I’ve created the CTO Pyramid (available on YouTube) as a visual framework for understanding how the immutable role plays out in practice.
But manifestos and pyramids aren’t enough. What we need is collective agreement and action.
What Happens Next
If you’re a CTO, start using this definition. Put it in your LinkedIn profile. Use it to evaluate your own performance. Share it with your CEO and board. Stop accepting the lazy narrative that your role is undefinable or constantly evolving.
If you’re hiring a CTO, use this definition to write your job description. Yes, you’ll need to specify the functions relevant to your stage and context, but ground them in the immutable role. Stop looking for unicorns that don’t exist and start looking for leaders who can execute the actual CTO role at your scale.
If you’re an executive recruiter, investor, or advisor, help propagate this definition. The entire ecosystem benefits when we have clarity around what a CTO actually is and does.
The alternative is more of the same: confused hiring processes, misaligned expectations, frustrated CTOs who don’t know what they’re supposed to be doing, and companies that fail to leverage technology leadership effectively.
We have a choice. We can continue pretending that the CTO role is some special snowflake that defies definition, or we can accept the simple, elegant truth that Brittany Cotton and I articulated in that marathon Zoom session:
The CTO first and foremost grasps a company’s business growth engine. They have a vision for the technology needed and the financial savvy to bring it to reality. The CTO assembles a team and leads them with precision to build the technology that fuels the engine.
That’s it. That’s the job. It’s always been the job. It will always be the job.
Now let’s stop talking about it and start doing it.