Poucos profissionais entendem este fato sobre a carreira em tecnologia: a empresa não te paga pela ferramenta que você domina. Ela te paga pelo problema que você resolve.
Este é o primeiro texto da série Além do Código, sobre o que realmente diferencia um profissional de tecnologia, além da parte técnica. Publiquei a versão curta no LinkedIn; aqui vai a versão completa.
Carreira em tecnologia: pelo que você não é pago
Nem sempre somos pagos para:
- Implementar ferramentas
- Operar ferramentas
- Escrever código
Isso soa estranho para quem passa o dia em um terminal, mas pense em quantas vezes você viu um projeto entregar “a ferramenta instalada” e, seis meses depois, ninguém saber dizer qual problema ela resolveu. Kubernetes sem necessidade de orquestração. Um SIEM que só gera alerta que ninguém lê. Um pipeline lindo que deploya um produto que ninguém usa.
Ferramenta é meio. Quando ela vira fim, o trabalho vira custo.
Pelo que você é pago
Somos pagos por:
- Conhecimento: entender o porquê por trás de cada decisão de arquitetura, não só o como.
- Habilidades: conseguir aplicar esse conhecimento num cenário real, com restrição de prazo, custo e gente.
- Mentalidade: olhar para um problema e perguntar “precisamos mesmo disso?” antes de “qual ferramenta usamos?”.
- Impacto real: disponibilidade que subiu, custo que caiu, risco que diminuiu, time que entrega mais rápido.
O operador sabe executar o procedimento. O profissional que soluciona sabe dizer quando o procedimento não deveria ser executado.
Por que isso ficou urgente
💥 Muitos estão se tornando apenas operadores de ferramentas, e esse perfil é o primeiro a ser substituído por IA.
Não é exagero. Gerar um manifesto, um módulo Terraform ou uma query já é trivial para um assistente de IA. O que continua difícil é decidir qual arquitetura faz sentido para aquele negócio, negociar o trade-off entre segurança e prazo, e explicar para a diretoria por que vale investir nisso agora. Essa parte não se automatiza com um prompt.
A IA não substitui quem soluciona. Ela acelera quem soluciona e torna desnecessário quem só opera.
Como sair do modo operador
Por isso, reuni algumas práticas que funcionam, tanto para quem está começando quanto para quem lidera time:
- Comece toda tarefa pelo problema. Antes de abrir o console, escreva em uma frase o que vai melhorar para o negócio quando você terminar.
- Meça o antes e o depois. Tempo de deploy, custo mensal, número de incidentes. Sem número, não existe impacto, existe opinião.
- Questione o pedido. “Instala a ferramenta X” quase sempre esconde um problema Y. Descubra qual é.
- Documente decisões, não só comandos. Um ADR curto vale mais que um runbook longo para quem chega depois.
- Use a IA para operar, e o seu tempo para pensar. Deixe o assistente gerar o boilerplate e invista o tempo ganho em arquitetura, segurança e conversa com o negócio.
Para refletir
Você está operando ou solucionando?
Olhe para a última semana de trabalho e separe o que foi execução de procedimento do que foi decisão que mudou um resultado. A proporção entre as duas diz muito sobre para onde a sua carreira em tecnologia está indo.
📚 Leia também: Introdução ao DevSecOps, sobre como a cultura muda a forma de entregar tecnologia.
Acompanhe e comente a série no meu LinkedIn.
Série Além do Código
- 1/4: Você está operando ou solucionando? (você está aqui)
- 2/4: Comunicação vale mais que código
- 3/4: Autonomia não se aprende em curso
- 4/4: Liderança não começa com um crachá
Atualmente atua como Architecture Manager pela Atos Brasil, entusiasta Microsoft, FreeBSD e Debian, com mais de 20 anos de experiência em infraestrutura de T.I com ambientes heterogêneos, possuí o título de Microsoft Certified Trainer, AWS Community Builder, FinOps Member Foundation, Membro do comitê público do IDCIBER e especialista em segurança de perímetro, tendo atuado com soluções como Isa Server, iptables, IPFW, Cisco ASA, SonicWall, Fortigate, pfSense e soluções de Web Application Firewall.
Deixe um comentário