Startup e o CTO: procurando o CTO na visão da Startup.

image

É 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.

image

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.

image

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!

image

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)