Se você é uma Pessoa Engenheira de Software, está acostumada a lidar com código, isso faz parte do dia a dia. Mas tem outra coisa que faz parte do dia a dia: pessoas.

Hoje meu objetivo com esse texto é te apresentar conceitos que vão te ajudar a criar uma vida melhor para você e seus pares, com um conceito simples: gentileza. Mas não confunda simplicidade com fácil.

Alerta de vulnerabilidade!

Eu quero fazer essa pausa intencional para dizer que esse texto vai ser muito aberto e eu vou ser muito vulnerável nele.

Lendo o livro Dare to Lead da Brené Brown (que eu recomendo demais), ela conta sobre como isso é parte do processo de construção de ser um bom lider.

Então eu quero contar para vocês sobre Kind Engineering, mas não só escrever um texto frio qualquer, mas dividir meus erros, algo que aconteceu de verdade comigo ao longo da minha jornada.

Eu errei. Eu refleti. Eu me arrependi. Eu pedi desculpas. Eu aprendi. Eu melhorei.

Por favor, deixe os julgamentos um pouco de lado e use esse momento para apenas escutar. Algumas coisas vão ressoar com você, outras não.

“Vulnerability is not winning or losing. It’s having the courage to show up when you can’t control the outcome”

"A vulnerabilidade não é vencer ou perder. É ter a coragem de se apresentar quando você não pode controlar o resultado."

O que é Kind Engineering?

“Ser gentil envolve se dedicar às outras pessoas, descobrir como ajudá-las e compreendê-las em sua situação."

Gentileza na engenharia é sobre empatia, boa comunicação e ser honesto consigo mesmo e com seus colegas. Isso é essencial para criar um ambiente de trabalho saudável e colaborativo. Ninguém gosta de trabalhar num lugar onde tem “AQUELE MALUCO ~~CRETINO~~” que revisa todos os PRs. Vamos ver alguns exemplos em que falta gentileza:

Aprovar um PR (Pull Request) sem ao menos ler, revisar o código ou testar, apenas respondendo "LGTM" ("Looks Good to Me"). Isso não só desconsidera o esforço da pessoa que contribuiu, como também desperdiça uma oportunidade valiosa de fornecer feedback técnico.
Ignorar pedidos de ajuda ou revisões no canal do time. Isso demonstra desinteresse e falta de empatia, enfraquecendo a cultura de colaboração.
Criticar o código ou expor publicamente os erros de um colega, seja em código ou incidentes, cria um ambiente constrangedor, onde as pessoas têm medo de errar por receio de serem expostas novamente.

Três exemplos que você com certeza já viu: um PR revisado de qualquer jeito, uma mensagem totalmente ignorada no Slack e AQUELE MALUCO que sempre tem uma crítica desnecessária (não confundir com críticas construtivas, por favor) sobre o seu PR.

Ser gentil é se importar com as pessoas: você pode dar um bom feedback técnico naquele PR que a pessoa levou algumas horas para escrever? Que tal responder à mensagem do Slack (Eu não sei também é uma resposta) e evitar que aquela pessoa fique sem nenhum retorno? Ter uma crítica difícil para dar acontece, mas ninguém precisa ser atacado (sim, essa é a palavra) em público. Não se omita, mas saiba como/quando/onde falar.

Importante destacar que gentil é diferente de legal.

Legal é aquela pessoa que só fala coisa boa, nunca tem nenhum conflito, quer agradar todo mundo, nada nunca está ruim. O mundo não é colorido assim não, desculpa.

Ser gentil é sobre ser realista quando as coisas não estão boas, engajar em conflitos saudáveis necessários para a evolução, entender que mesmo quando está ruim podemos fazer algo para melhorar.

Para mim, ser gentil é sobre se importar.

O livro Dar e Receber do Adam Grant é excelente para explicar a relevância da gentileza.

Ele fala sobre os três tipos de pessoas no mundo: os Takers (aqueles que pegam mais do que dão), os Matchers (que dão na mesma medida que recebem) e os Givers (os generosos). O livro explora como ser um Giver pode trazer muitos benefícios – mas com uma condição: tem que ser feito de forma sustentável, sem se esgotar.

Honestidade

“Being at work"

“Estar no Trabalho”

Não seja apenas profissional, seja você

Aqui a gente vai falar de honestidade. Sobre como você criar laços no trabalho, com seus pares é essencial para você estar aqui e ser mais do que “só um emprego”.

Quem aqui já ouviu aquela papo de separar vida pessoal do trabalho?

Vocês devem estar cansados de ouvir aquela conversa de entrosamento que a galera traz como se você tivesse que trazer para o trabalho a sua vida pessoal inteira. Não é isso.

Quem me conhece sabe que eu sou uma pessoa pouco social e que fala ainda menos da minha vida. Um dos meus líderes (Beijo Almeida!), que trabalhou 4 anos comigo, não sabe tanto assim da minha vida pessoal. Porque não é sobre isso.

Aqui eu estou falando sobre aquele lance de vulnerabilidade que eu disse no começo. Eu sou honesto com as pessoas do meu time em muitos aspectos.

Desde coisas pequenas como “não sei fazer isso”, até coisas mais delicadas, como feedbacks elaborados que demoram tempo para serem preparados. Eu já escrevi um feedback e fiquei dias revisando-o, para acertar o tom, a mensagem, a criticidade do assunto.

Por que estar no trabalho é importante? Vamos ver um exemplo prático.

O que você enxerga: A tarefa está demorando para sair

O que você não enxerga:

Um dos filhos dessa pessoa está doente
A esposa dessa pessoa está passando pela perda de um parente
A pessoa está atuando com uma tecnologia que ela nunca viu na vida
A complexidade do processo que solicitar um acesso à ferramenta traz (o famoso seis meses para um login no Jenkins)
A falta de documentação sobre o sistema (que você deixou de fazer na sua última tarefa)
O card com um escopo muito maior e que poderia ser quebrado
Uma thread no Slack que nenhuma resposta chega (Cadê a gentileza?)
A internet/luz da pessoa que não a ajuda a focar
A filha da pessoa esperando na escola sozinha

E trago exemplos do meu dia a dia:

“A verdade dói, a mentira mata, mas a dúvida tortura."

Bob Marley

“A verdade não dói. O que dói é você não saber falar direito. Não seja mau-caráter (nem todo homem, mas sempre um homem)”

Eu mesmo

A gente foi acostumado a acreditar nesse papo de que a verdade dói. Não é real isso.

Eu sei que não é exatamente gostoso ouvir que não estamos fazendo um bom trabalho. Ou que precisamos melhorar em uma coisa que a gente acreditava que estava mandando super bem. Só que a maneira como você conta isso importa muito. Você não fala de qualquer jeito com sua mãe, esposa, marido, filha. Por que tratar qualquer outro ser humano de qualquer jeito? Vou reforçar: não seja desagradável.

Comunicação Assíncrona

Comunicação é sempre um desafio. Comunicação assíncrona é 100x mais desafiadora.

Se comunicar é uma arte. Eu nunca fui um grande comunicador, mas quando eu falava com poucas pessoas isso “passava batido”. Hoje isso não é aceitável.

Mas a coisa fica ainda mais complicada quando a gente está falando de comunicação assíncrona. Quando eu virei TechLead eu embarquei na jornada do tudo async. “Chega de reunião, tudo a galera quer marcar uma call rapidinha”. Até que escutei, não lembro onde (se você souber me manda a referência), o seguinte comentário:

A gente é ótimo em reconhecer aquela reunião que poderia ser um e-mail, mas falha em entender aquela thread de 200 mensagens que poderia ser uma call de 15 min.

Além disso, nosso dia a dia também tem momentos diversos onde comunicação assíncrona ocorre.

Code review ou ofensa velada?

Um dos processos que a gente faz muito de forma assíncrona é code review. E aqui eu quero destacar a importância de entender por que as pessoas fizeram algo, não apenas como elas fizeram.

A gente cai muito na falácia de “essa pessoa não sabe o que está fazendo” e isso não é necessariamente verdade. O contexto, a motivação de uma mudança, é tão importante quanto a mudança em si.

Depois que a Marcela Sisiliani me apresentou o Conventional Comments, eu passei a usar ele em tudo. Até no Google Docs eu uso. Eu tento entender o que está acontecendo ali, isso me ajuda a prover feedback de qualidade, não apenas ficar criticando algo que eu nem entendo direito.

Deixe claro quando seu comentário é relevante ou não.

Cuidar da nossa base de código é importante, mas é muito frustrante quando uma pessoa coloca o esforço dela para criar uma solução para um problema e, ao pedir feedback, ela recebe comentários que não estão no cerne do problema apenas.

Também é importante deixar claro quando algo é bloqueante ou não. Por diversas vezes eu aprovo PRs do time deixando comentários e sugestões para que eles possam melhorar no processo, mas nenhum deles é algo extremamente crítico para que aquela solução vá para o ar.

Outra oportunidade valiosa é reconhecer boas ideias. Sabe aquele momento em que você lê um código e pensa “Nossa, que ideia boa”. Escreva isso! Deixe claro para a pessoa que ela mandou bem. Isso ajuda a entender onde está acertando.

E de novo aquela conversa de entender quando sair do async para o sync.

A gente começou a divagar muito em review, é hora de chamar uma call e fazer a revisão junto. Às vezes um pequeno alinhamento pode reduzir em muito esse vai e vem de revisão e diminuir o tempo que o PR fica lá aberto esperando alguém olhar (e o cliente esperando por aquela funcionalidade chegar em produção). Review ping-pong é ruim.

Segurança Psicológica

"Quão seguro você se sente em seu trabalho ao apontar problemas e resolvê-los?"

Segurança psicológica é sobre criar um espaço onde as pessoas podem se expressar como elas realmente são. Criar um lugar onde a gente pode dizer que não gostou de algo, que cometeu um erro, que não sabe de algo, que pode ser aberto e verdadeiro.

Um ambiente seguro tem que ter feedback. Eu não vou falar muito do feedback aqui porque isso merece um texto a parte, mas eu quero destacar que se a gente quer criar um ambiente onde as pessoas dão feedback, nós temos que cobrar elas. Aqui eu vou deixar duas dicas:

Peça feedback constantemente para as pessoas. Mas não é só para quem você gosta ou é seu líder. Sabe aquela pessoa que você não conversa muito? Ou aquele júnior do seu time? Eles têm muito a agregar para ti. Escute.
Feedback é uma habilidade a ser aprendida, então pode começar pequeno com: o que deu certo? O que deu errado? O que podemos fazer novamente no futuro? E aí com os feedbacks do feedback você vai melhorando.

Seja Inclusivo (alow diversidade!)

Um ambiente seguro passa por diversidade. Eu nem vou falar muito de diversidade, porque esse é um assunto que eu tenho MUITO o que aprender. Mas eu quero trazer provocações que me tocaram e que me fizeram começar a trilhar esse caminho. A gente fala muito da questão mulheres na tecnologia, então eu vou provocar: quantas mulheres têm no seu time? Quantas pessoas não-binárias? Quantas pessoas negras? Quantas pessoas cegas trabalham com você hoje?

Eu só me vi realmente pensando nisso quando eu me vi em times onde a maioria das pessoas que trabalhavam comigo eram mulheres. Eu achei que estava sendo diverso, aí a Paula Assis me cutucou “Por que a única TechLead hoje é a Fulana? Era uma provocação poderosa. A gente tem que todo dia se esforçar para ser mais diverso.

Na nossa fala, nas nossas atitudes, no que a gente acha normal.

Outro ponto perigoso: micro agressões. Uma explicação breve pra quem não sabe, microagressões são comportamentos ou comentários sutis e frequentemente não intencionais que comunicam hostilidade ou preconceito em relação a membros de grupos sociais minoritários. Sabe aquela piadinha machista ~~inofensiva~~? Aquele comentário que você acha inofensivo? Não é. Uma coisa comum é que a gente entende que por ter essa palavra micro na frente, parece que é coisa boba.

A comparação que eu faço é um corte de faca no dedo vs um tiro no braço.

Realmente, um tiro é uma coisa gigante. Mas imagina você ter seu dedo cortado todos os dias, por diferentes pessoas, toda vez no mesmo lugar. Não tem nada de micro nisso. O ponto central da microagressão é que ela cria um ambiente hostil para as pessoas, o que é totalmente o contrário de um ambiente seguro.

Por que eu estou te contando isso? Eu fazia MUITO isso. Tempos atrás eu criei o conceito de #bastaler, o que para mim parecia uma ótima ideia. Era uma piadinha com aquele tipo de problema que a gente tem que “uma lida no doc” resolve, sabe? Você já passou por isso, eu já passei, todo mundo passa.

Eu só percebi o quanto isso era venenoso no dia em que uma pessoa júnior de um dos meus times me disse o seguinte: “Eu me esforço muito, porque eu não quero que você mande um #bastaler pra mim”.

Aquilo doeu tanto em mim, porque eu criei um peso naquela pessoa. Eu criei um ambiente onde ela não podia mandar qualquer dúvida com medo de ser repreendida. Eu ainda cometo a falha de usar isso, antigos hábitos são difíceis de se matar, mas eu tento ser melhor todos os dias.

Você não está sozinho! Existem diversos materiais, discussões, apoio, grupos onde você pode aprender e crescer nesse tema. Mas tem que querer.

Eu vou me usar de exemplo, eu não participo ativamente do grupo que tem na minha empresa, tanto por questões de horário quanto de me sentir confortável na discussão mesmo. Mas eu estou no canal, eu vejo os materiais, leio os comentários, vou crescendo para um dia talvez eu ser mais ativo ali. Está tudo bem você não querer ser ativo na discussão, mas se você não está sendo parte da solução você esta sendo parte do problema.

Importante ficar atento às pessoas que falam pouco. Essa galera tem uma visão de mundo que você está perdendo! Quem tem contato comigo sabe que eu tenho uma voz ativa nas discussões, então eu sempre me esforço para falar por último. Ou chamar alguém na DM para perguntar “hey, o que você achou disso?” porque a gente tem jeitos diferentes de se expressar. Tem pessoas no meu time que não dizem tanta coisa no grupo, mas quando é uma 1-1 ou na mensagem escrita elas simplesmente mudam o jogo com os comentários delas. E como isso acontece? Eu fico atento a escutar mais essas pessoas. O que elas não estão dizendo? Por que não?

Você está fazendo isso com as pessoas à sua volta?

Sem culpados - Tornando a falha em aprendizado

Eu sei que falar de falhas e em não ter culpados é sempre fácil. E que fazer isso no dia-a-dia é difícil. Na prática, sempre tem aquela pessoa que apertou o botão. A culpa é dela?

Eu costumo usar muito a máxima do processo. Ele tem que estar afinado para garantir que não aconteça aquele problema. A gente fez review, teste de unidade, teste em staging, em produção e ainda assim deu incidente? Tem algo errado nesse processo.

Como a gente melhora ele para que a culpa não seja da coitada da pessoa júnior que nem sabia que tinha aquela funcionalidade escondida no produto? O que a gente pode aprender disso? O Post Mortem é legal para isso, a retrospectiva ajuda nisso tudo.

Temos que normalizar o erro, mas não a irresponsabilidade. Eu erro muito, mas eu nunca sou irresponsável. Subir um PR sem teste, sem descrição, sem revisão, sem nada beira a irresponsabilidade. Lembra que lá atrás eu falei para a gente ser honesto? Eu não sei o contexto que isso pode acontecer, eu preciso entender o motivo das coisas antes de sair marcando as pessoas como irresponsáveis. Por isso cada um consegue se avaliar sobre suas ações e entender se é erro ou irresponsabilidade.

Outra coisa que eu faço muito para normalizar os erros é contar dos meus erros (esse texto é um belo exemplo). Eu falo dos incidentes que cometi, eu mostro onde eu mandei mal, eu me esforço em mostrar para as pessoas que eu já estive no lugar delas, passando dificuldade com um problema e que elas também podem. Inclusive vou dividir um erro meu com vocês aqui. Lembra que falei sobre ser vulnerável? Então deixe o julgamento de lado e venha comigo.

Eu disse para vocês:

Serem honestos e criarem relações com as pessoas à sua volta
Comunicação é difícil, assíncrona, muito mais
Diversidade é importante e é um esforço diário
É importante criar um espaço seguro para as pessoas à sua volta

Enfim a hipocrisia. O meu causo é o seguinte:

No começo do ano de 2023, virei TechLead de outros times e fiquei responsável por algumas partes novas em um dos produtos da empresa. E aí que eu, em toda minha prepotência, fiz alguns questionamentos sobre uma das funcionalidades desse produto e marquei todas as caixinhas de erro que vocês conseguirem imaginar:

Não tive o cuidado na minha comunicação, em entender as motivações e o contexto das escolhas do passado e do presente
Direcionei minha mensagem à pessoa PM que nem era a referência técnica do assunto, num tom desnecessariamente agressivo
Não tinha nenhuma relação com os envolvidos (o que impacta na recepção da mensagem), pois tinha “acabado de chegar” naquele produto

Esse episódio me fez questionar muitas das minhas certezas. Sobre como eu agia. Sobre como eu me comunicava. Eu ouso dizer que meu ano inteiro de 2023 girou em torno de ser melhor por conta desse erro. E eu só pude fazer isso, porque a pessoa PM que recebeu essa agressão não fez de mim um culpado. Ela me deu feedback e me permitiu crescer com isso.

Uma coisa que ela me falou e ficou marcada em mim foi a frase “Isso é foto ou filme?”. Foi um erro ou foi irresponsabilidade?

A gente erra, alguns erros são menores, outros maiores, mas se você estiver disposta a crescer e as pessoas ao seu redor estiverem dispostas a dar feedback de verdade, a gente pode ser melhor. Mas eu não vou deixar passar esse momento. Diversidade é feita todos os dias. A gente que tem privilégios de vários tipos, facilmente esquece disso.

Feedback

“Feedback é a fórmula secreta do sucesso. Só não é secreta.”

Eu

Feedback é um assunto que a gente pode separar um artigo inteiro para falar. Mas eu quero recomendar muito o livro: Obrigado pelo feedback

O livro conta para a gente sobre três gatilhos que atrapalham na hora de escutar os feedbacks:

1️⃣ Gatilhos da verdade

Aqui a gente entende como às vezes o feedback não é o "que a gente está pensando" (o desafio da comunicação), então entender melhor ele é essencial para que a mensagem certa chegue.

2️⃣ Gatilhos de relacionamento

Se você já pensou "quem é fulano para me dizer isso?" provavelmente já caiu nessa armadilha. O objetivo aqui é desconectar a mensagem do emissor e ter uma escuta ativa. Facíl, né? 🆘

3️⃣ Gatilhos da identidade

O desafio aqui é não ser "atacado". É isso que é tão difícil do feedback, é alguém dizendo que o seu EU atual "não é bom o suficiente" ou algo assim. Mas a mensagem não é essa na real, e a gente entender o que coloca a gente na defensiva é essencial para lidar bem com feedback. E também cultivar uma mentalidade de crescimento.

Além disso, algumas dicas para te ajudar:

Fale sobre fatos e esclareça sua perspectiva sobre eles (CNV aplicada)
Reconheça o bom trabalho, ninguém gosta de só levar porrada (reconhecimento formal)
Dê feedback sobre os feedbacks que você recebe
Seja curioso, sem ser afrontoso

Mas dá para usar na empresa? Ou isso é papo de coach?

É possível, mas não é fácil. Eu acredito que ser o exemplo é sempre o melhor caminho. Para isso, tenha em mente:

Honestidade com seu time
Preocupação genuína com as pessoas
Comunicação pode ser aprendida
Seu líder também está aprendendo
Escute as pessoas que falam pouco

Eu tentei resumir muitos dos meus aprendizados nesse texto, mas existem outros materiais que vão te ajudar nessa jornada (vou deixar algumas referências no final), mas o mais importante nessa jornada é sua intencionalidade. Seja a mudança que você quer ver no mundo (e sim, eu sei que isso é bem treta).

E se quiser trocar uma ideia, só chamar.

Referências:

Kind Engineering

Table of contents