Em 2001 Nelson Repenning e John Sterman colaboravam em um dos artigos essenciais sobre a dinâmica de gestão de um capability [1] e a sua habilidade de entregar a performance desejada dentro de uma empresa.
O artigo entitulado “Nobody Ever Gets Credit For Fixing Problems That Never Happened” ganhou diversos prêmios e descreve talvez uma das relações mais subestimadas dentro de uma empresa: como um capability ( definido de maneira simplificada aqui pelo conjunto de processos/ferramentas, ativos e pessoas que confere a uma empresa uma certa capacidade [1] - vender do jeito como vende, atender do jeito como atende, construir e produzir do jeito como constrói e produz, por exemplo ) é criado, mantido ou se deteriora/melhora com o tempo?
O que eu vou descrever nesse artigo é uma análise do trabalho dos dois professores citados acima, e como ela reflete ( e muito ) a realidade de muitas empresas.
Uma visão sistêmica de um capability
A primeira dinâmica que precisamos avaliar é a que descreve como um capability é construído, mantido e deteriora-se dentro de uma empresa: uma forma de visualizar essa dinâmica começa através de um fluxo de investimento no capability (normalmente caracterizado pelo capital investido e pelo tempo gasto por pessoas habilitadas trabalhando na criação, desenvolvimento ou melhorias daquele capability, por exemplo, investimento na compra ou manutenção de melhores equipamentos, ou talvez treinamento e estabelecimento de melhores práticas e processos ). Esse investimento com o tempo se acumula, gerando o que podemos chamar de um estoque daquele capability, esse acúmulo ou estoque é o que o representa.
Quanto maior o estoque, decorrente do investimento feito naquele capability, normalmente maior é a performance que aquele capability consegue entregar.
No entanto, assim como tudo na vida, dado tempo suficiente as coisas tendem a se deteriorar ou erodir, por exemplo, um processo que não é revisitado após uma mudança na forma de atuação, um treinamento de requalificação que não é executado para antigos e novos funcionários, um software que não é atualizado ou refatorado para atender as necessidades mais atuais dos clientes. Não importa muito a causa, o que importa é que esse capability se deteriora com o tempo, assim como a performance que é derivada do mesmo.
Para exemplificar, um capability de uma empresa pode ser o seu motor de vendas, ou seja, o conjunto de pessoas, ativos e processos/ferramentas e estruturas organizacionais capaz de diferenciar como essa empresa atrai e adquire novos clientes para o seu produto ou serviço.
Um outro exemplo pode ser a habilidade de oferecer a modalidade de auto-atendimento para os seus clientes, talvez a partir de um canal digital. O conjunto que envolve pessoas ( gestores, product managers, designers, desenvolvedores, QA’s, DevOps, customer success/atendimento e as interações entre eles ), processos e práticas ( discovery, CI/CD, algum sabor de agilidade, design system, padrões e procedimentos de atendimento online/offline como transbordo, treinamentos ) e ainda o ativo de software ( o canal digital em si ) são algumas das coisas que constituem esse capability, conferindo aquela empresa uma certa capacidade para entregar uma certa performance e gerar valor atendendo aos seus clientes.
Voltando a nossa analogia anterior, fluxo de investimento para o desenvolvimento de um canal digital de auto-atendimento adiciona ao estoque daquela capacidade. Se eventualmente, a empresa parar o fluxo de investimento/melhorias ( ou reinvestimento ) ela irá inevitavelmente se deteriorar.
Assumindo uma relação direta entre mais investimento e aumento de performance ( hipótese razoável apenas se assumirmos que os gestores e membros da equipe sabem identificar onde e como fazer os bons investimentos para aumentar a performance ), melhor vai ser o resultado financeiro potencialmente obtido, o que gera mais recursos financeiros para serem reinvestidos no capability. Vale ressaltar que o inverso também é verdade, quanto menor o investimento em um capability, menor a sua performance potencial, menor o seu resultado financeiro e por consequência menor o potencial de reinvestimento no mesmo.
Logo, por esse modelo, a performance de um capability é determinada pelo seu estoque ( ou acumulo, em outras palavras: o seu estado atual ). Essa abstração para visualizar uma capacidade é essencial, pois muitas vezes enxergá-lo é difícil pois normalmente ela possui diversos aspectos intangíveis exceto pela sua característica mais externa - a performance mensurável que ele entrega.
Adicionalmente ao estoque daquele capability, temos uma segunda forma de aumentar a performance entregue: esforço de trabalho. A equipe envolvida naquele capability pode compensar ou incrementar a performance colocando mais horas de trabalho ou esforço em alguma atividade crítica do mesmo. Entra o ciclo working harder.
Working Harder
Duas dinâmicas essenciais determinam como um capability se comporta no tempo, a primeira é chamada de work harder, onde a equipe envolvida no capability entrega uma performance maior ao aumentar a pressão para fazer trabalho e gastar mais do seu tempo trabalhando incrementando assim a performance entregue.
Fonte: Nobody ever gets credit for fixing problems that never happened, Nelson P. Reppening, John Sterman
O diagrama acima exemplifica essa dinâmica: o capability entrega uma performance específica ( actual performance ), no entanto o que é desejado é uma performance maior (desired performance), por exemplo, entregar 30% a mais de vendas ou diminuir em 15% o lead time de entrega de pedidos, ou ainda aumentar o NPS dos clientes em 20%.
Essa performance desejada quando comparada com a performance efetivamente capaz de ser entregue pelo capability, pode apresentar um gap ( desired performance menos actual performance ). Quanto maior o gap, maior a pressão envolvida em atingir a meta, e quanto maior a pressão envolvida mais tempo as equipes passam trabalhando para atingir os targets de performance, e esse esforço eventualmente complementa a performance atual do capability, diminuindo o gap de performance, diminuindo a pressão e equilibrando o ciclo.
Esse ciclo, chamado de work harder, é comum em diversas empresas e por muitas vezes é um dos fatores determinantes da sua cultura, onde o trabalho 24x7 ( always on ), gestão e incentivo por meio de pressão, heroísmo e o conhecimento intrínseco sobre como “gamificar o sistema” para atingir um resultado é intimamente ligado com a forma como as coisas são feitas e recompensadas dentro da empresa.
No entanto, essa não é ( obviamente ) a única forma de resposta para a diminuição do gap entre a performance desejada e a performance capaz de ser entregue por um capability. Se uma forma de fazê-lo é correndo a milha extra adicionando pressão e esforço para obter a performance desejada, outra abordagem de fazê-lo é trabalhando de uma forma diferente e mais inteligente para aumentar a performance capaz de ser entregue pelo capability. Entra o ciclo working smarter.
Working Smarter
A segunda forma de endereçar o problema é investir tempo na melhoria do capability para aumentar a performance que este é capaz de entregar, e assim fechar o gap.
"Here, managers respond to a performance shortfall by increasing the pressure on people to improve capability. They may launch improvement programs, encourage people to experiment with new ideas, and invest in training. If successful, the investment will, with time, yield improvement in process capability, boost throughput, and close the performance gap. "
Fonte: Nobody ever gets credit for fixing problems that never happened, Nelson P. Reppening, John Sterman
Ou seja nesta outra forma de abordar o problema, quanto maior o gap entre a performance atual e a performance desejada, maior a pressão para investirmos em melhoria no capability para que a performance atual entregue seja maior, e por tanto feche o gap entre actual e desired performance.
O diagrama abaixo ilustra essa abordagem:
Fonte: Nobody ever gets credit for fixing problems that never happened, Nelson P. Reppening, John Sterman
Ainda sobre essa abordagem:
"(…) Of course everyone knows that it is better to work smarter than to work harder: An hour spent working produces an extra hour's worth of output, while an hour spent on improvement may improve the productivity of every subsequent hour dedicated to production.”
Fonte: Nobody ever gets credit for fixing problems that never happened, Nelson P. Reppening, John Sterman
Apesar de ser a abordagem mais óbvia para aumentar a performance, existem alguns desafios para a aplicação do work smarter:
Delay ( atraso ). Normalmente um investimento para melhorar um capability demanda tempo até que os seus efeitos positivos sejam percebidos. Esse tempo as vezes pode não estar disponível para a necessidade de aumento da performance no curto prazo
Risco. Existem riscos inerentes a abordagens de melhoria ( e investimento ), por muitas vezes não se encontra as causas raízes dos problemas e alavancas para o aumento de performance, novas ferramentas não trazem os ganhos esperados e experimentos muitas vezes simplesmente falham.
Modelos mentais dos gestores. As crenças sobre o estilo de gestão e incentivos no sistema que favorecem um comportamento com foco em curto prazo versus um comportamento com foco em longo prazo.
No entanto, apesar dos desafios acima, há de se concordar que work harder é uma abordagem fundamentalmente diferente da abordagem work smarter.
E agora, somos obrigados a fazer uma pergunta fundamental: se work smarter tem vantagens óbvias no longo prazo, por que a abordagem que a maioria dos gestores aplica quando confrontado com a necessidade de entregar uma performance superior é a work harder?
Capability Trap: como chegamos até esse estado?
Embora o ciclo work smarter seja obviamente a solução sustentável para o desafio de aumento de performance ( ou atingir uma meta ), o que comumente observamos na maioria das empresas é um ciclo diferente: para lidar com problemas de curto-prazo (atrasos, queda de produtividade, alcance de metas, defeitos urgentes em produção e outros problemas do tipo ), gestores sistematicamente optam por aumentar a pressão para endereçar essas questões de maneira reativa e com efeitos apenas nos seus sintomas.
Quando uma iniciativa está atrasada, coloca-se pressão para que mais horas de trabalho sejam feitas para se compensar o desvio. É autorizado (implícita ou explicitamente) que caminhos sejam “cortados” ( usualmente na forma de qualidade e/ou escopo, mas não apenas simplificação de escopo e sim a perda de funcionalidades críticas ou quesitos não funcionais essenciais para a sustentabilidade no longo prazo do produto ), instala-se uma cultura de microgerenciamento de atividades do time com objetivo de extrair uma maior produtividade, além de outros artifícios usuais.
O que deveria acontecer é que, aumentada a pressão e iniciado o ciclo work harder, após atingirmos as metas de performance, a pressão deveria se dissolver e a operação deveria voltar ao seu “estado normal”. No entanto, o que vemos sistematicamente é que isso não acontece, esse ritmo e forma de trabalho passa a ser a norma, institucionalizando-se culturalmente como a “forma com que fazemos as coisas por aqui”.
Em muitos casos isso se dá pois conforme os ciclos de work harder se repetem e um investimento sistemático em melhoria não é executado pela falta de tempo, aquela habilidade da empresa vai se erodindo, cada vez mais entregando menos performance, o que faz com que mais esforço seja necessário para atingir ou superar a performance requerida.
Fonte: Nobody ever gets credit for fixing problems that never happened, Nelson P. Reppening, John Sterman
Em outras palavras, gestores e funcionários sistematicamente recorrem a esse tipo de abordagem para atingirem as suas metas e consequentemente nunca possuem tempo para trabalhar em atividades de melhoria para aumentar de maneira sustentável a performance do mesmo.
Obviamente após repetidos ciclos executados com incentivos de cortar caminho usualmente através de uma diminuição de padrões de qualidade e segurança, o que vemos com o passar do tempo é a erosão do capability, ou seja, a diminuição da capacidade de entregar certo nível de performance, o que por sua vez reforça ainda mais o estimulo ( ou talvez agora a necessidade ) para resolver as coisas working harder em vez de working smarter.
O tradeoff entre work harder e work smarter acontece em alguns pontos essenciais:
quanto maior a pressão para work harder, menor o tempo disponível e investido em melhorias do capability
quanto menor o investimento e reinvestimento sistemático em melhorias, vai ser gradualmente menor a performance entregue por esse capability devido a sua erosão pela falta de manutenção e investimento
Enquanto isso, quanto maior for a performance atingida, maior será a próxima meta de performance a ser desejada no ciclo subsequente, eventualmente esticando o capability para além da sua performance máxima.
Para cada um dos casos a dinâmica é diferente e causa resultados divergentes no longo prazo.
"(...) The first simulation shows the response to an increased emphasis on working harder. As more effort is dedicated to work, gross throughput immediately rises. Time spent improving falls immediately, but capability does not. Performance therefore rises. The benefit of working harder is, however, short-lived. With less time devoted to improvement, capability gradually erodes, eventually more than offsetting the increased time spent working. Working harder creates a "better-before-worse” situation. Conversely, as seen in the second simulation, increasing the time spent on improvement reduces output in the short run. Eventually, however, capability rises more than enough to offset the drop in work effort and performance is permanently higher, a “worse-before-better” dynamic.
The interaction between the balancing Shortcut loop and the reinforcing reinvestment loop creates a phenomenon we call the Capability Trap and helps explain why organizations often find themselves stuck in a vicious cycle of declining capability. Managers and workers in need of an immediate performance boost can get it by skimping on improvement and maintenance. However, capability eventually declines, causing the Reinvestment loop to work as a vicious cycle. Managers who rely on working harder and shortcuts to meet immediate throughput needs soon find the process falling short of its objectives, requiring a further shift towards working harder and away from improvement.
(…)
By keeping the line going rather than stopping to fix the problem, these team leaders relied on the Shortcuts loop to hit their throughput objectives. However, by ‘running like crazy’ they also caused the Reinvestment loop to operate as a vicious cycle, driving the line to a minimal level of capability and forcing them to run even faster.”
Fonte: Nobody ever gets credit for fixing problems that never happened, Nelson P. Reppening, John Sterman
O gráfico abaixo descreve exatamente essa dinâmica: enquanto no modo working harder, a performance melhora no curto prazo ( dado o esforço e horas de trabalho ), a performance piora no médio/longo prazo, devido a falta de investimento em melhorias e manutenção para melhorar de forma sistemática a performance de um capability.
De maneira análoga, no working smarter a performance piora antes de melhorar, ou seja, retirar funcionários de atividades que imediatamente entregam mais performance para que eles trabalhem em melhorias e manutenções faz com que a performance no curto prazo piore, no entanto, o investimento em melhorias e manutenção faz com que a performance melhore no médio/longo prazo.
Fonte: Nobody ever gets credit for fixing problems that never happened, Nelson P. Reppening, John Sterman
Por que essa forma de gerir um capability persiste?
Dito isso, por que muitas empresas sistematicamente recorrem ao ciclo de working harder? Em primeiro lugar, por que ele funciona, especialmente no curto prazo. Em segundo lugar, por que existe um delay entre as ações relacionadas ao working harder efetivamente erodirem um capability, em outras palavras, demora algum tempo até que as consequências de meses ou anos trabalhando dessa forma causem erosão visível ou perceptível em uma capacidade já existente, assim como na sua performance, ao ponto onde as coisas se tornem insustentáveis.
Além disso, a dinâmica worse before better necessária para efetivamente atuar em melhorias requer tempo e paciência, o que implica em um compromisso de médio/longo prazo por parte das lideranças com essa abordagem.
Além disso, em muitos casos o gestor que estimulou o curso de ação working harder para endereçar um desafio, muitas vezes ou já foi promovido ( por ter entregue a performance, mesmo que daquela forma ) ou saiu da área/empresa antes de ver e experimentar as consequências das suas ações.
“(…) The capability trap goes beyond low capability and high work pressure. Eventually it gets embedded in deeper structures, including incentives and corporate culture. As organizations grow more dependent on firefighting and working harder to solve problems caused by low process capability, they reward and promote those who, through heroic efforts, manage to save troubled projects or keep the line running. Consequently, most organizations reward last-minute problem solving over the learning, training, and improvement activities that prevent such crises in the first place. As an engineer at an auto company told us, “Nobody ever gets credit for fixing problems that never happened.”. Over time, senior management will increasingly consist of these war heroes, who are likely to groom and favor other can-do people like themselves.
(…)
Thus incentives and culture not only reinforce the tendency toward short-run thinking and working harder, but also are themselves shaped by that very short-term focus and work-harder mentality, creating another reinforcing feedback that intensifies the capability trap.”
Fonte: Nobody ever gets credit for fixing problems that never happened, Nelson P. Reppening, John Sterman
A marcha da morte descrita no último artigo, muitas vezes pode ser um sintoma ( ou um evento ) causado por uma dinâmica complexa e mais estrutural que ocorre onde a iniciativa está inserida. Um gestor, seja de um produto ou de qualquer outra capacidade de uma empresa, que não leva em consideração essa dinâmica e a evita, muito provavelmente vai se encontrar preso nesta armadilha.
No próximo artigo vamos falar sobre abordagens insustentáveis e sustentáveis para a criação, desenvolvimento e evolução de um produto digital sob a ótica das dinâmicas descritas nos últimos dois artigos.
[1] - A palavra “Capability” é uma daquelas palavras em inglês que tem um significado ingrato quando traduzido para o português. Assim como “accountability” é diretamente traduzido como “responsabilidade”, apesar de no inglês accountability e responsability terem significados diferentes.
Temos um problema similar com o termo capability. Quando traduzido para o português ele se torna capacidade, no entanto quando traduzimos o termo capacity (que para o contexto de produtos digitais, tecnologia e o contexto de negócios normalmente denota a quantidade máxima ou disponível de algo que conseguimos suportar) também chegamos em capacidade, e muitas vezes isso é confuso. Algumas pessoas utilizam inclusive o neologismo capabilidade para denotar a diferença entre capacidade e capabilidade ( normalmente de um processo ), outros preferem o uso do termo competência.
Para o contexto do nosso artigo estamos falando sobre capability definido de maneira simplificada como o conjunto de pessoas, processos/ferramentas, e ativos que conferem a uma empresa uma habilidade específica de entregar algum tipo de valor para os seus clientes.