CTO, VP de Engenharia, CIO e CPO: fronteiras e arquétipos

Boa parte da confusão sobre o cargo de CTO some quando se olha para os cargos vizinhos, porque muito do que se atribui ao CTO na verdade pertence a um deles. Este capítulo é transversal às fases porque as fronteiras se movem: na fundação, todos esses papéis moram numa pessoa só, e é a escala que os vai separando.

CTO e VP de Engenharia: a separação que a escala impõe

A separação mais importante é com o VP de Engenharia, e ela é o assunto central da Fase 3, porque é lá que acontece. A leitura que se repete, e que sobreviveu à checagem, é que os dois papéis nascem fundidos na pessoa do fundador técnico e vão se separando conforme a empresa cresce: o CTO gravita para a estratégia, o horizonte mais longo e a face externa da tecnologia, enquanto o VP de Engenharia assume a execução, a operação do time e a gestão de pessoas do dia a dia. Não é uma hierarquia fixa nem uma regra universal, é uma tendência de divisão de trabalho que a escala torna quase inevitável.

A a16z resume o mecanismo por trás disso numa frase que virou lugar-comum por ser verdadeira: a empresa “entrega o próprio organograma” (ships its org chart). A forma como você estrutura a relação entre liderança de produto e de engenharia acaba impressa no produto, e é essa pressão que empurra a separação dos papéis à medida que o número de times cresce.

CTO e CIO: dentro contra fora

A fronteira com o CIO tem outra natureza. A distinção clássica, que remonta à literatura sobre o cargo, é a de staff contra line, e na prática se traduz numa divisão de território: o CIO cuida da tecnologia voltada para dentro (os sistemas de informação, a TI corporativa, como a organização usa tecnologia para operar), enquanto o CTO cuida da tecnologia voltada para fora (o produto, a plataforma, a tecnologia que a empresa vende ou que a diferencia no mercado). Em empresas cujo produto é software, essa fronteira fica borrada e às vezes um cargo engole o outro; em empresas onde tecnologia é meio e não fim, os dois coexistem com escopos nítidos.

O quadro comparativo

A tabela comprime essas distinções nas dimensões que mais as separam. É um mapa de tendências centrais, não um contrato: em qualquer empresa concreta as caixas vazam umas para as outras.

Cargo	Foco central	Horizonte	Orientação	Relação com o time
CTO	Tecnologia como estratégia e como produto	Médio e longo prazo	Externa (mercado, produto)	Gestor de gestores, ou de ninguém
VP de Engenharia	Execução e entrega de engenharia	Curto e médio prazo	Interna (operação)	Gestão direta de pessoas e times
CIO	TI corporativa e sistemas internos	Operacional e contínuo	Interna (organização)	Gestão de operações de TI
CPO	Produto, descoberta e roadmap	Médio prazo	Externa (usuário, mercado)	Gestão de produto e design

O CPO entra no quadro porque a fronteira CTO/CPO é onde nasce a tentação de fundir os dois num único CPTO (Chief Product and Technology Officer): um cuida do o quê e do para quem (o produto), o outro do como e do com o quê (a tecnologia), e há quem defenda que juntar as duas visões numa cabeça só reduz atrito. A a16z registra essa tendência recente e adverte, com todas as letras, que “encontrar alguém com a combinação certa de experiência para os dois papéis pode ser muito difícil”. É um alerta que vale generalizar: cada vez que o mercado inventa um cargo que soma dois, o gargalo deixa de ser organizacional e passa a ser de oferta de gente que caiba na descrição.

Os arquétipos, e uma atribuição que costuma sair errada

Como o cargo não tem definição única, a literatura tentou domá-lo por tipologia: em vez de dizer o que um CTO é, catalogar os feitios que o cargo assume. A taxonomia mais citada identifica quatro modelos, e vale registrar a autoria com precisão porque ela quase sempre aparece trocada. Os quatro arquétipos são de Tom Berray e Raj Sampath, de 2002. Werner Vogels, então CTO da Amazon, os reusou e popularizou num texto de 2007, creditando os autores originais. A versão que circula na internet atribuindo os “quatro tipos de CTO” a uma palestra de Vogels em 2009 é uma distorção: a atribuição não se sustenta, e a checagem deste levantamento a derrubou por unanimidade.

Os quatro modelos, na formulação que Vogels retoma, são estes.

Infrastructure Manager. Cuida de operações de TI, data centers, redes e segurança, dividindo território com o CIO. É o feitio mais próximo do lado interno da tecnologia.
Technology Visionary and Operations Manager. Acumula a visão de como a tecnologia realiza a estratégia do negócio e a responsabilidade por executá-la. É o feitio que melhor descreve o fundador técnico da Fase 1.
External-facing Technologist. Funciona como ponte entre clientes e desenvolvimento, influenciando o portfólio de produto a partir do contato com o mercado.
Big Thinker. Avalia tecnologias emergentes, ameaças competitivas e novos modelos de negócio, tocando prototipagem e pesquisa aplicada.

A utilidade da tipologia não é encaixotar uma pessoa num tipo, é dar nome à tensão quando a empresa precisa de um feitio e contratou outro.

Há tipologias mais recentes e mais granulares, quase todas de praticantes e não de pesquisa. Pat Kua, por exemplo, organiza oito arquétipos por contexto organizacional: os de estágio inicial (Founder, Startup, Fractional), os de crescimento e mudança rápida (Scale-Up, M&A, Turnaround) e os de complexidade e coordenação (Group, CTPO). O valor desses catálogos é serem, nas palavras do próprio autor, “ferramentas para perceber desalinhamento”, não gavetas rígidas; a maioria dos CTOs reais é híbrida e migra de feitio conforme a empresa muda. Como são frameworks de opinião informada, e não achados verificados, entram aqui como vocabulário útil, com o peso que essa origem recomenda.

Palavras-chave

Cargos: CTO, VP de Engenharia, CIO, CPO, CPTO, CTPO Distinções: staff vs line, dentro vs fora, execução vs estratégia, ships its org chart Arquétipos: Infrastructure Manager, Big Thinker, Technology Visionary and Operations Manager, External-facing Technologist Autoria: Berray e Sampath 2002, Werner Vogels 2007, Pat Kua Fonte: a16z, allthingsdistributed, refactoring.fm