Você não precisa falar menos técnico. Precisa saber para quem está falando.
Com a ascensão da inteligência artificial no dia a dia dos desenvolvedores, estamos produzindo cada vez menos código manualmente. Ao mesmo tempo, precisamos entender cada vez mais sobre o negócio, o problema que estamos tentando resolver e o impacto das nossas decisões.
Isso me fez perceber algo importante ao longo da minha carreira: saber desenvolver uma solução é apenas uma parte do trabalho. Saber explicar o valor dela é outra.
Imagine uma reunião com pessoas de tecnologia, produto, negócio, vendas e liderança.
Você diz:
"Implementei um novo endpoint, criei uma migration e adicionei um circuit breaker."
Para quem é técnico, provavelmente faz sentido.
Para o restante da sala, talvez seja apenas uma sequência de palavras.
E não existe nada de errado em falar tecnicamente. O problema é utilizar a mesma linguagem em todos os contextos.
Do técnico para o negócio
Um conceito do Domain-Driven Design que gosto bastante é o de linguagem ubíqua: criar uma linguagem comum entre pessoas técnicas e especialistas do domínio.
Acredito que essa ideia pode ir além do código.
Se estamos trabalhando juntos para resolver um problema de negócio, precisamos conseguir conversar sobre ele de uma maneira que todos entendam.
Afinal, dizer que um endpoint foi desenvolvido explica o que fizemos.
Mas não necessariamente explica por que fizemos.
E essa diferença importa.
Endpoint não é valor
Em uma experiência que tive, participei de uma mudança no formato das nossas reviews.
Antes, a reunião era basicamente uma lista de tarefas:
"Endpoint X foi desenvolvido?"
"Sim."
"Migration Y foi deployada?"
"Sim."
"Tarefa Z foi concluída?"
"Sim."
E uma pergunta começou a fazer cada vez mais sentido para mim:
Que valor isso tem?
Não que essas tarefas não fossem importantes. Elas eram necessárias para entregar o produto.
Mas apresentar apenas uma lista de tarefas técnicas pode passar a imagem de um time que simplesmente recebe cards e os transforma em "Done".
A mudança foi começar a apresentar os entregáveis e seus impactos.
Em vez de:
"Implementamos um circuit breaker."
Podíamos explicar:
"Criamos uma proteção para impedir que uma falha em um serviço comprometa outras partes do sistema."
A implementação técnica continuava sendo a mesma.
O que mudou foi a forma de comunicar o resultado.
Endpoint, migration e circuit breaker são meios. O valor está no problema que eles ajudam a resolver.
"Explique como você explicaria para sua mãe"
Uma das dicas que mais me ajudaram nesse processo foi simples:
Explique o que você faz como explicaria para sua mãe.
Não significa simplificar porque as pessoas não entendem tecnologia.
Significa entender tão bem aquilo que você está fazendo que consiga explicar sua importância sem depender de termos técnicos.
Se eu digo:
"Implementei um circuit breaker."
Estou descrevendo uma implementação.
Se digo:
"Criei uma proteção para que, quando uma parte do sistema falhar, ela não faça outras partes pararem também."
Estou explicando o problema e a solução.
Isso não demonstra menos conhecimento técnico.
Demonstra que eu entendo onde aquele conhecimento se encaixa.
Comunicação também é maturidade técnica
Acredito que essa habilidade se tornou ainda mais importante com a chegada da IA.
Se ferramentas conseguem nos ajudar cada vez mais a escrever código, gerar testes, refatorar soluções e até sugerir implementações, o diferencial não está apenas em quanto código conseguimos produzir.
Está em entender:
- qual problema estamos resolvendo;
- por que estamos resolvendo;
- qual solução faz sentido;
- e qual impacto aquela solução gera.
E, para isso, precisamos conseguir conversar com pessoas que não necessariamente conhecem a tecnologia que estamos utilizando.
Não precisamos parar de falar tecnicamente.
Quando estamos entre desenvolvedores, o contexto permite isso.
Mas quando estamos falando com produto, negócio ou liderança, talvez seja necessário mudar a linguagem.
Você não precisa falar menos técnico. Precisa saber para quem está falando.
No fim, talvez a pergunta não seja:
"Quão técnico eu consigo parecer?"
Mas:
"Quão bem eu consigo fazer alguém entender o valor do que estou construindo?"