O apagão na TI é um fenômeno real, mas um fenômeno bem estranho do nosso mercado é a distância entre o JR e o estagiário, ou seja o profissional possível, e o profissional desejável. É sobre esses problemas que vamos discutir hoje.

De um lado jovens querendo um emprego na TI, a nova mina e ouro do mercado corporativo. De outro empresas com cada vez mais dificuldade para reter e contratar bons profissionais.

Parecia a receita perfeita entre oferta e demanda.

Essa não é a realidade que percebemos no mercado. Formar um profissional custa muito, e não há segurança sobre o resultado sobre o investimento nessa formação.

A real é que em um passado não muito distante, era possível analisar mês a mês se o profissional dava ou não resultado, sem fazer um planejamento de muito longo prazo. Isso permitiu produzir análises mais rasas, sobre o quanto o dev é capaz de entregar por mês. Hoje, a dinâmica de contratação pede que a empresa gaste mais, mime mais, que produza um ambiente mais saudável e isso implica em custo.

Embora não ter esse profissional possa custar muito mais caro em muitos casos, ainda há certo medo e até amadorismo na forma de perceber custo.

Não pensar no LTV (lifetime value) dos desenvolvedores que você contrata e mantém é um risco para seu próprio planejamento.

E na minha opinião o maior problema está em enxergar o time de tecnologia como custo ao invés de enxergá-lo como investimento.

Empresas estão ficando cada vez mais descartáveis

Já faz um bom tempo que o desenvolvedor é protagonista nessa relação. Só o JR passa algum tipo de dificuldade para entrar no mercado. Mas de resto, todos que já estão posicionados no mercado recebem ofertas o tempo todo.

Cada vez as empresas estão mais ousadas na hora de buscar formas de captar novos profissionais.

Aliás, eu já direcionei algumas vezes, algumas consultorias, a usar sua equipe de marketing para redigir textos de vagas, usando técnicas de copywriting para que pudessem explorar melhor a comunicação dos valores e ambições da empresa, a proposta da vaga e assim tornar mais claro e límpido o que será feito e como será feito.

Não dá para dizer que é obrigatório existir um alinhamento e identificação entre empresa e profissional, no entanto a probabilidade de um candidato aplicar para uma vaga ou mesmo de entrar e permanecer na vaga tende a ser maior quando essa identificação ocorre.

Empresas estão em blacklists dos profissionais

Algo que as empresas não fazem ideia é de que elas possuem uma reputação perante o mercado.

Mas não estou falando dos seus clientes, estou falando dos seus colaboradores e dos colaboradores em potencial.

De forma física, não há uma blacklist escrita em um papel, um excel, ou em um banco de dados. Ela está presente na cabeça de cada desenvolvedor que acumula na memória diversos feedbacks que escuta ao longo do tempo.

Cada feedback constrói um fragmento de um quebra-cabeça incompleto, que é usado para tomar a decisão entre:

• Responder ou não responder a uma investida de um recrutador
• Decidir participar ou não de um processo seletivo
• Decidir entre uma ou várias propostas

Na prática conversamos sobre o que rola nos bastidores de cada empresa e isso ajuda outros desenvolvedores a formar uma consciência sobre como é trabalhar naquela empresa.

Claro que esse tipo de ação produz fantasmas, as vezes a relação do narrador com a empresa não é um padrão da empresa, ou as vezes até é uma percepção equivocada do que está acontecendo. Não é muito incomum esbarrar em leituras erradas da própria situação.

Mas o fato é que independente de ser certo ou errado, da percepção passada pelo dev estar aderente ou não com a realidade, esse tipo de conversa acontece em ambiente privado/particular e outros desenvolvedores pegam um pouquinho daquilo para formar sua pré-opinião e formar seu pré-julgamento a respeito da empresa, projeto e/ou equipe.

A sobrecarga

A maioria dos devs com que eu tive conversas sobre sobrecarga e demanda disseram se sentir sobrecarregados. Há cada vez mais relatos nas redes sociais, principalmente LinkedIn, sobre desenvolvedores que deram uma parada durante algum momento nos últimos meses porque estavam beirando a exaustão mental.

A pandemia colaborou com o stress, já que agora a jornada de trabalho parece ter aumentado não oficialmente. E por incrível que pareça há empresas empenhadas assegurar que seus colaboradores voltem à normalidade, no que diz respeito entre balanceamento entre vida e trabalho.

Quem entendeu que bem estar gera produtividade, consegue compreender bem a importância disso.

Leitura recomendada: Don’t expect employees to answer late-night emails: Microsoft Boss Satya Nadella @ businesstoday

O que é possível perceber é que a demanda aumentou e a pressão está bem maior. Não dá para concluir sobre a causalidade de um em razão do outro, mas é provável que este seja um dos fatores.

Com mais demanda, mais pressão, e dificuldades para contratar, temos a receita de bolo para o caos.

A contratação de desenvolvedores é um processo crítico e a formação dos novos devs se torna ampla, comum e frequente.

Se de um lado a demanda e pressão aumentaram, do outro o dev que estava acostumado a medir sua produtividade pelo pelo código, caso de uso, funcionalidade que entregava, agora tem outro dilema.

Agora sua métrica de produtividade precisa levar em conta o quanto ele ajudou seus pares. E isso não é fácil de ser percebido como produtividade.

A maioria dos devs que conheço, acham que ao ajudar o amiguinho, estão trabalhando, mas ao mesmo tempo não conseguem perceber isso como produtividade.

Embora se sintam bem ajudando, se sentem improdutivos. Não conseguem perceber o tempo que passaram ajudando outros devs, como produtividade.

É como se ao mesmo tempo ele soubesse que está ajudando e fosse mentalmente recompensado por conseguir ajudar. Mas do outro lado sente-se sente-se frustrado por “não ter sido produtivo”.

É irracional, não é lógico e basta uma gerência ligeiramente desalinhada para essa sensação se multiplicar.

Formar pode parecer um esforço em vão

Algo que chama a atenção é a percepção do dev de que o esforço empenhado em formar outro dev será um esforço em vão.

A foto do mercado hoje é marcada por um alto turnover. Ao mesmo tempo alguns desenvolvedores escalam de JR a SR em remuneração sem alcançarem a senioridade de fato.

Para isso usam empresas como trampolim.

As empresas muitas vezes flexibilizam na contratação, fazendo o desenvolvedor caber na vaga. Ou seja, o dev está abaixo do skill necessário, abaixo da senioridade necessária, mas é aceito porque é o mais próximo que alcançaram com o valor que podem pagar.

Eu já presenciei feedbacks de desenvolvedores que relatam que não enxergam valor nesse processo de formação de outros desenvolvedores porque ao invés de encontrarem nesses novatos um alívio para sua sobrecarga, se sentem-se usados como parte desse trampolim que o novato faz.

A percepção é de que o novato tem muito potencial para deixar a empresa nos próximos meses e de fato há uma parcela significativa que fica pouquíssimo tempo na empresa.

Quando um novato que está em formação pede demissão, o dev mentor se frustra. Afinal há uma quebra de expectativa. Quando o mentorado entrou, a expectativa era que esse mentorado, no futuro, pudesse suavizar a demanda do time, e assim reduzir a pressão e a sobrecarga. Com sua saída o sonho de dias melhores vai por água abaixo.

Nesse momento ele questiona o quão improdutivo ele foi durante esse tempo, o quanto poderia ter aproveitado para sanar seus próprios débitos técnicos e backlogs.

Esse momento de frustração é um bom momento para repensar se vale ou não estar naquela empresa, não acha?

Isso não é uma sugestão, mas um ponto de atenção para gestores ou quem quer que esteja empenhado em reter talentos. Esse é um momento em que o dev que a princípio estava “retido” na empresa, cogita sair.

Então faz sentido ter certo cuidado a mais com esse dev que perdeu seu mentorado para o mercado. O mínimo do mínimo que se pode fazer é conversar com ele sobre essa saída e dizer que está atento e entende o empenho dele nesse processo.

É sobre se importar.

Qual o impacto da flexibilização dos perfis?

Contratar um bom dev com uma ou duas décadas de experiência custa caro.

Formar é uma alternativa mais barata. Mas a produtividade só chega com o tempo. Ou seja: é um investimento em que nos primeiros meses não se paga.

O meio termo, era o caminho natural: Não buscava-se os especialistas com 15 anos de experiência, mas também não buscava-se os novatos. Nesse espaço entre o pleno e o especialista, é onde a maioria dos desenvolvedores estão. Esse é um dos melhores perfis do ponto de vista do contratante, porque ele é imediatamente produtivo o suficiente para se pagar em pouquíssimo tempo. E com isso é muito fácil gerir custo e entender se há retorno sobre o investimento ou não.

Como resultado, a disputa por esse perfil aumentou drasticamente.

A falta de desenvolvedores produz sobrecarga sobre o time, aumenta a pressão, o stress e tem muito potencial para aumentar o turnover. Se estava ruim contratar, agora você está perdendo seus melhores profissionais.

Então para estancar o sangramento, a empresa é obrigada a flexibilizar. E ela tem 2 formas óbvias de fazer isso:

• Pagar mais | Aumentar seu range de salários para se tornar competitiva. E as vezes ela faz isso da forma mais errada possível: colocando um JR ou PL como SR.
• Aceitar menos | Cortar skills necessários para uma vaga para achar o dev que se encaixe no perfil com o valor que se tem de budget.

Vamos supor que você flexibilizou e fez uma péssima contratação.

Existem algumas formas de errar:

Soft Skills

Mas nada custa mais caro do que um dev que coloca o time inteiro em conflito, com intriga.

O famoso desagregador.

Aquele que tudo reclama e acaba dando voz para problemas mínimos, transformando pedras no sapato em um vulcões em erupção.

Hard Skills

O lambão, aquele que o visual studio tem no menu de contexto do solution explorer “Add new problem“! Também custa caro demais.

E esse fenômeno de virar sênior só na carteira, usando empresas como trampolim tem muito potencial para produzir esse tipo de profissional. Esse cara é uma bomba relógio para seu time.

Mas qual é a solução?

Minha intuição me diz que formar é o melhor caminho. Mas não só.

Use o time

Usar mais o time no processo de contratação é de suma importância para assegurar a conexão entre esse novo candidato e o time.

O time também deve ser crítico quanto às habilidades técnicas do candidato.

Não promova só para trocar de faixa salarial

Promover um JR a SR só porque você não tem budget não é uma solução, é um problema. Não só para a empresa atual, mas para todo o mercado.

E quando eu estou falando em promover um JR a SR, eu não estou falando de promoções autênticas, aquelas em que o profissional simplesmente evoluiu e merece a promoção. Estou me referindo à promoção feita por qualquer motivo aquém dos HARD e SOFT SKILLS.

Ao promover um dev JR a SR você está desmotivando todo o seu time e de quebra está colocando um SR incompleto no mercado.

É importante classificar bem o candidato e promover o desenvolvedor de acordo com seus HARD e SOFT skills.

NUNCA SÓ POR HARD SKILL.

NUNCA SÓ POR SOFT SKILL.

Sempre por AMBOS.

O preço de catapultar o candidato de JR para SR é o preço de criar um ambiente nocivo e canibal entre seus próprios funcionários ou colaboradores. Talvez eles tenham ralado demais para chegar onde chegaram, e uma catapultada dessas desmotiva todo mundo que toma ciência do fato.

E para averiguar isso, basta ver o código, basta ver o comportamento, enfim, basta trabalhar junto. Não é necessário que as pessoas conversem para que isso seja exposto. Alguns percebem antes outros depois, alguns nem percebem.

E para quem acha que isso é apenas um problema da empresa, lamento avisar, mas é um problema também para o dev que aceita. Como SR ele será cobrado como SR, mas pela falta de experiência, jogado às covas dos leões. Fará o que puder para sair do outro lado. E uma parcela de fato vai amadurecer forçadamente e chegar à senioridade.

Mas a maioria… essa maioria vai se ferrar de tudo quanto é forma e pior, possivelmente esses pseudo-seniors ajudarão na formação de novos desenvolvedores no futuro. Afinal não é papel do Senior?

Como se não bastasse, embora todos tenham voz, a posição que ocupam muda o peso de cada voz. E acabamos de aumentar exponencialmente a voz de quem não tem maturidade ainda para exercer esse poder.

Dá para imaginar onde vamos chegar né?

Seja competitivo

Muitas empresas simplesmente estão desconectadas da realidade e não fazem ideia de quanto custa um Senior, um Consultor, um Arquiteto.

Se você quer pagar menos de 20k para um arquiteto, saiba que você terá no máximo um bom Senior.

Se você quer pagar menos de 15k para um senior, você terá no máximo um bom Pleno.

Se você quer pagar menos de 6k para um pleno, você terá no máximo um bom JR ou bom Estagiário.

Não há almoço grátis

Se você quer qualidade no software que você produz, se você quer uma aplicação escalável, dinâmica, resiliente e robusta, lamento informar, mas não dá para alcançar isso com um time exclusivamente de não seniors.

Parece óbvio mas precisa ser dito:

O fato de catapultar o JR, um PL a SR não faz dele SR. Faz dele um JR/PL enquadrado como SR. Só.

Ele não produzirá como SR, não performará como SR.

Não dá para magicamente realizar um upgrade de HARD e SOFT skills com uma canetada.

Se você está vendendo uma ideia de que seu produto está sendo construído sob essas premissas(escalabilidade, dinamismo, resiliência, manutenibilidade e robustez) , precisa ter um time com os skills para tal. E esses skills em geral não estão presentes no JR e no PL, porque o que distancia eles da senioridade é exatamente a experiência que os faz esbarrar nessas demandas e faz entender como se constrói aplicações com essas premissas.

Parece óbvio, mas o óbvio também precisa ser dito.

Mas para colocar fogo no parquinho posso assegurar que:

Se você tiver esse time “perfeito” com o balanceamento ideal sobre seniors, plenos e júniores, não terá qualquer garantia de alcançar esse objetivo, mas terá ao menos a oportunidade, a chance de chegar lá.

Mas porque as empresas continuarão buscando o Senior ao invés do JR?

Gestão de risco ineficiente

Primeiro porque a maioria das empresas ainda não aprendeu a lidar com o risco dessa contratação.

As empresas ainda não reagiram direito à essa mudança do mercado, elas ainda não sabem digerir quanto tempo leva para formar um novo desenvolvedor, boa parte não sabe em quanto tempo o dev está pronto. Não sabe quanto ela lucra de fato com cada dev. Não sabem quanto de produtividade é perdida com o acompanhamento de novos devs.

Em casa de ferreiro, o espeto é de pau!

Enquanto as métricas não extrapolarem salário e centro de custo mês-a-mês, não é possível entender quanto se perde no início e quanto se ganha no decorrer do tempo. E essa é a resposta para o sucesso.

O RH ainda está desconectado do data science. E portanto enquanto isso for realidade, será muito difícil gerar números concretos que apontem para estratégias de sucesso provável.

Até lá, será uma jornada pautada na experimentação. E isso leva tempo para alcançar certo nível de maturidade.

Hoje o esforço está quase que exclusivamente direcionado para captar e reter profissionais (não necessariamente talentos).

Mas não tenho visto empenho em produzir métricas.

Sem “observabilidade” as empresas estarão navegando sem feedback dos seus próprios processos.

Algumas empresas investirão em formar esses profissionais. Mas a maioria esmagadora produzirá outras estratégias para captar os profissionais já formados, como meio de filtrar os melhores.

Contratar um dev pronto não é mais barato, mas o feedback é imediato

Ao contratar um dev “pronto” ou pelo menos “mais pronto”, você não coloca tanta pressão na formação desse profissional. Embora ele também tenha uma curva de aprendizado, a capacidade de dar uma resposta quase que imediata sobre sua performance é maior.

As empresas estão mais habituadas a lidar com esse tipo de avaliação. É um sintoma da incapacidade da empresa em ser estratégica.

Note que eu não estou dizendo que isso é fácil, só estou colocando o dedo na ferida.

A quantidade de skills aumentou substancialmente

Na minha opinião essa é uma das maiores barreiras que as empresas encontram para conseguir tornar o processo de formação eficiente. A extensão da jornada de aprendizado.

Esse ponto é um dos mais importantes e determinantes para se contratar um dev pronto ao invés de formá-lo. Há um abismo entre o JR e o SR nos dias de hoje. Um abismo muito maior do que no início da minha carreira.

Se você é um dev .NET, está vendo evolução do C#, do .NET, do ASP .NET a cada 6 meses. Os ciclos de atualização estão cada vez menores e se manter atualizado é uma tarefa cada vez mais difícil.

Ao mesmo tempo você precisa conhecer mais infraestrutura do que no passado. Se no passado precisava conhecer o básico de IIS e quase nada de sistemas operacionais, hoje você precisa conhecer bem mais, principalmente a respeito do Linux, residência padrão do backend .NET hoje em dia.

Como se não bastasse conhecer Linux, você geralmente implanta no Linux usando Containers, e se sua empresa tem mais de 500 profissionais (total), você mais que dobras a probabilidade de precisar de um Kubernetes.

E se você está trabalhando com Docker, Kubernetes, vai em geral produzir 1.5 vezes mais métricas do seu ambiente, do que aplicações que não usam containers. Isso porque você se aproxima de ferramentas que darão suporte nessa jornada.

Também vai buscar ferramentas de gestão de logs, métricas e tracing, precisando de 3 ferramentas para cumprir esse papel.

Se você acha que habilitou Application Insights e pronto, tá observável, você não entendeu nada!

Um dos últimos reports da datadog conta com a análise de 1.5 bilhão de containers.

O reflexo no futuro do mercado

Aqui sequer abordamos as empresas gringas e as milhares de oportunidades que desenvolvedores brasileiros possuem para trabalhar para essas empresas. Isso acirra ainda mais a disputa além de inflacionar o mercado.

Mas um outro fenômeno que já vemos aqui no Brasil é que empresas pequenas viraram incubadoras de desenvolvedores. No entanto, os melhores logo trocam a empresa pequena por uma empresa maior, de maior porte que esteja trabalhando ou fazendo algo mais legal, mais interessante e provavelmente pagando melhor.

Isso faz com que nas empresas pequenas só sobre quem não conseguiu ou quem não teve vontade de ir para essas empresas maiores.

Nesses 2 perfis: os que não conseguem e os que não querem, a esmagadora maioria é tecnologicamente conservadora, e ser conservador em um ambiente de inovação é um tiro no pé.

O resumo é a produção de uma bolha. Uma bolha do mau.

Se esse movimento não for freado, eu acredito que teremos sérios problemas nessas pequenas software houses. Não é difícil vislumbrar que se esse movimento se confirmar, o fracasso é uma mera questão de tempo e sobreviver produzindo produtos com base em uma mão de obra tão desconectada da alta tecnologia custa caro. Custa a própria subsistência.

Ou seja, em algum momento a inovação será exclusividade das grandes empresas, sobrando apenas o bagaço da laranja para essas empresas menores.

Quanto maior a defasagem do time técnico, menor é a competitividade da empresa e seus produtos. Quanto mais defasada, mais difícil disputar profissionais com grandes empresas ou gringas.

Aqui vemos um problemão nas mãos. Se hoje essas empresas pequenas são responsáveis por formar esses profissionais, quem assumirá esse papel caso elas entrem em extinção?

Conclusão

O objetivo desse texto é trazer à luz os dilemas atuais.

Minha conclusão é que essa dinâmica precisa mudar e está claro que é preciso formar os jovens, mas de outro lado está claro muitas empresas não possuem maturidade nesse processo de formação.

Entender que é um jogo de gestão de riscos ou seja de investimento vs risco, e saber criar métricas para determinar sucesso vs fracasso é parte crucial para a tomada de decisão.

Enquanto a única métrica for custo vs receita mensais, a conta não vai fechar, mas a empresa é quem corre o risco de fechar no longo prazo.