Startup e o CTO: procurando o CTO na visão da Startup.
É de conhecimento geral o impacto que um CTO/Head de Tecnologia tem desde o começo em uma startup. Mas é muito difícil conseguir um bom CTO sem um bom investimento. Em geral o que se tem é uma relação de muito desperdício pra ambas as partes e que impacta negativamente pra o ecossistema de empreendedorismo.
Esse artigo está dividido em 3 partes: o cenário na visão da startup; o cenário na visão do CTO/desenvolvedor; e as possíveis soluções pra esse problema.
O Contexto
Muitas startups começam o negócio a partir de gente do mercado ou de escolas de negócios. É natural que se tenha pouca ou nenhuma experiência com o cenário de software, já que em grande escala o recurso é abundante e os projetos de software tem característica MVP, onde M não é mínimo, mas máximo. Desta forma, o contexto começa um pouco complicado, pois ao contrário de muitas outras disciplinas e aspectos de negócio, software é sempre caro e muitas vezes imprevisível.
A terceirização surge como uma primeira solução, desta forma, os fundadores não técnicos tem tempo pra testar o mercado e buscar outras validações. De fato, é algo que faz muito sentido. Aqui se dá o primeiro contato com o mundo de software, o que muitas vezes traz muitos problemas. É comum ver fundadores reclamando das empresas que eles contrataram. Também é comum que eles tenham pouca razão, pois tem pouca noção do que contratam. Mas no fim, a maioria consegue colocar algo no ar e logo depois chega a conclusão que precisa de alguém técnico dentro do time.
É nessa hora que começa a busca (desesperada) por alguém que possa resolver os problemas da empresa. E aqui, no Brasil, vemos muitos problemas que impactam a empresa e o ecossistema de startups como um todo. Abaixo listo as soluções iniciais e alguns erros relacionados com elas.
Contratar qualquer desenvolvedor
Em alguns casos, o que vejo é a Startup contratando um desenvolvedor, em geral com um bom perfil executor e o deixando sozinho pra evoluir o produto. Em geral, há uma boa possibilidade de se conseguir um software bom rodando sem um esforço grande, mas não o software certo. Natural pra um desenvolvedor/executor e pra uma equipe sem experiência com produtos/software.
O problema do produto certo
O maior risco deste tipo de solução é ficar dando voltas e não achar o produto adequado ao mercado em tempo. No começo tudo é muito fácil e as telas vão saindo, mas logo começam as tentações de refazer a home, refazer as telas, mudar o design toda semana, colocar features muito complexas, etc. No geral, um executor não discute muito, não consegue dizer não e argumentar. Então as coisas vão entrando no "plano", e se não dão certo é porque o desenvolvedor não está trabalhando o suficiente. A pressão gera erros em produção, e os problemas vão se somando.
Vamos contratar mais gente…
Uma equipe de especialistas vai se formando, porque o diagnostico é que é preciso mais velocidade. Então se contratam "frontends", "qas", "backends", "devs de apps", etc. Aqui surgem outros problemas relacionados a governança e comunicação. Em geral, decorrentes da falta de experiência, conhecimento e pressão.
E ai todos aprendem que o difícil não é construir um produto de software, mas sim mantê-lo e evoluí-lo. Principalmente no contexto de startups, que se deve manter o metabolismo sempre alto.
As promessas de um futuro incrível
É comum ver alguns tipos de promessas como: "Vamos crescer juntos"; "A gente vê o salário mais pra frente"; "Contratamos mais gente e você se torna o CTO", etc.
Mas quando a desilusão surge, como é se troca o CTO por alguém que faça mais sentido ? e as promessas que foram feitas pra ele ?
Em geral esse é um problema complicado que acontece muito. As empresas prometem uma série de coisas pra o desenvolvedor pra que ele embarque na ideia, depois cobram o "work hard", depois cobram visão de sócio/dono e depois chegam a uma conclusão que ele é o problema. Ai começa o problema em se trocar ele. Há os casos maquiavélicos que fazem isso de forma planejada, mas vamos acreditar que isso não é por querer.
Se esse ponto chegou é quase certo que não há ninguém certo, nem empresa nem funcionário. Todavia, a empresa é a principal responsável por estabelecer um plano que não tem competência pra fazê-lo. Normalmente acha que só trocar resolve, quando o problema, em geral, é bem mais profundo.
Nesse caso, seja transparente e lide com as consequências. É melhor pra todos e pro ecossistema.
Convencer alguém bom por pouco dinheiro
O principal trabalho de um líder de time é saber gerir e planejar a evolução do time. Nesse contexto, saber contratar e manter o empregado é chave. No contexto de Startups, quando você tem um cenário onde há uma alta rotação dentro do time, ou isso faz parte do modelo de contratação, ou isso é um erro que vai custar a evolução da empresa.
A remuneração
Quem não leu Drive e gerencia uma equipe de trabalho criativo (acho que hoje é quase todo mundo), por favor, leia!
A primeira coisa é que deve ser clara é que dinheiro importa. Estamos falando de empresa e não de brincadeira. Você deve ter claro na sua mente que se pagar menos que o mercado ou menos que a pessoa precisa pra viver, isso vai ter consequências.
"The best use of money as a motivator is to pay people enough to take the issue of money off the table."
Dan Pink — Drive
Então, provavelmente, se cometer um erro nesse aspecto você vai ver uma das duas coisas: ou o cara vai embora, ou ele vai ficar trabalhando em mais de uma coisa. O pior cenário é aquele que o Vampeta eternizou na sua frase:
“Eles fingem que pagam e eu finjo que jogo”
Não tem dinheiro pra ser justo, então não contrate.
O problema do equity como salário
Stock option ou equity são ferramentas de retenção, não de contratação. Não podem ser traduzidas em uma quantidade razoável de dinheiro.
Todos nós sabemos que a probabilidade de uma Startup dar certo é baixa, então como você quer considerar isso como um dinheiro real ? Entenda que isso não vai suprir as necessidades do empregado. Ainda, quantos exits ou mesmo realizações você já viu no Brasil ? São pouquíssimos os casos onde eu vi algum empregado de startup ganhar um dinheiro real a partir de equity ou stock.
Equity não é salário.
O padrão sócio/não-sócio
Aqui entramos em um outro problema comum, o padrão sócio/não-sócio. Isso acontece quando:
- O CTO ganha um equity ou stock padrão (até 5%).
- Naturalmente seguindo regras de Cliff e Vesting.
- É cobrado como sócio
Mas de fato, ele não participa das decisões da empresa e pode ser demitido antes de conseguir qualquer direito sobre as ações.
Sócio é sócio. Participa e tem influência. Dar algumas ações sem direitos somente com deveres é um modelo que não funciona com pessoas razoavelmente inteligentes.
Então aqui o melhor é seguir o mercado, usar stock ou equity como ferramenta de retenção, e não inovar nos percentuais. Tão ruim quanto um percentual baixo é um percentual alto (mostra que não sabe usar a ferramenta).
Por fim, o pior contexto aqui é quando se une o desenvolvedor mal pago com o sócio/não-sócio. Por favor, não façam isso!
Continuar com terceirização de escopo fechado
É muito difícil terceirizar software no contexto de Startups. Ainda mais quando não sabemos o que queremos, ou seja, quase sempre. Isso torna um modelo difícil pra ambos os lados.
Por outro lado, já existem várias empresas que fazem contrato de escopo aberto. Aqui o problema é que você não sabe se o seu orçamento vai conseguir desenvolver o que você quer. Mas no fim, você vai ter algo de concreto, o que pode não acontecer com o escopo fechado.
Então, trabalhar com escopo fechado não é brincadeira. É muito arriscado.
Mesmo considerando esses problemas que tem mais haver com a parte funcional do contrato, eu diria que o principal problema da terceirização está justamente na parte menos exata, na qualidade e no compromisso.
Como já disse, o problema não é desenvolver, é manter e evoluir. Você pode terceirizar o desenvolvimento de um aplicativo e dar tudo certo funcionalmente, ou seja, a empresa lhe entregar no prazo com todas as funcionalidades prometidas. O problema é que pra ela concluir ela teve que abdicar de aspectos da qualidade ou adotar algumas soluções "ad hoc". Essas mudanças podem fazer você pagar 10 vezes mais pra evoluir o aplicativo. Pode crer, você vai precisar evoluir se a sua empresa der certo.
Ou seja, se você não tem experiência com requisitos não funcionais e com qualidade de software, a probabilidade de uma terceirização ser boa em longo prazo é mínima.
Um outro aspecto que é ruim nos projetos de escopo fechado é o desperdício. Em alto nível, sempre quando fechamos escopos em escalas maiores que 3 dias é correto afirmar que teremos desperdício. Então imagine num projeto de um, dois, seis meses, e nem sempre em alto nível. Então conte com o desperdício, além de torcer pra que ele seja menor que 30%.
No fim, as soluções que eu listei aqui, embora sejam ruins na minha opinião, ainda sim são as mais utilizadas e continuam sendo "viáveis". Mas pelo menos tenha consciência dos seus problemas, assim, saiba como agir corretamente quando eles acontecerem.
Agora, com o contexto das startups mais explicado, no próximo artigo eu falo sobre a visão do CTO. No terceiro artigo falo sobre as soluções para um possível casamento.
Caso você queira discutir mais sobre isso, por favor, me contacte por alguma rede social: about.me/marcelioleal.
Créditos fotos (CC)
- Markus Spiske / raumrot.com
- RYAN MCGUIRE / http://www.gratisography.com/
