A comunicação executiva é talvez uma das habilidades mais importantes para cargos de liderança técnica dentro de ambientes corporativos. E não é fácil desenvolvê-la. Para pessoas, assim como eu, que possuem um perfil muito técnico, saber comunicar e explicar conceitos, problemas e resultados técnicos para executivos que, quase sempre, não os enxergam pelas mesmas dimensões, é uma habilidade que precisa ser desenvolvida o mais rápido possível. Nem sempre, porém, esse é um direcionamento tão óbvio ou um direcionamento claro vindo da carreira em Y. Muitos profissionais técnicos chegam ao nível sênior por suas qualificações em execução, troubleshooting, arquitetura e entrega. Porém, ao avançar para níveis Staff+, surge a necessidade de tornar o próprio impacto compreensível para pessoas que não participaram da execução e que não dominam, com a mesma profundidade, os detalhes de implementação.

Na cadeira de Staff+, seu resultado nem sempre é medido pela quantidade de problemas complexos que você resolve direta ou indiretamente. Muito do seu resultado será reflexo da sua habilidade de comunicar contextos, decisões e impactos, dividir riscos de forma clara e pedir recursos quando necessário, de forma clara e objetiva. Em um mar de possibilidades que poderiam me ajudar a resolver esse tipo de problema, escolhi adaptar o método STAR para esse fim. Neste texto, irei explicar como.

O método STAR

O método STAR é uma estrutura simples para organizar uma narrativa profissional de forma clara, objetiva e orientada a impacto. Normalmente, esta técnica é utilizada, majoritariamente, em entrevistas e é amplamente conhecida e esperada por entrevistadores e recrutadores. Porém, como pretendo mostrar a você aqui, ela não se limita apenas a esse contexto.

A sigla representa quatro elementos: Situação, Tarefa, Ação e Resultado. A ideia central é evitar relatos soltos, abstratos ou excessivamente técnicos, conduzindo a explicação por uma sequência lógica. Primeiro vem o contexto do problema, depois a responsabilidade; em seguida, o que foi feito e quais foram os desafios; por fim, o resultado e o impacto gerado.

“Refatorei o sistema core de aluguel e monitoramento de veículos da empresa.”

Situação

A situação é o ponto de partida do storytelling. Ela descreve o cenário inicial do que foi feito e as condições em que o problema se encontrava antes da atuação.

Nessa etapa, o objetivo é explicar o que estava acontecendo, qual era o problema, quem era afetado e por que aquele contexto era relevante. Ao invés de se ater a uma visão ultra-abstraída do problema, como “o sistema estava instável”, “o fluxo estava ruim” ou “havia muitos problemas”, ou a uma visão excessivamente técnica, como “o connection pool do Postgres estava sendo estourado mediante a quantidade de goroutines abrindo conexões em horários de pico”, podemos converter isso em uma versão intermediária, mais madura, de forma que seja compreensível para diferentes públicos. Para permitir uma comparação entre o antes e o depois, que veremos nos resultados, precisamos metrificar o máximo possível para guiar as próximas etapas.

Por exemplo:

Uma plataforma de aluguel de carros utilizava um sistema centralizado responsável por reservas, contratos, gestão da frota e monitoramento em tempo real dos veículos. Com o crescimento da operação, a frota conectada passou de 8 mil para 35 mil veículos, e o volume de telemetria aumentou para mais de 18 milhões de eventos diários. Em períodos de pico, os eventos de localização e monitoramento passaram a competir pelos mesmos recursos utilizados pelas jornadas de reserva e contratação. Como consequência, o tempo de resposta das APIs críticas ultrapassou 2,5 segundos, a taxa de erros cresceu, e a atualização da localização dos veículos passou a apresentar atrasos de até alguns minutos.

Tarefa

A tarefa apresenta qual era sua responsabilidade diante do contexto que você precisa ilustrar. Ela não deve ser confundida com o tópico de “Ação”. A tarefa ilustra qual era o objetivo esperado, quais restrições e dificuldades foram encontradas e qual foi a sua atuação profissional para chegar ao resultado esperado. Para um Staff Engineer, essa etapa é especialmente importante porque sua responsabilidade muitas vezes não está limitada a implementações diretas ou à resolução individual. Ela pode envolver coordenação entre times, resolução de conflitos entre pessoas ou áreas, definição de direção técnica, priorização de riscos, alinhamento com a liderança, mentoria de outros profissionais ou condução de uma decisão arquitetural.

Por exemplo:

Minha responsabilidade era liderar uma transformação arquitetural que permitisse sustentar o crescimento da plataforma sem comprometer a experiência dos clientes e a operação da frota. O desafio envolvia reduzir o acoplamento entre domínios, eliminar a competição por recursos entre cargas distintas e criar uma base tecnológica capaz de escalar de forma independente, conforme o crescimento do negócio.

Ação

A Ação descreve o que foi feito concretamente. Essa é a parte em que a narrativa precisa mostrar a execução, os julgamentos, as decisões e a influência exercida para a resolução do problema, em passos simples e claros. Uma boa descrição da ação não deve se limitar a frases genéricas, como “trabalhei com o time” ou “ajudei a melhorar a arquitetura”. Ela precisa evidenciar quais decisões foram tomadas, quais alternativas foram consideradas, quais trade-offs foram avaliados, quais pessoas ou áreas foram envolvidas e quais mudanças foram conduzidas. No contexto Staff+, a ação raramente se resume a escrever código. Ela pode envolver investigação, facilitação, desenho de solução, criação de padrões, negociação de prioridades, redução de ambiguidade e organização da execução.

Conduzi uma análise dos padrões de utilização da plataforma, identificando que os fluxos transacionais e o processamento de telemetria possuíam características de carga completamente diferentes. A partir desse diagnóstico, definimos uma nova arquitetura baseada em microserviços, separando domínios como reservas, contratos, frota e telemetria. A migração foi realizada de forma incremental, priorizando os componentes que mais impactavam a estabilidade da plataforma e acompanhando cada etapa por meio de métricas de latência, capacidade e confiabilidade.

Resultados

O Resultado fecha a narrativa mostrando o que mudou depois da ação. Essa é a parte mais importante do método, porque diferencia esforço de impacto, seja ele positivo ou negativo. Lembre-se de que uma falha também é um resultado.

Entregar uma refatoração, criar um dashboard ou migrar um serviço são exemplos de ações. O resultado está no efeito produzido por essas ações. Um bom resultado mostra redução de latência, diminuição de incidentes, economia de custo, aumento de disponibilidade, melhoria na experiência do usuário, redução de risco operacional, ganho de autonomia dos times ou melhoria na qualidade das decisões. Aqui, precisamos levantar o máximo de dados possível. Nem todo resultado precisa ser exclusivamente numérico, mas ele precisa ser observável. Mesmo quando não há uma métrica exata, é possível demonstrar impacto por meio de evidências concretas, como mudança de comportamento, redução de dependência, aumento de previsibilidade ou criação de uma capacidade organizacional reutilizável.

Após a migração, o tempo de resposta das APIs críticas foi reduzido em aproximadamente 75%, a taxa de erros caiu mais de 90%, e o atraso na atualização da localização dos veículos passou de minutos para poucos segundos. Além dos ganhos de performance e estabilidade, a nova arquitetura permitiu escalar os componentes de telemetria de forma independente, suportando o crescimento da frota sem impactar as jornadas críticas de negócio e reduzindo significativamente o risco operacional da plataforma.

Como eu uso no meu dia a dia

Tracking de Trabalho

Uma das formas mais práticas de usar o STAR no dia a dia é no tracking de trabalho. Em vez de acompanhar apenas atividades concluídas, tarefas em andamento ou status operacionais, o método ajuda a registrar a evolução de uma iniciativa a partir do problema que ela pretende resolver. Eu, particularmente, mantenho um repositório Git privado com todas as minhas entregas relevantes rastreadas ao longo do tempo no formato STAR. Isso me ajuda tanto a elaborar retrospectivas anuais ou semestrais das atividades que entreguei para minha liderança quanto a me preparar para futuras entrevistas de emprego. Esse tipo de dinâmica evita que eu caia no erro de medir meu próprio impacto apenas pela quantidade de atividades entregues, mas sim pelos resultados.

Ferramenta de Influência Técnica

O STAR também funciona como uma ferramenta de influência técnica. Em níveis Staff+, muitas decisões não dependem apenas de uma boa solução, mas da capacidade de tornar o problema compreensível para pessoas com diferentes níveis de contexto. Uma proposta tecnicamente correta pode não avançar se for comunicada apenas como uma preferência arquitetural, um gosto pessoal ou uma melhoria interna de engenharia. Para influenciar, é preciso mostrar qual situação torna aquela mudança necessária, qual risco está sendo tratado, qual ação está sendo proposta e qual resultado a organização pode esperar. Esse método me ajuda a transitar de forma mais segura entre fóruns técnicos e executivos. Mantendo sempre uma perspectiva data-driven, podemos sumarizar ações e propostas de forma padronizada e já ajustada para serem apresentadas em diversos contextos.

One-On-One com a Liderança

Em one-on-ones com a liderança, o STAR ajuda a transformar conversas soltas em conversas sobre evolução, impacto e direcionamento. Muitas vezes, profissionais técnicos usam esse espaço apenas para atualizar status, comentar bloqueios ou pedir validações pontuais. Embora isso seja útil, o one-on-one também deve ser um momento para discutir escopo, influência, prioridades, percepção de impacto e próximos passos de carreira. O STAR oferece uma estrutura simples para organizar essa conversa sem torná-la artificial.

Ao levar uma iniciativa para o one-on-one, posso começar pela Situação: qual problema está em andamento, qual é o contexto político, técnico ou organizacional e por que ele merece atenção. Em seguida, explico a Tarefa: qual papel estou assumindo, qual responsabilidade está sob minha condução e onde existem dúvidas de escopo ou expectativa. Depois, apresento as Ações realizadas ou planejadas, incluindo decisões, alinhamentos, riscos e trade-offs. Por fim, discuto os Resultados observados ou esperados, usando esse momento para calibrar se a direção ainda faz sentido.

Dessa forma, consigo munir minha liderança para debates técnicos e deixá-la a par de tudo o que está sendo feito dentro de um determinado contexto, pois essa estrutura sustenta evidências, capacidade de diagnóstico, priorização, comunicação e tomada de decisão.

Postmortens e Incident Reviews

Em postmortems e incident reviews, o STAR ajuda a organizar a análise sem cair em dois extremos comuns: a busca por culpados ou a descrição puramente técnica dos eventos. Um bom postmortem precisa reconstruir o contexto, explicar o que precisava ser protegido, descrever as ações tomadas durante a resposta e consolidar os resultados e aprendizados. Nesse sentido, o método STAR oferece uma estrutura natural para transformar um incidente em aprendizado organizacional.

A Situação descreve o estado inicial do incidente, indicando qual serviço ou jornada foi afetado, qual era o impacto para os usuários ou para a operação, quando o problema começou e quais sinais indicaram a degradação. A Tarefa esclarece qual era a responsabilidade durante a resposta ao incidente e a sala de guerra, como estabilizar a jornada, reduzir o impacto, preservar dados, comunicar stakeholders, restaurar a disponibilidade ou evitar a propagação da falha. A Ação registra as decisões tomadas, as mitigações aplicadas, os times envolvidos, os trade-offs assumidos e a sequência de resposta. Por fim, o Resultado mostra o desfecho, sumarizando, por meio de dados, o tempo de recuperação, o impacto final, os riscos remanescentes, as ações preventivas e as melhorias propostas.