Como uma startup perde o vigor
(blog.johnqian.com)- Em uma startup em estágio seed bem administrada, engenheiros encontram problemas dos usuários e conduzem diretamente a implementação e o lançamento, mas, à medida que a empresa cresce, esse ciclo se transforma em um trabalho mais lento e fragmentado
- Equipes com menos de 10 pessoas têm alta velocidade de implementação graças ao contato com usuários, à escolha de ideias, ao feedback dos colegas, a uma base de código pequena e a deploys leves
- Em organizações com mais de 100 pessoas, o contato com usuários é separado para PMs, e a velocidade de trabalho cai muito conforme se acumulam revisões de segurança, CI, reviews de PR e processos de infraestrutura
- Por trás da mudança estão a redução do alinhamento de interesses, a comunicação O(N^2) causada pelo aumento do número de funcionários e a menor tolerância a riscos à medida que crescem o número de usuários e a regulação
- É difícil impedir completamente que a diversão desapareça, mas é possível retardar isso evitando copiar cedo demais processos de grandes empresas, desenhando pequenas equipes independentes e incentivos, e reduzindo a velocidade de contratação
Por que trabalhar em uma startup pequena parece viciante
- Em uma startup em estágio seed bem administrada, o trabalho central de um engenheiro é entender problemas dos usuários, criar ideias, discuti-las com colegas, implementá-las e repetir o ciclo de lançamento e retrospectiva
- Em equipes com menos de 10 pessoas, cada etapa desse ciclo pode ser prazerosa
- É possível falar diretamente com usuários interessantes, tomar uma cerveja com eles e conversar
- Ao encontrar uma ideia valiosa para a empresa e pessoalmente interessante, dá para parar o que se está fazendo e começar a trabalhar nela imediatamente
- Os colegas têm interesse direto no desempenho da mesma empresa, então há incentivo para estimular boas ideias e explicar os problemas das ruins
- Um colega também pode ser usuário daquela ideia, querer trabalhar junto nela e conhecer uma parte grande da base de código, aumentando a chance de oferecer insights úteis
Implementação rápida e grandes expectativas
- Em equipes pequenas, a velocidade de implementação é alta
- Você pode escolher as ferramentas que quiser, e não há revisão de segurança
- A base de código é pequena, então dá para manter a estrutura inteira na cabeça e tentar grandes refatorações com relativa tranquilidade
- Graças ao hot reload rápido, é possível repetir ciclos de depuração por tentativa e erro rapidamente
- O merge de mudanças também é leve
- O CI não tem testes lentos, e mudanças seguras talvez não precisem de review bloqueante de PR
- Dependendo do caso, dá para fazer push direto para
master; para mudanças arriscadas, pode-se tocar no ombro de um colega e pedir review - Se não houver muitos usuários, é possível aceitar downtime para fazer mudanças rápidas no backend ou no banco de dados
- Em uma startup pequena, a expectativa de que qualquer coisa é possível é forte
- Um novo recurso pode aumentar o valor da sua participação acionária, e depois outras pessoas podem continuar construindo em cima dele
- Também é possível esperar uma situação em que um usuário diga: “foi você que teve essa ideia? Você salvou minha vida”
- Como todos os membros da equipe compartilham interesses, surge um clima de torcida pelo sucesso uns dos outros
Como o mesmo ciclo muda quando a empresa cresce
- Em organizações com mais de 100 pessoas, o contato direto com usuários diminui
- Conversar com usuários passa a ser papel do PM, e engenheiros podem acabar recebendo apenas resumos de insights de usuários e listas de prioridades
- No pior caso, recebem uma lista confusa de tarefas baseada em um entendimento equivocado dos usuários ou na visão autocentrada de um gerente, sem ninguém para explicar por que cada tarefa é importante
- Fica mais difícil escolher imediatamente o trabalho que você quer fazer
- Se todos fizerem o que quiserem, surge um caos de comunicação O(N^2)
- Gerentes desenham o plano individual levando em conta também outros trabalhos da organização
- Suas próprias ideias podem ter de esperar até que o trabalho definido seja concluído, ou ser tocadas às escondidas no tempo livre
- Ainda é possível conversar sobre ideias com colegas, mas o interesse e a disponibilidade diminuem
- O benefício que um colega obtém com o sucesso individual é menor, e ele também pode se tornar um concorrente em promoções
- Cada um tem uma longa lista de tarefas, sem liberdade para largar o que está fazendo e trabalhar junto
- Também é provável que faltem memória ou contexto sobre aquele código
Por que a implementação fica lenta em organizações grandes
- Em organizações com mais de 100 pessoas, a escolha de ferramentas já está definida
- Mesmo que exista uma nova ferramenta melhor, pode-se concluir que ela não vale o custo de quebrar a consistência
- Para usar uma nova ferramenta, é preciso perguntar ao gerente e mandar e-mail para a equipe de revisão de segurança
- Bases de código grandes crescem principalmente por motivos legados
- Há muito código que dá medo de mexer, e muito código que ninguém mais entende
- Testes rigorosos se tornam a única base de confiança de que o sistema inteiro não vai quebrar
- A depuração por tentativa e erro é necessária, mas o tempo de compilação é longo, tornando o ciclo de repetição mais lento
- Mesmo fazer merge de um PR pequeno pode levar 2 semanas
- É preciso esperar 20 minutos pelo CI e, se algum teste for flaky, rodar de novo
- Enquanto se espera pelo review, conflitos de merge se acumulam
- O revisor não tem contexto ou motivação suficiente, então pode fazer apenas comentários pequenos em vez de sugestões importantes
- O processo de incorporar mudanças solicitadas, fazer push de novo e esperar mais 20 minutos pode se repetir três vezes por PR
- Uma mudança de infraestrutura pode virar um processo de 14 etapas para evitar downtime ou perda de dados para 10 milhões de usuários
- Mesmo depois de trabalhar discretamente por 3 meses e lançar, a recompensa e o reconhecimento podem ser limitados
- Você ganha a chance de fazer uma demo que o CEO pode ver na reunião de sexta-feira, mas, na prática, só alguns colegas prestam atenção
- O gerente pode dizer que isso ajudará no ciclo de avaliação de desempenho daqui a 5 meses
- No melhor caso, você recebe um aumento salarial de 20% e uma mudança de cargo; no pior, uma reorganização 4 meses depois traz um novo gerente, e o projeto perde prioridade ou é cancelado
Como retardar a morte da diversão
- Essa mudança está mais para algo a ser retardado do que totalmente impedido
- As causas fundamentais são a redução do alinhamento de interesses, a comunicação O(N^2) e a menor tolerância a riscos
- A redução do alinhamento de interesses e os problemas de comunicação ficam difíceis de evitar conforme o número de funcionários cresce
- A menor tolerância a riscos é consequência do aumento do número de usuários e também se relaciona parcialmente à regulação governamental
- Startups podem antecipar desnecessariamente a corporatização ao copiar processos de grandes empresas
- Ao contratar gerentes vindos de grandes empresas, o playbook que eles usavam pode vir junto
- Muitas startups usam Jira apenas porque grandes empresas usam, mas a posição aqui é que esse tipo de prática deve ser evitado
- Pode-se dizer que a Y Combinator ampliou a percepção de que grandes empresas deveriam tentar operar como startups
- O playbook de grandes empresas é feito para grandes empresas e, quando uma startup chegar ao ponto de crescer, podem existir soluções melhores para lidar com problemas de escala
- Ao enfrentar dores de escala, é melhor resolver a partir de primeiros princípios ou se inspirar em startups que se movem mais rápido mesmo no mesmo porte
- Estruturar a empresa como várias startups independentes é algo que vale tentar dentro do possível
- A Rippling é citada como um exemplo que conseguiu fazer isso em alguma medida
- Porém, como os componentes do produto costumam ser conectados demais e a maioria deles não consegue gerar receita sozinha, geralmente há limites
- O desenho de incentivos pode retardar de forma significativa a redução do alinhamento de interesses
- Mas incentivos tão fortes quanto uma grande participação acionária e o poder de mudar seu valor são raros
- Uma das melhores formas é contratar menos
- Muitas empresas contratam rápido demais por desalinhamento de incentivos dos gerentes, pressão de investidores para parecerem outras startups de crescimento acelerado e falta de compreensão do custo real de uma pessoa a mais
- À medida que ferramentas, especialmente IA, melhoram, aumenta o número de usuários que equipes pequenas conseguem atender
- Fundadores do futuro podem se preocupar menos com essas dores de escala, e o trabalho pode ficar mais divertido para todos
1 comentários
Opiniões no Hacker News
Eu gostava muito do jeito como a Netflix trabalhava 10 anos atrás, quando ainda era pequena. Eles contratavam pessoas maduras e conseguiam eliminar processos; na prática, tentavam desprocessualizar tudo
Como resultado, as coisas simplesmente andavam e, na Netflix daquela época, muitas vezes se esperava que “as coisas acontecessem naturalmente, sem grandes incidentes”. Regiões active-active ficaram prontas em poucos meses, surgiu o Asgard, uma ferramenta de deploy fácil de usar, e o plano de criar uma CDN própria e fazer parcerias com ISPs foi executado em seis meses por umas 12 pessoas
Do ponto de vista de um engenheiro, havia só uma reunião semanal de equipe, e os gerentes e diretores faziam muitas reuniões para alinhar o contexto entre as equipes, então os engenheiros podiam trabalhar produtivamente à vontade. Na época eu achava isso natural, mas depois percebi que era um padrão altíssimo
Você precisa de desenvolvedores capazes de terminar o trabalho sem que alguém os pegue pela mão, mas os gerentes também precisam saber coordenar, em vez de controlar pegando pela mão
Mas, se for um produto que precisa receber inputs subjetivos de duas ou mais pessoas e melhorar de forma iterativa, comunicação e colaboração distribuída são importantes e necessárias. Isso não quer dizer que tenha de ser doloroso, mas o modelo da Netflix acima não se aplica em qualquer lugar e não deve ser copiado cegamente
Nos lugares em que trabalhei, o produto não era bem definido, não por descuido, mas porque era novo e tinha uma forma indefinida, então ninguém sabia o que ele deveria ser. Já a Netflix tinha o objetivo claro de “levar vídeo para a tela da forma mais eficiente possível”, o que se aproxima de resolver um problema puramente técnico
Claro que deve continuar havendo desenvolvimento de produto em áreas como publicidade ou back office, mas fico me perguntando se a missão central do produto é sólida o bastante para que se gaste menos tempo alinhando as pessoas na mesma direção
Sempre reviro os olhos quando vejo textos assim. A pessoa que escreveu parece bem júnior, ou então aquele tipo de fundador com expectativas estranhamente distorcidas sobre por que os funcionários trabalham para a empresa dele
Isso vem muito da cultura peculiar do setor de tecnologia em SF, mas fora dela as pessoas não pensam assim sobre o próprio emprego. Os melhores desenvolvedores com quem trabalhei não estavam “embriagados” pelo trabalho; eram profissionais que sabiam o que estavam fazendo, eram bem remunerados por esse conhecimento e tinham vidas plenas fora do trabalho, com amigos e interesses pessoais
Esse tipo de narrativa é praticamente propaganda para fazer engenheiros jovens e influenciáveis dedicarem ao trabalho uma parcela da vida maior do que o salário justifica. Se você é um engenheiro jovem, não faça isso. Há muitos chefes que se aproveitam do entusiasmo e da ingenuidade para destruir completamente a vida pessoal das pessoas, mas também há muitos lugares que esperam uma relação normal entre empregador e empregado
Quando ele propôs adiar meu salário até o lançamento do produto, anos de táticas de construção de confiança finalmente foram convertidos em dinheiro, e fui percebendo aos poucos que o salário péssimo era intencional. Eles poderiam pagar um salário decente por aquele trabalho, mas, quando pedi uma remuneração adequada, recebi apenas resistência, promessas em migalhas e muros erguidos
Mais tarde, quando pedi o dinheiro atrasado, ele disse que “não tinha dinheiro para pagar”, mas, depois que eu me demiti com raiva, contratou outra pessoa para refazer meu segundo projeto do zero. Eu não era o desenvolvedor mais rápido, e a pessoa nova parece que também era bastante boa, mas, tanto para mim quanto para outro desenvolvedor, meu trabalho estava dando conta do recado
São situações como: “três colegas foram demitidos e agora estou fazendo o trabalho de quatro pessoas, mas meu chefe não me ouve quando digo que estou sobrecarregado”. Uma pessoa profissional provavelmente já teria saído antes das demissões, ou, quando a situação surgisse, estabeleceria limites e negociaria o que vai ou não fazer dentro de uma semana normal de trabalho
A empresa pode demitir sem pensar duas vezes, mas há gente demais que foi condicionada a se preocupar mais com a empresa do que com a própria vida, a ponto de isso não fazer sentido
Depois fui para uma startup e não me arrependo. Trabalho mais, mas é muito mais divertido; talvez eu não consiga fazer isso para sempre, mas a recompensa financeira também melhorou, então acho que não vou precisar trabalhar até os 65 anos como naquele emprego estável e entediante
Isso também não significa que a pessoa não tenha uma vida plena, nem que esteja sendo explorada. Pelo contrário, quem diz que não é assim parece estar tirando menos do trabalho do que poderia. Passar 40 horas por semana desse jeito é meio desperdício
Basicamente, bebeu o Kool-Aid e está em um estado em que nem sabe o que não sabe
Há também fatores que vão um passo além da “faísca” e levam à destruição completa
Esta é uma lista incompleta do que, até agora, vi contribuir de forma significativa para deteriorar ou derrubar equipes de engenharia e produtos: líderes técnicos demais, líderes não técnicos, engenheiros problemáticos e microgerenciamento
Quando uma startup cresce, engenheiros superestrelas migram para papéis de liderança como VP Engineering, arquiteto ou CTO, mas, se não tiverem perfil de liderança, a equipe facilmente vira um zoológico sem visão; por outro lado, líderes não técnicos com pouca ou nenhuma experiência em engenharia são igualmente perigosos
Se entrevistas superficiais deixam engenheiros problemáticos entrarem e as demissões também são frouxas, mesmo que apenas 5% a 10% da equipe sejam desse tipo, eles atrapalham o progresso, evitam responsabilidade, acumulam reputação e empurram resultados ruins, prejudicando muito a moral. Manter uma boa equipe e cultura de engenharia parece tão difícil quanto equilibrar um lápis sobre a ponta
Fundadores iniciantes muitas vezes hesitam demais em dar feedback negativo, rebaixar um gerente técnico demais que deveria ter continuado como IC, ou desligar um funcionário que não se encaixa
Uma startup local colocou um amigo designer de UI de um executivo C-level como VP de Produto; ele não dava conta do trabalho de forma alguma, mas o mantiveram por dois anos “dando a ele uma chance de crescer”. Todos abaixo do VP sabiam que ele era incompetente e conversavam sobre como contorná-lo
No fim, as iniciativas de produto nem chegaram a começar, e a empresa precisou pivotar completamente para trabalho baseado em serviços. É melhor não ficar em uma startup que continua mantendo um líder desqualificado de quem as pessoas da empresa já desistiram
A mesma empresa teve, durante um downsizing, a oportunidade perfeita de eliminar o VP de Produto e seu império, que quase não trabalhava com ele, mas evitou fazê-lo por causa de suas conexões com o C-level e, em vez disso, demitiu engenheiros. Ao começar cortando os engenheiros mais bem remunerados, perdeu engenheiros essenciais, sinalizou que incompetência era tolerada se você conhecesse as pessoas certas e, nos meses seguintes, mais profissionais-chave foram embora
Todo mundo comete erros de contratação, mas a forma como se reage a esses erros determina o destino da empresa
Dá para citar regras práticas como “é preciso dar aos ICs o máximo de autonomia que eles conseguem suportar”, mas toda regra tem exceções. Sabedoria comprimida perde contexto e é facilmente mal interpretada, ou seguida como culto à carga por pessoas com pouca experiência
Vi pequenas dinâmicas surgidas de nuances de personalidade individual e estrutura organizacional levarem a grandes disfunções e perdas de produtividade, mesmo quando todos agiam de boa-fé e faziam o melhor possível. Boa engenharia não acontece com ordens vindas de cima e planejamento centralizado
É preciso haver gente suficiente, incluindo engenheiros na linha de frente, que entenda o produto e o negócio de ponta a ponta, para que pequenas decisões sejam tomadas em alinhamento com o quadro geral e as preocupações certas possam chegar à liderança. É preciso pesar em conjunto os custos de curto e longo prazo de produto, design, jurídico, finanças, suporte, segurança e operações
Isso só é possível com alta confiança e segurança, nas quais especialistas possam expressar opiniões e encontrar compromissos adequados; como ego e choques de personalidade atrapalham facilmente, é necessária maturidade na liderança. A analogia de equilibrar um lápis sobre a ponta é bem adequada
Essa pessoa começa a examinar o aplicativo e a chamar todas as decisões sem contexto de dívida técnica. Já vi isso algumas vezes e cheguei a dizer a um novo VP Engineering que parecia ignorante dizer que problemas e decisões anteriores foram julgamentos ruins quando ele nem estava presente para os problemas, as decisões ou o cronograma
Felizmente, mais tarde ele me chamou em particular, agradeceu e pediu mais contexto. Depois de ouvir a história completa, concordou que tínhamos feito as escolhas certas. Mas também já vi casos seguirem no sentido contrário, e aí é realmente difícil
Colocavam todas as equipes em planilhas e tentavam automatizar a gestão com métricas uniformes, em vez de se concentrar em gerenciar e desenvolver seus subordinados diretos
Por outro lado, vi um líder menos técnico chegar e os engenheiros ao redor revirarem os olhos com um pouco de machismo misturado, mas, na prática, ele demitiu contratações ruins, trouxe jogadores estrela e alinhou as prioridades de todos para torná-los produtivos. Liderança é algo completamente diferente de excelência técnica, e capacidades que deveriam ser recompensadas com aumentos ou bônus são recompensadas com promoção com frequência demais
Pessoas com experiência de liderança, mas que ainda têm competência prática e conseguem, se tiverem tempo suficiente, entender até os detalhes de uma nova stack tecnológica ou de movimentos financeiros, podem conquistar o respeito das superestrelas da linha de frente por suas contribuições de liderança de longo prazo
Discordo. Já comecei uma pequena empresa e também trabalhei em gigantes, incluindo FAANG e grandes bancos, mas esse tipo de ambiente imersivo pode ser criado em qualquer lugar
O ponto central é um líder dinâmico montar uma equipe em que as pessoas saibam exatamente por que estão ali, atribuir a cada uma o trabalho em que é boa e fazer com que quem é bom ajude no que outros não fazem bem. Depois, é preciso deixar claro qual é o valor da missão da equipe para a missão da empresa e para seu propósito no mundo, e remover obstinadamente as barreiras que impedem a produção e o impacto
Argumentos como comunicação N² são reducionistas e imprecisos. Nenhuma equipe depende de todas as equipes da organização; em geral, o domínio é pequeno e as equipes adjacentes também são finitas. Equipes centrais são exceção, mas uma equipe central que funciona bem não vira overhead N²; ela atua como um ponto de concentração, formando uma estrutura N para a qual as equipes vão
N pode ser grande, então triagem eficaz, automação, self-service, plataformas consistentes e autodocumentadas, e pessoas na equipe que realmente gostem de ensinar são importantes. Criar uma equipe assim foi incrivelmente difícil do ponto de vista de gestão e me deixou esgotado, mas gestão deveria mesmo ser incrivelmente difícil. No próximo trabalho, vou voltar às raízes por um tempo como distinguished engineer em uma startup em estágio avançado
Dito isso, é verdade que esse tipo de ambiente imersivo pode ser criado em qualquer lugar, e que é importante haver um líder dinâmico que monte uma equipe cujas pessoas saibam por que estão ali. Ainda assim, acho que isso tem relação com escala e incentivos ruins. Já ouvi dizer que, mesmo em FAANG, algumas áreas parecem startups, enquanto outras são um tédio que suga a alma
O contraexemplo apresentado não é um exemplo de que a complexidade N² não existe, mas de que ela foi gerenciada corretamente
Se você está dizendo que nem toda equipe depende de todas as outras equipes, então na verdade está concordando com o texto. Nesse caso, não entendo qual parte estaria errada
A eficiência de escala que se diz obter em organizações grandes, na prática, não parece eficiência. Refiro-me à eficiência de ter especialistas em recrutamento, RH, garantia de qualidade, pesquisa com usuários e assim por diante
Em vez de criar uma estrutura organizacional mais “eficiente”, talvez seja melhor fazer a organização crescer replicando repetidas vezes a menor equipe que funcionou de forma eficaz. Mas aí a forma de essas “miniempresas” se comunicarem eficientemente entre si é outro problema
Quando o valor da empresa aumenta e entram acionistas e gestores com menor apetite a risco, é preciso gastar muito dinheiro com gestão e mitigação de riscos. Em uma empresa anterior, um concorrente violava a lei descaradamente para atender às demandas dos usuários, mas, por ser pequeno e não ter receita, parece ter passado ileso
Além disso, pela minha experiência pessoal, a maioria dos funcionários não investe tanta energia quanto os fundadores, o que é completamente compreensível. Conforme a proporção de fundadores para funcionários diminui, você acaba contratando três pessoas para concluir de forma estável e pontual algo que você conseguiria fazer sozinho
As primeiras contratações são próximas dos fundadores e têm muito a ganhar se a empresa tiver sucesso, então se parecem mais com os fundadores; já o 213º funcionário vende 40 horas de trabalho por semana e, na prática, tudo o que recebe é um salário fixo. A ideia romântica de uma grande empresa formada por várias startups independentes é bonita, mas nunca vi funcionar na prática e nem consigo imaginar muito bem
Acho que a melhor forma de escalar é criar processos que reforcem as características desejadas nas equipes e contratar gestores que entendam que equipes são conjuntos de indivíduos diferentes. O gestor deve ter liberdade para administrar suas pessoas de um jeito que otimize entregas e reduza rotatividade
Entre equipes, os padrões de comunicação e de qualidade dos resultados precisam ser muito altos, e a cultura organizacional deve ser construída sobre respeito por cada pessoa contratada e um foco obstinado em colocar cada uma em uma equipe onde possa trabalhar de forma eficaz
Os frutos do trabalho ficam pendurados cada vez mais alto. No início de uma startup, o espaço de problemas é abundante, o impacto que uma pessoa consegue gerar é anormalmente grande, e o número de pessoas com quem dividir esse resultado é o menor possível
Quando a empresa cresce, os três fatores sofrem pressão. O espaço de problemas fica mais raro, o crédito por grandes impactos é cada vez mais apropriado pelos níveis superiores da hierarquia, e o número de pessoas que compartilham o impacto aumenta, enquanto o reconhecimento fica breve e difuso
Mas, no fim, acabou virando uma única organização gigante. A estrutura horizontal da Valve é parecida. Quando algo cresce o bastante, no fim tudo acaba virando um bloco só
A arte de gerenciar o crescimento está, em grande parte, em encontrar formas de libertar as pessoas em vez de acorrentá-las
A frase “a maioria das startups copia processos de grandes empresas e acelera desnecessariamente sua corporativização. Normalmente trazem gestores vindos de grandes empresas, e eles trazem seus próprios playbooks” é dolorosamente precisa
Passei por esse ciclo algumas vezes. A startup de que mais gostei, e a última bem-sucedida, foi adquirida por uma enorme empresa global em 2007, no seu quarto ano, e eu fiquei por mais dois anos.
Depois do lançamento do produto, ela ficou claramente mais lenta por causa da necessidade de suporte ao cliente e apoio a vendas. Um ótimo VP de Engenharia virou CTO, e os bons tempos acabaram quando contrataram um idiota de gerência intermediária como VP. O novo VP contratava “jogadores de equipe” em vez de bons engenheiros, recompensava lealdade acima de competência, e coisas ridículas aconteceram.
Meu tempo divertido, parecido com uma startup, encolheu para exatamente uma semana por ano, entre o Natal e o Ano-Novo. Nessa semana não havia ninguém, então eu tinha muito mais liberdade para trabalhar no que achava importante e conseguia criar uma versão alfa de algum novo recurso chamativo, fazendo a organização correr atrás.
O grupo de candidatos tem uma quantidade surpreendente de gente com perfil de tubarão. Eles aparecem, percebem que você é novo, dizem tudo o que você quer ouvir e prometem resolver todos os problemas. Afirmam que, em todas as empresas anteriores, fizeram exatamente aquilo de que você precisa, bajulam você e dizem que estavam esperando a chance de trabalhar com alguém como você.
Pense neles como uma versão cinco vezes mais intensa e mais difícil de detectar do candidato IC mais escorregadio que você já entrevistou. Eles têm um carisma inacreditável, mas pouco interesse em fazer o trabalho difícil; depois de se infiltrarem na empresa, começam a extrair valor dela.
Extraem a própria remuneração, vagas para contratar amigos, remuneração para esses amigos, contratos lucrativos para amigos terceirizados e talvez até propinas. Como geram muita atividade, pode levar anos até as pessoas perceberem que, na prática, eles fizeram muito pouco. Nesse processo, funcionários competentes acabam indo embora por se cansarem da bobagem ou são empurrados para fora por terem apontado a incompetência.
Loonshots, de Safi Bahcall, explica esse fenômeno muito bem. Por volta de 150 pessoas, ocorre uma “transição de fase” nos incentivos, que pode ser fatal para muitas organizações.
O segredo está em como a startup ultrapassa esse número de pessoas. Francamente, muitas empresas de software talvez nem precisem de mais de 150 funcionários.
O número de Dunbar é um conceito proposto como o limite cognitivo do número de pessoas com quem é possível manter relações sociais estáveis. Aqui, relações significam saber quem cada pessoa é e como elas estão conectadas entre si.
https://en.wikipedia.org/wiki/Dunbar%27s_number
O mundo já escalou além desse limite há milhares de anos, e empresas também podem escalar além dele.
É impossível enfatizar demais o valor da recomendação de contratar menos. Em outras palavras, só contrate quando não houver outra forma de resolver o problema — e mesmo assim com cuidado.
É preciso aceitar que esse princípio alonga bastante os cronogramas. O custo de médio e longo prazo de contratar demais é muito pior do que o custo de atrasar um lançamento. Infelizmente, o ambiente de captação de recursos e as expectativas de crescimento das startups muitas vezes incentivam o comportamento oposto.
Dito isso, eu subestimei bastante o quanto a situação de contratação nas startups do Vale do Silício ficou ruim. Muita gente está usando startups como um item para colocar no currículo enquanto se recupera do burnout em FAANG ou se prepara para entrevistas.
Nessa estrutura, por causa do risco de perder as poucas pessoas capazes de construir uma empresa, gerentes de contratação tendem a pender para um otimismo excessivo. No fim, é preciso dispensar agressivamente quem não se encaixa bem.
Houve partes deste texto de que gostei e partes das quais discordei.
A parte com que mais concordei foi “não contrate rápido demais”. Não consigo lembrar facilmente de startups ou empresas que fracassaram ou sofreram por contratar devagar demais, mas consigo pensar em muitos problemas causados por contratar rápido demais, incluindo pela minha experiência pessoal.
Por outro lado, a parte de “não use Jira” me fez revirar os olhos. Assim como o sol nasce no leste, criticar o Jira é um passatempo favorito dos engenheiros. Dependendo do tipo de startup, Jira pode ser uma ferramenta muito boa para o trabalho.
Se a empresa precisa dar suporte a muitos workflows, quando o acompanhamento é ruim e a propriedade dos issues não é clara, muita coisa passa batida e muito tempo pode ser desperdiçado. Claro, também é fácil desperdiçar tempo complicando demais o Jira com um milhão de status desnecessários, mas acho que hoje o Jira ficou fácil para equipes pequenas começarem a usá-lo de forma rápida e produtiva.
Não quero dizer que o Jira seja a melhor ferramenta para começar; na minha startup anterior começamos com Trello e funcionou bem. Mas, quando você entra em operação e precisa gerenciar e priorizar muitos issues operacionais junto com o desenvolvimento de novos recursos, é bem provável que precise de uma ferramenta como o Jira para alinhar todo mundo e compartilhar informações.