Escalando Pessoas: Quando o Código Deixa de Ser o Gargalo

Durante boa parte dos meus 15 anos de engenharia, eu fui o desenvolvedor que queria ser o mais atualizado, o mais proativo, o "conhecedor" absoluto dos processos. Eu queria Dailies curtas; se passasse de alguns minutos com uma única pessoa falando, eu já questionava, tentava puxar o próximo para que aquilo acabasse logo e eu pudesse voltar ao código.

No PHP, no Golang, na real, não importava a linguagem ou o banco de dados, eu pegava o desafio mais complexo e queria resolver rápido. Se o sistema precisava de A ou B, eu era o cara que subia o PR acreditando que estava garantindo a performance. Funcionou bem em algumas situações, me atropelei em outras, mas conforme o tempo passava, eu me tornava cada vez mais "expert" em codar e entregar, codar e entregar.

Mas quando assumi a liderança técnica, o choque veio forte.

De repente, aquele "antigo eu" não sabia mais fazer quase nada. Tentei continuar entregando na mesma velocidade de antes e conversava com o time quase como se estivesse tentando criar vários "Malkinhas". O raciocínio era: "Se eu fui promovido, o Malka's Way está correto e meu time deve performar como eu performava". Fazia algum nexo na minha cabeça, mas eu estava colocando a entrega acima das pessoas. Muitas vezes, isso faz a gente perder de vista o valor do que está sendo feito e as diversas formas de fazê-lo.

A sobrecarga mental veio e os resultados coletivos não acompanhavam meu esforço individual. Parei para olhar o que estava fazendo de errado. Afinal, cheguei onde cheguei por conta dos meus esforços, então a resposta deveria estar dentro de mim.

E estava. Lá encontrei um desenvolvedor que lutou muito contra a vontade de outros, que discutia código e tentava ser o melhor, mas que estava acuado pelo gestor que eu estava sendo. Percebi que não dava para replicar o "Malka". O melhor seria transformar o ambiente para possibilitar que os outros atuassem tão bem quanto eu, ou melhor. Eles deveriam encontrar seus próprios caminhos, e eu deveria ser apenas o conselheiro no ombro deles.

A virada veio quando entendi que meu "código" agora era outro, dotado das peripécias do mundo empresarial, da gestão de pessoas e de expectativas.

Enfim, percebi que meu papel principal era ser um facilitador estratégico. O sucesso não era mais sobre o meu protagonismo na execução, mas sobre construir um time com autonomia para rodar sem mim no operacional. Melhor ainda: que me consultasse somente quando estivessem empacados, para que eu pudesse agilizar a vida deles sem tornar seus dias mais complexos do que já eram.

Hoje foco em:

• Dar direção técnica (System Design) em vez de apenas ditar o código.

• Proteger o time de ruídos que atrapalham a entrega.

• Desenvolver pessoas para que resolvam problemas, sozinhas ou em conjunto.

Ainda desço para o "play" em incidentes críticos? Com certeza. Acompanho deploys e consumo métricas diariamente? Definitivamente. Mas isso hoje é puro saudosismo. Sei que o time do qual faço parte tem autonomia para voar sem depender de mim.

Não sou o PDI deles; sou apenas aquele sussurro ao vento que nos faz perceber que, às vezes, estamos confusos por buscar respostas apenas dentro de nós, quando o conhecimento pode estar em qualquer pedra, riacho ou montanha.

Você também sentiu esse peso quando virou a chave para a gestão? Como foi o seu processo de se tornar um facilitador?