Em 2022, eu e o Francisco Edilton (Chico, AWS Community Hero) nos encontrávamos todas as terças-feiras, sete da noite no horário do Brasil, para escrever a HeroBuzz. Ele em Lisboa, eu em São Paulo. A newsletter era a desculpa. O que a gente realmente fazia era jogar conversa fora.
A maioria das pessoas olha para uma hora marcada no calendário e pergunta quanto tempo aquilo vai durar. Comigo e com o Chico a pergunta sempre é como aproveitar melhor esse tempo. E era nessa "perda de tempo" que apareciam as histórias que compartilhamos na HeroBuzz. Coisas que a gente tinha visto dar errado, times que quebraram do mesmo jeito em organizações que não tinham nada a ver uma com a outra, decisões óbvias em retrospecto que ninguém tomou na hora. De vez em quando uma delas era boa demais para morrer ali, e um de nós dizia "e se a gente escrevesse sobre isso?".
Foi assim que nasceu a edição #33, em abril daquele ano. Na semana anterior tínhamos falado sobre o Technology Radar da ThoughtWorks e como ele é organizado. Naquela, pegamos o gancho para falar sobre por que uma organização poderia querer criar um radar próprio. Escrevemos sobre conhecimento concentrado em poucas cabeças, sobre o efeito copia e cola entre times, sobre stack que cresce sem gestão até virar problema de segurança. E terminamos com uma pergunta ao leitor:
Nós conhecemos algumas organizações que se beneficiariam muito de um radar próprio. E você, acha que faz sentido para a sua realidade? Quais seriam os anéis e quadrantes do radar para sua organização?
Era muito fácil escrever aquilo. A gente estava olhando de fora.
Há 45 dias assumi a direção de AI & Modernization na Dati e estou liderando as iniciativas do Dati Labs. A pergunta voltou endereçada a mim.
Boas ideias param na máquina de quem as teve
Essa cena eu já tinha visto se repetir em lugares que não tinham nada em comum, e levei tempo para entender que era sempre a mesma cena.
Alguém chega numa conversa e diz que a tecnologia "X" está muito melhor que as outras tecnologias que usamos na empresa. Qual é a prova? Não existe. É uma impressão legítima, formada por alguém competente, que não vira decisão de ninguém porque não tem lastro nem lugar para morar. Ou alguém inicia uma iniciativa que outro time já estava tocando havia semanas. Repare que aí ninguém errou. Os dois times fizeram exatamente o que se esperava deles, com autonomia e velocidade. O desperdício aconteceu do mesmo jeito.
Velocidade individual produz desperdício coletivo quando não existe um canal para as pessoas saberem umas das outras. E o problema é difícil de combater porque nunca se apresenta como falha. Ele se apresenta como movimento. Todo mundo ocupado, todo mundo entregando, e a organização andando menos do que se espera. É um dos sintomas clássicos de falta de coordenação.
Duas formas de escalar engenharia
Para simplificar a discussão aqui, podemos dizer que existem dois jeitos de organizar isso.
O primeiro é o time opinativo. A stack está decidida e o desenvolvedor não gasta julgamento escolhendo ferramenta. Ele gasta julgamento no negócio. Isso escala muito bem e entrega rápido, e quem despreza esse modelo normalmente nunca precisou sustentar cinquenta times ao mesmo tempo.
O segundo é o time onde experimentar é normal e até esperado. Você compra capacidade de descobrir coisas e paga em dispersão. No caso do Dati Labs, é o modelo certo. Nosso trabalho é justamente descobrir, e a gente não descobre nada sem experimentar.
O Dati Labs é a área de AI & Modernization da Dati, e o que nos ocupa é a transformação do trabalho com IA agêntica. A pergunta que a gente quer responder é o que muda no jeito de fazer as coisas quando agentes passam a participar do trabalho para valer, e como isso vai se refletir nas organizações, nos processos e no software.
No Dati Labs, autonomia é uma escolha deliberada. É como acreditamos que se constrói um time que precisa explorar tecnologia em constante mudança. Só que essa escolha tem uma conta, e a conta é transparência.
A conta da autonomia
Autonomia cria imediatamente dois desafios de comunicação que não existiam antes.
O primeiro é para cima. Como comunicar à liderança o que o time está explorando? Se a resposta for uma apresentação que você monta de vez em quando, com o que lembrar na véspera, então a autonomia do time está apoiada na sua memória, e isso não sobrevive a nenhum trimestre difícil. E, principalmente, não sobrevive à sua saída. Líderes vêm e vão, a organização continua. Quem está acima de você não vai retomar decisões por má-fé. Vai retomar porque ninguém consegue defender o que não enxerga.
O segundo é para os lados. Como permitir que seu time aprenda com outros times, e que outros times aprendam com o seu? Colaboração entre áreas não acontece por boa vontade. Acontece quando existe alguma coisa visível para colaborar em cima.
Foi aí que a ficha caiu sobre o que eu mesmo tinha escrito quatro anos atrás. Autonomia sem transparência produz desperdício com aparência de produtividade. E a transparência que resolve isso não é um relatório produzido por alguém, porque relatório tem a assinatura e o recorte de quem o produziu. Tem que ser um artefato que pertence ao time, que qualquer um consegue ler, e que continua existindo independente de quem está na sala.
Transparência morre quando é cara
Essa é a parte que eu subestimei em 2022, e é onde a maioria das tentativas fracassa.
Se contribuir com o artefato exigir ter uma opinião formada, ninguém contribui. A pessoa viu um lançamento interessante numa quinta-feira à noite, não tem tempo de avaliar, não quer ou não tem tempo para se posicionar sobre aquilo depois, e simplesmente não registra. A ideia volta a morrer na máquina de quem a teve, agora com um processo bonito por cima.
O que resolveu isso para o Dati Labs foi separar duas coisas que parecem uma só. Registrar e julgar.
Registrar precisa ser quase gratuito. Nome, categoria, link, data. Ninguém precisa ter opinião para colocar algo na fila, e colocar não significa endossar. Julgar é um passo separado e deliberado, que acontece depois, com calma e critério. Quando você mistura os dois, obriga cada pessoa a chegar com posição pronta, e o custo disso silencia justamente quem tem menos tempo e mais contexto de campo.
Essa separação é o que tenho de mais transferível para oferecer aqui, e ela não depende de ferramenta nenhuma.
Vale dizer o que pode dar errado do meu lado da mesa. Radar interno pode virar cemitério de blips (cada item registrado no radar) com uma facilidade impressionante, e quase sempre pelo mesmo motivo. Alguém confunde o artefato com o processo e começa a exigir campos, revisão e reunião de curadoria. O custo de entrada sobe, o mecanismo passa a servir a si mesmo, e o time volta a decidir por fora mantendo a aparência por dentro. Quando ninguém alimenta, a primeira hipótese que eu tenho que considerar é que eu tornei a entrada ou a avaliação cara demais.
Baixar esse custo de entrada e de avaliação é, por si só, um desafio e tanto. E é exatamente o tipo de coisa que IA agêntica resolve muito bem. No Dati Labs a gente já começou a usar agentes para isso. Mas esse é assunto para outro texto.
O radar começa como espelho
Cheguei imaginando que o trabalho inicial seria montar um mecanismo para decidir o que vem pela frente. Errei a ordem.
Quando você chega a uma organização que já entrega muito, não está diante de uma folha em branco. As pessoas já entregaram projetos, já resolveram problemas difíceis, já formaram opinião sólida sobre um monte de coisa. Já existe postura. Talvez ela só não seja recuperável por ninguém além de quem a formou. Fica viva no julgamento de cada pessoa e invisível para todas as outras ao mesmo tempo.
Descobrir isso não depende de epifania. É conversando com as pessoas e entendendo o contexto. Influência se constrói conhecendo as pessoas e o terreno, e eu passei as primeiras semanas aprendendo bem mais com o meu time do que o contrário. É um time talentoso e eu tenho sorte de trabalhar com eles.
Então o primeiro trabalho de um radar não é decidir nada. É dar nome ao que já é verdade. Você registra a postura que o time já tem antes de começar a triar o que chega de fora, e só depois de existir esse espelho é que faz sentido montar o filtro.
A matriz de fronteira e relevância do Dati Labs
Quando o filtro entra em cena, a tentação é ordenar tudo por novidade. Achamos que essa é a régua errada, e ela é o motivo de tanta gente boa gastar a semana correndo atrás do que está mais barulhento na timeline. O hype pelo hype.
No Dati Labs, a gente usa duas perguntas, e a segunda pesa mais que a primeira.
A primeira é sobre o potencial de mudança: isso muda o teto do que era possível, reabrindo casos que a gente considerava inviáveis, ou melhora muito alguma coisa que já dava para fazer?
A segunda é sobre relevância: isso toca os nossos clientes e/ou a nossa stack, ou é interessante para o mundo e distante do que a gente entrega e da estratégia?
Percebe? No limite, tudo é interessante. Então ter uma régua de relevância é fundamental para não desperdiçar energia.
| Perto do nosso jogo | Longe do nosso jogo | |
|---|---|---|
| Muda o teto do que é possível | Anel 1: Mergulhar. Testar agora. | Anel 3: Observar. De longe. |
| Melhora o que já era possível | Anel 2: Acompanhar. De perto, sem correr. | Anel 4: Passar. Registrar e seguir. |
A relevância pesar mais é o que muda o resultado, o que é um tanto contraintuitivo, se você pensar bem. Mas vem comigo, uma coisa impressionante que não toca no seu jogo, que não conversa com a estratégia de negócio, merece menos energia do que uma coisa entediante que toca. Faz sentido? Pense nisso como antídoto para o "isso aqui está muito melhor agora" solto numa conversa de corredor, porque a régua nos leva a completar a frase.
"Melhor para quê? Melhor para quem? Melhor quanto?"
Na mesma semana avaliamos duas novidades da mesma categoria, do mesmo fornecedor. As duas eram boas. Mas apenas uma reabria casos de uso que antes eram inviáveis para nós. A outra apenas melhorava uma solução que já funcionava. Pela régua do hype, elas competiriam pela mesma priorização. Pela nossa régua de fronteira x relevância, tiveram destinos diferentes. Uma foi para teste imediato, para o mergulho, enquanto a outra foi para acompanhamento. Nenhum dos dois foi ignorado. Registrar o segundo é o que impede o time de reavaliar a mesma coisa do zero daqui a três meses.
Créditos
Nada disso é invenção nossa. O Technology Radar da ThoughtWorks é a técnica original, e a ThoughtWorks mantém o build-your-own-radar aberto justamente para que qualquer empresa monte o seu.
O que mudou não foi a técnica, foi a pressão. O Technology Radar é um retrato curado e periódico. Ele não foi desenhado para a vazão diária de lançamentos que a gente vive hoje, o que não é defeito nenhum, é escopo. Na prática, quando a entrada acelera desse jeito, você precisa de um lugar separado para o que chegou e ainda não foi julgado. Se a fila de triagem se misturar com a lista de posturas, as duas perdem sentido, porque você deixa de saber o que foi decidido e o que só foi anotado. Foi por isso que acabamos com dois níveis, um para o que está chegando e outro para o que já é postura, com uma ponte entre eles para o que sobrevive ao teste.
O que ainda não sabemos
Estamos bem no começo disso. O que queremos construir é justamente uma forma de fazer com que as pessoas do time da Dati se sintam confortáveis em contribuir, mesmo sem certeza de que aquilo vale a pena. O mecanismo é o meio para que isso aconteça, não o objetivo.
Em 2022 eu e o Chico perguntamos aos leitores quais seriam os anéis e quadrantes do radar da empresa deles. A pergunta continua valendo. Só que hoje eu sei que escolher os anéis é a parte fácil. A parte difícil é alimentar e manter aquilo numa terça-feira comum, com entrega pressionando e ninguém cobrando.
Me pergunte de novo daqui a seis meses.
Se você também está pensando em como a IA agêntica transforma o trabalho e as organizações, entre em contato comigo.
Top comments (0)