
Especialmente em grandes empresas, o design organizacional pode não refletir o produto que você está construindo. Por mais que você tente alinhar as pessoas à problemas, eventualmente haverá expertise distribuída por toda a empresa. Como equipes diferentes podem ter prioridades diferentes, o alinhamento entre organizações torna-se uma habilidade muito valiosa.

<Image src="/assets/uploads/2021-10-29/boats.webp" alt="Barcos em alinhamento" caption="Foto por Simon Micheler no <a href='https://unsplash.com/photos/kALqjIawiv0'>Unsplash</a>" placement="default" width="450" height="300" />

### O que cria o desalinhamento?

O desalinhamento, na maioria das vezes, não é intencional. Em uma cultura saudável, a maioria das pessoas desejará apoiar e permitir que você entregue seu produto. No entanto, não há muito que você pode fazer quando está focado nas coisas que acredita serem as mais importantes e sem tempo adicional. Algumas das principais razões pelas quais ja vi times ficarem presos em desalinhamento incluem:

**Priorização divergente.** As equipes devem ter autonomia para definir suas prioridades. Às vezes, haverá desacordo sobre o quão importante um projeto compartilhado é no roadmap de diferentes equipes.

**Financiamento desproporcional ou unilateral.** Não é raro ter organizações trabalhando em domínios semelhantes sendo financiadas por centros de custo diferentes. O que pode acontecer é que o financiamento aconteça para um lado, mas não para o outro, ou, em uma versão mais leve e não necessariamente menos prejudicial, haja investimentos desproporcionais em ambos os lados. Em suma, há uma assimetria na capacidade de execução em relação ao plano original.

**Aumento no escopo devido à descoberta iterativa.** Mesmo quando os ciclos de planejamento estão perfeitamente alinhados, descobrir uma oportunidade maior devido à pesquisa qualitativa, análise de dados ou a insight vindo de clientes após o planejamento dos prazos pode significar que você tem menos flexibilidade para pivotar.

Embora você provavelmente possa resolver esse tipo de desalinhamento taticamente, por exemplo, persuadindo uma equipe parceira a eliminar uma prioridade ou reduzindo o escopo para se adequar a iniciativa na capacidade de ambas as equipes, o comportamento repetido pode fazer os dois lados se sentirem presos um ao outro. Acredito que a causa raiz para esse tipo de situação está frequentemente na falta de entendimento compartilhado ou desacordo na priorização de nível mais amplo.

### Chegando a um entendimento compartilhado

John Cutler tem uma opinião muito boa sobre [o que é entendimento compartilhado](https://www.productplan.com/blog/build-shared-understanding/). Em vez de um "alinhamento de curta duração", o entendimento compartilhado é um estado de alinhamento por meio da direção, em vez de um destino. Algumas das características comuns que observei em equipes que têm esse tipo de alinhamento de longa duração são:

1. **Propósito compartilhado.** Mesmo que pareça óbvio, é fácil negligenciar se você tem ou não um propósito comum para colaborar. Colaboração nem sempre é a resposta - você provavelmente pode nomear várias empresas que sobreviveram à duplicação em grande escala por uma questão de velocidade de execução ou para evitar a otimização prematura. Se você decidir colaborar, porém, o objetivo deve ser claro. Você pode definir um propósito compartilhado escrevendo uma visão conjunta ou, ainda melhor, uma estratégia de produto conjunta. Existem muitos recursos excelentes sobre como fazer isso ([este artigo de Melissa Perri](https://melissaperri.com/blog/2016/07/14/what-is-good-product-strategy) tem um canvas muito útil). Se você não tiver ideias sobre por onde começar, um bom ponto de partida é facilitar uma sessão em que ambas as equipes abstraem projetos compartilhados anteriores e futuros em temas.

2. **Resultados claros.** Um nível abaixo é tentar entender o que você está efetivamente tentando obter com a colaboração. As diferentes equipes contribuem para as diferentes partes do quebra-cabeça? Ou talvez as duas equipes joguem juntas em um ato de equilíbrio, como [metric/counter-metric](https://lethain.com/goals-and-baselines/)? O resultado esperado deve ser específico, mas não para um projeto (de curta duração), mas para a colaboração entre as próprias equipes (de longa duração). Para fins de tangibilidade, considere duas equipes, uma responsável por adoção (aquisição de clientes) e outra pela qualidade (retenção, experiência do usuário). Todos provavelmente concordarão que a baixa qualidade é irrelevante para um produto sem clientes, e a adoção é irrelevante se todos os usuários não retornam devido a experiências de baixa qualidade, mas o que significa sucesso para esse grupo? Em que proporção cada papel deve ser desempenhado? Pode ser, por exemplo, atingir as metas de receita sem diminuir a retenção em mais de 2%.

3. **Modelo de colaboração.** Igualmente importante, toda colaboração precisa de formas de trabalho bem definidas. Você quer evitar uma situação em que precise rediscutir responsabilidades, como medir o progresso em direção ao resultado e como lidar com eventuais riscos de cada novo projeto. O modelo de colaboração como um conjunto de expectativas sobre como você opera as duas equipes como uma equipe mais ampla. Algumas boas práticas que já vi incluem:
    - Formalizar uma "equipe virtual" com alguma representação de ambas as equipes e comprometimento exclusivo ou alta prioridade por um período de tempo mais longo do que um ciclo de planejamento. Fazer isso ajuda não apenas com o foco, mas também com a eficácia, pois as pessoas ficarão entrosadas com o tempo;
    - Usar [matriz RACI](https://www.cio.com/article/2395825/project-management-how-to-design-a-successful-raci-project-plan.html) para alinhar quem faz o quê. Eles ajudam a desvendar mal-entendidos sobre responsabilidades e prevenir lacunas de comunicação;
    - Definir como medir o progresso juntos. Pode ser por meio de métricas, um conjunto de objetivos de entrega, ou desemaranhando uma grande incógnitas em desconhecidos menores. O objetivo final aqui é que a equipe conjunta responsabilize-se mutuamente pelo progresso e tenha expectativas claras de milestones ao longo do tempo.
    - Criar fóruns apropriados para a tomada de decisões, discutindo riscos ou bloqueadores, ou quaisquer outros assuntos não estruturados. Isso evita ter que conversar com pessoas diferentes sobre o motivo de uma decisão ou quais trade-offs foram discutidos, já que o grupo sempre faz parte dessas discussões.

Assumindo que todos concordem sobre o propósito, os resultados e como trabalhar juntos, e a ambigüidade sobre as prioridades, financiamento e oportunidades desaparece. Ao priorizar, diferentes equipes compartilham uma noção dos critérios de priorização, as dependências de financiamento são bem conhecidas e podem ser sinalizadas por ambas as partes, e todos ficarão felizes em mudar os projetos se novas informações chegarem, já que há alinhamento nos resultados desejados. O ponto principal sobre isso é que o alinhamento não é feito no nível do projeto (curta duração), mas no nível da equipe/organização (longa duração).

Um resultado não tão positivo é que existe desacordo em princípio: não há clareza entre as equipes na priorização de nível mais amplo.

### Articulando desacordo para alinhamento

Na maioria das vezes, as pessoas têm medo de discordar e isso pode ser desconfortável, especialmente quando você tem dois grupos de pessoas que estão muito convencidas de que estão certas. Porém, pior do que discordar é não chegar a uma conclusão. A melhor maneira que vi pessoas resolverem esse tipo de situação é articular o desacordo em conjunto, concordando sobre a representação mais justa da realidade e escalando-a para a cadeia de reporte dos dois lados na forma de uma [matriz de decisão de semáforo](https://www.linkedin.com/pulse/decision-making-101-traffic-lights-puppy-case-study-valerio-magliulo/). É assim que funciona:

1. **Escolha uma lista de critérios:** descreva quais são as dimensões sobre as quais você está tentando tomar uma decisão;
2. **Faça com que cada equipe defina uma opção** e defina como ela afeta cada critério;
3. **Represente as compensações que você está fazendo** ao codificar por cores cada célula da matriz *Critérios × Opções*.

O resultado deve ser parecido com este:

<Image src="/assets/uploads/2021-10-29/traffic-light-matrix-pt.png" alt="Exemplo de matriz de decisão de semáforo" caption="Exemplo de matriz de decisão de semáforo" placement="default" width="715" height="400" />

Em vez de passar semanas convencendo, o que pode ser extremamente doloroso, pedir ajuda geralmente é o caminho mais rápido a seguir. Ao representar a situação de maneira justa, as equipes ajudarão as duas linhas de reporte a tomarem a melhor decisão. Como potencial efeito colateral, pode haver alinhamento sobre o trade-off adequado para outras situações semelhantes no futuro.

____

Embora isso seja uma simplificação exagerada do assunto, encontrar o alinhamento entre as organizações é uma habilidade fundamental. Design organizacional ajuda a aumentar a coesão, mas as pessoas mais bem-sucedidas com quem trabalhei [não "shippam o org chart"](https://twitter.com/stevesi/status/1275311075508936704) e tentam construir coesão além das linhas organizacionais.


Encontrar alinhamento entre organizações é uma habilidade inestimável. Aqui estão algumas maneiras de chegar a um entendimento compartilhado e articular desacordos para encontrar alinhamento.

Alinhamento entre organizações


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:

<Video id="eRkgK4jfi6M"/>

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](https://pt.wikipedia.org/wiki/Linguagem).

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](https://www.amazon.com/exec/obidos/ASIN/0321125215/domainlanguag-20). 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](https://en.wikipedia.org/wiki/Domain_model) 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](https://www.whatmatters.com/faqs/okr-meaning-definition-example/) 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](http://www.apostilasdaqualidade.com.br/os-5-porques-5-why-analise-da-causa-raiz/).

**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](https://philcalcado.com/2020/01/31/how_i_like_to_use_okrs.html). 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](https://pt.wikipedia.org/wiki/Lei_de_Goodhart) explica bem:

<Quote quote="Quando uma medida torna-se uma meta, ela deixa de ser uma boa medida." author="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)](https://en.wikipedia.org/wiki/Active_users). 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](https://lethain.com/goals-and-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.


Uma ideia em como superar desafios que times de engenharia e produto enfrentam com stakeholders, metas e métricas através de linguagem.

Desenvolvimento de Produtos

Alinhamento entre organizações

Linguagem como ferramenta para times de engenharia