Descentralizando a Tomada de Decisões com Shawna Martell e Dan Fike
- Aisha Washington
- há 2 horas
- 8 min de leitura
As organizações de engenharia frequentemente dizem que querem que as equipes atuem de forma autônoma. Na prática, as decisões ainda sobem na hierarquia, ficam paralisadas em reuniões ou dependem de qual arquiteto sênior estiver disponível. Shawna Martell e Dan Fike descrevem um modelo diferente desenvolvido na Cartek: estabelecer uma estratégia de engenharia explícita e, então, capacitar líderes técnicos de confiança — chamados Navigators — para ajudar as equipes a aplicá-la.
A abordagem deles trata a descentralização como algo mais do que delegar autoridade. As pessoas precisam de princípios compartilhados, contexto local suficiente, acesso a conselheiros experientes e uma maneira de questionar ou aprimorar a estratégia. Quando essas peças funcionam juntas, colaboradores individuais podem tomar decisões importantes sem obrigar que toda questão passe pela gestão ou por uma função centralizada de arquitetura.
Por que a Autonomia Exige uma Estratégia de Engenharia
Martell e Fike relacionam o programa Navigator a um problema recorrente: os engenheiros queriam orientações mais claras. Sem uma estrutura acordada, as equipes não conseguiam avaliar de forma confiável opções técnicas concorrentes nem saber quais prioridades organizacionais deveriam prevalecer.
O resultado não era necessariamente uma engenharia ruim. Era uma engenharia inconsistente. Duas equipes diante de trade-offs semelhantes poderiam chegar a conclusões incompatíveis porque cada uma usava um padrão diferente, em grande parte implícito. Os mesmos debates ressurgiam repetidamente, consumindo tempo sem produzir conhecimento organizacional duradouro.
Aprovar centralmente cada escolha teria resolvido a inconsistência ao criar um gargalo. Em vez disso, a Cartek buscou tornar amplamente disponível a base para boas decisões. Sua estratégia de engenharia tornou-se um ponto de referência compartilhado — uma explicação documentada de como a organização avalia trade-offs e do que tende a valorizar em determinadas circunstâncias.
De forma crucial, a estratégia surgiu em resposta a engenheiros que pediam contexto. Martell e Fike não a apresentam como uma determinação criada isoladamente por executivos. Seu propósito era dar aos colaboradores confiança para agir, mantendo suas escolhas conectadas a uma direção mais ampla.
Comece pela Realidade, Não por um Cartaz Aspiracional
Uma parte marcante do processo da Cartek foi sua ênfase em documentar como as decisões já estavam sendo tomadas. A equipe não começou descrevendo uma organização futura ideal. Primeiro, examinou o estado atual, incluindo práticas que pareciam inconsistentes ou difíceis de defender.
Esse tipo de arqueologia organizacional importa porque todo grupo de engenharia já possui uma estratégia, mesmo quando ninguém a colocou por escrito. Ela vive em escolhas repetidas: se as equipes otimizam para desempenho imediato ou escala futura, aceitam complexidade operacional para aumentar a flexibilidade ou estendem um sistema existente em vez de criar um novo serviço.
Documentos de design anteriores e registros de decisões de arquitetura podem revelar esses padrões. Um registro útil captura as alternativas consideradas, os benefícios e custos de cada uma e o motivo pelo qual uma opção prevaleceu. Vários registros vistos em conjunto revelam os valores por trás dessas escolhas.
Martell e Fike distinguem esses valores das próprias decisões. Uma decisão diz o que aconteceu em um caso. Um princípio oferece orientação condicional que pode ser aplicada a outro caso — na prática: “Quando estas condições se aplicarem, favoreça esta resposta.” Extrair esses princípios pode exigir revisitar as pessoas e circunstâncias por trás de decisões antigas, especialmente quando os documentos registram um resultado, mas omitem sua justificativa.
Começar honestamente também torna a mudança mensurável. Uma estratégia idealizada pode soar inspiradora enquanto oculta a distância entre política e prática. Uma descrição do sistema real cria uma linha de base a partir da qual a organização pode deliberadamente se tornar melhor.
Navigators Ajudam as Equipes a Ler o Mapa
O nome do programa expressa uma importante divisão de responsabilidades. A estratégia de engenharia funciona como um mapa; os Navigators ajudam as pessoas a interpretá-lo em um terreno desconhecido. Eles contribuem para a estratégia, mas seu papel principal não é emitir um plano mestre nem decidir pessoalmente todas as questões técnicas.
No momento discutido, aproximadamente uma dúzia de Navigators dava suporte a uma organização de engenharia com cerca de 400 pessoas. Eles vinham de diversas disciplinas técnicas, incluindo engenharia de front-end e back-end, confiabilidade e segurança. Suas posições na hierarquia formal variavam: alguns trabalhavam profundamente inseridos nas equipes, enquanto outros atuavam mais próximos da liderança sênior.
A seleção dependia menos do cargo do que de discernimento demonstrado, profundidade técnica e influência. Martell e Fike descrevem uma rede informal que existe paralelamente ao organograma de gestão. Certos engenheiros naturalmente se tornam as pessoas que os colegas consultam quando um problema é ambíguo. O modelo Navigator reconhece e conecta essas figuras de confiança, em vez de pressupor que a autoridade flui apenas pelas linhas de reporte.
Os Navigators precisam ter um contexto substancial sobre os produtos e sistemas ao seu redor. Devem saber quais decisões estão em andamento, reconhecer quando o trabalho entra em conflito com a estratégia e intervir quando uma equipe precisa de ajuda. Isso não significa assumir o controle. Um Navigator pode orientar a equipe durante a análise dos trade-offs, identificar princípios relevantes ou levar uma questão não resolvida ao grupo mais amplo de Navigators.
Eles também transportam informações em ambas as direções. A estratégia ajuda as equipes a tomar decisões locais, enquanto as dificuldades encontradas pelas equipes revelam onde a estratégia está incompleta. Portanto, os Navigators são tanto intérpretes quanto importantes colaboradores para sua revisão contínua.
Aconselhamento Sem um Gargalo de Arquitetura
A Cartek evita intencionalmente fazer de um arquiteto formal a porta de entrada obrigatória para decisões técnicas. Staff engineers podem realizar trabalho de arquitetura quando necessário, mas a organização não quer um cargo permanente que concentre a autoridade de decisão em um único lugar.
Em vez disso, seu modelo se assemelha a um processo de aconselhamento em arquitetura. Um engenheiro pode tomar uma decisão após consultar as pessoas afetadas, colegas com experiência relevante, a estratégia escrita e um Navigator quando necessário. A autoridade permanece distribuída, mas a consulta é esperada.
A estratégia serve como uma fonte coletiva de aconselhamento. Ela fornece até mesmo aos engenheiros menos experientes um padrão com o qual podem testar uma proposta. Por exemplo, pode esclarecer como a organização pondera desempenho em relação à escalabilidade ou custo de manutenção em relação à velocidade de entrega.
Nem toda questão pode ser reduzida a uma orientação universal. Martell e Fike mencionam escolhas como decidir se uma capacidade pertence a um monólito existente ou justifica um novo serviço. Uma organização pode ter uma direção geral sem uma regra precisa o bastante para todas as situações. Nesses casos, a estratégia deve reconhecer a ambiguidade e direcionar os engenheiros a consultas bem fundamentadas.
Isso preserva o discernimento em vez de substituí-lo por burocracia. O objetivo não é codificar todas as respostas futuras. É tornar as escolhas rotineiras mais fáceis, expor as que são genuinamente difíceis e oferecer às pessoas uma maneira consistente de raciocinar sobre exceções.
A Estratégia Deve se Tornar Gradualmente Menos Equivocada
Martell e Fike apresentam a estratégia como um instrumento em evolução, e não como uma doutrina acabada. Os princípios iniciais terão lacunas. Alguns serão amplos demais, enquanto outros podem falhar em condições que seus autores não anteciparam.
As decisões reais fornecem o feedback necessário para aprimorá-los. As equipes comparam uma opção com a estratégia, descobrem onde a orientação ajuda ou deixa de funcionar e relatam essas evidências por meio de seus Navigators. Com o tempo, tanto as decisões individuais quanto a estrutura compartilhada podem se tornar menos equivocadas.
Permitir uma ambiguidade limitada faz parte do desenho. As equipes ainda precisam de espaço para desenvolver “microestratégias” locais adequadas a seus sistemas e restrições. Os Navigators ajudam a garantir que essas abordagens locais permaneçam compatíveis com a direção mais ampla da organização, sem forçar todas as equipes a uma implementação idêntica.
Os relacionamentos dos Navigators entre si fortalecem esse ciclo de feedback. Eles não assumem coletivamente a responsabilidade por todas as decisões, mas podem consultar seus pares quando um problema atravessa domínios. Sua combinação de ampla consciência organizacional e profundo conhecimento especializado é particularmente útil para questões que abrangem segurança, confiabilidade, arquitetura de plataforma e desenvolvimento de produto.
A Descentralização Também É um Sistema de Mentoria
Distribuir autoridade só funciona se mais pessoas aprenderem a exercê-la. Portanto, o papel de Navigator inclui uma responsabilidade implícita de ensinar: como identificar trade-offs, buscar aconselhamento adequado, documentar o raciocínio e decidir com informações incompletas.
Isso é especialmente importante para engenheiros que antes não recebiam confiança para fazer escolhas de alto impacto. Dizer a eles para “assumirem a responsabilidade” é insuficiente se toda proposta relevante acaba sendo anulada posteriormente por um grupo sênior inacessível. Navigators podem tornar o processo de raciocínio visível e apoiar colaboradores, mantendo a decisão próxima do trabalho.
Martell e Fike também separam a perspectiva do Navigator da perspectiva de gestão. Gestores precisam equilibrar pessoas, entregas e execução da equipe. Navigators oferecem julgamento técnico aprofundado e conectam escolhas locais de engenharia à estratégia de toda a organização. As duas perspectivas devem se complementar, em vez de se fundirem em um único papel.
Os candidatos são reconhecidos por sua contribuição já existente e indicados por líderes seniores, em vez de se candidatarem por meio de um processo convencional. Credibilidade técnica, por si só, não é suficiente. Alguém que não esteja disposto a desenvolver outras pessoas ou compartilhar seu julgamento teria dificuldade para cumprir o propósito do programa.
Medindo o Sucesso por Meio de Decisões Melhores
O valor da descentralização aparece em resultados concretos de decisões. Martell e Fike descrevem uma equipe que considerava um novo serviço de plataforma compartilhada para um problema observado em vários domínios. Uma resposta superficialmente razoável poderia ter sido construir uma solução universal e iniciar um longo esforço para obter o acordo de cada parte interessada.
Um Navigator comparou a proposta com a estratégia da organização e concluiu que uma plataforma única para todos não era a direção preferida. Como a estratégia já representava um padrão acordado, o Navigator pôde resolver a questão sem reconstruir todo o argumento do zero.
Isso ilustra uma mudança significativa no ônus da prova. Em vez de defensores tentarem repetidamente persuadir os demais de que uma direção é a correta, a estratégia documentada fornece o ponto de partida. Desvios continuam possíveis, mas exigem uma explicação convincente.
Indicadores úteis de progresso incluem decisões mais rápidas, menos escalonamentos desnecessários, raciocínio mais claro em documentos de design e maior confiança entre os colaboradores. Os sinais qualitativos também importam: os engenheiros devem se sentir menos perdidos, e debates recorrentes devem produzir cada vez mais princípios reutilizáveis, em vez de mais um compromisso temporário.
Como Líderes de Engenharia Podem Começar
Martell e Fike deixam claro que nomear Navigators antes de articular uma estratégia dificilmente funcionará. Sem um mapa compartilhado, indivíduos de confiança podem simplesmente distribuir suas preferências pessoais de forma mais eficiente.
Os líderes podem começar revisando decisões anteriores de arquitetura e documentos atuais de design. Devem identificar trade-offs recorrentes, registrar primeiro os princípios menos controversos e examinar a lacuna entre os valores declarados e o comportamento observado. O desconforto com esse registro é uma evidência útil: ele aponta para práticas que a organização talvez queira mudar.
Uma sequência prática é:
documentar decisões representativas e seus respectivos raciocínios;
extrair princípios condicionais a partir de padrões recorrentes;
identificar áreas em que a prática atual conflita com a direção desejada;
encontrar colaboradores técnicos respeitados que já aconselham outras pessoas;
posicionar essas pessoas onde possam conectar o trabalho local à estratégia organizacional;
revisar a estrutura à medida que decisões reais revelarem omissões ou contradições.
A lição mais profunda é que a descentralização depende de uma infraestrutura para o julgamento. Princípios escritos fornecem consistência, Navigators oferecem contexto e mentoria, e as equipes contribuem com as evidências que mantêm o sistema fundamentado. Juntos, esses mecanismos permitem que a autoridade se aproxime do trabalho sem que a organização se fragmente em direções técnicas incompatíveis.
