Como evoluir de desenvolvedor para executivo de tecnologia

Adalberto Silvestre chama a observação de superpoder — e transforma conhecimento capturado fora do trabalho em valor dentro dele.

A regra que a mulher dele precisava seguir para abastecer um carro corporativo virou insumo de um projeto de consultoria. "Isso é uma coisa que eu ouvi minha mulher comentando, eu usei num projeto que estou trabalhando hoje e está sendo extremamente relevante", ele conta. "É um conhecimento totalmente aleatório."

Ninguém escreve isso no currículo. Mas é esse tipo de captura que sustenta a passagem de desenvolvedor para executivo de tecnologia.

A maioria dos desenvolvedores que aspiram a se tornar executivo de tecnologia trava no mesmo ponto. Aprofunda a coluna técnica até virar referência e, na hora de subir, acha que precisa trocar essa profundidade por discurso de gestão.

Não precisa. O salto não é abandonar a técnica — é alargar a base sem derrubar a coluna. O problema é que quase ninguém ensina como fazer as duas coisas ao mesmo tempo, e a maioria dos modelos por aí ensina o desenvolvedor a escolher um dos dois lados.

O desenvolvedor que vira executivo não troca profundidade por discurso de gestão

Existe uma crença difundida nos corredores corporativos de tecnologia: para subir, você precisa parar de codar e começar a apresentar em slides. Como se os dois fossem incompatíveis.

Adalberto Silvestre é gerente sênior de consultoria digital na Avanade, com passagens por empresas como TikTok e Nvidia, e períodos de trabalho fora do Brasil — incluindo Dubai. Ele construiu uma leitura sobre o que distingue quem evolui de quem estagna: a combinação de uma coluna técnica real com uma barra horizontal de contexto que a maioria dos desenvolvedores nunca foi incentivada a desenvolver.

O profissional em T — conceito que ele usa como referência — não é uma metáfora de autoajuda. É uma descrição de como funciona o trabalho executivo na prática. Profissional em T é quem tem profundidade vertical numa especialidade e largura horizontal suficiente para navegar contextos, traduzir linguagens e criar valor nos pontos de interseção entre áreas. Você precisa ter profundidade suficiente para ser levado a sério quando o assunto é técnico, e amplitude suficiente para entender as implicações de negócio de cada decisão técnica. A barra horizontal não substitui a coluna — ela é o que torna a coluna útil em escala maior.

A confusão é entender alargamento como abandono. Não é. É adição com direção.

Quem aspira a fazer o salto de desenvolvedor para executivo de tecnologia não pode largar a credibilidade técnica — é ela que cria autoridade nas salas onde as decisões são tomadas. Mas precisa construir a capacidade de transitar entre a linguagem do código e a linguagem do negócio sem perder o fio de nenhum dos dois.

A barra horizontal do T: por que data literacy virou pré-requisito, não diferencial

Há dez anos, um desenvolvedor que entendia de dados além do seu próprio stack era raro o suficiente para ser visto como um diferencial. Hoje, em grandes consultorias e empresas de tecnologia, essa leitura de dados virou o custo de entrada para qualquer conversa estratégica.

Foi a virada da própria trajetória de Adalberto: ao migrar do marketing para Business Intelligence, ele percebeu que os dados são a linguagem da estratégia — e construiu ali a reputação de profissional híbrido, que conecta negócio e dados. Data literacy, nesse sentido, não significa dominar modelos estatísticos ou substituir o time de analytics. Significa entender o que os números dizem sobre o negócio antes mesmo que alguém te explique.

Só que a ordem importa, e é aqui que a maioria erra. "A amplitude é fundamental, mas a amplitude muitas vezes demanda profundidade", ele diz. E completa, sem meio-termo: "Amplitude não gera nada."

Alargar sem ter onde apoiar não produz nada. E a conta sobe com o cargo: "Quanto mais você quer crescer, mais competências vai ser necessário."

Em projetos de transformação nas empresas grandes onde a Avanade atua, quem entra numa sala com líderes de negócio e faz a pergunta certa sobre os dados — antes de falar de arquitetura — sai com vantagem desproporcional.

Nas aulas que dá na FGV, ele faz a mesma distinção. O aluno quer saber a ferramenta; ele insiste no princípio. "Se tiver os princípios, você consegue. Você vai de repente mudar para uma empresa que tem outras ferramentas, vai apanhar duas semanas para aprender as especificidades, mas os princípios são os mesmos."

Nada disso aparece em certificado. Não existe curso de "como fazer as perguntas certas antes de propor uma solução". Mas quem domina isso chega às posições sêniores mais rápido que quem domina só as respostas.

O caminho de desenvolvedor para executivo de tecnologia passa por ler o negócio com a mesma curiosidade com que você lê uma documentação técnica — e isso inclui entender carreira em operações como dimensão estratégica, não apenas suporte.

O superpoder que ninguém escreve no currículo

Perguntado sobre o repertório que o coloca em vantagem no mercado, Adalberto não cita ferramenta, certificação nem empresa. "Eu vou falar que meu superpoder é o poder da observação."

Não é frase de efeito. É a descrição de um método. "Minha capacidade de observar pessoas, relacionamentos, negócios, a curiosidade é uma coisa muito forte em mim."

Repare no que a história do cartão de combustível tem de incômodo: o conhecimento não veio de reunião, relatório ou treinamento. Veio de uma conversa doméstica sobre uma regra de compliance de uma empresa que não era a dele. Ele guardou. Anos depois, usou.

A maior parte das pessoas descartaria aquilo na hora. É justamente aí que está o ponto: a barra horizontal do T não se constrói ganhando amplitude em abstrato, se constrói capturando informação que ninguém ao seu redor está catalogando.

"Tente capturar o máximo de informação para você e tentar usar sempre tudo o que você tem de conhecimento", ele resume. "Nunca jogue fora nenhum tipo de conhecimento."

Isso parece óbvio até você olhar como funcionam os ambientes de tecnologia. Os times são estruturados por domínio — backend, dados, infraestrutura, produto — e é fácil passar anos ali sem saber o que acontece na mesa ao lado. Observar além do próprio perímetro distingue o desenvolvedor que acumula expertise do que acumula contexto. Os dois crescem. O segundo cresce numa direção que o torna mais valioso à medida que os problemas ficam mais complexos.

Explorar a trajetória completa de Adalberto nesse aspecto vale o tempo: episódio 04 — Adalberto Silvestre.

Dubai custou quatro meses e pagou em leitura cultural

A tentação, ao falar de amplitude, é sugerir que ela se compra com passaporte. A experiência internacional de Adalberto desmonta isso melhor que qualquer argumento.

Ele estava na Claro quando recebeu proposta de uma empresa angolana com escritório em Dubai. Cargo de gestão, liderança de pessoas, um time remoto em Angola. Contrato de três anos.

"Eu fiquei cerca de quatro meses."

O projeto não entregou o que prometia. Ele mesmo resume: "Aquelas coisas que eu falei não deu tanto certo." Não há métrica bonita para exibir, não há case para vender em entrevista.

O que sobrou foi outra coisa. Viver ao mesmo tempo a realidade de Dubai e a de Angola — culturas de negócio que ele descreve como completamente antagônicas — deu a ele um repertório que nenhum projeto bem-sucedido no Brasil teria dado. "Só isso já teria valido a minha escolha."

É um cálculo que quase ninguém faz em público. A aposta não rendeu o resultado contratado; rendeu leitura de contexto — a capacidade de entrar num ambiente cujo código você não domina e decifrar quem decide, o que importa e por quê. Isso é barra horizontal.

Quatro meses fora não fazem executivo ninguém. O que fez diferença foi ele tratar o erro como fonte de informação, não como linha para esconder do currículo.

De desenvolvedor para executivo de tecnologia: dados e convencimento

Antes do TikTok, Adalberto foi responsável pelo marketing da Nvidia na América Latina — posição com interlocução direta com a matriz e com os times da Ásia e da Europa.

Foi ali que ele testou a tese que interessa a qualquer profissional técnico que quer decidir, não só executar.

Ele propôs um projeto de produção de conteúdo em podcast para um segmento que o time considerava perdido. A reação inicial foi a de sempre: "Ai, TI, esquece isso aí." Nem discussão o assunto merecia.

"E eu fui trazendo dados e convencendo eles que era relevante." O projeto virou case internacional da Nvidia.

Preste atenção na estrutura da frase, porque ela carrega o artigo inteiro. Dados somados a convencimento. Não um ou outro.

Dado sozinho não move companhia nenhuma — todo desenvolvedor que já apresentou um gráfico irrefutável numa reunião e viu o assunto morrer sabe disso. Convencimento sem dado é vendedor interno, e tem prazo curto. O que destrava decisão em sala executiva é a soma.

E note o que não aparece na história: autoridade formal. Ele não tinha o cargo que autoriza a decisão. Tinha o material que torna a decisão inevitável.

Quebrar silos é parte do trabalho do executivo — não um efeito colateral

Existe uma diferença fundamental entre alguém que "trabalha bem com outras áreas" e alguém cuja função é eliminar ativamente as fronteiras que impedem o trabalho de acontecer.

O desenvolvedor que vira executivo de tecnologia eventualmente descobre que boa parte da sua agenda não é sobre tecnologia. É sobre conexões que não existem: entre a visão do produto e as limitações da arquitetura, entre o que o time de dados produz e o que o time comercial consegue usar, entre o que a TI entrega e o que o negócio realmente precisava.

Esse é o terreno em que a barra horizontal se paga. A Avanade trabalha com grandes transformações em empresas estabelecidas — ambientes onde os silos têm anos de história e estruturas de poder bem consolidadas. O consultor que entra nesses contextos com apenas competência técnica vai bater numa parede. O que funciona é a combinação de credibilidade técnica com capacidade de fazer diferentes áreas convergirem em torno de um problema comum.

O executivo de tecnologia que não quebra silos não lidera transformação. Entrega projeto.

A diferença entre os dois está nos artigos sobre especialista ou gestor na carreira técnica e sobre desenvolvimento de competências para liderança.

O que separa quem faz o salto de quem espera a promoção

Há um padrão que aparece na trajetória de quem consegue evoluir de desenvolvedor para executivo de tecnologia sem virar um gestor genérico: eles não esperaram uma promoção para começar a se comportar como executivos.

Isso significa coisas concretas. Significa opinar sobre impacto de negócio antes de ser convidado a fazer isso. Significa fazer perguntas sobre o cliente final numa reunião de arquitetura. Significa ler os relatórios de resultado da empresa mesmo quando ninguém pediu.

A promoção, quando vem, é o reconhecimento de algo que já estava acontecendo — não a concessão de uma nova identidade profissional.

Adalberto constrói essa leitura a partir de experiência prática em contextos com alto nível de complexidade — projetos internacionais, empresas com operações regionais distribuídas, ambientes onde a solução técnica certa e a solução de negócio certa raramente são a mesma coisa. O que ele descreve não é uma teoria de carreira. É uma observação sobre o que diferencia os profissionais que chegam às posições sêniores dos que ficam presos na especialização.

A técnica continua sendo a base. O que muda é o que você constrói em cima dela.

O que você pode observar já na próxima semana

Construir a barra horizontal do T não exige troca de emprego nem inscrição em MBA. Exige prática deliberada — e ela cabe no expediente que você já tem.

Três pontos de partida concretos: participar de pelo menos uma reunião fora do seu domínio com o objetivo explícito de entender a lógica daquela área, não de contribuir tecnicamente. Ler os relatórios de resultado da empresa — trimestrais, OKRs publicados, atas de board quando acessíveis — e anotar onde a tecnologia aparece como alavanca ou como gargalo. Fazer uma pergunta por semana ao time de produto ou comercial sobre como eles medem sucesso num projeto em que você está envolvido.

Nenhuma dessas ações muda o seu cargo. Mas mudam o que você observa, e por consequência o que você tem a dizer nas salas em que as decisões são tomadas. A progressão de carreira em tech acontece muito mais por acumulação de contexto do que por acumulação de certificados.

Se você está nesse processo de ampliação, a pergunta que vale carregar é esta: o que você está observando hoje fora do seu domínio que ainda não entrou na sua conversa com o negócio?