O CTO sem código

Jason Cole Blocked Desbloquear Seguir Seguindo 11 de janeiro

Uma conversa recente entre um grupo de CTOs:

“Eu fui engenheiro de software por 15 anos antes de me tornar um CTO, e ainda me certifico de que codifique pelo menos 20% do tempo, mesmo que tenha que fazê-lo fora do trabalho. Você não acha que um CTO tem que ser capaz de codificar ativamente?

"Claro! Como você pode liderar engenheiros se você não entende a tecnologia pelo menos tão bem quanto eles? Você nunca conseguiria o respeito deles!

“Eu tive um CTO que não era engenheiro uma vez. Tudo o que esse cara fez foi criar PowerPoints e 'gerenciar'. Ele não fazia ideia do que fazíamos todos os dias.

Hoo boy …

Eu tenho esse debate há décadas: "Como você pode possivelmente liderar pessoas técnicas se você não pudesse fazer o trabalho delas por elas, só que melhor?"

Me desculpe, eu quis dizer: "Você pode levar engenheiros se você não codifica?"

"Como você pode possivelmente liderar pessoas técnicas se você não pudesse fazer o trabalho delas por elas, só que melhor?"

Minha resposta definitiva é sim, você pode ser um líder de tecnologia de sucesso sem nunca escrever uma linha de código . É definitivamente o caminho mais difícil no começo, mas o sucesso a longo prazo como CTO exige uma visão equilibrada de pessoas, produtos e tecnologia. A experiência técnica com excesso de peso acaba se tornando uma desvantagem.

Dizer que você tem que codificar para ser um CTO é como dizer que, para projetar um arranha-céu, você tem que começar como um misturador de cimento, então vá até a rebitagem antes de finalmente pendurar o drywall e instalar o Windows antes de deixá-lo projetar o edifício. Ele assume que os detalhes são mais importantes que os conceitos, que o conhecimento prático dos rebites é mais importante do que entender a carga estrutural e a rigidez do material. Esse tipo de pensamento de baixo para cima é uma falha em muitos líderes técnicos seniores, deixando-os incapazes de participar de um pouco do pensamento “livre de gravidade” que é tão crítico na definição da direção de uma empresa. Entender os detalhes certamente ajuda, mas ser capaz de pensar em um nível conceitual é muito mais importante para um líder.

O sucesso de longo prazo como CTO exige uma visão equilibrada de pessoas, produtos e tecnologia. A experiência técnica com excesso de peso acaba se tornando uma desvantagem.

Isso irá surpreender algumas pessoas que me conhecem ou trabalharam para mim nos últimos 20 anos, mas eu não codifico . O último programa completo que eu escrevi foi um jogo de aventura de texto escrito em BASIC (e foi incrível, a propósito), mas 30 anos atrás eu escolhi a rota de negócios. Os engenheiros da Comp Sci não estavam fazendo quantias ridículas saindo da faculdade naquela época: eles iriam trabalhar nos porões da Digital ou da Bell Labs, que tinham pouco apelo. Então eu me especializei em marketing.

Mas eu adorei a tecnologia e a entendi em um nível conceitual e detalhado, por isso, depois de alguns anos nos papéis de negócios, me vi trabalhando para uma startup de software em Harvard Square.

Como um…

espere por isso…

… Gerente de projeto .

Sim, o cara que garante que as pessoas estão checando suas tarefas! A pessoa mais odiada e inútil em uma organização de engenharia, certo? A própria definição de OVERHEAD .

Exceto que não fui. Em vez disso, eu era a pessoa entre os engenheiros e os empresários, traduzindo em ambas as direções. Quando eu não estava lá, os engenheiros pareciam intratáveis, obstrucionistas e condescendentes, porque tudo o que eles faziam era repetir as variações de “isso não funciona assim, e se você entendeu todos os detalhes do que eu tenho que fazer você faria nem sequer me pedem para fazer isso. ”E para os engenheiros, os empresários pareciam bobos insensatos e sem cabeça, que nunca paravam de querer coisas novas antes que as outras coisas que eles pediam fossem sequer iniciadas.

Mas quando eu fiquei no meio e simplesmente traduzi as conversas, os dois lados perceberam que:

  1. Eles estavam mais próximos do que pensavam: eles queriam as mesmas coisas, mas não entendiam o modo de pensar da outra pessoa o suficiente para se comunicar de forma eficaz.
  2. Na maioria das vezes, era uma questão de prioridade e tempo, não viabilidade. O software pode fazer praticamente tudo o que você quiser, se estiver disposto a esperar por ele.
  3. Não era razoável esperar que as pessoas em qualquer das funções investissem o tempo necessário para entender os detalhes do trabalho da outra pessoa, mas poderiam concordar com os conceitos: “Aqui está o problema que precisamos resolver. Como fazemos isso? ”Na maioria dos casos, isso significava que alguém precisava traduzir.

O resto da minha carreira, até e incluindo esta semana passada, tem sido variações sobre este tema. Se eu estava construindo o primeiro MVP para uma startup antecipada ou uma divisão de software para 300 pessoas com 4 produtos SaaS corporativos, sempre estive na interseção de negócios e tecnologia, descobrindo como transformar capacidade técnica em vantagem competitiva.

E acho que esse é o papel do CTO. Como líder da organização de tecnologia, seu trabalho é alavancar a tecnologia para ajudar sua empresa a vencer a concorrência. Se você trabalha para uma startup com cinco pessoas e você é o único engenheiro, então sim, isso significa que você precisa fazer muita codificação. Mas quando você tem uma equipe, qualquer tipo de equipe , seu trabalho é garantir que eles estejam trabalhando nas coisas certas, construindo primeiro os recursos de maior valor e fazendo isso da maneira mais eficiente possível. Sim, isso requer algumas decisões tecnológicas fundamentais, e sim, você deve ter o respeito de sua equipe se for conduzi-las bem, mas se você não está constantemente olhando para frente e abrindo caminho para sua equipe, então eu não acho você está fazendo seu trabalho como CTO. E se você, como líder, não está fazendo o seu time bem sucedido, se você tornar seu trabalho mais difícil ao invés de mais fácil, então nenhuma quantidade de proezas técnicas fará com que eles o respeitem.

Como líder da organização de tecnologia, seu trabalho é alavancar a tecnologia para ajudar sua empresa a vencer a concorrência.

Se você não prestar atenção ao lado das pessoas da equação à medida que sua equipe cresce, você e sua empresa vão fracassar. Aqui está a coisa que muitas vezes falta nessas conversas: com algumas raríssimas exceções, as empresas não têm sucesso ou fracassam por causa de decisões tecnológicas fundamentais. Você não precisa ir muito longe no estábulo dos unicórnios para ver que pode construir um negócio extremamente bem-sucedido com uma tecnologia absolutamente terrível, e eu vi produtos lindamente criados que poderiam ser dimensionados para centenas de milhões de usuários, mas nunca tive a chance, porque esses usuários nunca vieram. A capacidade básica de implementar tecnologia é um requisito de entrada para uma empresa de tecnologia , mas não é um fator primário de sucesso. Em vez disso, o sucesso é determinado pela capacidade de uma empresa em:

  1. Aplique tecnologia à necessidade do negócio. Isso requer que a empresa compreenda seu espaço de negócios, seus clientes e onde a tecnologia realmente fornecerá alavancagem (e, da mesma forma, onde ela não será importante).
  2. Reúna e motive uma equipe de pessoas a fornecer essa tecnologia de maneira rápida e eficiente e responda às mudanças no ambiente . Isso requer o conhecimento de onde e como encontrar as pessoas certas, a capacidade de motivá-las a trabalhar nas coisas certas nos momentos certos e a dedicação para melhorar continuamente seu ambiente à medida que a empresa cresce, para que possam permanecer ágeis e eficazes. em sua entrega.

A capacidade básica de implementar tecnologia é um requisito de entrada para uma empresa de tecnologia , mas não é um fator primário de sucesso.

Em uma empresa de tecnologia, o CTO deve ser a única pessoa na equipe executiva que analisa esses dois fatores e diz: "Sim, esse é o meu trabalho". Você não precisa identificar a necessidade do negócio – isso pode vir do CEO , marketing ou vendas – mas você precisa entender bem o suficiente para fornecer a alavancagem correta . Se você realmente quer cumprir seu papel, não pode simplesmente dizer "diga-me o que construir".

Você também tem que entender as pessoas bem o suficiente para liderá-las, o que inclui lidar com toda a sua desordem humana. Simplesmente liderar pelo exemplo não é o suficiente: se você realmente quer construir uma equipe de alto desempenho, precisa descobrir o que faz com que cada pessoa marque individualmente, o que raramente é a mesma coisa que faz você funcionar.

A capacidade de codificar ajuda nessas áreas? Claro, isso te dá uma vantagem. Isso torna mais fácil (embora raramente mais rápido) avaliar novas plataformas de tecnologia e, às vezes, você pode se aprofundar e ajudar a resolver problemas técnicos específicos. Ele permite que você avalie pessoalmente a capacidade do indivíduo de codificar antes de contratá-lo, o que é valioso para as primeiras contratações. Mas se você confiar em suas habilidades práticas de codificação à medida que escala, rapidamente se tornará um gargalo, especialmente se ser o melhor engenheiro da empresa continua sendo sua principal medida de sucesso como líder.

Aqui está o porquê:

  • A codificação é, por sua própria natureza, um exercício muito tático. Trata-se de resolver um problema específico (ou conjunto de problemas) com um grande número de detalhes. Lógica, variáveis, interfaces, estruturas de dados se acumulam em sua cabeça e você tem que segurá-los enquanto cria uma solução estruturada. Requer grande concentração e atenção aos detalhes, e é tudo sobre “o como”. Isso é exatamente o oposto do pensamento estratégico, que é sobre o quê, por que e quando, e pode ser muito confuso para um solucionador de problemas. Se você gastar uma parcela significativa do seu tempo no código, você terá dificuldades para mudar sua mentalidade para resolver grandes questões não técnicas.
  • À medida que sua equipe cresce, mais e mais tempo será gasto em questões de pessoas, e isso começa cedo. Conversei com CTOs que têm menos de cinco pessoas em sua equipe e já sentem que mal têm tempo de codificar. Se a sua empresa for bem-sucedida, você vai crescer rapidamente até o ponto em que, se quiser que sua equipe tenha um alto nível, terá de investir energia para torná-la bem-sucedida. Se você acha que escrever código é o seu “trabalho real”, então você passará o dia inteiro frustrado com as interrupções.
  • À medida que o negócio cresce, o mesmo acontece com as demandas da tecnologia. Alguém tem que mediar essas conversas e traçar um curso que equilibre as necessidades de negócios com os recursos técnicos. Infelizmente, isso significa reuniões, o que tira tempo da codificação. Se o seu valor para a empresa é baseado na saída do seu código pessoal, você terá que fazer uma escolha: ter voz nas decisões ou apenas implementar os resultados. Você não pode fazer as duas coisas, e se você abdicar dessa responsabilidade, então você relega a sua organização para se tornar um grupo de tomadores de pedidos.
  • Se a sua autoestima como líder é baseada em ser o melhor engenheiro na sala, então você rapidamente se tornará, na melhor das hipóteses, um fator limitante no que sua equipe pode realizar e, no pior dos casos, uma influência destrutiva na equipe. Eu já vi isso acontecer mais de uma vez, onde grandes engenheiros se tornam líderes terríveis porque sentem a necessidade de provar constantemente a si mesmos. Para ficar no topo da pilha, eles ou contratam pessoas que são piores engenheiros ou insistem em estar no código muito tempo depois de terem liberado o controle para sua equipe, frustrando a equipe e afastando os melhores engenheiros.

Tudo se resume a isto: baseado apenas em demandas de tempo, ser um líder de tecnologia eficaz significa que você terá que sair do código eventualmente. Aqueles que se dedicam à codificação entregam essas responsabilidades de liderança a outras pessoas ou tentam cobrir a lacuna colocando mais horas, o que as queima ao longo do tempo. E os líderes de engenharia que acham que seu valor principal para a empresa é baseado em sua capacidade de codificação geralmente se sentem fracassados à medida que suas equipes crescem porque ninguém lhes disse que precisam mudar seu foco de sua produção individual para a produção da equipe .

Se você confia em suas habilidades práticas de codificação à medida que escala, rapidamente se tornará um gargalo, especialmente se ser o melhor engenheiro da empresa continua sendo sua principal medida de sucesso como líder.

Então, você tem que ser um programador para ser um CTO? Minhas respostas:

  • É um ótimo ponto de entrada, mas não é a única maneira de entrar. Ser um programador prático pode ajudar com uma pequena equipe, mas, nesse ponto, você não está atuando como CTO: você está atuando como um colaborador individual. O rastreamento de candidatos e a revisão do código estão corretos no início, mas não são escalonáveis.
  • Cumprir a função estratégica primária do CTO – aplicar a tecnologia para obter vantagem competitiva para sua empresa – exige a capacidade de entender e aplicar a tecnologia, mas não a capacidade de implementá-la. Conhecimento detalhado de codificação pode levar a entender o que a tecnologia pode fazer pela sua empresa, mas não é o único caminho e os detalhes muitas vezes atrapalham.
  • Um CTO efetivo deve estar na intersecção de negócios e tecnologia e ter uma compreensão fundamental de ambos os domínios. Você pode chegar lá de qualquer direção, contanto que você esteja disposto e capaz de investir o tempo necessário para entender e funcionar bem em ambos os lados da conversa.
  • À medida que as responsabilidades da CTO aumentam, a capacidade detalhada de codificação torna-se cada vez menos relevante, e a insistência em manter-se ou ser o melhor engenheiro na sala rapidamente se torna um fator limitante da eficácia da CTO e da equipe. Em vez disso, o CTO deve mudar seu foco para tornar sua equipe o mais eficiente possível, trocando problemas técnicos por problemas de pessoas. Muitos tecnólogos puros lutam com essa transição.

Esse debate é um ótimo exemplo do desejo humano de prototipar as coisas (e as pessoas) depois de nossas próprias experiências. Nós olhamos para um problema desafiador – como construir uma empresa ou uma carreira de sucesso – e dizemos: “Isso funcionou bem para mim. Portanto, a melhor solução é a minha. ”É fácil, é natural e parece que é apoiado por evidências. Quero dizer, olha só a minha experiência! É também, perdoe a frase, pensamento preguiçoso . Uma vez que é baseado em evidências anedóticas, é semelhante a dizer: "Está muito frio aqui em Minneapolis, então o aquecimento global não é real!"

Esse debate é um ótimo exemplo do desejo humano de prototipar as coisas (e as pessoas) depois de nossas próprias experiências.