Conforme uma inicialização cresce, seus fluxos de trabalho devem mudar. Percebi que isso é especialmente importante para engenheiros. Minha função como cofundador e CTO mudou significativamente ao longo dos anos. Minhas responsabilidades e tarefas diárias mudaram e tive que mudar minha abordagem de trabalho várias vezes para ajudar a empresa a alcançar o próximo nível.
Nos primeiros dias da empresa, a equipe era composta por três caras que trabalhavam à noite e nos fins de semana, serrando no porão o que mais tarde se tornaria Zapier. Antes do lançamento, fizemos três ou quatro versões do produto. Seis anos se passaram desde então, agora estamos processando centenas de milhões de solicitações para nossa API, e nossa equipe emprega 80 especialistas de todo o mundo (incluindo mais de duas dezenas de engenheiros).
O crescimento desde os dias em que éramos três até hoje tem sido muito difícil. Se quiser, você pode ler as conclusões que tirei durante esse tempo. Caso contrário, sugiro que você se familiarize com as lições que aprendi durante minha infância como um novo CTO.
Árvore de desenvolvimento de gerenciamento de tecnologia em uma startup
Antes de irmos muito longe, vamos descobrir - quem diabos é um CTO, afinal? Esta é a pergunta que me perguntei quando contratamos os primeiros dois engenheiros da equipe. CTO - um ditador eterno benevolente que no mundo do software faz a mesma coisa que segue o código? Ou é algum tipo de supergerente ou super hacker?
Pedi conselhos a muitas pessoas. Procurei CTOs na Buffer, Unbounce e outras startups que eram um pouco maiores do que nós. E obtive a resposta: ninguém sabe ao certo. Esta é uma função difusa que não pode ser inserida em nenhuma estrutura. No processo de comunicação, descobri vários padrões de crescimento comuns de pequenas startups orientadas para a tecnologia e formulei o que o CTO deve fazer em cada estágio de desenvolvimento.
Como sou nerd e adoro jogar videogame, a árvore de desenvolvimento me parece a mais óbvia. Conforme você ganha experiência no jogo, você aumenta seu nível e em certos pontos pode escolher diferentes ramos de desenvolvimento.
É assim que a árvore de desenvolvimento do CTO em uma inicialização pode se parecer.
Hacker solitário (1-2 engenheiros)
Esta é exatamente a época em que trabalhávamos no porão. Foi um momento divertido e fugaz. Você faz muitas coisas, quase não há sobrecarga de comunicação e comunicação, porque todos trabalham em sincronia. Você está apenas tentando descobrir o que funciona e o que não funciona.
Pequena equipe de codificadores (2 a 6 engenheiros)
Como fundador de uma startup, você deseja aumentar sua equipe, então começa a contratar pessoas. Normalmente, todo mundo começa contratando amigos. Alguns dizem que não vale a pena contratar amigos, mas acho ótimo nesta fase inicial. Você sabe que pode trabalhar com eles, sabe como eles são inteligentes e se encaixam perfeitamente. O estágio de equipe pequena é quando o CTO começa a sentir a dor de passar do hacking para outra coisa. Ainda é muito bom porque você só tem alguns engenheiros. A sobrecarga de comunicação é bastante pequena. Você ainda está praticamente em sincronia. Você entende o que está acontecendo. Nada te surpreende.
Crescimento da equipe (6 a 12 engenheiros)
Então tudo fica um pouco estranho. Você para de falar com cada um dos membros da equipe. Você terá que lidar com o terrível mistério da gestão, para mim era algo fundamentalmente novo - em contraste com a programação que era compreensível e natural para mim. É nesse estágio que a sobrecarga de comunicação para escrever código aumenta significativamente. Você pode precisar considerar a contratação de pessoas que não são seus amigos. As coisas ficam complicadas porque começam a acontecer coisas que você nunca soube que existiam. Nesse estágio, tudo acontece muito rapidamente e você também encontrará o primeiro branch na árvore de desenvolvimento.
Organização da equipe (12+ engenheiros)
Com uma equipe desse tamanho, você provavelmente trabalha em áreas diferentes. Você não será capaz de lidar bem com pessoas e código ao mesmo tempo, então você tem que fazer uma escolha:
VP de Engenharia: foco no gerenciamento de
CTO: foco em codificação e arquitetura
VP de Engenharia é a pessoa que configura processos, implementa ferramentas, que melhoram a produtividade geral e ajudam os engenheiros a se desenvolver. Se você permanecer CTO, continuará a fazer coisas relacionadas à codificação direta. É o CTO que está familiarizado com todo o sistema de e para, e também sabe onde os esqueletos estão escondidos nos armários.
Você deve ser um CTO?
Eu não estava pronto para tal decisão. Eu nem sabia que teria que fazer uma escolha. Achei que o CTO seria o gerente de fato. Esse parece ser o caso em mais da metade das startups com quem conversei. Independentemente do caminho que você escolher (gerencial ou técnico), você terá que encontrar alguém que assumirá a segunda filial.
Para tomar uma decisão, vale lembrar suas origens. Onde você passou mais tempo, quão confiante você está e para onde gostaria de voltar?
No início, sua equipe terá apenas um ou dois engenheiros. Todo o seu tempo será gasto na codificação, o que é ótimo. Quando sua equipe tiver cerca de 6 pessoas, também vai dar tudo certo. Cerca de 80% do tempo será gasto na codificação e 20% na comunicação. E o fluxo de trabalho ainda será bom. Você terá cerca de 90% de certeza de tudo
E então as coisas ficarão muito mais difíceis. Você estará engajado no trabalho direto na metade do tempo, pois estará ocupado contratando novos e novos funcionários. Haverá mais e mais funcionários precisando de ajuda, e isso não é tão bom, porque você terá que fazer isso e escrever código tanto quanto antes. Neste estágio, você precisa decidir o que deseja fazer - gerenciamento ou desenvolvimento. O que você acha desse movimento ao longo da árvore do desenvolvimento?
Você só precisa encontrar aquele que faz sua dopamina.
Este é um ótimo conselho de um fundador de startups. Você se sente bem se pode ajudar alguém a cumprir uma tarefa? Ou você gosta de resolver problemas técnicos? São as respostas a essas perguntas que devem ajudá-lo a entender qual caminho você deve seguir.
Quatro lições de CTOs de diferentes startups
Falei com 15 fundadores e CTOs tentando decidir o que focar. Perguntei a cada um deles o que notaram ao longo do caminho e as dificuldades que enfrentaram. Nessas conversas, quatro tópicos surgiram constantemente:
1. Aceite pontos de inflexão
Perguntei a todos sobre seu maior erro - que experiência eles tiraram disso, o que e como o consertaram. Então perguntei como eles tentariam evitar isso. Todos pensaram um pouco antes de responder e então disseram algo como: “Sabe, provavelmente não faria isso. Temos que passar por momentos como este para realmente entender o que estamos tentando fazer. Para aprender a fazer isso direito, você precisa se familiarizar com o outro lado. "
Em termos de CTO, trate os pontos de inflexão como um escalonamento do serviço. Se você encontrar gargalos, terá que corrigi-los. Isso é muito mais eficiente porque é muito difícil prever sua aparência - especialmente em startups.
2. Terra de ninguém
É assim que posso chamar uma equipe de 6 a 12 engenheiros. Nessas equipes, um pouco de tudo acontece e é muito confuso. Você perceberá que está dizendo frases como “Por que essa pessoa não sabia disso? E ele não sabia o que fazer? " Se você se deparar com essas questões, não será mais capaz de combinar responsabilidades - você precisará fazer uma coisa e transferir a outra metade das tarefas para alguém que possa lidar com elas. Você não é gênio o suficiente para desempenhar dois papéis ao mesmo tempo, mas não é estúpido o suficiente para ignorar esse estado de coisas. Você parece estar preso no meio.
Nesse estágio, a comunicação pode ajudar a construir pontes. Se você se pega dizendo frases como “Por que X fez isso?” Então você deve começar a dizer certas coisas com mais frequência. Repita até que as pessoas reviram os olhos e digam: "O mesmo de novo" Isso é importante porque ajuda a garantir um nível igual de compreensão entre todos os funcionários.
3. Mimetismo estrutural
Muitas vezes, ouvi CTOs dizerem algo como: "Bem, vimos como eles fazem isso no Spotify ou" Vimos como a Amazon faz isso. " Essas pessoas adotaram a estrutura de outras empresas. Se você, como empresa de tecnologia, inova, não invente métodos de gestão inovadores. Você não deve nem mesmo inventar algo novo na estrutura da sua empresa. Você precisa inovar por meio de sua tecnologia, código e produtos.
Encontre o que você acha interessante e tente aplicá-lo em sua empresa. Com o tempo, sua empresa se tornará única ao combinar ideias e formas de organização que ninguém mais conseguiu. Você pode ser capaz de inventar algo sozinho, mas esse não deve ser seu objetivo. Você deve tentar entender o que as outras pessoas estão fazendo e se esforçar para evitar o aborrecimento.
4. Foco
A última lição é baseada em meus erros pessoais. Quando começamos a contratar engenheiros, pensamos que mais pessoas nos permitiriam trabalhar mais. No início, os fundadores e a primeira dupla de funcionários contratados literalmente faziam malabarismos. Pareceu-nos que todos poderiam trabalhar em dois ou três projetos - e tudo bem. Portanto, quatro engenheiros podem executar de oito a doze projetos ao mesmo tempo, certo? Não, foi um pensamento terrível.
Quanto mais projetos, mais tópicos de comunicação. É muito mais difícil acompanhar todos os processos e ter certeza de que todos entenderam tudo. Olhando para trás, acho que quando contratamos mais gente, valeu a pena manter a carga de trabalho no mesmo nível, e talvez até reduzi-la um pouco.
Nós apenas escolhemos um projeto no qual todos se concentraram. Deixamos claro para todos que essa é nossa prioridade. Havia também algumas tarefas secundárias, mas eram secundárias, nosso objetivo principal era o principal.
Espero que minha experiência ajude aqueles que estão tentando navegar nas águas turvas dos estágios iniciais de startups, especialmente como CTO. Seria ótimo se eu soubesse de tudo isso com antecedência, mas talvez eu não tivesse toda essa experiência. No entanto, é absolutamente normal ficar confuso, adiar decisões para mais tarde e resolver o problema em movimento. Isso tudo é normal, porque nos estágios iniciais as startups têm uma grande variedade de necessidades.
- Discussão no HackerNews
- Canal de telegrama "HackerNews em russo"