Define These Terms Once So Everyone Means the Same Thing

These definitions are plain-English and specific to how the book uses the terms.

• Architecture. The important structure and boundaries of a technical system, plus the decisions that make change easier or harder. In an enterprise it can also mean how applications, data, infrastructure, integrations, and standards fit together. Architecture is not only a diagram.
• Architecture Decision System. The rules, people, evidence, thresholds, and escalation used to make significant architecture choices. A CTO is usually accountable for whether this system works, not for approving every design.
• Build, Buy, or Partner. A decision about whether the company creates a capability itself, purchases it, or depends on another organization. The choice includes differentiation, cost, speed, control, concentration, data, security, integration, and exit.
• Business-Unit CTO. A technology executive accountable close to one division or line of business while operating inside enterprise platforms, standards, and risk obligations.
• CISO. Chief information security officer. Usually leads cyber risk expertise, security operations, controls, assurance, and executive advice. The business or another authority may accept final risk.
• CIO. Chief information officer. Commonly leads enterprise information systems, technology services, infrastructure, vendors, workforce technology, and transformation. Boundaries with the CTO vary.
• CPO. Chief product officer. Usually leads product strategy, customer value, discovery, portfolio priority, and product outcomes.
• CTO. Chief technology officer. In this book, the executive who makes the organization capable of placing, executing, and revising consequential technology bets. Scope and authority must be defined for each company.
• Decision Right. The authority or role a person has in a decision. Useful rights include recommend, decide, approve, fund, execute, verify, accept risk, and veto under stated conditions.
• Engineering Management. The system of managers, staffing, performance, planning, team health, and delivery used to organize engineering work. It can report to a CTO or VP Engineering.
• Enterprise Architecture. The structure and direction of technology across a large organization, including applications, data, integration, infrastructure, and shared principles. It is valuable when it improves real investment and change decisions.
• Evidence. Information that supports or challenges a claim. A candidate statement is evidence that the candidate made the statement. It is not proof that the claimed result occurred.
• Fractional CTO. A technology executive who works for an agreed portion of time, often across several clients. The role needs a charter, internal execution owner, and explicit limits.
• Guardrail. A boundary within which local teams can decide without central approval. Good guardrails name the outcome or risk protected and allow timely exceptions.
• Hands-On. A vague term that should be replaced. It may mean coding, design reviews, incident work, prototypes, metrics, field observation, or direct work with experts. Define the mechanism and expected time.
• Interim CTO. A temporary executive who occupies the CTO role during transition, crisis, search, or a bounded mission.
• Mandate. The operating agreement for why a role exists, which outcomes matter, what it controls, which constraints are real, and how it will be evaluated.
• Platform. A shared capability used by products, teams, or businesses. It may include software, infrastructure, data, hardware, or networks of commercial partners. An internal platform needs customers, service, economics, adoption, and an exit or change path.
• Product. Something designed to create value for a customer or user. It may be commercial software, a vehicle, a medical device, an internal platform, a customer experience, or a public service.
• Product-Market Fit. Evidence that a product solves a meaningful market problem in a way that can support a business. It is not a single metric or permanent state.
• Risk Acceptance. A conscious decision by the authorized person or body to live with a known residual risk for a stated reason and period. It is different from failing to notice or fund the risk.
• Scale. Growth in customers, transactions, products, people, geography, obligations, or coordination. “Can it scale?” is incomplete until the kind and likely magnitude of scale are named.
• Strategic. Related to choices about where the company will play, how it will win, and which capabilities or constraints matter. Strategic does not mean distant from implementation.
• Technical Debt. A current constraint created by earlier choices that makes future change, operation, assurance, or understanding more costly. It can exist in code, architecture, data, hardware, vendors, skills, evidence, and organization. Not all debt is a mistake; some buys useful learning.
• Technical Option Value. The organization’s ability to deliver now, survive failure, change direction, integrate acquisitions, meet obligations, attract capable people, and use future technology without being trapped by today’s systems, contracts, data, hardware, or organization.
• Transformation. A coordinated change in business capability involving technology, process, people, data, vendors, and adoption. A system installation is not automatically a transformation.
• VP Engineering. The executive or senior leader usually responsible for engineering delivery, management, staffing, and team health. The role can be the top technology leader or work beside a CTO.