Hey! This week I am excited to host an original article by Pat Kua — a coach and CTO with 25+ years of experience in tech, and one of my favorite authors, whose ideas I have often quoted and mentioned here on Refactoring!
Pat’s article touches on a complex subject: the CTO role. He explores how such a role differs based on several factors, defines common sets of responsibilities, and provides insights you can use to improve alignment during hiring, company growth, and career conversations.
If you’d like to connect with Pat, please find him on Linkedin!
Here is the agenda for today:
👑 What’s a CTO — why the title carries seniority but rarely comes with documented scope.
🧩 Why I use archetypes — tools for sensing misalignment and converging on shared expectations.
🎭 CTO archetypes — eight recurring shapes that appear across different organizational contexts.
🛠️ How to use these archetypes — practical applications for hiring, growth, and career planning.
Let’s dive in! 👇
👑 What’s a CTO?
I’ve found that many people struggle to describe the scope of the CTO role.
Two people with the same “CTO” title can have radically different responsibilities, spend their days on entirely different problems and be measured by very different outcomes. These differences matter because misaligned and unclear expectations around the CTO role lead to frustration, inappropriate hires, organizational friction or burnout.
Many management and leadership roles often ask: “What is expected of me?”
I hear this frequently from Engineering Managers (EMs) and Tech Leads (TLs) in my training courses. While all roles have some slight differences, answering this for EMs/TLs is relatively straightforward, as I’ve previously written about in “The Definition of a Tech Lead” and “5 Engineering Manager Archetypes.”
Answering this question as a CTO, however, is much harder.
The title carries seniority and authority, but rarely comes with a documented understanding of scope, priorities, or success. After all, if you’re a CTO, you’re supposed to “work it out.”
Over my 25-year career in tech, I’ve worked with and observed many different types of CTOs. As a Principal Consultant at ThoughtWorks, I partnered with CTOs to help them transform and modernize products, platforms, processes, and organizational structures. As the CTO of the German digital bank N26, I met many CTO peers facing both similar and very different challenges. Since then, I’ve advised and coached CTOs across a wide range of organizations and situations.
What this experience has reinforced is that while CTO roles can vary dramatically, they are not always arbitrary. There are recurring shapes to the role that emerge in response to specific organizational contexts and constraints.
In the rest of this article, I describe these recurring shapes as CTO archetypes, which you can use to make sense of what different CTO roles cater for, why mismatches occur, and how the role might evolve over time.
🧩 Why I use archetypes
In software development, we often draw on design patterns such as the Observer, Singleton, or Decorator.
A pattern is a reusable solution to a specific problem in a defined context. Archetypes serve a different purpose. Rather than prescribing how to solve a problem, they describe recurring shapes that appear across many systems. When applied to leadership roles, I feel the term “archetype” fits better with the commonly understood meaning of “a typical example of something.”
Archetypes are not meant to be boxes people fit neatly into. Reality is always messier. Instead, they are tools for sensing misalignment and to converge on shared expectations.
Archetypes can help us turn implicit assumptions into explicit ones and provide a shared language to discuss expectations, trade-offs, and mismatches among an organization’s needs, a role’s scope, and an individual’s skills, experience, and growth opportunities.
No catalog of archetypes will ever be comprehensive or perfect, which is why my favorite quote from George E. P. Box applies so well here:
“All models are wrong, some are useful.”
When I wrote about the Engineering Manager archetypes, many people told me it helped them start productive conversations about which EM role their organization needed or which EM role someone was applying for. Others used it as a vehicle for growth, seeking new opportunities to build experience that allowed them to play other archetypes.
It’s also important to emphasize what these archetypes are not.
They are neither a hierarchy nor a maturity model. Most real-world CTO roles are hybrids, and an organization’s needs will change over time. Just as effective leaders practice adaptive leadership, a CTO’s shape must evolve as the company grows, shrinks, or changes direction. Used well, archetypes act as lenses rather than labels and support reflection and dialogue rather than categorization.
Although these archetypes are not meant to be exhaustive, I hope they’re still useful in practice. Whether you are an existing or aspiring CTO, a CEO or board member, an executive recruiter, or simply curious about what CTOs actually do all day, the goal is not to find the “right” archetype, but to have clearer, more grounded conversations about fit, focus, and context.
🎭 CTO Archetypes
The shape of a CTO role is mainly driven by organizational context and constraints, and because there are common situations, we can loosely group the following archetypes into one of the following categories:
🟣 Early-Stage or Small — Founder, Startup and Fractional.
🟠 Growth and Rapid Change — Scale-Up, M&A and Turnaround.
🔵 Complexity and Coordination — Group and CTPO.
Let’s look at all of them:
1) Founder CTO
The Founder CTO optimizes for turning a personal vision into a successful company, while carrying responsibility for both the business and its technology.
Imagine you want to start a tech company tomorrow, and you’re the most technically skilled person involved. Congratulations! You’re now a Founder CTO, and you wear the distinct hats of both Founder and CTO.
Founder CTOs typically have a much stronger attachment to the business than non-founder employees. While early-stage employees may have strong financial incentives, founders’ attachment is much deeper and more personal. For many Founder CTOs, the company’s success and eventual financial outcome are the positive side effects of seeing a personal mission come to life.
Founder CTOs often begin as the most experienced technical person in the organization. As the company grows, however, this may no longer hold true. Successful Founder CTOs frequently hire people who are more specialized or more experienced in particular technical domains. Some, such as Jack Dorsey (Twitter) and Patrick Collison (Stripe), eventually transitioned into CEO roles. Others, like David Heinemeier Hansson (Basecamp / 37signals) and Mitchell Hashimoto (HashiCorp), remained deeply technical as the company scaled.
The primary tension of the Founder CTO role is balancing the competing demands of the two hats, and in practice, the Founder hat often wins. During fundraising rounds, for example, the Founder CTO may spend significant time with investors rather than on technology leadership. In other situations, the Founder CTO becomes the public face of the business, requiring more time with customers or on marketing than leading the technology organization.