O valor está em lidar com as coisas bagunçadas

Subbu Allamaraju Blocked Desbloquear Seguir Seguindo 10 de janeiro

Nos últimos anos, tive a oportunidade de liderar alguns projetos que eram grandes demais para qualquer equipe única executar. Também lidei com problemas que não se encaixavam na equipe e nas estruturas organizacionais. Alguns destes também foram problemas “multi-VP” (veja abaixo). Estes foram projetos confusos e ambíguos que tentam você a desistir e ir embora.

Decidi anotar minhas observações e lições aprendidas quando descobri que as pessoas que querem crescer em suas carreiras como gerentes ou colaboradores individuais devem estar à vontade para lidar com esses problemas. Caso contrário, é improvável que eles sejam capazes de influenciar e entregar qualquer coisa importante.

Começa com silos

Quem não culpa os silos em seu local de trabalho por sua lentidão, burocracia e disfunção? Quem não quer se ejetar de tais lugares para pousar em terras mágicas e livres de silo onde as coisas se movem perfeitamente fluidas?

Nós culpamos os silos por sua resistência à mudança. Os silos são conhecidos por produzir arquiteturas, processos e operações que seguem as linhas de comunicação entre esses silos, com pouca atenção ao problema geral. Esta é a essência da lei de Conway :

Qualquer organização que projete um sistema (definido mais amplamente aqui do que apenas sistemas de informação) inevitavelmente produzirá um design cuja estrutura é uma cópia da estrutura de comunicação da organização.

Em seu livro Toward Simplifying Application Development, em uma dúzia de lições , Conway posteriormente esclareceu que a importância desse princípio é investigar

(se) sua organização de design está impedindo você de projetar algumas coisas que talvez deva estar construindo.

ou ainda mais importante, fazer a seguinte pergunta.

Existe um design melhor que não está disponível para nós devido à nossa organização?

Esta questão é o teste decisivo por excelência para silos. A maioria de nós que teve experiências frustrantes com silos responderia afirmativamente a essa questão.

No entanto, também preferimos pequenas equipes autônomas independentes para tomadas de decisão mais rápidas, ciclos de feedback curtos e para aproximar a responsabilidade de onde a informação e a execução estão. De fato, podemos resumir todo o movimento de micro-serviços como um para criar pequenos silos para agilidade e eficiência para criar valor rapidamente. Por meio de arquiteturas inspiradas em microsserviços e microsserviços, estamos facilitando pequenas implementações independentes de código, cada uma das quais faz uma coisa bem e está removendo os monolitos de impostos de coordenação necessários para criar valor. Como notas da Wikipedia:

paraleliza o desenvolvimento , permitindo que pequenas equipes autônomas desenvolvam, implantem e dimensionem seus respectivos serviços de forma independente

Justo. Mas observe a dicotomia entre querer separar os silos e, ainda assim, querer que pequenas equipes autônomas (isto é, silos) se movam rapidamente.

Por que essa dicotomia? Esses dois querem estar certos? Existe uma maneira de ter eficiência e agilidade de pequenas equipes e, ainda assim, evitar a armadilha da lei de Conway?

Essa dicotomia não é fictícia. Você não pode liderar nenhum corpo importante de trabalho sem enfrentar essa dicotomia. Independentemente do seu título ou função no seu local de trabalho, lidar com esse tópico é um pré-requisito essencial para a crescente influência e liderança. É improvável que você influencie a mudança, se permanecer frustrado com essa dicotomia, ou evite-a completamente ao se ejetar para pousar em outro lugar.

Silos são centros de eficiência

A primeira coisa a reconhecer é que precisamos de silos por um motivo. Uma vez que entendemos como decompor um grande problema em vários problemas menores, os silos ajudam a resolver essas partes de forma eficiente. Você estrutura o silo como um centro de trabalho para se concentrar em torno das informações para resolver o problema, equipá-lo com os recursos necessários e empurrar a tomada de decisões para o silo. Assim, cada silo se torna um centro de eficiência para produzir valor rapidamente.

Silos permitem papéis e responsabilidades claros. Você sabe para onde ir e quem perguntar quando há um problema. Todos no silo estão próximos das informações necessárias para fazer ou alterar decisões de forma autônoma. Isso leva ao empoderamento e o empoderamento leva à responsabilidade.

Os silos também criam suas próprias micro-culturas, que incluem rituais, processos, regras, linguagem, orgulho e propriedade.

A cultura e os processos que o silo cria para si são geralmente otimizados para executar a eficiência do status quo. O status quo pode ser uma ou mais áreas problemáticas, a execução de certas tarefas para produzir alguns resultados bem definidos ou para produzir algo de valor que se encaixa em um contexto mais amplo. Uma equipe de “perfil de usuário” em uma empresa de comércio eletrônico ou a equipe de remessa em uma loja de varejo são exemplos perfeitos de silos.

A micro-cultura do silo também cria um limite invisível em torno dele. O “orgulho e a linguagem” que cada silo desenvolve constitui a outra face de uma moeda chamada “propriedade e responsabilidade”.

Por necessidade de autonomia e eficiência, os silos desenvolvem uma terminologia de "nós e eles". Por isso, parecem insulares e resistentes à mudança. Por exemplo, quando você aborda a equipe de “perfil de usuário” (um silo) para o que você acha que é realmente um recurso importante, eles podem receber uma resposta que “nossa equipe decidirá após o próximo sprint” ou que “decidimos não criar esse recurso por razões x, yez. ”Você pode pensar que eles estão resistindo à mudança por serem inflexíveis quando, na verdade, podem estar apenas exercendo sua autonomia.

Como veremos abaixo, tal resistência nem sempre é culpa do silo.

Ambiguidade

Silos tornam-se ineficientes quando você está tentando qualquer alteração importante que abranja vários silos existentes. Os silos parecem atritos quando você sobrepõe uma mudança de transformação em cima dos silos existentes.

Enfrento este desafio com os maiores problemas em que trabalho. Esses problemas nem sempre mapeiam para silos existentes. Não sei dizer qual das equipes existentes pode ajudar a resolver o problema.

Vou dar-lhe um exemplo fictício do que eu costumava chamar de brincadeira como um problema de "multi-VP".

Um problema multi-VP é aquele que requer que vários gerentes de nível VP trabalhem juntos para estruturar uma solução, ou a implementação da solução leva mais tempo do que a posse de um único gerenciador de nível de VP. Esse mandato pode ser em torno de 2 a 3 anos, quando a solução pode levar de 5 a 6 anos. Em ambos os casos, a chance de resolver o problema com sucesso não é alta.

Aqui está o meu exemplo fictício. Implica quebrar um grande banco de dados monolítico do qual tudo depende de uma empresa para a maioria dos dados, em bancos de dados menores e desacoplados para facilitar uma arquitetura de micro-serviços. Soa familiar?

A arquitetura técnica para o problema é simples. Pode envolver blocos de construção, como escolher uma nova tecnologia de banco de dados legal, modelagem de dados, migração de dados, dados de gravação dupla, migração de dados, adaptadores para alternar entre banco de dados antigo e novo etc. para cada bloco lógico de dados no banco de dados monolítico. A elaboração da arquitetura é a parte fácil. Todo mundo fica animado com essa parte, pois é considerada inovação.

No entanto, quem deve realmente fazer o trabalho sujo de implementar essa arquitetura? Alguns colegas se queixam de que eles “precisam de energia” para “empurrar” sua arquitetura.

Devemos perguntar à equipe que gerencia e administra o banco de dados monolítico para implementar essa arquitetura? Essa equipe pode estar equipada com as habilidades necessárias para administrar os servidores de banco de dados e os bancos de dados de maneira eficiente. Eles podem ser os melhores da empresa para executar esse banco de dados em escala com alta disponibilidade. Eles podem ser adeptos em gerenciamento de capacidade, atualizações, backups e restaurações sem falhas. Eles podem ser especialistas em gerenciamento e indexação de esquemas. Apenas olhando para a consulta, eles podem ter desenvolvido as habilidades para identificar os gargalos. Mas é improvável que liderem uma transformação de micro-serviços, pois talvez nunca tenham olhado para os aplicativos que dependem do banco de dados, ou tenham a menor idéia do que esses aplicativos realmente fazem, ou pratiquem qualquer codificação.

Que tal perguntar a uma ou mais das dezenas de equipes que dependem desse banco de dados de monolito? Não tendo a necessidade de saber nada sobre o âmago da questão de gerenciar um banco de dados por conta própria, eles provavelmente estão acostumados a lançar todas as suas tarefas de banco de dados do outro lado da cerca para a equipe que gerencia o banco de dados. Eles provavelmente também têm rolagens longas de recursos para construir. Com o tempo, eles podem ter desenvolvido certa cadência de desenvolvimento que não tem mais ciclos para aprender e captar o trabalho relacionado ao banco de dados.

Essa é a natureza de um problema ambíguo. É grande para qualquer equipe única escolher e resolver. O problema envolve muitos blocos de construção sem mapeamento claro para os silos existentes. Implementar uma solução leva muito tempo. Os resultados não são claros e não são garantidos. Você pode encontrar várias surpresas ao longo do caminho.

Lutei, no começo, para resolver esses problemas. Eu costumava ficar frustrado e às vezes pensava em seguir em frente em vez de tentar encontrar um caminho. Isso mudou uma vez que eu ajustei meu modelo mental.

Meu modelo mental original via a organização como política, inflexível, burocrática e incapaz de mudar com grupos de equipes, investida em sua sobrevivência, resistindo a qualquer mudança. Este é um modelo mental bastante comum empregado por muitos de nós. No entanto, esse modelo é falho, letárgico e instila a estagnação e não muda.

Minha atitude mudou quando mudei meu modelo mental. Agora vejo esses problemas como sendo ambíguos na natureza. Meu modelo mental agora reconhece rapidamente que os silos existentes não são otimizados para resolver a ambigüidade, que não há problema com os silos existentes, que o novo problema requer uma nova abordagem e que a oportunidade pode ser minha para derrubá-lo.

Interromper silos atuais para criar novos silos

Quando confrontados com problemas ambíguos como o “problema multi-VP” acima, primeiro reconheça que você precisa desambiguar o problema, reestruturar a complexidade do problema e influenciar a organização para instilar a mudança. Isto é mais fácil dizer do que fazer. Requer empatia com os silos existentes, humildade para deixar suas idéias, paciência e tenacidade para influenciar os outros.

Embora eu não possa escrever uma receita que todos possam seguir, abaixo estão alguns dos que funcionaram para mim e o que vi os outros praticarem.

  • Adquirindo o problema, reconhecendo que há uma oportunidade de se impor e assumir o problema, por mais confuso que seja, em vez de agir como uma vítima enfrentando um vilão. Você deve estar confortável com a bagunça que vem com um problema ambíguo.
  • Desenvolvendo e esclarecendo o porquê. Não é suficiente dizer que o problema que você viu é importante. Você tem que ser capaz de dividi-lo em detalhes que os outros podem se relacionar, identificar-se e estão motivados para resolver. Isso, obviamente, requer a identificação e construção de coalizões e a identificação proativa de riscos e bloqueadores.
  • Acompanhar a execução de uma solução, ajudando a formar novos silos para solucionar eficientemente o problema. Esta pode ser a parte mais difícil. Mas reconheça que nenhuma outra pessoa pode ter passado tanto tempo quanto você sobre o problema, e provavelmente não há ninguém que possa dar esse passo por você.
  • Finalmente, permanecendo focado nos resultados e não em "como" você quer que o problema seja resolvido. Ou seja, você deve estar disposto a abandonar suas ideias da solução para que novos silos possam se desenvolver para solucionar o problema de maneira eficiente.

Estes são todos os traços de liderança.

Alguns dos líderes mais eficazes com quem tive a chance de trabalhar são desambigüadores-mestres. Quando se deparam com uma mudança de transformação, eles se concentram em interromper os silos existentes apenas para formar novos silos para liderar a mudança. Eles confiam menos no poder posicional e mais na influência para desambiguar o problema e desenvolver maneiras para os outros contribuírem para uma solução.

De volta ao ponto Em vez de culpar os silos existentes, você pode ter que formar novos silos para fazer mudanças transformacionais. Isso não significa reorganizar as equipes existentes em uma nova estrutura de relatórios. Você pode fazê-lo mais tarde ou ignorá-lo totalmente se a cultura da organização for construída em torno de unidades de trabalho e não relatar relacionamentos.

Lide com a bagunça para causar impacto

Para concluir, os silos não são ruins. A maioria dos silos são centros de eficiência. Em vez de sempre tentar sobrepor uma nova transformação, pequena ou grande, em cima dos silos existentes e ficar frustrado com a lentidão e a fricção, talvez seja necessário primeiro estruturar uma solução e descobrir que tipos de silos você precisa executar com eficiência e depois avançar para liderar essa mudança. Você prossegue e descobre que os novos centros de trabalho (silos) não estão ajudando na próxima transformação. Você passa pelo mesmo processo novamente. Isso é um ciclo.

Você deixará de culpar a organização por sua cultura silo quando reconhecer que os silos existentes estão otimizados para executar o status quo de forma eficiente, mas não para causar uma mudança.

Conway pode ter reconhecido isso quando ele escreve sobre sua segunda lição em Toward Simplifying Application Development, em uma dúzia de lições :

Lição 2: Se você quer o produto mais limpo possível, você precisa encontrar o design mais simples possível antes de organizar a construção, ou então você deve estar preparado para reorganizar.

Deixe-me reiterar que isso não é fácil. A dicotomia entre querer separar os silos e, no entanto, querer pequenas equipes autônomas é um processo natural de instilação de mudanças. Pode ser frustrante. Haverá altos e baixos. O sucesso não é garantido e você cometerá erros. Aí reside uma oportunidade.