tão desafiador. As pessoas esperam que a liderança atue mais: • No desenvolvimento contínuo da equipe • Na criação de condição para pessoas experimentarem novas formas de fazer as coisas “ ” Fonte: Carreira dos Sonhos, 2022
em seres vivos e orgânicos, ou mesmo em organizações Existem muitas expectativas sobre elas, principalmente que essas mudanças resolvam problemas de forma definitiva. Além disso, não ser parte delas torna o processo de entendimento muito mais complexo
surgem nossos padrões, mentais e práticos, que vêm com a nossa experiência, nossas vivências. Acabamos aplicando as mesmas soluções para problemas conhecidos
risco mais conhecido, é o de vieses inconscientes Viés de Confirmação usar um fato, um acontecido, como prova de que aquela mudança precisa ser feita “Viu o que falei? É por isso que precisamos fazer essa mudança” “Quando digo que precisamos mudar determinada coisa, é por conta desse exemplo aqui” Viés de Recência dar mais importância pra eventos recentes do que os de longo prazo, afim de justificar uma mudança necessária “Parece que não estamos entregando no prazo. Precisamos dar mais cadência nas entregas. Acho melhor começarmos a medir a velocidade do time” “Tivemos muitos incidentes. Me parece que o time está perdido e a arquitetura que temos não suporta nosso momento”
risco mais conhecido, é o de vieses inconscientes Viés de Halo chegar num time e aplicar mudanças, influenciando a percepção positiva (quando dá certo) do time ou de lideranças “Que bom que você chegou e mudou isso! Era isso que faltava, alguém com experiência!” Viés de Similaridade por ter visto algo parecido funcionar em outro lugar, usamos esse pretexto pra trazer aquela mudança para o contexto atual “Mas lá no ****** funcionava assim e era muito bom!” “Eu prefiro fazer dessa forma, pois acho que funciona melhor, como nesse lugar aqui, que sempre funcionou”
partimos para o uso exclusivo da Experiência, assumimos que o contexto, o momento, o ambiente, são os mesmos de outras vivências Nossa tendência é aplicar essas soluções em busca de resolver o problema de forma rápida Na maioria das vezes acaba- se criando processos, burocracias, entraves, que geram ineficiência
mudança não “cabia” para aquele contexto, e assim, criamos uma forma de lidar com o problema que é desproporcional ao momento Um exemplo disso é criar times de plataforma que não tem ferramental self-service, e que acumula a execução de tarefas num formato de suporte
Olhamos para uma mudança como se fosse óbvia “Se isso está ocorrendo de forma X, é porque Y é a causa” “Foi como eu tinha te falado… Agora precisamos fazer a mudança X para isso melhorar” A Experiência nos deixa com mais preguiça de investigar, ter curiosidade
O pior dessa análise superficial é permitir que lideranças que optam pelo comando e controle como recurso único, sempre utilizem essa forma de analisar problemas como refúgio para perpetuar a dinâmica do poder
Tiramos a criatividade das pessoas em sugerir uma ação para um problema, porque queremos resolver rápido, porém sem profundidade Usando a Experiência, podemos cair na armadilha de prover soluções simplórias, que não resolvem o problema de fato - às vezes nem sabemos o problema real, e aplicamos soluções superficiais
Um exemplo clássico disso é adotar uma política mais severa ao aprovar pull/merge requests. Com a intenção de melhorar a qualidade do código ou diminuir número de incidentes, aplicamos políticas de submissão de código que exigem pessoas mais experientes avaliando o trabalho final. Quando na verdade, o problema principal não se resolve, que é o da falta de conhecimento das pessoas em determinadas tecnologias ou conceitos
Problema Real “Já aconteceu assim em determinado lugar que passei, o problema com certeza é esse!” Justificando com Experiência, fugimos de entender o problema real
Problema Real Um exemplo disso é a famosa “falta de contexto” dos times. “Esse time não tem contexto suficiente, por isso não está performando bem” Nas experiências que tive, o contexto existia, porém ele não era o que de fato resolveria os problemas de performance do time. Existia uma série de ineficiências, desde a forma que a arquitetura dos serviços foi construída, até o desencontro de informações entre as pessoas do time. Faltar contexto não era o problema, mas sim o modo em que o time estava operando, sem ter tempo de refletir sobre como o trabalho poderia ser melhor realizado
os times tem uma mentalidade de testar e validar hipóteses antes de entregar soluções para os clientes Alguns chamam isso de “Cultura de Experimentação” Um exemplo: teste A/B, é uma forma de experimentar. Mas como fazer isso com mudanças culturais?
fi nirmos em quais times as pessoas vão trabalhar, deixarmos elas escolherem? O self-selection é uma técnica que possibilita as pessoas escolherem seu próximo time, quando acontece uma re- organização. Rodei esse experimento em diversos times, e notei que, em 100% dos casos, não houveram problemas de senioridade sem um balanço saudável, ou mesmo con fl itos de pessoas quererem os mesmos times.
leva tempo e exige que os times parem para re fl etir sobre eles, de forma recorrente. Pensando nisso, rodei um experimento para testar se poderíamos resolver tensões nesses acordos de forma assíncrona
experimentar - tempo, energia, investimento ($) DICAS 2. Limite o número de experimentos 3. De fi na papéis para os experimentos acontecerem (ex: Líder do Experimento) 4. Organize experimentos por temas, como por exemplo “Acordos” - onde experimentos que sejam em torno de melhorias de arcodos fi quem acomodados
e dinheiro não gastamos tempo com achismos evitamos mudanças grandes e abruptas, que podem dar errado começamos pequeno, testamos rápido, jogamos fora o que não deu certo empoderamos o time a tomar decisões de descartar coisas antes de gastar muita energia nelas
Se precisar de ajuda com assuntos relacionados a liderança, arquitetura de software, design organizacional e cultura de engenharia, me manda um email no: