CARREIRA

Como evoluir de desenvolvedor para executivo de tecnologia

26 May 20269 min

Em Dubai e depois no case da Nvidia para a América Latina, Adalberto Silvestre percebeu que o que abria portas não era o domínio técnico que ele já tinha.

Em Dubai e depois no case da Nvidia para a América Latina, Adalberto Silvestre percebeu que o que abria portas não era o domínio técnico que ele já tinha. Era a curiosidade de entender o que acontecia nas mesas ao lado.

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 é consultor sênior 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.

Adalberto aponta data literacy — a capacidade de ler, questionar e interpretar dados de negócio — como um dos pilares da barra horizontal que o desenvolvedor precisa construir. 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.

Isso é especialmente relevante no contexto de grandes projetos de transformação digital, onde a Avanade e consultorias similares atuam. Um profissional técnico que consegue entrar numa sala com líderes de negócio e fazer perguntas inteligentes sobre os dados — antes de falar sobre arquitetura — tem uma vantagem desproporcional.

É o tipo de competência que não aparece em nenhum certificado. Não existe curso de "como fazer as perguntas certas antes de propor uma solução". Mas os profissionais que dominam isso chegam às posições sêniores mais rápido que os que dominam apenas as respostas.

Na prática, o caminho de desenvolvedor para executivo de tecnologia passa obrigatoriamente por aprender a 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. Você vai descobrir que os padrões e as inconsistências estão nos dois lugares.

Observação e curiosidade são a superpotência que ninguém coloca no currículo

Em Dubai, o que Adalberto narra não é uma epifania de carreira. É algo mais cotidiano e ao mesmo tempo mais raro: ele prestava atenção no que acontecia fora da sua área.

Essa descrição parece óbvia até você perceber como funciona a maioria dos ambientes de tecnologia. Os times são estruturados por domínio — backend, dados, infraestrutura, produto. Cada área tem seus rituais, suas métricas, sua linguagem própria. É muito fácil, dentro de um ambiente desses, passar anos sem saber o que acontece na mesa ao lado.

A capacidade de observar além do próprio perímetro é o que distingue o desenvolvedor que acumula expertise do desenvolvedor que acumula contexto. Os dois crescem. Mas o segundo cresce em uma direção que o torna mais valioso à medida que os problemas ficam mais complexos.

No projeto em Dubai, Adalberto aplicou exatamente isso. Num ambiente com operações distribuídas e times de culturas diferentes, ele mapeou o que travava a adoção de soluções técnicas — e a resposta não estava no código. Estava na falta de alinhamento entre o que a área de negócio pedia e o que a equipe técnica entendia como requisito. Ao trazer essa leitura para o caso da Nvidia na América Latina, o mesmo padrão se repetiu: identificar onde os silos criavam ruído antes de propor arquitetura. O resultado mensurável foi redução no ciclo de entrega — não porque a solução técnica mudou, mas porque o problema foi enquadrado corretamente desde o início. Isso não acontece por acidente. Acontece porque alguém decidiu observar o que estava acontecendo nas outras mesas.

Curiosidade, nesse sentido, não é um traço de personalidade. É uma prática. Você decide prestar atenção nas conversas de outras áreas, fazer perguntas fora do seu domínio, entender o que o cliente final de um produto sente — mesmo que isso não seja sua responsabilidade direta.

É essa prática que alimenta a barra horizontal do T sem que você precise sair do seu trabalho para desenvolvê-la. A maior parte do que um executivo de tecnologia precisa saber sobre negócio está disponível nas reuniões que os desenvolvedores normalmente ignoram.

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

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.

Adalberto observou esse padrão nos ambientes em que atuou. 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.

Isso é diferente de "habilidade de comunicação" — expressão que virou genérica a ponto de não dizer nada. É específico: entender o incentivo de cada área, adaptar a linguagem sem trair a substância, e ter reputação suficiente para ser ouvido quando aponta um problema que cruza fronteiras organizacionais.

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?