Muito tem sido escrito sobre a importância do autodesenvolvimento do fundador em startups de rápido crescimento. Como regra, os textos sobre esses tópicos são dedicados ao papel do CEO. Dicas gerais de liderança também podem ser úteis para outras funções, mas não consegui encontrar nenhum material para ajudar os fundadores de tecnologia. Depois de ler um monte de formulários S-1, ficou claro que é muito difícil encontrar CTOs do zero que foram de MVP a IPO (enquanto a situação com fundadores-CEOs é exatamente o oposto). Achei esse fato intrigante - decidi cavar mais fundo. Eu queria chegar ao fundo da essência e as razões desse estado de coisas. Também me incomoda um pouco: e se eu não conseguir crescer rápido? Eu deveria descobrir antes que problemas reais surgissem! Quero ser o CTO que torna a RevenueCat uma empresa pública! (1)
É mais difícil para fundadores que não são CEOs crescerem rapidamente? Será que o CEO geralmente tem um apoio significativo? Seja como for, tudo tem suas razões. Talvez eu apenas tenha colocado a pergunta errada. Depois de conversar com muitos fundadores de CTO, ficou claro que não existe uma definição padrão de CTO. As responsabilidades de uma pessoa nesta posição podem mudar completamente dependendo da empresa e do seu estágio de desenvolvimento. O CTO provavelmente está dando muitas sugestões pessoais no início, mas isso pode mudar em breve. A experiência de pessoas diferentes pode ser muito diferente. Infelizmente, não tenho respostas para fundadores que não são CEOs. Talvez eu também não tenha respostas para aqueles que se tornaram CTOs pela primeira vez. Seja como for, achei que seria útil refletir sobre o que aprendi,e como minhas responsabilidades mudaram em 3 anos na RevenueCat.
Dilema: CTO vs. VP de Engenharia
Simplificando, a função do CTO está mais próxima da arquitetura e do código, enquanto o VPE será responsável pelo processo e gerenciamento. Uma analogia seria comparar a trajetória de um engenheiro sênior / em tempo integral e de um gerente de engenharia.
No início, você precisa de um CTO que possa reunir e organizar os executores que criam o MVP. Nesta fase, o fundador pode ser muito útil, pois é necessário definir a visão do produto e a cultura dos processos técnicos. Idealmente, um CTO deve entender o problema que sua startup estará resolvendo.
E se o produto for bem-sucedido? E se o produto entrar no mercado? Nesse caso, você precisará contratar mais engenheiros para atender a demanda dos clientes. Este é um desafio maravilhoso. Talvez você tenha sorte e encontre financiamento, ou talvez já esteja gerando lucros. Porém, quanto maior for sua equipe, maiores serão os requisitos para excelência de processo. O momento chegará inevitavelmente em que alguém terá que se tornar um vice-presidente de engenharia. O início deste momento se tornará aparente assim que os processos existentes (ou ausentes) pararem de funcionar. Em tal situação, você tem várias opções. O CTO pode assumir a função de VP de Engenharia ou a empresa pode contratar funcionários adicionais. Essa decisão provavelmente é uma questão de preferência pessoal e experiência de gerenciamento.Enfrentar esses tipos de desafios requer um conjunto de habilidades completamente diferente, e pode ser difícil adquiri-las em um ambiente onde você precisa crescer muito rapidamente. É por isso que o CTO geralmente é terceirizado.
O fundador pode ser flexível. Ele pode ter autoridade para determinar o caminho que a empresa seguirá. Talvez você odeie gerenciar pessoas e queira continuar com suas habilidades e conhecimentos para trabalhar diretamente com tecnologia. Ou talvez você queira melhorar suas habilidades de gerenciamento. O primeiro tipo geralmente perdoa mais as falhas gerenciais dos fundadores. Eles se juntaram à equipe porque confiaram nos fundadores, acreditaram em suas ideias e estavam confiantes de que tinham boas intenções. No início, eles podem preferir trabalhar diretamente com você, em vez de uma pessoa externa. De qualquer forma, no futuro a empresa terá vários níveis de gestão, então se você quiser trilhar esse caminho e não tiver experiência, então deve aprender, e aprender rápido.
Brian Helmig, cofundador e CTO da Zapier diz que você precisa descobrir o que a dopamina oferece. Pessoalmente, sempre foi mais fácil para mim me comunicar com computadores do que com pessoas. Não tinha a certeza da escolha do caminho de desenvolvimento, mas preferia fazer coisas relacionadas com computadores. Sempre adorei trabalhar com eles e posso dizer que sou mais eficiente como engenheiro do que como gerente. Depois de integrar o novo recurso, me sinto mais fortalecido do que depois de me encontrar pessoalmente.
No entanto, como fundador, recebo altas doses de dopamina quando a empresa está indo bem. Quando os compradores recomendam nosso produto. Quando atingirmos nossas metas de receita. Quando contratamos engenheiros melhores do que eu. Quando esses engenheiros estão satisfeitos com tudo e resolvem com sucesso tarefas ambiciosas. Quando a revisão do código é cansativa, mas é feita em uma atmosfera de colaboração, não de raiva.
Por isso, no final, decidi não só seguir as minhas preferências, mas fazer o que é mais eficaz para a empresa nas diferentes fases do seu desenvolvimento. Afinal, posso resolver problemas. Foi assim que falei sobre meu papel. Minhas qualidades como fundador são mais importantes do que minha posição como CTO. De uma perspectiva de longo prazo, como principal acionista, devo fazer o que for melhor para a empresa.
Normalmente, uma fratura ocorre quando você tem de 8 a 12 engenheiros em sua equipe. Porém, pode ocorrer em outro momento, tudo depende do produto e do ambiente. Como uma empresa totalmente distribuída, enfrentamos vários pontos de inflexão à medida que criamos novos fusos horários em nossos fluxos de trabalho. Naquela época, muitos tinham que assumir as funções de CTO e VP de Engenharia ao mesmo tempo. Tentei aceitar trabalhos para os quais outros não tinham recursos (fiz temporariamente e não muito bem). Isso me ajudou a encontrar pontos problemáticos, estabelecer processos e contratar alguém que possa assumir essas tarefas.
Quando aprendi como outros fundadores gerenciam seu tempo em diferentes estágios de trabalho, fui capaz de navegar melhor em minha função. Desde a fundação da empresa, mantenho um diário. Com base nessas notas, falarei sobre as tarefas nas quais me concentrei e como minha função evoluiu.
2018: YC, MVP e primeiros funcionários
Quando viemos para YCombinator, éramos apenas Jacob e eu. Jacob trabalhou no SDK e front-end e eu trabalhei no back-end. Depois de YC, contratamos os dois primeiros engenheiros para assumir as responsabilidades de Jacob e trabalhar em tempo integral. Todos nós morávamos em San Francisco e já conhecíamos essas pessoas. Tínhamos controles simples (e quase completos). Não havia sobrecarga, tínhamos sprints semanais e nos movíamos muito rapidamente.
Esses dias foram intensos, mas muito divertidos. Lançamos as bases para uma cultura de engenharia e vimos os clientes chegando um após o outro. Passei a maior parte do tempo desenvolvendo as primeiras versões dos recursos sobre os quais os clientes falaram. Atendemos seus pedidos o mais rápido que pudemos. A maioria das solicitações foi processada no mesmo dia.
O que eu mais duvidava na época era que estávamos criando um produto de que as pessoas realmente precisavam e que ele poderia crescer e justificar nossa rodada de sementes de $ 1,5 milhão.
As principais conclusões: são muitos, é muito difícil generalizar. Aprendemos muito quando passamos pelo YCombinator. Provavelmente, vale destacar a comunicação com os clientes, a capacidade de criar o que os deixa felizes e de atender às suas necessidades. Isso e uma entrega muito rápida se tornaram nossos valores fundamentais.
2019: Acompanhamos os clientes e desenvolvemos tecnologias
Parece que conquistamos nosso nicho de mercado. Os clientes nos procuravam, os pedidos de suporte começaram a se acumular e o desempenho de nossa API crescia a cada dia. O primeiro engenheiro remoto de Taiwan juntou-se à equipe. No início, a diferença de fusos horários causou certas dificuldades, foi necessário adaptar os processos de trabalho. No entanto, tudo deu certo. Fizemos um bom trabalho com as consultas e monitoramento dos clientes.
A adaptação foi um processo simples e único. Eu fazia reuniões cara a cara (não com muita frequência, cerca de uma vez por mês), mas gerenciar era muito fácil. A maioria das conversas ainda eram técnicas. Eu ainda estava contribuindo como um artista comum. Também participei de várias conferências.
Naquela época, eu tinha preocupações principalmente técnicas. Principalmente, pensei na escalabilidade de nossos sistemas. Todos os nossos engenheiros tinham experiência com o produto e tínhamos pontos claros de falha. Eu sempre pensei que nada iria quebrar. A balança estava constantemente fora da minha zona de conforto. Temos lidado bem com a otimização dos cenários mais comuns, migração de infraestrutura e evitamos pontos críticos. Também pagamos a dívida técnica acumulada no último ano.
Na verdade, até o quarto trimestre, eu era engenheiro de chamadas. Eu não queria incomodar outros membros da equipe fora do horário comercial e senti que era minha responsabilidade, como fundador do departamento técnico, garantir o máximo de confiabilidade. Eu carreguei meu laptop comigo literalmente em todos os lugares. Por fim, garantimos a rotação. Olhando para trás, entendo que deveria ter sido feito antes.
Principais vantagens: não se concentre na escalabilidade, mas não se esqueça do monitoramento. Esteja atento a possíveis gargalos e pontos de falha. Esses problemas são estressantes, mas lidar com eles não é tão ruim. Contrate e treine engenheiros de chamadas o mais rápido possível, documente soluções para incidentes conhecidos. Confie na sua equipe. Não há nada de errado com a dívida de tecnologia se você abordá-la com responsabilidade e tentar encontrar o produto que terá demanda no mercado.
2020: Delegação e planejamento da futura organização
Em 2020, nossa equipe dobrou mais uma vez. Contratamos engenheiros da Europa e América Latina. No final do ano tínhamos vários colaboradores em cada uma das equipas (SDK, frontend, frontend, ...). Conseguimos trabalhar em vários projetos e, por fim, assumimos tarefas mais ambiciosas. No entanto, precisávamos melhorar a coordenação. Nesse estágio, o trabalho na estrutura de governança não poderia ser evitado.
Durante o primeiro e o segundo trimestres, passei a maior parte do tempo fazendo revisões de código, fornecendo diretrizes de arquitetura e escrevendo algum código adicional. Eu ainda sou a pessoa que entende nossos sistemas. No meio do ano, ficou claro que eu era o gargalo para o lançamento de novos recursos. Eu também fiz reuniões individuais, participei de discussões de brainstorming e não tive mais tempo para escrever código e implementá-lo no prazo.
Eu parei completamente de programar. Em vez disso, confiei minhas tarefas a outros engenheiros e comecei a passar mais tempo transferindo conhecimento. A princípio pareceu que estava demorando muito, mas a delegação fez muitos projetos decolar e deu a muitos engenheiros um forte senso de propriedade. Foi muito estranho não escrever código no início. Eu sentia que não estava fazendo meu trabalho (ou que estava trabalhando de forma improdutiva). Este é um sentimento totalmente natural. Logo percebi que havia me libertado da programação e agora posso ver o quadro geral. Pude pensar no futuro da estrutura de engenharia.
Em termos de gestão, passei a dedicar mais tempo a falar de avanço na carreira e comecei a trabalhar com engenheiros para crescer e se desenvolver. No lado do produto, não tínhamos recursos para priorizar, planejar e coordenar sprints de maneira adequada. Fiz o meu melhor para libertar as pessoas e estabelecer comunicação.
Também passamos pela rodada de financiamento A e começamos a realizar reuniões de diretoria. Também comecei a gastar muito tempo recrutando.
Principal vantagem: novos fusos horários se tornaram mais fáceis de implementar quando se sobrepõem. Diminuir o fator de ônibus é muito importante para dimensionar a equipe de engenharia. Depois de verificar seus fluxos de trabalho e eles estão funcionando, automatize-os tanto quanto possível. Se você não vê a floresta para as árvores, pare de programar e delegue.
Futuro
No próximo ano, planejamos dobrar nossa equipe novamente. Parece que passar de 20 para 40 funcionários é mais difícil do que passar de 10 para 20. No final de 2021, a empresa mudará significativamente.
Acho que vou me concentrar na escalabilidade da equipe. Não me interpretem mal, é claro que enfrentaremos sérios problemas técnicos e temos muitas tarefas ambiciosas em nossos planos. Nos últimos anos, aprendemos muito sobre nossos clientes, problemas e a pilha técnica que fundamenta nossa solução. Trabalhar com engenheiros talentosos com habilidades e entusiasmo para resolver problemas é uma grande parte para mim.
Quero continuar contratando os melhores talentos e manter uma cultura de engenharia saudável. Não vai ser fácil. Terei que trabalhar em estreita colaboração com o gerente de RH para agilizar e automatizar os processos de sourcing, contratação, integração e comunicação. As referências ajudaram a acelerar o desenvolvimento da equipe, mas é hora de focar na diversidade das equipes. Acho que teremos oportunidades de contratação de juniores, gostaria de ajudá-los a atingir todo o seu potencial.
Precisamos melhorar nossa gestão de engenharia para deixar os engenheiros felizes e capacitá-los. Além disso, se quisermos realizar tarefas ambiciosas, precisaremos investir em processos de planejamento. desenvolvimento e lançamento de produtos.
Estou muito animado com o que vai acontecer no próximo ano. É claro que, além dos problemas existentes, surgirão novos. Mas nunca acontece de outra forma. Não será mais fácil!
Espero que este texto seja interessante e útil. Pretendo retornar a este post e complementá-lo com novos conhecimentos. Se esta é sua primeira vez como CTO, terei todo o gosto em ajudar no que puder. Sinta-se à vontade para tweetar ou enviar um e-mail.
Agradecimentos especiais a Alex Plugar, Calvin French-Owen, Xavi Santana, Adam Houghton, Sam Lown, Saul Diez e Will Larson pelos conselhos e pelo tempo dispensado para compartilhar suas experiências. E, claro, a toda a equipe de engenharia do RevenueCat por me permitir fazer experiências com eles, por aceitar minhas deficiências e seus comentários francos.
(1) Com o tempo, aprendi que a ansiedade e o medo são causados principalmente pela síndrome do impostor e que não têm fundamento. Se a empresa supera você, não é necessariamente uma coisa ruim. Na verdade, este é um problema sério! O fundador deve enfrentar isso. Concentre-se em contratar pessoas melhores do que você, que o ajudem a crescer e tornar sua empresa melhor. Ainda quero ajudar o RevenueCat a abrir o capital e, se isso der certo, minhas responsabilidades e posição serão menos importantes.
- Discussão no HackerNews
- Canal de telegrama "HackerNews em russo"