Eu venho me interessando muito mais em linguagem ultimamente. Acho que é por conta de eu estar convivendo com pessoas que conversam sobre o assunto frequentemente. Como consequência disso, venho prestando mais atenção em o quão poderosa pode ser para vários propósitos.

Esse vídeo abaixo é um bom exemplo. O Jacob Collier explica harmonia em música para uma variedade de audiências, a começar por uma criança de 7 anos de idade e finalizando com Herbie Hancock, um jazzista lendário:

Eu acho impressionante como que em alguns segundos, Jacob consegue explicar harmonia em linguagem apropriada para múltiplas audiencias, indo de pessoas sem nenhuma expertise técnica em música (veja de 00:00 a 1:05) até meta-linguagem (veja 11:00 até 12:00). Em algum momento no estágio final, as interações são desprovidas de palavras – e ainda assim a comunicação é extremamente eficiente. Esse é o principal propósito da linguagem, comunicação.

Eu não consigo evitar fazer um paralelo a tecnologia, especialmente quando vivemos imersos em termos, conceitos e abstrações que não são triviais de serem entendidos, como harmonia em música. Com isso dito, existem situações nas quais acredito que linguagem pode ajudar times de engenharia a serem mais efetivos e comunicar melhor.

Coesão entre time e stakeholders

Eu acho que o melhor exemplo que posso pensar na minha carreira no que diz respeito a linguagem impactar o relacionamento com um stakeholder e metas de um negócio foi quando fui exposto a sistemas de pagamento pela primeira vez. Tentar entender toda a terminologia específica do domínio foi aterrorizante. Ainda me lembro tentar entender autorizações, captura, clearing, liquidação, estornos vs cancelamentos, disputas… era ainda mais difícil tentar entender como essas partes se conectavam quando meus stakeholders articulavam os mesmos conceitos de multiplas formas diferentes ou intercambiáveis.

Minha principal descoberta através dessa experiência foi que aprender algo novo pode ser difícil mas é ainda mais quando uso de linguagem é mal definido entre pessoas técnicas e de negócios.

Minha abordagem favorita ao problema é um conceito discutido no Domain Driven Design do Eric Evans. Segue um pequeno resumo do que ele descreve no livro:

  • Quando stakeholders e times técnicos não compartilham linguagem para comunicação você tem sérios problemas, já que cada grupo constrói seu entendimento em silos;
  • Porque cada grupo tem sua própria linguagem, no melhor dos casos a tradução é cara, e no pior as incompatibilidades passam despercebidas;
  • Isso acaba se refletindo no código e design dos sistemas, o que pode fazer com que jargão técnico ou conceitos específicos de domínio sejam representados de forma incompleta ou errada;
  • E da mesma forma, a linguagem usada por stakeholders não cobre a necessidade do time técnico, levando ambos a ainda mais isolamento;

A proposta para se resolver esse problema é o que Eric chama de Ubiquitous Language (Linguagem Onipresente): ter uma linguagem compartilhada que articula um modelo do domínio de forma simples, concisa, sem vazar detalhes de implementação ou jargão específico de domínio excessivamente. Todos os envolvidos usam e fazem parte da construção dessa linguagem compartilhada. O resultado é uma linguagem que você pode user em qualquer lugar, do código à ao planejamento estratégico já que ela representa o que é relevante para o contexto com o nível certo de granularidade e abstração para qualquer contexto, portanto funcionando para ambos times técnicos e especialistas de um domínio.

Apesar de não relacionado a relação stakeholder/time de engenharia, e além de todos os benefícios inerentes a uma comunicação melhor, Ubiquitous Language pode reduzir a curva de aprendizado para novos membros de um time, ajudar na mobilidade interna de talento, facilitar troca de conhecimento entre domínios, e reduz bloqueios para engenheiros(as) terem maior impacto em um domínio.

Definição de metas e responsabilidades

Ao definir metas você provavelmente usará uma combinação de qual impacto é esperado e resultados mensuráveis para atingir aquele impacto, como por exemplo OKRs são um excelente exemplo de como se fazer isso. Aqui estão algumas ideias em como melhorar uma meta.

Primeiramente, os benefícios de se atingir uma meta devem ser óbvios. Se é dificil de se articular o valor que será criado ao atingir uma meta, isso pode potencialmente significar estar resolvendo o problema errado, ou apenas o sintoma de um problema. A situação se torna ainda mais difíceis como parte de um time, dado que existe uma inclinação natural a confirmation bias e comportamento de manada e os outros membros do time vão facilmente ter empatia. Quando estiver em dúvida se esse é ou não o problema certo a se resolver, uma técnica que pode ajudar é a five whys.

Para fazer a meta em si ser óbvia, a linguagem usada deve ser simples. Para atingir isso, evitar técnicos demasiadamente técnicos, acrônimos, nomes de componentes, apelidos, linguagem específica de negócios ou domínio, ou linguagem interna que alguém fora do seu time não entenderia pode ajudar. Usar esse tipo de recurso em contextos extremamente técnicos é justificável, contanto que haja um trade-off consciente, dado que se uma nova pessoa entrar no time, ou existir a necessidade de se articular a meta fora do time, será mais dificil fazer a meta ser informativa para essa pessoa.

Ainda mais, uma meta deve ter opinião e ser focada em outcomes ao invés de outputs. Uma excelente leitura nesse assunto é este artigo do Phil Calçado no qual ele fala sobre OKRs. Fazer esse paralelo de usar os KRs como o teste para o Objetivo é bastante interessante do ponto de vista de linguagem, dado que existe uma opinião inerente do que é necessário para atingir um impacto desejado através da escolha de resultados mensuráveis.

Finalmente, metas não devem ser relativizáveis. Como resultado de linguagem mal definida, eu já vi metas serem relativizadas não-intencionalmente. Uma boa escolha de linguagem ajuda a definir responsabilidade, e como consequência ajuda o time a ser honesto sobre definição do que é sucesso. Isso inclui como frasear objetivos e resultados chave, como graduar progresso de resultados chave seja através “sim”/”não”, percentuais, status, ou como rodar uma retrospectiva para avaliar o que pode ser feito de uma forma melhor.

Em resumo, uma boa meta tem um benefício óbvio, é escrita em linguagem simples, deixa espaço suficiente para criatividade sobre o que precisa ser feito e como – a ser definido pelo time trabalhando no problema a ser atingido – mas tem um porque obvio e explícito, quanto precisa ser atingido, e deve comunicar o que é sucesso de forma extremamente clara.

Definição de metricas e baselines

Métricas são parte fundamental de qualquer meta, mas metas chamam por foco. É dificil de se articular uma métrica de uma forma simples e ao mesmo tempo capturar todas as nuances daquela medida como métricas de suporte, baselines para métricas que competem com a métrica principal, ou consequencias além do escopo de um time para um time específico.

De toda forma, métricas isso não significa que uma métrica que não está em foco através de uma meta não seja importante. Na verdade, não se atentar a métricas de suporte ou baselines pode te tirar do seu curso ao atingir uma expectativa em uma métrica em uma meta, mas ainda assim não entregar o valor que você espera. Como a Lei de Goodhart explica bem:

Quando uma medida torna-se uma meta, ela deixa de ser uma boa medida.

— Charles Goodhart

Como um exemplo, imagine uma situação hipotética de um grupo de times responsáveis por fazer onboarding de novos usuários a um produto, com a meta de “aumentar o numero de cadastros em 20% na primeira metade do ano”. Ao focar demais em qualidade de leads, existirá um aumento na fricção através de checagem de identidade, o que como consequencia aumentará o churn, e virará custo adicional em um time em um ponto anterior da jornada, por exemplo ads para aquisição de clientes. Em contrapartida, no outro lado do espectro existe otimizar demais em intake, o que então gerará mais custos por fraude em times em pontos posteriores da jornada, ou overhead operacional em cancelamentos de conta por motivos de fraude.

Com este contexto, uma forma que linguagem pode ajudar é criando uma nova métrica, chamemos ela de “cadastros genuínos” que leva em consideração ambos baselines – manter churns de checks de identidade em <5% e rejeições por motivos de fraude de identidade em <0.1%. A nova meta é “aumentar o numero de cadastros genuinos em 20% na primeira metade do ano”. Isso torna a definição da métrica muito mais clara: aumentar sign-ups enquanto se mantém qualidade e intake nos mesmos níveis. Em efeito complementar, a métrica agora foca no domínio que é responsabilidade do grupo de times, e pode ajudar com foco na definição de o que precisa ser feito:

  • O que precisa ser feito para melhorar a experiência do usuário no cadastro?
  • O que precisamos fazer para reduzir fricção ou churn quando o usuário se cadastra?
  • Quais features do modelo de ML de fraude podemos usar para prever comportamento fraudulento no cadastro?

Isso é útil não só no contexto que existem baselines, mas também quando você tem uma métrica de suporte implicita, ou uma definição de onde o valor vem no contexto do seu produto. Um bom exemplo é monthly active users (MAU) and daily active users (DAU). Cada produto terá sua própria definição do que é um usuário “ativo”, por exemplo através de uso do produto ou engajamento. Você pode ir mais a fundo se quiser, ou apenas utilizar a informação que a palavra “ativo” te oferece em termos de informação.

Uma boa leitura sobre baselines é esse artigo do Will Larson sobre Metas e Baselines no qual ele explica uma dinâmica similar a o que foi descrito acima e uma abordagem diferente para metas que eu achei bastante interessante.


Em conclusão, como o Jacob Collier mostra no vídeo do início do artigo, linguagem é mais eficiente quando é considerada em relação à audiência. Ela vai exigir diferentes formas e formatos em diferentes cenários. A parte mais legal dessa jornada é estar aberto a tentar e descobrir o que funciona, em conjunto.