Working backwards

O Working Backwards nasceu na Amazon e virou o alicerce de uma cultura que combina obsessão pelo cliente, decisões baseadas em dados, comunicação escrita e disciplina quase teimosa. Não é um manual de PowerPoint, é uma forma de pensar o negócio de fora para dentro e de dentro para fora ao mesmo tempo. No artigo Working backwards eu destrincho cada mecanismo, explico como tudo se encaixa e mostro onde esse modelo funciona, minhas opiniões e por que ele pode ser genial para umas empresas e questionável para outras.

O Working Backwards nasceu na Amazon e virou o alicerce de uma cultura que combina obsessão pelo cliente, decisões baseadas em dados, comunicação escrita e disciplina quase teimosa. Não é um manual de PowerPoint, é uma forma de pensar o negócio de fora para dentro e de dentro para fora ao mesmo tempo. No artigo Working backwards eu destrincho cada mecanismo, explico como tudo se encaixa e mostro onde esse modelo funciona, minhas opiniões e por que ele pode ser genial para umas empresas e questionável para outras.

Mas, além do artigo Working backwards, aqui no blog também temos diversos outros artigos sobre kubernetes, desenvolvimento, gestão, devops, etc. Veja alguns exemplos: Diferenças entre Paradigmas, Axiomas e HipótesesDesenvolver na empresa ou comprar prontoFuja da otimização prematura, entre outros.

O Framework working backwards

O Working Backwards, também traduzido como “De Fora para Dentro”, é um framework de gestão utilizado pela Amazon desde o fim dos anos 90. Ele visa trazer uma mentalidade de gestão, cultura, decisões e alinhamento estratégico baseada em dados e comunicação eficaz. O modelo junta conceitos clássicos de administração, ideias emprestadas de outros autores e mecanismos criados internamente pela Amazon ao longo de décadas.

Esquema explicativo do framework Working backwards.

O objetivo é simples na teoria, mas profundo na realidade: criar um modelo mental e uma linguagem comum capaz de alinhar toda a organização ou entre organizações. O framework foi feito para qualquer empresa de qualquer tamanho, segundo a Amazon. Eu, particularmente, não concordo, por achar que nenhuma empresa precisa de framework à priori. Isso é se apaixonar pela solução e não pelo problema. Porém, é claro que é um modelo muito maduro e válido para muitas empresas.

Obsessão pelo Cliente

Todo o framework nasce de um princípio: vestir a pele do cliente. Não é para fazer tudo o que ele pede, mas pensar como ele pensa. Isso orienta absolutamente tudo no framework. O Balanced Scorecard, em contraponto, coloca as finanças no centro e o cliente em segundo lugar. Essa é uma diferença fundamental e um reforço que me faz acreditar que não é válido para qualquer empresa.

Agora, é claro que, mesmo para o modelo da Amazon, as finanças continuam com um destaque, mas não adianta ganhar dinheiro ignorando o cliente: isso não é sustentável! Há de se ter um equilíbrio inteligente.

Flywheel

Essa ideia veio de Jim Collins, no livro Good to Great baseado na pergunta: “No que sua empresa realmente é boa?”. Flywheel é o mecanismo que alguns carros têm de reaproveitar a energia gerada pelo seu movimento gerando ainda mais movimento. A lógica no modelo da Amazon é: foque no que é bom. Depois, crie estruturas secundárias que cooperem para que o foco seja ainda melhor. Isso me lembra as separações de domínio que normalmente fazem quando se pensa em Domain Driven Design (DDD): domínios core, domínios genéricos e de suporte, como comentei no artigo Domain Driven Design Estratégico.

Princípios de Liderança

Os princípios de liderança vêm, de certa maneira, de uma especialização da fundação do posicionamento estratégico: missão, visão e valores. Os princípios são conjuntos de frases que servem de drivers que orientam todas as ações estratégicas da empresa. No modelo tradicional, por mais que hajam valores, nem sempre há conexão com as ações práticas no negócio. A Amazon, por exemplo, trabalha com 16 princípios. Veja alguns: “Invent and Simplify”, “Hire and Develop the Best” e “Insist on the Highest Standards”. E continue lendo para entender como os princípios se conectam com as ações práticas.

Bar Raiser

Nesse modelo temos a figura do Bar Raiser, que é um profissional treinado para auxiliar no recrutamento, avaliando a afinidade do candidato com os princípios. Após as entrevistas técnicas e comportamentais se iniciam as entrevistas culturais. Nesse momento o objetivo é saber como o candidato está fit com cada um dos princípios e o que a vaga exige. Por um lado isso aumenta o tempo do processo de recrutamento mas reduz os problemas de afinidade, além de ser um impulsionador natural do framework.

Tenets

Os princípios são grandes drivers, já o Tenets são direcionadores locais, internos da squad/tribo. Eles devem ser coerentes com os princípios, mas dando autonomia para as áreas. Os tenets têm por objetivo: orientar decisões, estruturar a priorização, evitar ruídos e dar autonomia de fato. Um possível exemplo de Tenet: “privacidade é mais importante do que conveniência”. Sob outra ótima, eles podem se assemelhar a ADRs como comentei no artigo Architecture Decision Record.

Comunicação Baseada em Papers

Esse é um dos pontos mais famosos e polêmicos do framework: não devemos usar PowerPoint, devemos usar Word. O framework orienta que os documentos sejam escritos em até 6 páginas e que não se utilize slides por alguns motivos: (1) isso mantém o foco no conteúdo e não na forma; (2) evita o risco de um bom palestrante suplantar um tímido excelente no que faz; (3) uma slide pode sempre precisar de um apresentador explicando, portanto, anos depois ela pode perder o sentido. Já o documento textual carrega todas as informações necessárias escritas nele.

Além disso, o framework orienta que o documento seja lido durante a reunião e não necessariamente antes dela. A ideia é que eu não sou dono do tempo do colega, portanto, o timebox da reunião resolve todo esse problema.

Por fim, o documento deve ser ancorado em fatos e dados. A seguir comentarei sobre as métricas que devem embasar e evitar ao máximo as opiniões antes das evidências e comprovações.

Métricas

O Working Backwards é fundamentalmente orientado a dados. As empresas que adotam o modelo passam a conviver com um volume grande de indicadores revisados semanal, mensal e trimestralmente. As métricas se dividem em dois tipos.

As Output Metrics são resultados sobre os quais a empresa tem pouca capacidade de interferir. Um exemplo é o NPS. Já as Input Metrics são aquelas sobre as quais os times podem agir e que geram os Output Metrics. Se usuários ficam frustrados com lentidão num home broker, por exemplo, a métrica de desempenho é afetada. Essa métrica, por sua vez, por impactar em aumento de detratores e consequentemente em NPS.

Reuniões de Atualização

As rotinas periódicas existem para realinhar, corrigir rota e garantir que os temas essenciais não se percam com as complicações do dia-a-dia. O WBR (Weekly Business Review) é mais tática e detalhada. O MBR (Monthly Business Review) analisa tendências um pouco mais amplas. Por fim o QBR (Quarter Business Review) faz uma visão macro do negócio, focando em outputs estruturantes e suas causas.

Planejamento Anual

O Framework trabalha com uma estruturação estratégica baseada em documentos denominados Operational Plans. Eles são estruturados em duas partes, o OP1 e OP2.

O OP1 nasce nas áreas de negócio. Traz a situação atual, o futuro desejado, as necessidades de recursos, riscos, orçamentos e potenciais OKRs. É uma visão bottom-up. Já o OP2 consolida tudo. A direção ajusta inconsistências, conecta as peças e garante coerência estratégica. A ideia não é reescrever, mas garantir alinhamento entre os diferentes OPs, ajustes e complementos.

Quando o OP1 sugere novos produtos, entra em cena o PR/FAQ (Press Release / Frequently Asked Questions). Essa ferramenta é uma simulação do futuro: escreve-se um press release explicando a solução como se já estivesse lançada em uso pelo usuário final, e um FAQ expondo dúvidas duras sobre cliente, viabilidade econômica, riscos, diferenciação e propósito, etc.

Cultura de Aprendizagem

O Working Backwards não condena o erro. Ele o trata como base da melhoria contínua, até porque não existe inovação sem falha. Mas isso não significa que se está promovendo o erro, mas sim que ele não seja à toa: que a empresa seja capaz de absorver o que há de melhor nele. O importante é o mecanismo de aprendizado posterior. Note que essa visão se conecta fortemente com o SRE do Google, especialmente com Error Budget e Postmortem, mecanismos que você já explorei no artigo sobre Engenharia de Confiabilidade.

Conclusão de Working backwards

Finalmente, o Working Backwards é apenas um conjunto coerente de mecanismos que funcionam bem quando existe maturidade, disciplina, clareza estratégica e vontade real de tomar decisões difíceis. Assim, empresas que tentam copiá-lo sem cultura escrita, sem rigor analítico ou sem coragem de dizer não para si mesmas podem fracassar. Já as que adotam o modelo com consciência ganham uma linguagem comum, uma forma estruturada de pensar produtos e uma organização que aprende mais rápido do que erra.


Thiago Anselme
Thiago Anselme - Gerente de TI - Arquiteto de Soluções

Ele atua/atuou como Dev Full Stack C# .NET / Angular / Kubernetes e afins. Ele possui certificações Microsoft MCTS (6x), MCPD em Web, ITIL v3 e CKAD (Kubernetes) . Thiago é apaixonado por tecnologia, entusiasta de TI desde a infância bem como amante de aprendizado contínuo.

Pacote Full Stack