Twelve Role Cards Name the Base Role and Any Overlay

Real CTOs combine types. Use these cards to name the base role and any overlay. Do not turn the taxonomy into personality categories. Each card ends with the base role or overlay it maps to in this book’s seven role types and four overlays; where a card fits none of them cleanly, it says so.

Founding Builder#

• Setting. Pre-seed through early product-market fit, often as cofounder or first technical executive.
• Mission. Reach the next business proof before runway, attention, or founder trust runs out.
• Usually owns. First product and architecture, early technical hires, delivery credibility, infrastructure and security basics, and technical feasibility. Product priority and fundraising are shared founder decisions.
• What good looks like. Fast learning, useful product, honest feasibility, proportionate quality, runway preserved, and an early team that can take ownership.
• Evidence to seek. Products built under uncertainty, customer contact, choices not to build, early recruiting, direct response to failure, and changes of mind based on evidence.
• Failure pattern. Overbuilding, heroic coding, hidden risk, treating the CEO as a requirements source, or inability to give away work.
• Hiring caution. A brilliant builder who wants control of the technical answer may not want the executive co-ownership the company needs.
• In this book’s terms. Startup (base role).

Scale CTO#

• Setting. A growth company moving from one product and a compact team to several products, markets, geographies, and management layers.
• Mission. Turn early success into a repeatable technical and organizational system without suffocating product speed.
• Usually owns. Cross-product architecture, platform strategy, systemic reliability, technical leadership quality, long-horizon investment, and often engineering. A VP Engineering may own delivery and management.
• What good looks like. Product and platform capacity is explicit, delivery is more predictable, reliability and cost improve, senior leaders grow, and coordination tax falls.
• Evidence to seek. Mechanisms that replaced personal attention, leaders hired and changed, platform adoption, migration choices, cost judgment, and enterprise customer credibility.
• Failure pattern. Ceremonial futurism, shadow management of engineering, architecture bureaucracy, or platforms without customers.
• Hiring caution. Experience at great scale can hide dependence on mature institutions the hiring company does not possess.
• In this book’s terms. Growth and scale (base role).

Product-Company CTO#

• Setting. An established company whose commercial products are substantially technical.
• Mission. Preserve technical differentiation, product coherence, and long-term changeability across a portfolio.
• Usually owns. Technical product direction, architecture, senior technical community, research or advanced development, and systemic product risk. Product priority and delivery may be shared.
• What good looks like. Technical capability creates customer or strategic advantage, product groups share foundations where useful, and technical claims match real capability.
• Evidence to seek. Product and architecture judgment, technology-to-market translation, research-to-product conversion, portfolio choices, and customer truth under commercial pressure.
• Failure pattern. Technology roadmap detached from product strategy, research that never reaches a product, or using architecture to control product decisions.
• Hiring caution. Do not assume strong product technology judgment includes enterprise IT or large-scale people operations.
• In this book’s terms. Growth and scale (base role); an established product company may also fit Enterprise.

Cyber-Physical or Hardware-Software CTO#

• Setting. Vehicles, devices, industrial systems, robotics, energy, aerospace, medical products, and other physical systems.
• Mission. Make hardware, software, data, suppliers, manufacturing, and lifecycle behave as one product system.
• Usually owns. System architecture, technical product development, interfaces, major make-buy choices, lifecycle technology, and often engineering disciplines beyond software.
• What good looks like. Requirements and interfaces are coherent, irreversible choices are made with evidence, suppliers are governable, field learning returns to design, and safety or quality obligations remain credible.
• Evidence to seek. Hardware freezes, supplier failure, systems tradeoffs, field incidents, configuration, certification, manufacturing change, and long-lived support.
• Failure pattern. Assuming software can catch up after physical commitments, or allowing slow hardware practice to prevent useful software iteration.
• Hiring caution. Test the missing side. A software executive needs physical-system humility; a hardware executive needs modern software operating judgment.
• In this book’s terms. Hardware-software (overlay).

Software-Enabled Business CTO#

• Setting. A company that earns money through retail, services, logistics, healthcare, media, finance, or another business where software enables but is not always sold.
• Mission. Use technology to improve customer experience, operations, economics, and strategic choice.
• Usually owns. Digital products or channels, business platforms, architecture, data and integration influence, and technical transformation. Enterprise IT may sit with a CIO.
• What good looks like. Technology changes business behavior and economics, old work retires, vendors support rather than control the strategy, and customer or operating results improve.
• Evidence to seek. Process and technology change, benefit realization, product thinking in a non-product culture, vendor judgment, and adoption.
• Failure pattern. Importing software-company language without understanding operations, or delivering systems with no business owner.
• Hiring caution. “digital” can hide who owns the actual operating change.
• In this book’s terms. SME (base role); a large software-enabled business may fit Enterprise.

Enterprise Transformation CTO#

• Setting. A large established organization changing core systems, data, processes, operating model, or customer experience.
• Mission. Convert a portfolio of change into real business capability while the institution continues to operate.
• Usually owns. Transformation architecture and technology direction, cross-program dependencies, selected platforms, technical risk, and executive truth. Business leaders must own adoption and benefits.
• What good looks like. Fewer initiatives, clearer business ownership, working transitions, systems retired, benefits realized, and risk visible.
• Evidence to seek. Programs stopped, benefits tracked, business process change, vendor and integrator control, legacy retirement, and continuity during migration.
• Failure pattern. Transformation as permanent additional work, milestone reporting without adoption, or a program office substituting for operating ownership.
• Hiring caution. Confirm whether the CTO has authority over capital and retirement, not only responsibility for architecture.
• In this book’s terms. Enterprise (base role).

Federated Business-Unit CTO#

• Setting. A business unit with product, engineering, or operational technology inside a larger enterprise.
• Mission. Produce unit outcomes while making responsible use of enterprise capability and obligations.
• Usually owns. Unit technology agenda, engineering or delivery leadership, local architecture, customer and product technical decisions, and the unit’s side of enterprise dependencies.
• What good looks like. Unit outcomes improve, shared decisions move, exceptions are priced and retired, and enterprise requirements support rather than erase local accountability.
• Evidence to seek. Matrix decisions, unit economics, enterprise negotiation, standards challenged with evidence, and local teams built without isolation.
• Failure pattern. Local optimization that transfers cost and risk, or enterprise conformity that damages the unit.
• Hiring caution. Relationship skill cannot compensate for a missing federal decision model.
• In this book’s terms. Business unit (base role).

Group or Enterprise CTO#

• Setting. A diversified, multinational, or multi-business organization with several senior technology leaders.
• Mission. Create enterprise coherence in the few decisions where local independence would destroy value or create material risk.
• Usually owns. Technical strategy, enterprise architecture mechanisms, selected platforms, portfolio integration, technology options, and board technical narrative. Direct operating authority varies.
• What good looks like. Capital follows clear choices, duplication and governance fall where appropriate, local CTOs retain useful authority, and cross-enterprise options improve.
• Evidence to seek. Federated influence, capital allocation, platform economics, portfolio subtraction, acquisitions, board work, and mechanisms that survive the executive.
• Failure pattern. Strategy without investment, central control without service, innovation programs that avoid hard investment choices, or dependence on personal relationships.
• Hiring caution. Insist on no more than four primary outcomes. Otherwise the role becomes an enterprise aspiration list.
• In this book’s terms. Enterprise (base role).

Regulated or Safety-Critical CTO#

• Setting. Any company where technical failure can harm people, license to operate, market access, or public trust.
• Mission. Create useful technology that the organization can justify, observe, control, and change safely.
• Usually owns or shares. Technical risk, lifecycle evidence, validation, architecture, release readiness, post-market or field monitoring, and regulator or assurance engagement.
• What good looks like. Evidence is produced during work, risk decisions are explicit, independent challenge is useful, and controls do not depend on paperwork after the fact.
• Evidence to seek. Stop decisions, assurance conflict, intended use, validation, incident or field response, traceability, and controlled change.
• Failure pattern. Treating compliance as a gate, or using regulation to protect slow and unexamined practice.
• Hiring caution. Domain employment is not enough. Confirm the candidate’s actual decision and evidence responsibility.
• In this book’s terms. Regulated or safety-critical (overlay).

Market-Facing CTO#

• Setting. A technology provider where customers, analysts, partners, standards bodies, or investors require senior technical credibility.
• Mission. Connect market understanding and external trust to product truth and technical strategy.
• Usually owns. Technical narrative, strategic customer engagement, field technical community, partner architecture, standards influence, and market feedback. Engineering management may be outside the role.
• What good looks like. External claims remain credible, customer patterns influence products, exceptions do not fragment the company, and technical reputation supports commercial goals.
• Evidence to seek. Promises stopped, customer conflict, public position changed, standards work, analyst or investor interaction, and mechanism connecting market evidence to product.
• Failure pattern. Becoming more fluent in the story than the system, or turning anecdotes from large customers into strategy.
• Hiring caution. Define how the person maintains technical contact and who approves commitments.
• In this book’s terms. Market-facing (overlay).

Internal Engineering-Systems CTO#

• Setting. A large product or technology company where developer platforms, infrastructure, tools, and engineering effectiveness require executive ownership.
• Mission. Make the engineering organization faster, safer, and more effective through internal products and operating foundations.
• Usually owns. Developer platform portfolio, engineering productivity systems, technical standards, infrastructure direction, and systemic engineering risk.
• What good looks like. Internal customers adopt useful capability, friction and incident load fall, secure defaults improve, and teams retain local choice where it helps learning.
• Evidence to seek. Internal product management, adoption, platform economics, service levels, developer research, and retirement of poor tools.
• Failure pattern. Mandated platforms measured by compliance, or productivity metrics that reward visible motion rather than business outcomes.
• Hiring caution. Confirm the role has internal product and change capability, not only technical authority.
• In this book’s terms. Internal engineering systems (overlay).

Portfolio or Title-Equivalent CTO#

• Setting. Venture funds, private equity portfolios, holding companies, professional services, or organizations using CTO for cross-company technical judgment.
• Mission. Improve technical decisions across investments, companies, or client situations without pretending to operate each one.
• Usually owns. Diligence frameworks, technical risk and value assessment, executive coaching, portfolio patterns, and selected intervention. Company CTOs retain operating ownership.
• What good looks like. Investment decisions improve, company leaders gain capability, repeated risks are visible, and the portfolio CTO exits operating detail.
• Evidence to seek. Diligence that changed price or plan, coaching transfer, context-sensitive advice, conflicts managed, and interventions stopped.
• Failure pattern. One playbook across companies, shadow management, or recommendations tied to preferred vendors.
• Hiring caution. Define whether the role advises investors, supports company CTOs, or temporarily enters operations. These are different powers.
• In this book’s terms. None of the seven; the book treats this as “other.”

Combine the Cards Into One Role Statement#

Write the role as one base plus up to two overlays.

We need a [BASE ROLE] with [OVERLAY] because [BUSINESS EVIDENCE]. The role does not need to be [ADJACENT TYPE] because [CONDITION]. We expect the base role to evolve toward [NEXT TYPE] when [TRIGGER].

Examples:

• Founding builder with regulated overlay, evolving toward scale CTO after repeatable market evidence and a 25-person team.
• Software-enabled business CTO with SME control emphasis, not a product-company CTO until proprietary software becomes a material revenue capability.
• Federated business-unit CTO with market-facing overlay, working inside group architecture and risk guardrails.
• Enterprise CTO with portfolio integration emphasis, not transformation operator because the CIO and business presidents retain program and adoption ownership.

Ask your AI for help.

• Purpose. Select a base CTO type and overlays from business evidence.
• Give your AI. Need statement, role diagnostic, decision inventory, stage, company structure, and three-year business change.
• Prompt. Use the twelve CTO role cards to propose one primary base role, no more than two overlays, and the next likely role evolution. For each selection, cite the supplied business evidence and name the types that may sound attractive but do not fit. Show which hiring evidence changes because of the overlays. Do not blend every type. End with a one-paragraph role statement and three facts that would change the classification.
• Go deeper. Ask the AI to make the case for the second-best base role and identify the decision that distinguishes it from the first.
• Check before acting. Review the classification with current technical and business leaders. The cards organize work; they do not rate people.
• Save. Base-role and overlay statement for the mandate.