Ep. 173 - Frameworks: aliados ou inimigos?

Hoje vamos falar sobre transformações para além dos frameworks. Será que eles ainda são úteis? Quando que eles são úteis? Por que ainda tem tanto apego a alguns frameworks? Será que faz sentido?

Frameworks, para mim, são como receitas. Imagine que você está aprendendo a cozinhar, quer melhorar seus skills, e vai atrás de uma receita para seguir os passos, entender os ingredientes, o tempo no forno. O framework oferece uma estrutura, um arcabouço de passos, técnicas, ferramentas, modos de fazer que ajudam a atender um determinado objetivo. É inevitável que, ao repetir os passos, você reproduza o que o framework indica. Mas chega um ponto em que você já não está mais nem aí para a receita, porque internalizou o conhecimento. Aí você precisa trazer contexto da empresa, experimentar coisas melhores. Frameworks são caminhos que te ajudam a começar até você estar apto a entender o que pode fazer além deles. Eles não são outcome, são pontos de partida, não pontos de chegada.

Um dos grandes erros que se vê é: aplicou o framework num pedaço, deu certo, vamos aplicar para todo mundo. E não é o caminho, porque o problema é outro, o nível de maturidade de cada área é outro. Departamentos ou problemas diferentes na companhia podem exigir soluções diferentes. O que não muda é todo mundo olhar e falar: vamos entender qual é o nosso problema, qual é o nosso alvo. A partir daí, testar frameworks para ver qual melhor se aplica. Vê-se muito gente pegando um framework e forçando um quadrado no redondo, chamando coisa operacional de estratégica, coisa tática de operacional. Quando o resultado não dá certo, culpam o framework, mas na origem já estava errado.

Há também a tranquilidade que um framework traz para quem está começando: alguém já trilhou esse caminho, você não precisa reinventar do zero. Isso é confortável. Cada framework resolve algum problema específico. Mas chega um momento em que você tira a rodinha da bicicleta. A rodinha te ajudou a não ralar o joelho, mas chega um ponto que você tira, porque senão não fica nem mais divertido. Frameworks são pontos de partida, não pontos de chegada.

É muito comum que, no dia a dia, a gente comece a atacar um problema e, depois de uma ou duas semanas, perceba que fez uma combinação do framework A com o framework B e virou natural. O mais legal é que você não está preso à técnica, está usando a técnica e aplicando. Às vezes cria-se uma tese nova, uma forma de aplicar que ninguém tinha feito. Mas a gente fica se prendendo a narrar o que do ponto de vista teórico usou, e perde o sentido. O legal é ir juntando as coisas e aplicando no dia a dia.

Se você se apaixona pelo framework, vai viver em função de ter o framework aplicado, acreditando que ele é a panaceia universal que vai resolver todos os problemas da organização, desconsiderando particularidades de área, níveis de maturidade, características específicas. Vai perder a oportunidade de usar uma salada de outros ingredientes, outros temperos, para fazer uma receita que seja sua. É importante se apaixonar pelo problema que o framework pode ajudar a resolver, não pelo framework em si.

Quando alguém chega com uma demanda de impor um framework como fim e não como meio, o primeiro passo é entender para quais fins esse meio vai funcionar. Se já foi definido qual é a técnica, procure entender quais problemas ela vai se aplicar, porque vai ter mais chance de sucesso. Tente aproveitar esse meio para mostrar que outros problemas não serão resolvidos por essa técnica. Não fique batendo de frente simplesmente com o meio porque alguém definiu. Tenha empatia para entender o porquê de aquilo ter vindo. É sobre adaptação: a ferramenta já está aí, como posso melhor usá-la nos problemas onde ela se aplica?

Tem briga que a gente só evolui a partir dela. Se já foi definido, já foi aprovado, não vamos reabrir a caixa da discussão. Pega a sua não concordância e vai trabalhar junto. Faz engenharia reversa a partir daquele ponto: quais problemas essa ferramenta atende? O lead time tá ruim, a experiência do cliente não tá sendo considerada, precisa de mais eficiência operacional. No final das contas, é trabalhar orientado ao problema que a gente quer resolver. Como líderes de transformação, a gente vai ter que trazer isso pra mesa, por mais que já tenha uma solução desenhada.

O lance de brigar se a ferramenta A é boa ou a ferramenta B é ruim é puro desperdício de energia. É um operador de desperdício potencial absurdo, porque você vai gastar um tempão tentando chegar na definição do sexo dos anjos, que sabemos que não existe. Um caminho que costuma funcionar bem é considerar elementos adicionais ao framework que já está sendo usado, entender o que pode extrair de outros frameworks parciais. Sem ofender ninguém e sem criar briga corporativa, ajuda a própria corporação a ampliar o espectro. Toda decisão é super bem intencionada, nem sempre é tomada da melhor forma, mas a gente pode ajudar quem tomou a decisão a ampliar o horizonte.

Outro ponto importante: será que a pessoa que emplacou o framework realmente conhece a fundo a técnica, ou uma vez que venceu, o objetivo dela agora é comprovar que a tese trouxe os resultados? Se a pessoa não conhece a fundo, pode adaptar, usar o framework mas não na forma pura. Se o resultado estiver vindo, está todo mundo feliz, inclusive o stakeholder que vai estar celebrando como aquele framework trouxe o resultado esperado. É um exercício de adaptação e comunicação, porque no final é sobre o resultado que você vai atingir.

Como agentes de transformação, às vezes é preciso aceitar as coisas como elas são, por um lugar de saúde mental. Impuseram um meio como fim, tá bom, é isso que tenho hoje. Como começo pelo que tem, como evidencio que não tá bacana, e cuido da minha saúde mental para lidar com essa frustração.

Existem elementos importantes para evocar. Tem brigas que não vale a pena brigar porque você não vai ganhar. Você vai puxar um revolver calibre 22 e vai ter uma artilharia antiaérea na sua frente. As crenças não são iguais. Primeiro, você pode estar errado e aquele framework pode estar ajudando. Segundo, você pode não ter a consciência da diferença que pode fazer dentro da organização. Será que a melhor diferença que você pode fazer é comprando uma briga e parecendo um maluco, ou entendendo a realidade do terreno e descobrindo maneiras de se adaptar? O agente de transformação precisa ter consciência do papel que pode exercer e encontrar as melhores ferramentas para gerar impacto positivo, não necessariamente dizendo não e brigando com cada decisão que não concorda.

Imagine um contexto em que a janela de entrega era de um ano e, com um ciclo de planejamento trimestral, você consegue coordenar 20 times e em três meses tem uma promessa de entrega. Sair de 365 dias para 30, 60, 90 é maravilhoso do ponto de vista de produtividade. Não é um julgamento seu dizer que isso não trouxe melhoria. Guarda esse julgamento para você.

Depois que você começa a capturar isso, observa quanto acontece de pessoas tão apaixonadas pelo framework que quase viram uma seita. Dentro dessa seita, o único objetivo muitas vezes não é chegar no resultado, é comprovar que estão certas em relação ao framework. Não faz leitura de público. Você está num evento falando de agilidade, vende seu peixe. Agora, vai falar com o seu C-Level, não faz a narrativa explicando como o framework foi fundamental. Explica o resultado. O idioma desse público não é um idioma de framework, é um idioma de resultado, de outcome. Você pode entrar com algumas pitadas, mas o resultado fala sozinho.

Ninguém vai bater palma pro livro de receita que você usou para fazer a comida. Eles vão lembrar da comida que comeram, se estava boa ou não. O resultado tem voz para falar sozinho.

Raramente se usa uma receita pura. Já se pegou de tudo, de Safe, de Lean, de um monte de coisas. Quebrou cabeça uma série de vezes. É muito sobre o ponto de partida para em algum momento chegar à conclusão de que fez sentido usar determinadas partes e não outras, ou experimentar num contexto pequeno uma outra coisa.

A discussão que falta muitas vezes é o grau de profundidade da transformação. É a analogia de largura versus profundidade, amplitude versus profundidade. Você está gerando de fato o resultado? Está chegando na experiência do cliente, na eficiência operacional, no resultado financeiro? Para isso, tem discussão profunda que vai tocar no status quo de um monte de gente. O framework não vai ter todas as respostas porque cada empresa tem seus pormenores. Ficar na discussão do design organizacional ou do design do funil é uma discussão muito rasa.

Um exemplo concreto: na Serasa, a dor não estava na qualidade do produto de score, estava no tempo de entrega. O processo envolvia 15, 20 áreas diferentes, cada uma correndo para sua meta local, como uma corrida de 4 por 100 em que a pessoa terminava e a outra nem estava lá para receber o bastão. Tentaram trazer frameworks, post-its no quadro, nada funcionou. Até o dia em que fizeram uma narrativa simples: entregar score é como fritar batata em saquinho. Quem puxa o dado está plantando batata, quem faz governança está selecionando a batata, se o caminhão não chega na fábrica certa não vai ter preparação. Na hora que aplicaram essa narrativa, todo mundo comprou. Estavam aplicando vários frameworks, mas narraram de um jeito que todo mundo entendia. Às vezes cabe fazer a leitura de quem é o público e adaptar a linguagem. Quem domina a narrativa domina a história.

O movimento foi muito inteligente: todos ficaram menos preocupados em botar um rótulo de framework A, B ou C. Passaram a entender: temos esse desafio, qual é a melhor maneira? É muito mais Sun Tzu do que Jeff Sutherland ou David Anderson. Entende o terreno, adapta, movimenta as tropas para o lugar certo na hora certa. Diminuíram a carga de esforço, o resultado foi mais simples, e viraram o jogo.

Há uma frase que muita gente da área de saúde usa: conheça todas as teorias, domine todas as técnicas, mas lembre que ao tocar numa alma humana, você só precisa ser uma outra alma humana. Se você não conhece as técnicas e não está de coração aberto para evoluir a partir delas, ficar defendendo o seu, não vai adiantar.

No contexto atual de crise, com funding caro e taxa de juros em 13%, se você não tiver um ROE de projeto acima de 20%, é simples fazer a conta. Tem gente defendendo ferramenta, defendendo um framework específico, mas isso não gera resultado. É um índice de corte. Se a adoção de um framework fosse garantia de sucesso, não teria nenhuma empresa mal. Não é assim que funciona.

Quando se pensa em escalar a transformação, a primeira pergunta é sempre o porquê, pra quê. Qual é o objetivo, aonde você quer chegar? Se me disser para onde quer chegar, posso avaliar os caminhos. Se o objetivo é só vender para o mercado que agora você é digital, vai pelo marketing. Arranje um bom marqueteiro. Você não vai mudar porcaria nenhuma, mas vai vender bem. Transformação digital de verdade exige entender onde você quer chegar.

Conheça o teu ambiente, conheça o teu terreno, saiba o que faz sentido. Se forçar algo de forma revolucionária, a tendência é ter muito mais resistência do que trabalhando de forma evolucionária. É muito mais difícil conseguir gente para queimar colchão contigo do que conseguir gente para te ouvir no cafezinho e testar algo em pequena escala.

Sobre amplitude versus profundidade: imagine que transformou três unidades de negócio, mas tem outras cinco que não foram transformadas e já passou um ano. A pressão sobre amplitude vai acontecer. Você vai ter que entender que, nesse momento, faz sentido acelerar um movimento de amplitude. A questão é: qual é o grau de consciência sobre a profundidade que você gostaria de dar versus a amplitude que está sendo obrigado a dar? No mínimo, o agente de transformação precisa trazer o trade-off pra mesa, os riscos. Você não vai decidir sozinho, vai ser parte de um comitê. É a essência do disagree and commit: discorde, mas se comprometa.

Sobre o momento atual, a gente viveu uma onda em que foi difícil doutrinar executivos de que na discussão entre eficiência e eficácia, a gente tinha que trabalhar focado na eficácia. Muitas empresas chegaram num nível de eficácia bacana. Dado o contexto econômico agora, os resultados foram para baixo. Não foi por causa da discussão eficiência versus eficácia, mas dado a pressão de resultado de curto prazo, muitas empresas estão buscando eficiência, falando de expand layers, coisas que vão destruir muito do que foi construído. Adianta ficar batendo de frente? Não. A empresa precisa entregar o resultado de curto prazo. Argumente, mas vai acontecer. Pensa pelo lado bom: essa onda vai passar. Daqui a pouco você vai ser triplamente necessário para voltar a construir tudo aquilo que foi destruído. E, como já fez um processo com lições aprendidas, vai fazer mais rápido na retomada.

Cuidado com a conta maldita de quanto custa por pessoa. Um squad é mais caro que a lógica de projeto e alocação via planilha, mas a probabilidade de um squad com interações mais frequentes gerar mais receita ao longo do tempo e estar mais perto do valor é maior do que um projeto que vai levar um ano e não vai entregar nada. Se não tem dinheiro para manter um squad, priorize uma das demandas, faça a escolha difícil, e os três devs tendem a entregar mais rápido.

Há uma frase de uma diretora financeira: um problema que a gente vai viver daqui um ou dois anos é que, quando a gente entra no modo crise, o CFO assume o leme do barco. Normalmente a área de produtos e marketing puxa o financeiro. Quando entra no modo crise, entrega a chave do cofre para o CFO defender o fluxo de caixa. Daqui a dois anos, a gente vai pagar o preço desse tipo de escolha. Faz parte, mas não podemos esmorecer.

Frameworks são o começo, não o final. À medida que aprende, tem que estar preocupado em aprender e evoluir. Naturalmente, com esse aprendizado, mecaniza a parte onde repetir tem valor e cria um espaço infinito de expressão do que for melhor no contexto. Respeite o framework como algo que te ajuda a começar, mas não se prenda a ele como a única coisa que vai te levar para onde você quer. Adaptação é sempre importante, e humildade também. Nem todas as brigas a gente vai ganhar. Entenda quais valem a pena lutar. O que você não pode fazer é não se apresentar pro jogo. A pior coisa de todas é não jogar.

Seguir um framework é a base da ciência. O método científico é construído em não reinventar todos os tijolinhos do zero. Framework faz parte. O problema principal é quando você delega a sua carreira e a sua identidade para ser um aplicador de framework, porque a IA vai te substituir nesse ponto. O trabalho repetitivo de aplicar um framework vai passar. Não terceirize a sua carreira pro framework preferido que você tenha. Pode ser framework de produto, de agilidade, de marketing. O problema segue o mesmo. Você é mais do que isso.

É sobre saber fazer perguntas, fazer leitura de cenários, ler. Você vai ter uma caixa de ferramentas, mas se não souber fazer perguntas, a IA vai substituir. Às vezes a pergunta é para você mesmo, no seu momento de reflexão: o que o cenário está pedindo nesse momento? Como adapto o meu idioma? Aprenda o idioma. Você pode fazer a melhor tese do melhor framework para o melhor problema, mas se estiver usando o idioma chinês numa sala que ninguém fala chinês, ninguém vai entender. Adapta o seu idioma para a forma como as pessoas vão entender, não da forma como você quer que elas entendam. Não venda o framework, venda o resultado. E o resultado, nesse momento, pode ser redução de custos para otimizar a P&L. Adapte seu idioma, aprenda a fazer perguntas. Às vezes as perguntas não são só para os outros, são para você mesmo: será que eu estou certo mesmo? Talvez o melhor seja montar grupos de alinhamento. A última mensagem é: aprenda a fazer perguntas e aprenda a falar no idioma que as outras pessoas vão te entender.