
A confiança é um ingrediente fundamental de qualquer relacionamento bem-sucedido. Talvez por causa dessa qualidade fundamental, as pessoas tendem a pensar na confiança como um estado aspiracional de robustez inabalável, mas, na realidade, a confiança é meio que uma "bagunça". Ela será colocada à prova, na maioria das vezes de maneiras não intencionais. Então, se você esperar demais para o lado da robustez, rapidamente se encontrará em um estado em que não confia em ninguém e se priva de conexão humana e autenticidade.

Talvez o "estado alvo" da confiança seja um sistema antifrágil? Para fins de definição:

<Quote quote="Algumas coisas se beneficiam de choques; elas prosperam e crescem quando expostas à volatilidade, aleatoriedade, desordem e estressores e adoram aventura, risco e incerteza. No entanto, apesar da onipresença do fenômeno, não há nenhuma palavra para o exato oposto de frágil. Vamos chamá-lo de antifrágil. A antifragilidade está além da resiliência ou robustez. O resiliente resiste aos choques e permanece o mesmo; o antifrágil melhora." author="Nassim Nicholas Taleb" />

É improvável que alguém construa confiança por meio da volatilidade, aleatoriedade, desordem e estressores. Provavelmente o oposto funcionará melhor para construí-lo. Você também não quer infligir tais fenômenos em nenhum relacionamento intencionalmente. No entanto, é ingênuo pensar que é evitável.

Com a confiança estabelecida, relacionamentos genuinamente confiáveis ficam mais fortes e melhores diante de adversidades inesperadas. Portanto, confiança é antifrágil.

Uma nota sobre relacionamentos confiáveis pode melhorar com a volatilidade, aleatoriedade, desordem e estressores.

Confiança é antifrágil


Há muita literatura excelente sobre [por que você deve construir uma plataforma](https://kislayverma.com/platform-thinking/why-you-should-build-a-platform/) e [o que é uma platforma](https://martinfowler.com/articles/talk-about-platforms.html), mas não encontrei um recurso que ilustre situações específicas em que você possa querer construir uma. Com isso, comecei a pensar em padrões que poderiam ajudar a identificar a necessidade de uma plataforma e o que fazer quando você se encontra nessa situação como líder de engenharia.

Pretendo escrever alguns artigos sobre diferentes padrões que vi no passado. Se você pensar em outros exemplos, <SocialLink type="twitter">entre em contato no twitter</SocialLink> e eu escreverei sobre ele e creditarei você como contribuidor.

### O que é uma plataforma?

Para pessoas menos familiarizados com plataformas técnicas, usarei a seguinte terminologia simplificada e um conjunto de princípios que podem ajudar a entender o básico. Se você quiser se aprofundar no assunto, os artigos na introdução lhe darão mais profundidade sobre o assunto.

##### Terminologia

- **Equipe de aplicação** é uma equipe que aproveita a plataforma técnica para um caso de uso específico, por exemplo, uma equipe construindo cobrança recorrente por meio de uma plataforma de pagamentos;
- **Equipe da plataforma** é a equipe que opera e mantém a plataforma técnica alavancada pelas equipes de aplicação, por exemplo, a equipe da plataforma de pagamentos;
- **Capability** é um pedaço de software que fornece à empresa e ao usuário a capacidade de fazer algo, por exemplo, "cobrar um cartão de crédito" é um recurso da plataforma de pagamentos, assim como "reembolsar uma transação com cartão".

##### Princípios

1. **Uma plataforma é self-serve para a maioria dos casos de uso.** Não apenas do ponto de vista técnico – o que significa excelente documentação, experiência do desenvolvedor etc. – mas também do ponto de vista de pessoas e processos. O [modelo de coordenação de self-serve do Jade Rubick](https://www.rubick.com/platform-teams-and-the-self-service-model/) ilustra em detalhes o que quero dizer.
2. **Uma plataforma é extensível para casos de uso aos quais ela não oferece suporte.** As equipes de aplicação podem aproveitar a plataforma como blocos de construção em vez de uma caixa preta para criar e dar suporte às suas próprias necessidades. Por exemplo, estender uma plataforma de pagamentos para suportar cobrança recorrente por uma equipe de aplicação pode ser fácil se ela tiver um recurso de "armazenar cartões" e suportar "cobrar um cartão de crédito".
3. **Uma plataforma opera de forma semelhante a um terceiro para os casos de uso.** Toda a complexidade na manutenção do domínio da plataforma é abstraída da equipe do aplicativo. Prevenção de abuso, segurança, conformidade e fornecedores terceirizados são bons exemplos da complexidade que uma plataforma deve abstrair.

A seguinte citação que tirei [deste artigo](https://martinfowler.com/articles/talk-about-platforms.html) escrita por Evan Bottcher no blog de Martin Fowler ilustra muito bem o conceito:

<Quote quote="Uma plataforma digital é uma base de APIs self-serve, ferramentas, serviços, conhecimento e suporte que são organizados como um produto interno atraente. Equipes de entrega autônomas podem usar a plataforma para fornecer recursos do produto em um ritmo mais rápido, com coordenação reduzida." autor="Evan Bottcher" />

Com esta cartilha rápida sobre plataformas técnicas, aqui está uma história fictícia que exemplifica o que quero dizer com o padrão de "consolidação".

### Uma história e o problema

A Acme corp iniciou seus negócios atendendo apenas clientes empresariais. Além de construir um ótimo produto, eles também tinham uma equipe de engenharia de software cujo objetivo era onboarding de empresas. Além de projetar a experiência, a equipe de onboarding de empresas desenvolveu algumas funcionalidades básicas para:
- Verificações de autenticidade através de um número de identificação fiscal (CNPJ) para garantir que as empresas clientes estão legalmente registradas;
- Verificações de compliance para prevenção de lavagem de dinheiro, por motivos de compliance, segurança e qualidade;
- Verificação de informações de contato para garantir que qualquer empresa cliente possa ser contatada por qualquer motivo;
- E, como parte do fluxo de onboarding, era necessário um cartão de crédito, que seria cobrado após o término do trial do produto.

Product-market fit veio muito rápido para a Acme, devido ao seu produto inovador. Consequentemente, suas ambições se ampliaram e a liderança da Acme anunciou uma nova estratégia para apoiar os consumidores sem um negócio jurídico, com um conjunto diferente de recursos. Para fazer isso, eles contrataram outra equipe para construir o onboarding de consumidores finais. Com a crescente pressão dos investidores para atingir as metas, fazia sentido que a equipe de onboarding de consumidores desenvolvesse seu próprio conjunto de sistemas. Nessa fase, para evitar contas falsas, bastava enviar um e-mail para confirmar o endereço de e-mail do consumidor.

Ao longo de alguns meses, o lado de consumidores finais do negócio também cresceu consideravelmente. A Acme viu outra oportunidade de cobrar um subconjunto de consumidores para um plano de seu produto comercial. A equipe de onboarding de consumidores implementou rapidamente o recurso, que foi uma excelente vitória. No entanto, alguns meses após o lançamento, alguns problemas vieram à tona:
- Trials entre os perfis do consumidor e do negócio eram inconsistentes, e gerenciar diferentes durações de ciclos criava muita sobrecarga para a equipe financeira;
- Dado que a integração do consumidor e da empresa usou fornecedores de pagamento diferentes, o mesmo cartão de crédito que funcionaria em uma conta comercial não funcionaria em uma conta de consumidor;
- Como ambos os produtos foram construídos de forma independente, a linguagem para se referir ao domínio variou entre consumidores e empresas, e às vezes era até conflitante;
- À medida que a Acme se expandiu para novos mercados, as equipes de consumidores e empresas tiveram que adicionar novos tipos de pagamento, novas verificações de conformidade e suporte para novas moedas.

### Sintomas

Normalmente, existem alguns sintomas que antecedem a necessidade de aplicar o padrão de consolidação:
1. **Tecnologia fragmentada para um recurso**. Especialmente quando você está experimentando um novo produto, o excesso de indexação na coesão geralmente é uma má ideia, pois você mal sabe se o produto será bem-sucedido. Na anedota acima, quando a equipe de liderança de engenharia formou a equipe de onboarding de consumidores finais, receber um pagamento estava fora do escopo, então provavelmente foi a decisão certa construir um novo conjunto de sistemas. Embora, à medida que o escopo aumentou, a empresa acabou com sistemas duplicados para muitos recursos, como "receber um pagamento", "executar verificações de conformidade", "gerenciar trials".
2. **Duplicação de trabalho ou dependências indiretas similares**. Na anedota, ao expandir para novos mercados, as equipes de integração de consumidores e empresas dependeriam de uma "equipe de gerenciamento de usuários" para adicionar um campo "país" ao modelo de usuário para selecionar qual moeda usar ao fazer um pagamento. Podemos abstrair isso como mais de uma equipe tendo que fazer uma implementação muito semelhante ou às vezes o mesmo trabalho, ou duas equipes tendo dependências indiretas pelas mesmas razões para as mesmas partes.
3. **Linguagem quebrada em toda a empresa**. No exemplo acima, referir-se a "trial de produto" ou "verificações de conformidade" é muito ambíguo, pois você pode estar se referindo a coisas muito diferentes dependendo de com quem você fala. Para pessoas familiarizadas com o livro Domain-Driven Design, o capítulo [Ubiquitous Language](https://martinfowler.com/bliki/UbiquitousLanguage.html) vem à mente aqui.

### Uma solução para o problema

Um exemplo de um caminho a seguir para equipes em tal situação é usar o modelo ["aplicação/platforma"](/pt/composition-for-teams-platform-and-application-pattern) e dividir a responsabilidade em três áreas:
- Onboarding de consumidores, que foca na experiência do onboarding do consumidor e qualquer coisa específica do lado do consumidor;
- Onboarding de empresas, com foco na experiência do negócio e suas especificidades;
- Plataforma de onboarding, que consolida em uma plataforma os recursos utilizadas por ambas as equipes de onboarding. Bons exemplos de recursos nesta equipe de plataforma podem ser "receber pagamentos", "gerenciar testes", "executar verificações de conformidade", que podem ser configurados ou estendidos a diferentes casos de uso;

E aqui está um detalhamento de um passo a passo para testar a mudança e ver se faz sentido para o seu caso:

1. **Forme uma [equipe virtual](https://www.referenceforbusiness.com/management/Tr-Z/Virtual-Organizations.html) com representação de ambas as equipes**. Este grupo de pessoas será responsável por colocar juntos um plano de ação e testar a hipótese. Além de trabalhar em um roadmap compartilhado, recomendo analisar SLAs por caso de uso, nível de extensibilidade necessário por equipe e priorizar casos futuros na nova plataforma com a contribuição de ambas as equipes. Você pode descobrir que talvez possa viver com a duplicação por mais algum tempo, ou até mesmo concluir que uma plataforma não é o ajuste certo;
2. **Desenvolva capacidade para consolidar recursos** Se esse for o caminho a seguir, em vez de fazer uma migração big bang ou reescrever tudo do zero, puxe um recurso de cada vez dos sistemas anteriores para a nova plataforma. Uma maneira de priorizar são os casos de uso que são os maiores pontos problemáticos tanto para as equipes quanto para o negócio, e também quais são os maiores gargalos para o negócio;
3. **Eventualmente, forme uma nova equipe**, de preferência com alguma representatividade das equipes existentes, e adote o modelo de aplicação/plataforma.

E para encerrar, veja como fazer isso resolve os sintomas mencionados acima:

1. A tecnologia fragmentada não é mais um problema, pois, por design, os recursos compartilhados estão em uma única equipe;
2. Idealmente, a maior parte do trabalho deve ficar com a equipe da plataforma ao adicionar um novo tipo de pagamento, cumprir uma nova regra de compliance ou adicionar um novo tipo de trial;
3. O novo limite organizacional na equipe da plataforma pode ser uma função forçante para a correção da linguagem, mesmo que ainda seja necessario um esforço consciente da equipe da plataforma.

_____

*Agradecimentos especiais a [David Golden](https://xdg.me/) por seus comentários sobre uma versão anterior deste artigo.*


Padrões de Plataforma é uma série sobre como usar padrões para construir plataformas. O padrão de consolidação consiste em mesclar recursos dispersos em uma equipe de plataforma.

Padrões de Plataforma #1: Consolidação


O caminho mais comum para o gerenciamento de engenharia é por meio de uma posição de liderança técnica com responsabilidades de pessoas, também conhecido como [tech lead manager (TLM)](https://www.teamblind.com/post/What-does-Tech-Lead-Manager-mean-in-Google-8e4VQDy1). Nessas funções, além de ter responsabilidades de pessoas, o gerente de engenharia também é um especialista técnico dentro da equipe.

À medida que avança em sua carreira de gerenciamento, uma pessoa gerente pode se deparar com situações em que gerencia uma equipe com um conjunto de habilidades diferente do que tinham como engenheira. Embora esse tipo de oportunidade venha com muito aprendizado, também pode vir carregado de dúvidas.

Não há uma resposta absoluta sobre o quão técnica deve ser uma gerente de engenharia, pois a resposta está vinculada ao contexto em que está inserida. Ainda assim, um fato é que os gerentes de engenharia são líderes funcionais. Eles devem apoiar sua equipe na tomada de decisões estrategicamente alinhadas para os negócios, mesmo quando não estiverem tão confiantes em suas habilidades técnicas.

### Proteger o alinhamento estratégico

Como um TLM, você tem uma capacidade maior de introduzir controles granulares. Revisar código, discutir como implementar uma mudança ou um simples mergulho profundo com um engenheiro são exemplos desses controles granulares que informam sua perspectiva para fornecer conselhos e comentários. Um gestor menos técnico que precisa garantir que o investimento de tempo e esforço vá para as oportunidades mais impactantes só pode recorrer exclusivamente a controles um pouco mais abstratos, incluindo:

1. **Uma visão clara de longo prazo.** Isso é particularmente importante, pois "tunnel vision" é ainda mais prejudicial para equipes sem uma líder técnica forte. A forma como os sistemas são construídos pode impactar fortemente sua capacidade de permanecer alinhado à estratégia, portanto, ter uma compreensão clara de qual é a condição-alvo por um período mais longo (por exemplo, 2-3 anos) e comunicá-la bem ajuda a equipe a tomar decisões que são à prova de futuro, na medida mais significativa possível;
2. **Um conjunto de métricas de primeira linha e métricas de proteção.** Ter um conjunto bem definido de indicadores que informam "o que é bom" ajuda a avaliar os resultados do time e desempenha um papel considerável na priorização. Por exemplo, priorizar entre aumentar a disponibilidade em 1% ou reduzir falsos positivos em 10% é mais fácil quando você pode atribuir ambos ao mesmo resultado de negócio, como "Economia de custos operacionais". Também o ajuda a ficar longe dos detalhes de implementação que você não entende;
3. **Um ciclo de planejamento com um conjunto claro de resultados.** Embora você possa não entender os aspectos internos de como algo será alcançado, é essencial entender o que e por que isso precisa ser alcançado, assim como comunicar isso claramente com a equipe . Resultados claros e quantificáveis ​​ou objetivos de envio claros vinculados a um resultado de negócios são essenciais para qualquer contexto, mas é proibitivo para equipes com líderes não tão técnicos, pois tentar alinhar a equipe através dos detalhes será contra-intuitivo na melhor das hipóteses e desastroso no pior cenário.

Embora você possa achar que suas habilidades técnicas podem prejudicar sua capacidade de fazer o que foi dito acima, definir bons controles abstratos requer muito mais compreensão do negócio do que as partes internas dos sistemas que alcançam os resultados.

### Descentralizar as funções de liderança técnica

Por muitas razões, incluindo evitar se tornar um gargalo, gerentes de engenharia devem compartilhar as funções de liderança técnica, mesmo quando são relativamente técnicas. Torna-se imperativo quando você pensa que não é competente para tomar decisões técnicas sólidas. Uma abordagem para resolver a situação, que eu particularmente não sou fã, é o TL + EM [two-in-a-box](https://hbr.org/2012/04/leadership-teams-why-two-are-b), em que o EM transfere a liderança técnica para um engenheiro sênior/staff na equipe, mantendo as responsabilidades de gerenciamento de pessoas. Acredito que isso não resolva o aspecto do gargalo, mas, em vez disso, o fragmenta em dois gargalos diferentes com a sobrecarga de alinhamento adicional.

O que acredito ser uma abordagem melhor é identificar os diferentes desafios na equipe e delegar problemas inteiros aos mais competentes para resolver os desafios. Isso evita a fusão de todos os problemas em um único problema e ajuda a identificar as melhores pessoas em sua equipe para esclarecer cada área problemática. Para poder confiar e delegar diferentes tipos de desafios a diferentes pessoas, você pode acabar com [uma equipe em forma de triângulo invertido](https://twitter.com/GergelyOrosz/status/1480942071179579393) – uma equipe com um maior presença sênior – que vem com seu próprio conjunto de desafios, mas geralmente resolve bem a lacuna de liderança técnica na equipe.

### Reúna informações imparciais para tirar conclusões

Se você tem alinhamento de alto nível e liderança compartilhada para diferentes assuntos, como você constrói uma imagem coesa do estado de toda a equipe? Ao confiar em vários engenheiros seniores ou de equipe com diferentes desafios, você pode resolver bem as áreas de problemas individuais, mas não permite a coesão. É fácil desviar a responsabilidade pensando que o alinhamento virá de pessoas falando umas com as outras, especialmente em uma equipe sênior. A coesão só acontece intencionalmente e, se você deixar que ela seja estabelecida organicamente, pode ser altamente tendenciosa por algumas pessoas mais vocais, com alta propensão a serem aquelas em quem você confia mais responsabilidade.

Com a falta de competência para [verificar e inspecionar](https://lethain.com/inspection/), e não se sentir confortável em apenas confiar, já vi pessoas terem muito sucesso em criar mecanismos onde você reúne informações imparciais para chegar às suas conclusões. Algo tão simples quanto executar uma pesquisa anônima com apenas respostas de escala linear variando de 1 a 5 pode fornecer uma imagem coesa que representa as opiniões de todos e ajudar a iniciar as discussões certas.

### Aprenda o básico ao longo do caminho

Eu me encontrei nessa situação no passado, gerenciando equipes que trabalhavam de perto com machine learning quando, sem dúvida, eu falharia em uma prova de estatística básica. No entanto, mais comumente, as pessoas têm orgulho de seu ofício e terão prazer em ajudá-lo a entender o que fazem. Além de aprender ao longo do caminho, desenvolvi uma boa apreciação por identificar pessoas que poderiam me ajudar com sucesso a entender o básico. Como se vê, isso também é um forte sinal de competência de quem seria capaz de melhorar o nível dos outros na equipe sempre que necessário.


Gerenciar equipes para as quais você não tem conhecimento técnico pode ser um desafio. Neste artigo eu falo um pouco sobre o que já funcionou para mim antes.

Gerenciando times de engenharia fora da sua expertise técnica


A gestão de performance é amplamente utilizada como uma forma de planejar, revisar e recompensar as pessoas por suas contribuições. Para pessoas que não estão familiarizadas com o processo em grandes empresas de tecnologia, ele consiste basicamente em:

1. **Alinhar as expectativas.** As empresas geralmente têm uma estrutura que dita o comportamento esperado e o escopo do impacto para um nível de senioridade específico; e expectativas específicas da função fornecidas pelo gerente direto da pessoa, como expectativas dentro de sua equipe ou organização. O início de cada ciclo de gestão de desempenho geralmente consiste em discutir o estado atual das habilidades da pessoa nessas duas dimensões e entrar em acordo sobre como será o próximo ciclo.

2. **Forneçer suporte e feedback continuamente.** Ao longo do ciclo de avaliação de performance, as pessoas precisam ter os canais de suporte para buscar input, fornecer feedback e realinhar expectativas. Normalmente, o processo consiste em 1:1s em uma base semanal/quinzenal e revisões de plano/metas todos os meses. Algumas empresas também fazem check-ins no meio do ciclo, que são o ponto médio de um ciclo de desempenho, com feedback e reflexões um pouco mais formais.

3. **Reconhecer e recompensar as contribuições.** Ao final de cada ciclo de desempenho, as pessoas são recompensadas e reconhecidas por suas realizações. Diferentes empresas também terão seus meandros, mas geralmente é uma combinação de compensação extra (por exemplo, aumentos de salário, atualizações de ações/equity, bônus) e mais escopo e responsabilidade (promoções, assumir mais responsabilidades e assim por diante). A parte da recompensa geralmente é definida por meio de um comitê criado para reduzir o viés/bias e focar nos fatos, para que o processo seja o mais justo possível. O que sai deste estágio é usado como entrada para o próximo ciclo de desempenho.

A gestão de desempenho implica controle, e os gerentes têm sua parcela justa de responsabilidade pelo sucesso de um relatório em suas funções. Embora, na grande maioria das vezes, **eu acho benéfico abordar minha função como gerente no desempenho de um reporte como uma função de capacitação em vez de uma função de controle**. Para explicar melhor meu ponto, considere [duas metas de desempenho que tirei do Radical Candor](https://www.radicalcandor.com/growth-and-stability/): pessoas que buscam crescimento e pessoas que buscam estabilidade.

### Facilitando uma trajetória de crescimento

Por uma questão de definição, o crescimento pode consistir em pessoas buscando uma promoção de sênior para staff, mas também pessoas que procuram uma oportunidade de aprendizado, como um engenheiro de back-end que deseja fazer mais trabalho com dados ou deseja tente uma nova função, ou uma gerente de engenharia entrar como EM provisória para uma vaga dentro da mesma organização para se expor a diferentes desafios.

Independentemente do cenário, facilitar o crescimento de uma pessoa é fundamentalmente achar oportunidades de match às suas aspirações. Facilitar consiste em identificar em conjunto oportunidades significativas que levarão as pessoas à condição desejada. O primeiro cenário é mais simples - as promoções são "lagging", o que significa que há uma necessidade de desempenho no próximo nível para ser promovida, portanto, o alinhamento das expectativas consiste em estabelecer metas para aquela pessoa em alinhamento com expectativas do proximo nível. No caso focado em aprendizado, as expectativas são geralmente menos vinculadas à empresa e muito mais vinculadas à equipe ou à organização - o que, teoricamente, a pessoa gerente tem ainda mais agência em encontrar oportunidades.

Da mesma forma, fornecer suporte e feedback pode ser feito de várias maneiras. Exemplos são diretamente por meio de canais 1:1 já estabelecidos mencionados anteriormente e indiretamente, ajudando a pessoa a construir uma rede de apoio ao seu redor: bons mentores para fornecer conselhos, um incentivo financeiro para aprendizagem e desenvolvimento utilizando o orçamento da empresa, etc.

Em suma, **embora gerentes possam ser uma força multiplicadora na trajetória de crescimento de alguém, as pessoas devem ter agência e desejo pelo caminho de desenvolvimento.** É por isso que acredito que o papel da pessoa gerente na trajetória de crescimento de um reporte é fundamentalmente sobre facilitação.

### Facilitando uma trajetória de estabilidade

Uma trajetória de estabilidade pressupõe que a pessoa está tendo um bom desempenho em seu nível atual e deseja continuar assim por qualquer motivo. Embora algumas empresas tenham pressão de crescimento para a progressão na carreira até o que chamam de nível "terminal", que uma vez atingido, não há risco de "up-or-out". Em tais circunstâncias, as pessoas geralmente buscam estabilidade em vez de crescimento por vários motivos, que vão desde o foco estar em outra parte da vida ou simplesmente gostar das coisas como são.

Em tais cenários, as pessoas já conhecem bem as expectativas em seu nível. **Na maioria dos meios, especialmente nos níveis "terminais", a função de um gerente para um reporte em uma trajetória de estabilidade é facilitação.**

### Quando controlar o desempenho

Embora a maior parte do trabalho seja facilitação, há grandes razões pelas quais controlar o desempenho é uma abordagem razoável. Em última análise, a pessoa gerente é responsabilizável pelos resultados da equipe e, às vezes, não é possível chegar a um consenso com o reporte. Aqui estão alguns exemplos que vêm à mente:
- **Quando uma trajetória de crescimento individual pode afetar as metas ou compromissos do negócio**. Cenários típicos de algo errado incluem perseguir uma promoção por meio de [desenvolvimento orientado à promoção](https://twitter.com/gergelyorosz/status/1442162670753431559) e resultar em um rating ruim no nível atual e metas perdidas devido à negligência do gerente, ou não definir um período de experimentação e plano de reversão para as pessoas que estão fazendo movimentos laterais de IC para gerente e vice-versa. Bons controles para evitar situações como essa são usar o estágio de alinhamento de expectativas no início do ciclo de desempenho para definir quando intervir e como isso aconteceria.
- **Quando uma ação individual impacta a equipe diretamente**, por exemplo, quando há resistência para desenvolver uma habilidade onde a falta dela afeta o funcionamento da equipe. Um bom exemplo pode ser um gerente que não deseja nenhum envolvimento nas decisões técnicas, mas não consegue delegar a responsabilidade a um IC sênior/staff. As pessoas às vezes podem nadar sem querer contra a corrente da equipe, e uma boa maneira de controlar proativamente isso para não se tornar um problema de desempenho é por meio de 1:1s, revisões de metas, apontando as pessoas para as diretrizes de expectativa de nível da empresa para seu nível, etc.

Existem muitas outras circunstâncias, mas acredito que **o resultado final é duplo: em primeiro lugar, mais do que quando, "como" importa muito** - o controle arbitrário pode parecer microgestão; **e em segundo lugar, normalmente o aspecto de controle da gestão de desempenho torna-se fundamental para ser exercido quando há um impacto além da pessoa em suas ações**, o que é muito comum para gestores, menos para ICs.

### Quando não controlar o desempenho

Da mesma forma, as coisas também podem dar errado ao tentar gerenciar demais o desempenho do ângulo de controle. Um exemplo que vem à mente é quando o gerente e o reporte apresentam incentivos desalinhados. O que quero dizer com isso é que o que é "certo" para a função em questão não é o que é "certo" para a pessoa, por exemplo, necessidade significativa de formato em T em skillset e o desejo do indivíduo ser de seguir a rota de especialização. Em tais circunstâncias, **aplicar controle pode deixar apenas duas opções ruins para escolher: dobrar a função para caber a pessoa ou dobrar a pessoa para caber na função.**

É nessas situações que o enquadramento de capacitação tem me ajudado mais - um indivíduo de alto desempenho em outra equipe é um resultado melhor do que um indivíduo de baixo desempenho nesta equipe específica para o negócio. Já vi pessoas se mudarem internamente e serem promovidas no próximo ciclo porque estavam fundamentalmente prontas, mas não tinham oportunidades de correspondência, e pessoas deixaram as empresas porque não queriam desenvolver seu conjunto de habilidades na direção de que a equipe específica precisava. Sem dúvida, a primeira situação é preferida, por isso, por padrão, **acredito que olhar a gestão de desempenho do ângulo da facilitação tende a funcionar muito bem, pelo menos para mim.**


Gerenciamento de performance é uma forma de planejar, revisar e recompensar as pessoas pelas suas contribuições. Nesse artigo eu explico porque eu acho que o processo é mais sobre facilitação do que controle.

Facilitação de performance


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


Recentemente, um colega gerente de engenharia me perguntou qual era meu framework para delegação, e isso me fez pensar em como resumir o que acredito ser uma boa delegação em alguns princípios. Há muita literatura por aí sobre delegação. Mesmo assim, nunca investi tempo sintetizando o que acredito ser uma boa delegação em algo tão simples como um conjunto de princípios.

Em essência, os melhores exemplos de delegação que experimentei compartilham algumas características. Como delegador, eu poderia concentrar minha energia em outro lugar; Tive o nível certo de envolvimento quando solicitada a minha orientação e cheguei ao resultado esperado por meio do delegado. Da mesma forma, como delegado, tive oportunidades de trabalhar em problemas desafiadores e descobrir como resolve-los sozinho; Eu tinha o nível certo de suporte sempre que me sentia bloqueado e era responsabilizado pelos resultados esperados.

O padrão é bastante claro: **os melhores exemplos de delegação que posso pensar combinam a movimentação de autonomia e responsabilidade simultaneamente do delegador para o delegado**. Eu reduzi isso a três princípios para me ajudar a reproduzir o padrão que acredito ser uma boa delegação:

### Delegue problemas em vez de pedaços de uma solução

Na maioria das vezes é uma má ideia delegar com muita estrutura. Se você tiver que quebrar todas as etapas para chegar à solução, provavelmente significa que ainda está resolvendo a maior parte do problema sozinho. [Work is like a hill ("o trabalho é uma colina") e muito disso está em descobrir o que fazer](https://basecamp.com/shapeup/3.4-chapter-13#work-is-like-a-hill). Os incentivos não são alinhados se você delegar com muita estrutura: dois dos principais resultados que você obtém ao delegar a outras pessoas é expor as pessoas a uma experiência de aprendizado e liberar-se para concentrar sua atenção em outro lugar.

Ao delegar com muita estrutura, você provavelmente não está cumprindo nenhum dos dois. Em primeiro lugar, o aprendizado é limitado, pois a maior parte vem de descobrir como quebrar o problema em uma solução. Ao propor um conjunto de instruções para chegar à solução sozinho, a transferência de contexto para o delegado pode acabar sendo ainda mais cara do que deixá-lo descobrir o que fazer sozinho.

Por outro lado, definir bem o problema e esclarecer por que ele é importante geralmente leva a uma dinâmica muito mais saudável e a melhores resultados. **Ao delegar um problema bem estruturado, você está muito mais perto de expor o delegado ao aprendizado e chegar a um resultado com menos envolvimento.**

### Defina limites claros para o problema que você está delegando

Além de enquadrar o problema claramente, definindo por que ele é importante, definir as restrições para o problema a ser resolvido e alinhar com o resultado esperado são igualmente importantes.

Por exemplo, não estar alinhado em insumos como prioridade e prazos é uma receita para responsabilidade frouxa e investimento desproporcional de esforço/resultado. Ao definir as entradas de antemão, ambas as partes podem alinhar as expectativas de importância e esforço.

Não estar alinhado com o resultado é uma receita para reduzir a autonomia. O delegador é pressionado a se aprofundar nos detalhes. Toda a complexidade do problema em questão se torna o assunto principal nas conversas, em vez de como maximizar o resultado. O delegado é empurrado a focar majoritariamente em execução e perde autonomia.

**Ao definir insumos e resultados precisos, você define os limites do problema, o que define um contrato mais limpo entre as partes**. Conforme você transfere a responsabilidade e a autonomia para o delegado, o desafio passa a ser prepará-lo para o sucesso.

### Gerencie riscos *com* o delegado, não *para* eles

A gestão de riscos é um aspecto fundamental da delegação. Conforme os riscos surgem, é essencial não pular direto para a intervenção, pois ela tem um custo muito alto de várias maneiras.

Um modo de falha comum para delegação é oferecer conselhos que você foi pedido. Por mais que venha de um lugar de cuidado e proteção, vai tirar autonomia e responsabilidade, especialmente em uma situação de pressão. É muito provável que o delegado leve o conselho do delegador muito mais a sério em tais cenários.

A alternativa que encontrei é gerenciar o risco * com * o delegado. Supondo que você não tenha configurado o delegado para a falha delegando algo muito além de sua [maturidade relevante à tarefa](https://getlighthouse.com/blog/management-concept/), e que você delegou todo o problema, em vez de um parte da caixa preta da solução para o problema, eles estão em uma posição melhor para tomar decisões. Nesses casos, **você pode gerenciar o risco com eles, em vez de por eles, sendo curioso, fazendo perguntas e apoiando-os para que cheguem às suas conclusões.**

___

Este conjunto de princípios é especialmente inclinado para cenários de sucesso. As coisas nem sempre saem como planejado. Quando isso acontece, bons líderes fazem as pessoas sentirem que têm uma rede de segurança e podem intervir se a situação exigir; mas, o mais importante, eles fornecem a combinação certa de aprendizado e suporte de que as pessoas precisam para crescer e ter sucesso na próxima vez.


Delegação é uma das habilidades mais fundamentais em liderança. Tentei sintetizar o que acredito ser uma boa delegação em três simples princípios.

Três simples princípios para delegar


Uma tensão em engenharia de software que sempre me fascinou é saber quando dividir um em muitos. Sempre parece haver esse ponto de inflexão, geralmente desencadeado pela percepção de duplicação, compreensão de complexidade de responsabilidades ou perceber que acoplamento se tornou um problema.

Da mesma forma, as organizações também se beneficiam desse padrão. Os sinais de que pode ser necessário são os mesmos: há duplicação de sistemas, uma fusão de escopo e acoplamento indesejável de objetivos entre times. Uma solução de design organizacional comum é estabelecer uma "equipe de plataforma" responsável por generalizar os casos de uso existentes em uma plataforma e "equipes de aplicação", com foco nas especificidades dos casos de uso.

Apoiar esse tipo de mudança pode ser perturbador para as equipes e, às vezes, a frustração vem da definição de novos limites e propósitos dissociados. Aqui estão algumas idéias de como traçar limites e ajudar equipes de plataforma e aplicação a terem sucesso.

### O que permanece nas equipes de aplicação

Definir responsabilidades claras para equipes de aplicação ajuda a definir o que uma plataforma poderia ser. Uma maneira de entender o que precisa ser uma plataforma é entender o que não deve ser, pois isso geralmente é mais óbvio do que o contrário.

1. **Plataformas têm menos probabilidade de resolver problemas subjetivos ou com muitas nuances.** Considerando que o papel de uma plataforma é atender a vários casos de uso, elas geralmente são excelentes para resolver problemas objetivos. Embora, para a maioria dos problemas que tendem ao lado subjetivo, as equipes de aplicação brilham muito mais. Para uma plataforma de processamento de pagamentos, existem muitos desafios de produto difíceis a serem resolvidos como uma equipe de aplicação: quando e como autorizar um cartão, quando tentar um pagamento novamente, quando e com que frequência liquidar fundos, o melhor dia do mês para repetir um pagamento, para citar alguns.

2. **Otimização relacionada ao contexto deve viver próxima ao contexto.** As plataformas são ótimas para resolver a maior parte dos problemas compartilhados entre aplicações, embora alguns dos trabalhos de otimização mais desafiadores, especialmente em sistemas de grande escala, estejam no contexto. Para uma plataforma de recomendações, o contexto em que uma recomendação é feita é extremamente relevante para que seja eficaz, por ex. uma recomendação em uma página de lista de produtos, com baixa intenção de compra versus uma recomendação de pré-pagamento ou upsell. Embora as plataformas possam fornecer vantagens para a otimização, todo o ajuste, calibração e significado do sucesso tende a viver mais perto do contexto. Em geral, as equipes de aplicação estão em uma posição muito melhor para localizar sinais de alta qualidade que são sensíveis ao contexto para otimização.

3. **A plataforma pode afetar seu usuário.** Equipes podem ser extremamente bem-sucedidas trabalhando em estreita colaboração com pesquisadores de experiência do usuário para entender quais são as necessidades específicas de seus usuários. Às vezes, o insight gerado por meio de pesquisas pode ser contraditório em diferentes superfícies ou contextos, e esse entendimento pode determinar como a plataforma afeta o usuário. Os resultados da pesquisa podem variar de equipes de aplicação influenciando a direção da plataforma se o insight for válido em todos os casos de uso, até também revelar que talvez o limite traçado proposto afete de alguma forma o caso de uso e decidir que é prematuro ter uma plataforma.

### Uma nova plataforma emerge

À medida que você entende o que fica, o que deveria ser generalizado fica muito mais claro. Mais do que mudar sistemas, times de plataforma exigem uma mudança massiva de mentalidade. Para quem não está familiarizado com equipes de plataforma, eles tendem a compartilhar algumas características. Um exemplo notável é trabalhar com vários clientes ou partes interessadas. Dito isso, grande parte da tensão para as equipes de plataforma é encontrar o equilíbrio entre a utilidade e permanecer agnósticos - as plataformas são projetadas para resolver bem um conjunto de problemas, mas não todos. Algumas características que observei que equipes de plataforma bem-sucedidas possuem são:

1. **Pense na infra-estrutura como parte do produto - ou o próprio produto.** Quando uma equipe não consegue controlar todas as consequências downstreams de diferentes modos de falha, ela precisa ter SLAs, processos de gerenciamento de incidentes e práticas de continuidade de negócios muito mais rígidos. Por exemplo, um requisito de disponibilidade de 99% pode ser aceitável para uma plataforma de pagamentos com um ticket médio de $10 @ 500k transações por dia - significando uma perda de ~$3.5k por hora. No entanto, se o ticket médio está na casa dos milhares, isso pode significar diferentes requisitos de disponibilidade. Ser uma equipe de plataforma exige uma mudança no pensamento de que a infraestrutura é uma parte muito mais relevante da oferta do produto.

2. **Tenha cuidado ao presumir equivalências em dados.** Especialmente para plataformas de machine learning ou data, pode ser muito difícil encontrar maneiras de comparar significados, padronizar e compartilhar protocolos para labelling de dados ou gerar insights. Além disso, às vezes pode ser enganoso se você não compreender totalmente os casos de uso antes de compartilhar dados para análise ou treinar modelos. Dito isso, uma boa maneira de evitar cenários como esse é ser conservador sobre onde traçar o limite do domínio da plataforma e começar com o menor valor possível. Por exemplo, uma plataforma de recomendações de produtos pode começar com uma API que retorna scores de probabilidade para vários tipos de recomendação - compre novamente, também comprei etc. - em vez de lidar com a ranking de produtos, que é um problema muito mais complexo e matizado.

3. **Pense na plataforma como recursos, em vez de um pacote único.** Uma das formas pelas quais as plataformas geralmente falham é tentar empacotar todos os recursos em vez de fornecer às equipes de aplicativos um conjunto de recursos interoperáveis ​​que podem ser usados ​​como necessário. Embora possa ser bastante conveniente abstrair toda a complexidade por trás de uma única API, quando as equipes de aplicativos não têm acesso a recursos independentes, elas são incentivadas a "dar a volta" na plataforma. Em vez disso, dividir domínios lógicos em blocos de funcionalidade pode dar aos usuários a capacidade de estender funcionalidades. [Esse post do Kislay Verma sobre como evitar "dar a volta" com platform thinking](https://kislayverma.com/platform-thinking/preventing-go-around-with-platform-thinking/) explica o problema e a solução muito bem.

___

Por mais que a mudança seja positiva quando você pode definir claramente a responsabilidade de cada constituinte, introduzi-la prematuramente pode ser muito prejudicial. Considerando o quão perturbadora uma decisão errada pode ser e quão lento é o ciclo de feedback para definir se uma reorganização foi bem-sucedida ou não, [abordar a mudança por meio de experimentação](https://dballona.com/pt/reorganising-teams-through-experimentation/) pode ajudar a mitigar riscos e tornar a experiência menos frustrante para todos.


Da mesma forma que software, times podem se beneficiar de composição. Um padrão de design organizacional comum é definir uma equipe de plataforma e utilizá-la através de vários times de aplicação.

Composição para times, plataforma e aplicação


Assim como sistemas, conforme equipes de engenharia crescem, você se depara com pontos em que precisa iterar o design e otimizar para características diferentes. Você também não _over-engineer_, pois a otimização para casos futuros pode levar a consequências indesejáveis. Esse é um momento em que você pode querer considerar uma reformulação ou reorganização de times.

Reorganizações raramente são a única maneira de resolver um problema. Na verdade, geralmente são a forma mais cara e custosa. Embora, às vezes, reorganizar ou redesenhar é a decisão certa. Alguns dos sintomas que podem indicar que um reorg deve ser considerado são o gerenciamento recorrente de dependências complexas, uma carga cognitiva esmagadora necessária para manter os sistemas pertencentes a um grupo de pessoas, uma quantidade enorme de processos para compensar a comunicação inefetiva e assim por diante.

Uma forma de reduzir os riscos de uma reorganização para resolver um problema e acabar criando mais alguns é esclarecendo o problema, levantando uma hipótese, abordando a mudança como um experimento e depois compartilhando suas descobertas, o que informa a decisão final.

### Antes de tomar uma decisão

Em primeiro lugar, **esclareça qual é o problema que você está tentando resolver por meio da reorganização de times**. Acredito deve-se existir uma tendência forte a não fazer um reorg. Na maioria das vezes alinhamento em um nível organizacional mais alto, reavaliar o ownership de sistemas ou responsabilidades e introduzir melhores práticas ou processos de comunicação pode ajudar a não se tomar essa decisão.

Se você está convencido de que precisa fazer isso, **esclareça quais grupos de pessoas são afetados pelo problema**. Uma maneira de começar é perguntando às pessoas individualmente e prestando atenção às nuances que cada pessoa traz para a discussão. Essas nuances servirão como entrada para a geração de hipóteses.

Depois de saber quem é afetado pelo problema, de forma colaborativa **gere um conjunto de hipóteses responsáveis pela existência do problema**. Entender as frustrações das pessoas geralmente é um bom ponto de partida e, em seguida, perguntar por que isso as frustra pode levar você a uma boa hipótese. [Liberating Structures](https://reimaginaire.medium.com/what-are-liberating-structures-de6f6d14c2c8) são úteis para obter a opinião de todos, livre de julgamento.

A seguir **desenhe diferentes maneiras de organizar as pessoas para validar sua hipótese** e **entenda as lacunas de capacidade que cada mudança candidata geraria**. Uma reorganização pode apresentar riscos e, para times, um grande fator é a composição da equipe. Uma mudança como essa pode fazer você perder características essenciais em uma equipe, como conhecimento especializado sobre um conjunto de componentes, cobertura on-call para operar a infraestrutura que a equipe é responsavel, throughput diluído do ponto de vista de entrega, e assim por diante.

Então, depois de encontrar de forma colaborativa algumas das melhores opções, **ouça as pessoas que estão mais hesitantes e mais entusiasmadas com cada possível mudança**. Isso o ajudará a avaliar se a divisão seria saudável para as novas equipes e também para as pessoas individualmente. Idealmente, você deseja resolver para todos - a organização, a equipe e também para cada indivíduo. Algumas pessoas podem ficar insatisfeitas com a mudança proposta, e opositores fortes geralmente têm seus motivos que podem ser extremamente relevantes e encobrir pontos cegos do grupo.

### Experimentando com mudança

Enquadrar a mudança como experimentação tira parte da pressão do sucesso e é mais fácil reverter do ponto de vista administrativo, mas também do ponto de vista do moral e de gestão de expectativas. **Comprometa-se com uma hipótese e aborde-a como experimentação**. Como qualquer experimentação, você precisa dar tempo suficiente para obter um feedback preciso, pois haverá um atraso considerável entre a implementação da mudança e a capacidade de avaliar sua eficácia.

No início, você provavelmente terá mais fios cruzados, as pessoas ficarão mais desconfortáveis, a qualidade pode diminuir e o ritmo pode ficar mais lento. **Deixe durar o suficiente para construir um julgamento justo** antes de tomar uma decisão definitiva seja positiva ou negativa. Um bom ponto de partida são seis meses para reavaliar. Esse intervalo de tempo provavelmente corresponderá ao seu cronograma de definição de metas, análises de desempenho e planejamento de pessoal, portanto, dar tempo suficiente o ajudará a compreender as consequências dessa decisão de várias perspectivas.

**Configure um ciclo de feedback com a equipe e partes externas**. Obter feedback da equipe é fundamental, mas geralmente é mais direto, pois você pode ter estabelecido canais de comunicação como 1:1s e pesquisas de saúde do time. Também é essencial entender quais são os impactos externos, portanto, passar tempo com as partes interessadas e equipes adjacentes aos times afetados pode ajudar a avaliar a satisfação interna e externa e agir de acordo com ela.

Pode ser útil **reavaliar se os problemas que você presumiu que a reorganização resolveria estão sendo resolvidos**. Você pode sentir que, de forma anedótica, as equipes estão mais saudáveis ​​e performando mais, mas é essencial entender por quê. Olhar para trás e entender quais foram as motivações para fazer isso pode ajudar a validar se você está resolvendo os problemas a partir da própria hipótese inicial ou de outra coisa.

Considerando que a experiência está sendo bem-sucedida e as novas equipes estão se saindo incrivelmente bem, você ainda precisa estar ciente dos fatores externos. Um deles é a demanda: entender as necessidades futuras e **como a demanda e a oferta evoluem ao longo do experimento** pode ser um forte sinal para justificar o crescimento de uma equipe ainda mais ou estar proativamente preparado para outro plano. A maneira menos arriscada que conheço de fazer isso é observar a oferta e a demanda de perto e ser transparente sobre suas observações com todas pessoas envolvidas.

### Tomando uma decisão

Como você sente que o novo experimento atingiu a maturidade, **compartilhe suas descobertas internamente e abra para discussão**. O [model, document and share](https://lethain.com/model-document-share/) do Will Larson pode funcionar bem para iniciar a conversa com uma perspectiva informada em vez de autoritária, especialmente se você for a pessoa responsável pelo sucesso da equipe, onde pode ser fácil ser top-down desnecessariamente.

Também é importante recapitular o que você estava tentando alcançar coletivamente e o quão bem-sucedido foi ao fazê-lo. **Organize uma reunião retrospectiva para refletir** sobre o que deu certo, o que deu errado, o que deveria mudar e resumir as lições aprendidas. Neste estágio, você tem a oportunidade novamente de construir um entendimento compartilhado e decidir como deseja seguir em frente. Use o resultado desta retrospectiva como entrada para o que você comunicará publicamente.

Em seguida, você provavelmente já tomou uma decisão. Se você tiver alguém preocupado com a mudança, reserve um tempo para **ouvir e entender as necessidades individuais das pessoas**. Às vezes, nem todos ficarão felizes com a mudança. Pessoas insatisfeitas têm todo o direito de querer descobrir como será o futuro para elas, e é sua função e responsabilidade apoiá-las na busca por algo que as agrade, de preferência dentro dos novos times ou da organização.

Na próxima etapa, independentemente do resultado do experimento, **torne suas descobertas públicas**. Volte ao contexto que gerou o experimento, como foi abordado, o que você aprendeu durante o processo e compartilhe a mudança com o público afetado por ela. Se você acha que o experimento deu certo, a Uma Chingunde tem um ótimo post sobre [comunicar mudanças organizacionais](https://umach.medium.com/communicating-organizational-changes-6277e4b47cff), que é excelente para esse propósito.

___

Mudar nunca é fácil, mas geralmente é para tornar as coisas melhores. Acredito que os aspectos mais importantes para reorganizações de equipes bem-sucedidas são encontrar clareza sobre o porquê, ter a opinião das pessoas sobre o processo e ouvir as pessoas com atenção. Novamente, raramente é a única resposta para um problema, mas se você acha que é o seu, experimentar antes de tomar uma decisão final pode ajudá-lo a gerenciar os riscos de forma mais conservadora.


Times de engenharia, como sistemas, podem crescer de maneiras inesperadas. Utilizar conceitos de experimentação pode ajudar em tais cenários.

Reorganizando times através de experimentação


Depois de postar [minhas opiniões sobre postura em entrevistas de system design](/pt/posture-in-system-design-interviews) no [TechWriters](https://lethain.com/techwriters/), [David Golden](https://twitter.com/xdg) me inspirou a escrever sobre calibrações em entrevistas técnicas. O ângulo que estou abordando calibragens neste artigo é intencionalmente estreito, pois escolhi um caminho para falar mais sobre como as calibrações contribuem para um processo de contratação mais justo e equilibrado e, como consequência, mais eficiente. Por causa disso, estou abordando o assunto das calibrações para duas perspectivas:

1. Como um grupo de entrevistadores pode avaliar e chegar a um entendimento comum de quem é a pessoa mais adequada para uma contratação;
2. Como a gerente responsável pela contratação pode aumentar a certeza de que está tomando a melhor decisão para sua equipe e organização.

Mesmo que meu objetivo seja abordar o assunto com a maior transposição e objetividade possível, calibrar entrevistas não é de forma alguma um assunto imutável, transferível ou exato. Semelhante a qualquer sistema ou conceito complexo, esta é uma representação excessivamente simplificada do assunto como uma tentativa de torná-lo mais digerível. Calibragens são um assunto com muitas nuances, mesmo dentro do mesmo contexto de cultura organizacional e ainda mais para diferentes organizações. Diferentes organizações esperarão resultados diferentes de processos de contratação, e para cobrir calibragens no grau de profundidade para fazer justiça ao assunto, seria necessário entender especificações do processo de contratação projetado para sua organização, que está fora do escopo e alcance desse artigo.

### Contexto e pré-requisitos

Para aqueles que não estão familiarizados com o termo: caligragens de entrevistas servem o propósito de encontrar um consenso entre entrevistadores sobre o desempenho geral de um(a) candidato(a) e, em seguida, comparar o desempenho dos candidatos(as) entre si, para que avançar com a pessoa mais adequado para a próxima etapa de entrevista ou a uma oferta de emprego.

Mesmo que as calibragens das entrevistas possam ser desestruturadas, como por exemplo falar de forma informal sobre impressões gerais sobre um aplicante, abordá-la dessa forma tem uma grande propensão a dar errado. Os gerentes de contratação e as pessoas mais seniores no ciclo de entrevistas geralmente estão bem posicionados - mesmo que não intencionalmente - para influenciar as opiniões dos outros, tornando o processo menos justo e mais tendencioso.

Dessa forma, acredito que os pré-requisitos para calibrar razoavelmente candidatos são:

1. **Uma estrutura que define o nivelamento em toda a organização**, delineando funções, expectativas e impacto para cada nível - o que Junior, Pleno, Senior, Staff e outras funções significam na prática;
2. **Um processo de entrevista bem definido por nível ou plano de carreira** que seja usado de forma equitativa para todos os aplicantes, independentemente das circunstâncias, como referências ou retorno de funcionários;
3. Para etapas de entrevista mais estruturadas, como entrevistas técnicas, **um banco de dados de perguntas com orientações claras** à disposição da pessoa entrevistadora;
4. **Um programa de treinamento como pré-requisito para entrevistar candidatos**, cobrindo o que é importante para a organização, abrangendo desde aspectos práticos até D&I e treinamento de preconceito e bias inconsciente.

Esses pré-requisitos ajudarão a estabelecer uma base para comparação objetiva entre o talentos existentes na organização, uma forma padronizada de avaliar os candidatos e que os entrevistadores entendam como avaliar os candidatos de forma justa.

### A função da pessoa entrevistadora

Acredito que um bom ponto de partida da perspectiva dos entrevistadores, independentemente de sua função, é **estudar a estrutura de nivelamento de pessoas**. Entender o nivelamento é, inerentemente, entender as expectativas de uma função - e esse é um ponto de partida para garantir a justiça. Em outras palavras, além de definir que quem faz x, y e z é Engenheira Sênior, definir qual tipo de impacto e efeito você espera que essas pessoas tenham na função ajuda a esclarecer o que você está procurando para as necessidades da vaga aberta. Estudar esta estrutura ajuda a calibragem, pois se você entender as expectativas para uma função, poderá avaliar um candidato de forma mais objetiva.

Em seguida, **ter dados e critérios comparativos entre candidatos sob diferentes óticas** também pode ser útil. Em situações em que há restrições, como menos vagas abertas do que candidatos que passam da barra de entrevistas, pode ser difícil definir qual candidato é mais adequado para a vaga, especialmente se pessoas diferentes entrevistaram candidatos diferentes. Já vi isso ser resolvido de duas maneiras: ter mais de um entrevistador por entrevista (por exemplo, um entrevistador principal e um [entrevistador sombra](https://rework.withgoogle.com/guides/hiring-train-your-interviewers/steps/giving-interviewers-practice/)) ou tendo mais de uma entrevista do mesmo tipo por candidato (por exemplo, duas entrevistas de system design dentro do mesmo ciclo de entrevistas feitas por pessoas diferentes). Ambos podem ajudar a diminuir bias e dar aos entrevistadores mais ângulos para debater, comparar e calibrar os candidatos entre si por meio de mais perspectivas para os mesmos critérios.

Outra tarefa crítica é **definir o que se espera como um bom resultado para uma fase de entrevista antecipadamente**, para que você tenha o que calibrar após a entrevista, caso tenha várias pessoas passando no processo. O que "melhor" significa é, na maioria das vezes, relativo, portanto, discutir nos mesmos termos com outros entrevistadores no caso de vários resultados positivos nas entrevistas ajudará a condução de discussões específicas. Por exemplo, para uma entrevista de projeto de sistema, você provavelmente está procurando por critérios como "conclusão", "priorização", "profundidade de conhecimento", "amplitude de conhecimento", "comunicação", "entendimento de trade-offs" e assim por diante. Observações adicionais fora do escopo podem ajudar na decisão geral, mas para garantir que o processo funcione conforme previsto quando projetado é essencial ater notas de performance aos critérios do estágio de entrevista em questão.

Em consonância com o ponto anterior, **definir como o desempenho por etapa da entrevista é mapeado ao nivelamento de um candidato** pode ajudar a informar o processo. Para fins de contexto, o nivelamento de um candidato geralmente leva em consideração o desempenho geral do candidato durante a entrevista, além de suas realizações e experiências anteriores. Ou seja, o desempenho geral deve ser apoiado pelo desempenho em cada etapa, que então é ser apoiado por critérios de avaliação da etapa. Um exemplo um pouco mais tangível é, por exemplo, em entrevistas de system design, pessoas engenheiras experientes são mais propensas a terem um nível mais profundo de consciência sobre trade-offs sendo feitos em comparação com pessoas menos experientes. Entender o que esperar em termos de desempenho para cada estágio de entrevista para cada nível pode ajudar a tornar a decisão mais justa. Porém, esteja ciente de que transformar a avaliação em um processo exclusivamente objetivo ou mecânico também não é desejável, o que nos leva aos próximos dois pontos.

Provavelmente, você não precisará tomar uma decisão exclusivamente com base nos sinais coletados na fase de entrevista que conduziu. Dito isso, **dar aos candidatos o benefício da dúvida por padrão** pode ser uma maneira generosa de falar sobre as habilidades de alguém que você mal conhece. Entrevistar é uma experiência estressante, principalmente quando o candidato realmente quer a vaga. Em vez de julgar pretensiosamente se alguém é adequado ou não para uma função, entender a entrevista como um snapshot dos comportamentos observados ajuda a se manter aberto(a) para ser convencido a opiniões contrárias - tanto para favorecer a contratação quanto para retirar sua recomendação de contratação.

Por fim, se você chegar a uma situação em que tenha mais de uma ótima candidata por função e a notas entre os entrevistadores para o mesmo tipo de entrevista revelar que provavelmente há um empate, **delegue a decisão a outros estágios de entrevista**. É difícil obter uma imagem precisa da capacidade de alguém em uma entrevista de 45 minutos. Em algum ponto, a precisão para ordenar candidatos fala mais sobre seu próprio viés do que sobre as qualidades do candidato, portanto, deixe outros critérios conduzirem a decisão.

### A função da gerente de engenharia contratante

Um dos principais aprendizados que tive como gerente foi **contratar primeiro para a organização e depois para a equipe**. Independentemente da maturidade da organização que você faz parte, as coisas darão errado com frequência. Ter uma estratégia de contratação estreita demais pode trazer consequencias dramáticas. Bons exemplos disso são um projeto em que uma pessoa foi contratada para tocar ser desincentivado, ou decidir comprar software de um fornecedor em vez de construí-lo internamente. Essas são circunstâncias em que as calibragem é útil - se o nivelamento for padronizado em toda a organização, mover as pessoas para o próximo papel lateralmente é menos prejudicial para todos os envolvidos.

Dito isso, **resista ao impulso de pensar exclusivamente nas lacunas que suas equipes tem** e em suas necessidades específicas. Como gerente, você obviamente deve estar focada nos problemas que estão no seu escopo de trabalho, porém, as pessoas podem acabar precisando de mais do que isso para permanecer ou crescer na organização. Investigar se existem necessidades semelhantes em algum outro lugar da organização pode ajudar a tomar uma decisão mais assertiva. Validar suas suposições com outros gerentes e alinhar uma potencial responsabilidade adicional para uma vaga antes mesmo de contratar uma pessoa pode forçá-lo a pensar em qual é o caminho de progressão desse candidato dentro da empresa e garantir que você possa trazer alguém com um espaço de problema claro para assumir. No lado positivo do exemplo anterior, se as coisas correrem incrivelmente bem, essa pessoa terá opções para escolher seu caminho dentro da empresa, o que é extremamente positivo.

**Antes de decidir por um candidato específico, calibre-o em relação à estrutura de nivelamento** para garantir que você está nivelando as pessoas recém-chegadas de forma justa. A maioria das empresas tem situações em que níveis têm responsabilidades e faixas de remuneração sobrepostas. Para alcançar a promoção para o próximo nível, é preciso ter um desempenho consistente no próximo nível, então, ao trazer novas pessoas, é importante nivelá-las corretamente, mas ainda mais, você quer ter certeza de fazer as coisas certas para o time dessa pessoa também. Nos casos em que você não tem certeza sobre o nível de uma pessoa, fazer uma oferta do nível abaixo é geralmente a coisa certa a fazer, pois promover alguém dentro de 6 a 12 meses é mais simples do que ajustar o nível para baixo depois que a pessoa já estiver na empresa.

Um cenário típico como gerente é direcionar a contratação para seus projetos, equipes e necessidades. [Este artigo do Google](https://ai.googleblog.com/2006/03/hiring-lake-wobegon-strategy.html) descreve como a contratação por projeto/equipe afeta a qualidade geral de talento na empresa. Como gerente de contratação, o que você pode fazer a esse respeito é **calibrar os candidatos em relação aos seus pares em potencial**. Isso pode ajudar a alcançar resultados semelhantes em termos de qualidade de talento à estratégia usada pelo Google. Pense em equipes ou organizações adjacentes que têm pessoas no mesmo nível para o qual você está contratando, dentro da mesma disciplina, e entenda os deveres, impacto e responsabilidades dessas pessoas. Isso provavelmente revelará como essa candidata se encaixaria no quadro geral, garantindo assim a qualidade de talento em toda a organização.

Além disso, **calibre os entrevistadores uns contra os outros, para que você tenha uma média ponderada como medida**. Entrevistadores diferentes têm critérios diferentes para avaliar as pessoas, mesmo com uma estrutura de nivelamento bem definida. Tenho a impressão de que muitas vezes tenho tendência a focar no lado positivo de entrevistas. Outros podem ser muito mais conservadores em relação aos riscos e tendem a recomendar "não contratar" quando faço recomendações de "contratar". A grande maioria dos sistemas de gestão de aplicantes tem [relatórios de calibração](https://help.lever.co/hc/en-us/articles/206403385-How-can-the-Interview-Calibration-report-help-me-identify-bias-in-interview-feedback-) que podem ajudar a entender como os entrevistadores tendem a classificar os entrevistados que receberam ofertas, e isso pode servir como um sinal para avaliar o desempenho geral quantitativamente, sem aprofundar muito em análise.

Então, para decisões divididas, onde entrevistadores têm opiniões diametralmente diferentes ou o nível de incerteza é alto em vários estágios, **aumente o alinhamento e a consistência através de uma reunião de revisão do pacote de entrevistas**. Esse tipo de reunião geralmente consiste em reunir todos os entrevistadores que participaram de cada etapa do processo de entrevista do candidato, chegar em um consenso e, em seguida, tomar uma decisão final. Normalmente, é uma excelente oportunidade para entender onde pode haver ambiguidade para um critério dentro de uma etapa de entrevista, para dar feedback aos entrevistadores e receber feedback sobre o candidato e o processo, e como consequência disso, melhorar o processo e torná-lo mais justo e decisões mais precisas.


___

Como dito anteriormente, esta é apenas a ponta do iceberg - calibrações de entrevistas de pessoas engenheiras de software são um assunto fascinante que provavelmente exigirá esforços interdisciplinares de equipes de pessoas, como aquisição de talentos e recursos humanos, bem como perspectivas técnicas. Para garantir calibrações e contratações mais justas, é fundamental continuamente avaliar, medir e, por meio de sinais quantitativos e qualitativos, evoluir o processo.


Avaliar quem é o melhor candidato para uma vaga não é, de forma alguma, uma tarefa simples. Aqui estão algumas das minhas abordagens sobre este assunto.

Calibragem em entrevistas de pessoas engenheiras de software


Se eu tivesse que escolher apenas um método de entrevista para avaliar pessoas engenheiras, provavelmente seria system design. Não porque entrevistas de coding, comportamental, simulação de papeis ou estudo de caso sejam menos valiosas - eles são reveladores e ajudam a construir uma imagem mais complexa do(a) candidato(a). Se você tiver recursos para criar um processo que ofereça suporte à diversidade, uma estrutura justa para evitar bias e o tempo, as pessoas e o treinamento para executar um processo de vários estágios, provavelmente reduzirá a propensão de falsos positivos. No entanto, se eu fosse obrigado a escolher apenas um, escolheria system design.

Acho a mistura entre os critérios subjetivos e objetivos que a entrevista de design impõe muito útil para avaliar os candidatos de vários ângulos. Há uma estrutura razoavelmente bem definida para a avaliação técnica, mas apenas chegar a um bom design não é necessariamente suficiente. Da mesma forma, o comportamento do candidato tem um papel vital a ser avaliado, mas a falta de nexo causal e habilidade técnica revelará claramente a adequação à posição ou não.

Existem muitos recursos por aí que são uma base excelente para as partes mais objetivas. Fiz a curadoria de alguns dos meus favoritos no [apêndice](#appendix) deste artigo. Eles merecem um grande foco na hora de estudar para uma entrevista, pois são a parte mais fundamental da avaliação que está sendo feita. Tendo passado por algumas entrevistas recentemente e praticado, pensei em escrever sobre alguns pontos que aprendi e que acredito que podem ajudar nos aspectos subjetivos, especialmente sobre postura.


### Não se limite a comunicar: colabore com os entrevistadores

Uma das coisas que considero muito úteis nas entrevistas técnicas é transformá-las em colaboração, em vez de apenas uma avaliação. O papel que os entrevistadores devem desempenhar fundamentalmente é avaliar se um candidato é adequado para ser seu colega. Eu acredito que quando você atinge uma atmosfera colaborativa ao entrevistar, você está dando às pessoas uma perspectiva muito melhor para avaliar sua adequação de forma justa.

Com isso em mente, uma vez que o entrevistador compartilha qual é o problema a ser resolvido, uma técnica que pode ajudar é **reformular o objetivo com suas próprias palavras.** Acho que isso ajuda a evitar situações em que você presume entender o que está sendo perguntado. É muito melhor esclarecer com o entrevistador do que desenhar a solução certa para o problema errado. Faça perguntas, por mais óbvias que possam parecer, e tente reunir todas as informações que puder antes de prosseguir.

Com o objetivo melhor definido, é essencial **estabelecer o que está dentro do escopo e o que está fora.** Estreitar quais são os limites do escopo para o problema da entrevista ajudará você a se concentrar no que é mais importante para o design em questão. Fazer concessões no escopo no início impedirá que você gaste o pouco tempo de que dispõe para falar sobre adjacências do problema.

Quando inferirir informações a partir do que lhe foi dito ou quando chegar a uma conclusão, **expresse suas suposições e conclusões.** Você precisa trazer seus entrevistadores para ver o problema do ângulo que você está olhando para fazer um julgamento justo se você está saindo do planejado e te colocar no trilho novamente, se necessário.

Então, ao trabalhar na solução proposta, **evite transformar a experiência em um monólogo. Deixe espaços para feedback**. Entrevistadores geralmente não se importam de sinalizar quando você sair do caminho esperado. Faça com que eles contribuam para a discussão, mesmo que de forma não verbal, independentemente se for sobre as implicações das decisões de design que você está escolhendo e por que, ou de forma mais específica, como se você deve dividir um componente em dois.

Em suma, comunicação é muito importante para as entrevistas técnicas. Além disso, buscar ativamente a colaboração aumenta suas chances de um bom desempenho na entrevista e também ajuda os entrevistadores a avaliar se gostariam de trabalhar com você - e vice-versa.

### Amplo primeiro e fundo depois

É fácil se aprofundar prematuramente nos detalhes do sistema, pois as perguntas da entrevista de design geralmente não cabem no intervalo de tempo disponível, ao contrário de uma entrevista de coding, por exemplo, onde o problema provavelmente se encaixa no tempo disponível. Ninguém espera que você encontre a solução perfeita para um sistema que é operado por dezenas, centenas ou mesmo milhares de pessoas - embora o ideal seja você ter um esboço para resolver o problema de ponta a ponta ao fim da entrevista.

Como nos sistemas da vida real, o design irá evoluir. Feito geralmente é melhor do que perfeito. **Comece simples antes de se tornar complexo, favorecendo a extensibilidade em vez da perfeição**. Apresente o design mais simples que não apresentará problemas óbvios de escalabilidade primeiro, mantenha quem está te entrevistando informado(a) sobre sua estratégia e, quando você cobrir os requisitos propostos, entre em otimizações mais profundas.

Uma maneira que descobri de enquadrar o problema no nível certo como ponto de partida é **colocar-se no lugar do usuário do sistema que você está prestes a projetar.** Basicamente, converse com o entrevistador sobre as etapas que o usuário levaria para usar o produto/sistema que você está projetando para as funcionalidades presentes no escopo. Estar atento às necessidades do usuário ajudará a esclarecer as características deste sistema, por exemplo, o que precisará de APIs públicas à internet, quais componentes terão mais leituras do que escritas, ou quando favorecer consistência em relação à disponibilidade. Olhar para o sistema através da perspectiva de experiência do usuário geralmente sugere o que é fundamental para aquele sistema e ajudará a definir alguns porquês mais adiante.

Quando você sentir que entendeu o todo, criou um design em alto nível e mostrou ao entrevistador que você tem controle sobre o problema no geral, escolha a parte com a qual se sente mais confortável para ir fundo e explore-a. **Foque suas forças ao invés das suas áreas para desenvolvimento.** Provavelmente, o problema em questão tem alguns desafios de escala interessantes para qualquer disciplina. Escolha o seu aspecto favorito do problema sobre o qual você possa falar profundamente, por exemplo otimização de bandwidth no lado do cliente, modelo de dados e particionamento, automação de infra de machine learning ou o que você quiser.

Dito isso, resista ao impulso de entrar em detalhes antes de entender totalmente o problema. Elevar a conversa às motivações e aos resultados esperados primeiro te ajudará a tomar decisões de design mais assertivas e a tornar alguns porquês mais evidentes para você e para a pessoa que te entrevista posteriormente.

### Fale sobre nuances e edge-cases

O que acontecerá se o seu sistema parar de enviar dados para um componente downstream do seu sistema? Como você notifica os sistemas upstream para reverter algo que foi alterado por engano? Como o sistema funciona para o 99º percentil de seus power users? Todas essas são questões que podem influenciar suas escolhas de design, portanto, pensar no que pode dar errado lhe dá a oportunidade de alterá-lo ou de confirmar que tomou as decisões corretas de design.

Especialmente em sistemas distribuídos de grande escala, você geralmente terá que otimizar para características específicas. Isso introduz inexoravelmente comportamentos indesejados - dos quais você precisa estar ciente para tomar a decisão certa. **Fale sobre as compensações que você fez e por que** escolheu uma abordagem ao invés de todas as outras opções que você tinha.

Além disso, **explorar cenários de falha e opções de recuperação** mostrará que você entende o design que você se comprometeu. Isso pode se tornar especialmente interessante quando você pode cobrir não apenas as falhas de sistema, mas como os usuários podem abusar o sistema, quais riscos são introduzidos que você terá que aceitar, ou até mesmo erro humano. Quando possível, fale sobre como você recupera ou evita que isso aconteça.

**Converse sobre como consertar as coisas quando as coisas dão errado**. Um exemplo disso é uma experiência pessoal em que superestimei capacidade em uma entrevista. Ao invés de alocar 1GB de armazenamento para contas gratuitas do sistema que estava desenhando, dediquei 1TB. Percebi que algo estava errado à medida que o armazenamento e bandwidth começaram a parecer absurdos para o problema em questão com o volume de acessos que o entrevistador e eu havíamos combinado. Depois de reconhecer que algo estava errado, falei sobre as etapas que tomaria para reverter o erro se isso fosse ao ar, como manter os usuários que se inscreveram na proposta de 1TB com os benefícios pelos quais pagaram indefinidamente, conversar com equipes responsáveis por publicidade/marketing e growth sobre o erro, e outras medidas de controle de danos que poderiam ser tomadas. Acho que essa conversa acabou sendo ainda mais interessante do que se eu tivesse calculado a capacidade certa a princípio.

Resumindo, as coisas darão errado em algum ponto - mostrar prontidão para trilhar o caminho não tão feliz aumentará sua confiança nas suas escolhas de design, e se você tomou uma decisão errada, ainda tem tempo para se adaptar e torná-la melhor ou pelo menos reconhecer o erro.


### Fale brevemente sobre adjacências do problema

Novamente, dado que a entrevista de design é extremamente limitada em tempo, você precisa estar ciente do que deseja enfatizar. Embora seja ótimo ter um escopo estreito para trabalhar, tocar levemente em tópicos adjacentes ao design em si pode mostrar ainda mais amplitude de conhecimento. Aqui estão alguns exemplos de assuntos a serem cobertos, que podem estar fora do escopo, mas podem aumentar o número de sinais, aumentando assim suas chances de um bom desempenho.

Acredito que a maioria dos engenheiros aprecia o fato de operar sistemas de grande escala é muito difícil. Eu pessoalmente gosto de **cobrir a operações, não apenas o design**. Especialmente em grandes empresas, onde você geralmente tem funções dedicadas de infrastructure engineering, é fácil de achar que ops "vem de graça". Falar brevemente sobre assuntos como alerts, monitoramento, tracing e observabilidade pode revelar problemas ao escalar um design específico.

Especialmente para ambientes altamente regulamentados, como pagamentos e prevenção de abuso, tocar em **segurança, compliance e restrições regulatórias** pode ser uma vantagem. Algumas idéias de assuntos a abordar são retenção de dados ou anonimização de dados para sistemas com informações de identificação pessoal, ou gerenciamento de risco por meio da divisão de componentes em redes internas diferentes para separar escopo de auditorias.

Talvez um aspecto mais relacionado a liderança técnica ou gerenciamento, as decisões de design irão ditar inerentemente como as equipes serão mobilizadas para domínios específicos. Uma grande vantagem de microsserviços é tornar a escalabilidade independente - incluindo pessoas e design organizacional. Falar sobre como o design provavelmente afetará **como você mobiliza as pessoas no conjunto de equipes responsáveis ​​pelo design** e mostrar consciência de escalonamento não apenas de infra-estrutura e sistemas, mas também de organizações pode gerar conversas interessantes.

Meus exemplos aqui são altamente influenciados pela minha própria experiência, mas fazer um breve aparte enquanto você cobre algo dentro do escopo da entrevista pode servir como um sinal adicional e aumentar a confiança do entrevistador em você.

___


Para encerrar, é importante notar que todas essas dicas são baseadas em minhas próprias experiências e preferências. Organizações diferentes se concentrarão em coisas diferentes, e seu melhor ponto de partida é entender as expectativas da empresa para a qual você está se candidatando. Acredito que incorporar os tópicos acima destacados à minha postura quando entrevistando me ajudou, e espero que ajude você também.

___


### Apêndice

Abaixo, adicionei um pequeno apêndice para alguns recursos sobre o lado técnico das coisas. Espero que você goste!

- [Grokking the System Design Interview](https://www.educative.io/courses/grokking-the-system-design-interview) feito pelo [Design Gurus](https://designgurus.org) no educative.io;
- [Designing Data-Intensive Applications](https://dataintensive.net/) por Martin Kleppmann;
- [System Design Primer](https://github.com/donnemartin/system-design-primer) por Donne Martin;
- [High Scalability](http://highscalability.com/all-time-favorites/) blog;
- [How the Web Works](https://github.com/vasanthk/how-web-works) por @vasanthk;
- [SuccessInTech](https://www.youtube.com/c/SuccessinTech/videos), canal no YouTube;
- [TechDummies](https://www.youtube.com/c/TechDummiesNarendraL/videos), canal no YouTube;
- [How we've scaled Dropbox](https://www.youtube.com/watch?v=PE4gwstWhmc) video;
- Amazon's [DynamoDB](https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf) paper;
- Google's [MapReduce](https://static.googleusercontent.com/media/research.google.com/en//archive/mapreduce-osdi04.pdf) paper;
- Google's [Hypertextual Web Search Engines](http://infolab.stanford.edu/~backrub/google.html) paper;
- Google's [GFS/Google File System](https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf) paper;
- Facebook's [Cassandra](https://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf) paper;
- Facebook's [TAO, a social graph data store](https://www.usenix.org/system/files/conference/atc13/atc13-bronson.pdf) paper;


Algumas ideias sobre como melhorar o desempenho nas partes comportamentais e subjetivas do meu tipo de entrevista técnica favorito: system design.

Postura em entrevistas de system design


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.

Linguagem como ferramenta para times de engenharia


Esse ano fui apresentado ao [Radical Candor, da Kim Scott](https://www.radicalcandor.com/the-book/), em meio a um processo de entrevista. O livro é uma jóia nos assuntos liderança e gerenciamento, independentemente de em qual estágio em sua carreira você está e se você gerencia pessoas ou não.

A primeira parte do livro contém um grupo de anedotas de líderes em grandes organizações como Google e Apple – inclusive a própria Kim, a qual inclusive liderou centenas de pessoas nos tempos dela de Google. Já a segunda parte é mais focada em ação, com dicas de como se colocar em prática, e como efetivamente executar o que as anedotas contam.

Após ler e digerir, achei que seria legal compartilhar minhas três reflexões favoritas do livro.


### Reflexão #1: Desafiar é, efetivamente, se importar

A principal estrutura do livro se define em duas dimensões: _Se importar Pessoalmente_ e _Desafiar Diretamente_, o que divide comportamentos das pessoas em quatro quadrantes. A Kim usa anedotas que exemplificam os colaterais de se utilizar demais qualquer uma das dimensões: _Empatia Ruinosa_ quando você se importa, mas não desafia, e _Agressão Obnóxia_ quando você desafia, mas não se importa. Quando seu comportamento não apresenta nenhuma das duas dimensões, você cai em _Manipulação Insincera_ e finalmente, quando você consegue demonstrar ambos, você atinge o comportamento _Candura Radical_. É importante mencionar que esses comportamentos são transientes, o que significa que ninguém fundamentalmente _é_ nada disso, mas _expressa_ esses comportamentos em diferentes situações.

<Image src="/assets/uploads/2020-09-12/framework.jpeg" alt="The Radical Candor Framework" caption="The Radical Candor Framework" placement="default" width="450" height="300" />

Como você sabe, pode ser extremamente difícil desafiar seu/sua chefe. Essa trava pode vir de vários lugares, como por exemplo diferenças culturais, como vir de um contexto onde hierarquia é respeitada demasiadamente. Pode vir do fato de que você pertence a um (ou vários) grupos minorizados. Pode vir do fato de que seu ambiente de trabalho e experiências anteriores nunca permitiram que você deixasee a candura florescer. Pode vir pelo medo de julgamento, falta de confianca, ou do sentimento de que sua opinião é menos relevante do que as das outras pessoas. A lista poderia se estender, mas no fim das contas o que quero dizer é que não é fácil começar.

Portanto, minha opinião no assunto é que primeiramente, **como um/a líder você deve incentivar e recompensar o desafiar, mas não apenas isso, você deve ajudar as pessoas a desafiarem você e os outros**. Muito possívelmente, o ato de desafiar vai começar através de uma nota sutil, ou uma pessoa tangenciando o que elas querem te dizer que não concordaram com você. As pessoas te darão sinais que elas estão tentando discordar de você, e é sua responsabilidade ajudá-las a te desafiarem quando você achar que elas estão tentando.

Além disso, **nós só discutimos por coisas que significam algo para nós, as que não nos importamos nós ignoramos**. Se as pessoas estão dando a opinião delas, é porque _elas se importam_, e isso é a qualidade mais importante que você pode ter em alguém no seu time. Os melhores times que trabalhei até hoje tinham um senso profundo de orgulho, pertencimento, e estender a alguém a chance de mudar o seu percurso traz um efeito muito mais valioso do que atribuição, ou propriedade sobre uma solução: isso dá ao time um propósito compartilhado.

Finalmente, isso não deve ser uma coisa de gerente-reporte. Pares e colegas de trabalho devem desafiar o trabalho e comportamento entre si, e essa é geralmente uma forma muito boa se você não se sente a vontade de desafiar seu chefe. **Aumentar a coesão de um time no ponto de vista de cultura ao desafiar seus pares pode ser um excelente passo em direção a desafiar seu chefe**.

Em conclusão, a estrutura que o livro propõe me ajudou a trazer ainda mais para o consciente que as duas dimensões (se importar e desafiar) estão entrelaçadas.

### Reflection #2: Esclareça para chegar ao real significado


Outra ferramenta que o livro oferece é a [GSD Wheel](https://www.radicalcandor.com/4-ways-help-new-managers-succeed/). O passo _Clarify_ (Esclareça) capturou muito da minha atenção. Basicamente, esse passo descreve o quão importante é deixar as ideias respirarem, e dar espaço para elas atingirem a maturidade, para não cortar uma ideia muito cedo ou muito curto. A seção começa com uma citação:

<Quote quote="É apenas através da seleção, eliminação e ênfase que chegamos ao real significado das coisas." author="Georgia O’Keeffe" />

A forma que consegui processar isso é que _selecionar_ é escolher o equilíbrio certo entre certeza e incerteza, e o quanto de cada um desses ingredientes você deve permitir para cada situação. Algo como definir o apetite para esforço e risco. Outra forma de pensar sobre isso é um produto que é altamente bem sucedido, que parece ter poucas funcionalidades. O que é comum nesse tipo de cenário é que o produto "fatia" uma parte de um problema, e foca em resolver **aquele problema e suas adjacentes incrivelmente bem** com muita opinião sobre o que ele não deve fazer ou não faz. Isso nos leva ao proximo ponto.

_Eliminação_ é sobre definir as fronteiras e limites, ou em outras palavras, **o que você não vai resolver naquele momento**. Bons exemplos de eliminação são:

1. **Articular _rabbit holes_ com clareza :** vamos fazer A e B, mas não sabemos muito sobre C e o quão complicado será, portanto vamos deixar esperar até sabermos melhor;
2. **Definir bem limites de um domínio:** adorariamos ter essa funcionalidade, porém achamos que deveria viver em algum outro lugar do que esse domínio, portanto vamos pensar melhor;
3. **Reduzir escopo de trabalho:** através de X e Y vamos atingir 85% de um resultado chave que estamos buscando. Por hora, não iremos fazer Z pois aumenta a complexidade de X e Y drasticamente e pode comprometer o todo.

Em outras palavras, _eliminação_ é sobre reduzir o ruído na sua mensagem, para que você não dilua ela com coisas menos relevantes. Mas será que só falar "não" é suficiente?

Muito provavelmente não, e é ai que _ênfase_ é importante. Ênfase é sobre **apostar dobrado no que realmente é importante na fatia do problema que você está resolvendo**, para que você aumente suas chances de sucesso. Apenas dizer "não" para um grupo de coisas não garante que algúem vá saber o que você quer dizer, portanto intencionalidade, consistência, e repetição são importantes para que sua mensagem seja mais pessoal, alcance uma audiência mais ampla, e se assegure e esclareça o que de fato você está fazendo.

Para propósitos de comparação, alguns anti-padrões a isso que consigo pensar são:
- **Seleção**: se focar em excesso em necessidades do cliente e acabar em uma situação que você perde o fio da sua própria estratégia;
- **Elimination**: não ter uma postura firme em falar não, e deixar muito espaço para intepretação ou enganos;
- **Emphasis**: começar num estágio amplo de mais, ou ter uma estratégia muito abstrata, sem opinião tática, o que faz difícil de se tangibilizar.

Ter esse tipo de formato ajuda a esclarecer o que quer que seja que você está fazendo em uma forma simples, mas poderosa e com opinião, _para chegar no que você quer dizer_ – que a propósito é o subtitulo do livro.


### Reflection #3: Consciência contextual é chave para o desenvolvimento

Outro assunto que achei super interessante foi [conversas de carreira](https://www.radicalcandor.com/how-to-have-career-conversations/). Essa é a estrutura proposta pelo livro:

1. **Comece pelo Passado:** Mergulhe na história de vida da pessoa;
2. **Converse sobre o Futuro:** Fale sobre as metas, ou preferencialmente, os sonhos delas;
3. **Planeje para o Presente:** Proponha um plano de ação;

O que tentei fazer no ultimo ciclo de desenvolvimento do meu time é propor um plano de desenvolvimento usando essa estrutura.

_Começe pelo Passado_ é semelhante em formato a [topgrading](https://www.greenhouse.io/blog/what-is-the-topgrading-interview-process), mas com propósito diferente: ao invés de avaliar valores e _fit_, **entender motivadores para cada evento na vida da pessoa**, por exemplo:

- Por quê você resolveu estudar X? e por quê você abandonou o curso?
- O que te fez escolher o emprego na empresa Y ao invés de outras opções?
- Qual foi o projeto mais interessante que você trabalhou na empresa Z?

A principal meta é encontrar padrões, como por exemplo, sair de uma série de lugares por falta de oportunidades de crescimento, e mencionar que um projeto que foi significativo para dar um salto na carreira pode pertencer a um motivador _Buscando Crescimento_. Isso seria diferente, por exemplo, de alguém ser motivado por ter um grande impacto nos projetos que desenvolve. Existe uma diferença na motivação como uma é focada em progressão e a outra por resultados. Uma observação, principalmente quando se trabalha com contribuidores individuais que tem décadas de experiência, ao invés de olhar para experiências específicas, eu recomendo agrupar papéis semelhantes em blocos, definidos em conjunto com a pessoa.

Quando você detectar 3-5 motivadores, escrever algumas perguntas baseadas em cada motivador pode ajudar, como: _quais são as maiores oportunidades para crescer aqui na sua opinião e porque?_, ou __ para _Buscando Crescimento_. Essas perguntas podem ajudar você e a pessoa quando vocês forem definir quais são as oportunidades para o presente.

Eu acho fantástica a forma que a Kim trata _Converse sobre o Futuro_ por incluir sonhos, não apenas metas. **Entender as necessidades pessoais de alguém** reforça o seu entendimento do contexto delas, e te ajuda a calibrar o que é um bom grupo de iniciativas para essa pessoa naquele momento. O livro recomenda um processo de achar 3-5 sonhos, como chegar a um papel influente em posição de gerencia, ou ganhar um campeonato de esportes, e então afunilar em habilidades necessárias para atingir esses objetivos. Eu pessoalmente gosto da ideia de pedir pelo menos um objetivo não relacionado a trabalho, para ter ainda mais contexto, além de tentar conhecer quem eu trabalho com um pouco melhor.

Por exemplo, você pode descobrir uma grande dificuldade uma pessoa do time vai ter para mudar de apartamento, ou algo que ela vem trabalhando por vários anos para conseguir. Independentemente do que seja, vai te ajudar a ser um(a) líder empático, e também vai te guiar no que é realmente importante para aquela pessoa naquele momento.

E é claro, após ter essas duas entradas, você está em uma posição muito mais informada para _Planejar para o Presente_ para qualquer pessoa. Através do conhecimento adquirido, você pode se desafiar a entender se as áreas você espera que alguém se desenvolva estão alinhadas com a própria motivação delas. Essa consciência ajuda e suporta a estrutura proposta pelo livro – ter conversas cândidas, enquanto se importa pessoalmente e desafia de forma direta. Nesse ponto, é mais sobre tática: **achar as oportunidades que existem para essa pessoa atingir o que elas querem.**

___


Resumindo, Radical Candor foi extremamente prazeroso de se ler. Eu gostei muito da mistura entre anedotas e coisas práticas para se testar. O livro possui vários outros conceitos interessantes, portanto eu recomendo que você [dê uma olhada](https://www.radicalcandor.com/)!


Três reflexões após ler o livro "Radical Candor" da Kim Scott sobre se importar pessoalmente e desafiar diretamente.

Gestão de Engenharia