Leitura: Agile IT Organization Design

Um resumo completo do livro Agile IT Organization Design escrito por Sriram Narayan.

Nota 01: Qualquer artigo que leve mais de uma semana de pesquisa, organização e escrita agora está atrás de uma paywall. Contribua.

Nota 02: Esta é uma tradução adaptada por IA de um resumo do livro que li e escrevi originalmente em inglês. Para acessar o artigo original, clique aqui.

E se o maior obstáculo para a agilidade da sua empresa não for a tecnologia ou as pessoas... mas o próprio jeito como a organização foi desenhada?

Essa é a provocação logo de cara no livro Agile IT Organization Design, do Sriram Narayan.

E não, não é mais um daqueles livros que explicam cerimônias ágeis ou frameworks passo a passo.

O foco aqui é outro: como redesenhar a estrutura da sua área de TI para que a agilidade deixe de ser uma prática isolada e passe a fazer parte da forma como a empresa realmente funciona.

Com histórias práticas, reflexões diretas ao ponto e uma linguagem bem clara, o autor desafia várias ideias que a gente costuma aceitar sem pensar muito, sobre projetos, equipes, orçamentos e até o papel da TI nas organizações.

É uma leitura simples, mas cheia de ideias fortes.

Ótima para quem está vivendo uma transformação digital ou liderando times de tecnologia no mundo real.

Até o momento, não há uma versão em português do Brasil do livro Agile IT Organization Design: For Digital Transformation and Continuous Delivery de Sriram Narayan.

Vamos fundo?

Nós iremos cobrir hoje:

• 3 motivos para ler o livro

• 4 ideias chave do livro

• 6 lições do livro

• Visão geral do livro

• Uma revisão do livro, capítulo por capítulo

3 Motivos para Ler Agile IT Organization Design

Agilidade, de Verdade

O livro muda o foco da agilidade de algo que acontece só dentro dos times para algo que depende de como a empresa inteira é estruturada. Você vai repensar organogramas, formas de financiamento e até os papéis dentro da organização. É uma visão mais realista do que significa ser ágil, muito além dos sprints e das reuniões diárias.

De Projetos para Produtos

A estrutura tradicional de projetos está nos atrasando, segundo o autor. O livro explica o porquê disso e defende o modelo de times estáveis, focados em resultados, que entregam valor continuamente e aprendem ao longo do caminho. Isso faz muito mais sentido dentro da realidade do desenvolvimento de software e inovação.

Um Olhar Pé no Chão

Nada de buzzwords vazias. O livro fala sobre o que realmente funciona dentro das empresas. A escrita é prática, honesta e baseada em experiências reais. Em vários momentos, você vai se pegar concordando, rindo, ou até repensando completamente como a estrutura da sua organização funciona hoje.

4 Ideias-chave de Agile IT Organization Design

Equipes Permanentes

As equipes devem ser permanentes, multifuncionais e focadas em resultados reais de negócios. Isso evita as transferências intermináveis e dá às equipes verdadeira responsabilidade. A entrega deixa de ser um esforço pontual e passa a ser uma evolução contínua.

Valor em vez de Previsibilidade

O sucesso não é sobre cumprir prazo; é sobre resolver os problemas certos. O livro redefine o desempenho ao focar no valor entregue, não nos planos concluídos. Isso ajuda as equipes a saírem de uma mentalidade de medo do fracasso e passarem para um aprendizado contínuo por meio da entrega.

Motivação Intrínseca

A agilidade cresce onde as pessoas são confiadas e inspiradas. Organizar para autonomia, mestria e propósito libera uma melhor colaboração. O que você precisa não são sistemas baseados em permissão, mas ambientes que incentivem a iniciativa.

Design Organizacional como Alavanca

Como sua empresa é estruturada molda como as pessoas se comportam. Ferramentas ágeis não vão corrigir um sistema quebrado. O livro mostra como um design organizacional inteligente pode liberar a agilidade que os métodos sozinhos não conseguem alcançar.

6 Lições Principais de Agile IT Organization Design

Desenhe ao Redor das Pessoas

As equipes funcionam melhor quando são confiadas, não micromanageadas. Crie ambientes que apoiem autonomia, segurança e propósito. A forma como as pessoas se sentem no trabalho molda o desempenho delas.

Conserte a Estrutura, Não as Pessoas

A maioria dos problemas não é sobre comportamentos ruins — é sobre sistemas desalinhados. Quando você ajusta papéis, responsabilidades e incentivos, as pessoas naturalmente melhoram. Não culpe os indivíduos pelos resultados que foram desenhados no sistema.

Valorize o Progresso em vez dos Planos

Perseguir a previsibilidade leva à rigidez. Foque, em vez disso, em melhorias pequenas e contínuas. Entregue algo real, aprenda com isso e adapte-se no caminho.

Trabalhe de Forma Aberta

Acesso, transparência e ferramentas compartilhadas importam mais do que pensamos. Quando as equipes veem o que as outras estão fazendo, elas colaboram mais rápido e inteligente. Abra sempre, a menos que haja uma razão clara para não fazer isso.

A Estrutura Molda a Cultura

A cultura não é criada por slogans — ela flui de como as decisões são tomadas, quem possui o quê e como as equipes interagem. Desenhe sua organização intencionalmente, e a cultura seguirá.

Deixe as Métricas Apoiarem, Não Controlarem

As métricas devem guiar conversas, não dirigir medos. Use-as para aprender, não para punir. As métricas certas são aquelas que ajudam as equipes a melhorar — não as que as fazem esconder.

Visão Geral do Livro

E se o verdadeiro motivo pelo qual sua transformação digital não está funcionando não for a tecnologia... mas sim a forma como os times foram estruturados?

Nota 01: Qualquer artigo que leve mais de uma semana de pesquisa, organização e escrita agora está atrás de uma paywall. Contribua.

Nota 02: Esta é uma tradução adaptada por IA de um resumo do livro que li e escrevi originalmente em inglês. Para acessar o artigo original, clique aqui.

Essa é a ideia, meio silenciosa mas bem provocativa, que guia todo o livro Agile IT Organization Design, do Sriram Narayan.

Não é um livro pra te ensinar a fazer standups melhores ou a usar o Kanban certinho.

O autor dá alguns passos pra trás e faz uma pergunta maior: como sua organização de TI deveria ser desenhada se você realmente quer que a agilidade funcione?

A resposta começa com uma ideia simples, mas que muda tudo: desenvolvimento de software não é um processo de produção, é um processo de design.

Parece coisa de sala de aula, mas olha só o impacto disso.

Na indústria, previsibilidade é prioridade. Já no mundo digital, com produtos e sistemas antigos sendo refeitos o tempo todo, tudo é incerto.

Você experimenta, aprende e ajusta.

Se sua empresa foi construída pra controlar e prever tudo, é bem possível que ela esteja matando justamente o que mais precisa agora: resposta rápida às mudanças.

Narayan também bate forte no modelo tradicional de projetos.

Aquele em que a gente monta um time temporário pra entregar algo com escopo fixo e depois dissolve o grupo quando termina.

Segundo ele, é aí que as transformações digitais morrem.

O conhecimento vai embora, a responsabilidade se perde, e o time nunca fica junto tempo suficiente pra melhorar de verdade.

A proposta dele?

Times multidisciplinares, estáveis e com responsabilidade total — não só por entregar um produto, mas por cuidar dele, evoluir com ele e aprender com os usuários.

Essa virada, de estruturas focadas em atividades pra estruturas focadas em resultados, é a base de todo o resto.

É o que permite dar autonomia sem criar bagunça, porque cada um sabe claramente pelo que é responsável.

Mas ele avisa: autonomia sozinha não resolve.

Tem que vir junto com alinhamento. Os times não podem sair correndo em direções diferentes. Precisam de um propósito comum, direção clara e visibilidade de como o trabalho deles conecta com o todo.

O livro também vai além das conversas comuns sobre Agile. Narayan fala de orçamento, RH, layout de escritório e até microagressões na comunicação — tudo isso com o olhar voltado pra agilidade.

Por exemplo: ele critica os modelos tradicionais de finanças, que separam CapEx e OpEx de forma tão rígida que acabam separando o desenvolvimento da operação — o oposto do que o DevOps tenta fazer.

Até o jeito de contratar muda. Em vez de contratar por cargo — testador, desenvolvedor, analista — ele propõe contratar por habilidade.

Equipes ágeis funcionam melhor quando as pessoas são "T-shaped", com profundidade em uma área, mas abertas a colaborar em outras.

Títulos de cargo, ferramentas isoladas e hierarquias antigas só atrapalham.

Até o design do escritório entra na conversa.

Em vez de baias infinitas ou ambientes abertos barulhentos, ele sugere layouts flexíveis, pensados pro time, equilibrando bem visibilidade e privacidade.

E sobre trabalho remoto?

Nada de ideologia.

Ele é prático: às vezes ajuda, às vezes atrapalha.

O importante é ser intencional.

O que faz esse livro se destacar é o quanto ele é pé no chão.

Sem hype, sem buzzwords, sem fórmula mágica.

Só conversa real de quem já viu organizações por dentro e sabe o que trava tudo.

Ele usa exemplos bem vivos — como o lançamento desastroso de um site de saúde, uma equipe de testes escondendo bugs pra ganhar bônus, ou uma empresa discutindo política de home office no fórum interno — pra mostrar como cultura, estrutura e sistemas se misturam de jeitos surpreendentes.

Quando chega no final, dá pra ver que o assunto já saiu da TI faz tempo.

O que está em jogo é repensar como as organizações funcionam, com mais confiança, propósito e adaptação.

Narayan não promete que vai ser fácil.

Mas ele deixa claro: o problema não é o Agile em si.

É a forma como a gente enfiou o Agile dentro de uma estrutura ultrapassada.

Se o seu time vive atolado em reuniões inúteis, se o Agile parece mais teatro do que prática, ou se a transformação digital está andando com o freio puxado mesmo com todas as ferramentas certas… esse livro talvez traga a virada de perspectiva que estava faltando.

Não é um manual.

É um espelho.

E às vezes, é exatamente disso que a gente precisa.

Capítulo 1 – Contexto

O livro começa direto ao ponto. Sriram Narayan mostra que, apesar das práticas ágeis já terem se espalhado bastante no desenvolvimento de software, levar a agilidade para toda a organização de TI — e ainda fazer isso de forma alinhada aos objetivos do negócio — continua sendo um baita desafio.

Segundo ele, ser ágil de verdade não tem a ver só com entregar mais rápido ou com ter boas práticas de engenharia.

O que falta, na real, é agilidade organizacional: a capacidade interna de se adaptar, colaborar e reagir às mudanças entre áreas, departamentos e funções.

Uma agilidade que apoia não só a TI, mas a empresa como um todo.

Logo nesse começo, o autor apresenta uma diferença importante: ele separa a TI em dois blocos — TI-B (de Build, construção e operação de sistemas) e TI-I (Infraestrutura e operações).

O foco do livro está na TI-B: times responsáveis por criar e manter sistemas internos, plataformas digitais e serviços que fazem a empresa funcionar.

Narayan destaca que, nas grandes organizações, a TI ainda vive separada do negócio.

E mesmo com todo o discurso sobre DevOps e integração, diferenças culturais e estruturais continuam travando essa conexão.

Ele também fala sobre a famosa shadow IT, quando as áreas de negócio começam a contratar ferramentas SaaS por conta própria ou usam nuvem sem passar pela TI interna.

Ao invés de enxergar isso como uma rebeldia, Narayan vê como um sinal: o relacionamento entre TI e negócio precisa melhorar. E urgente.

Esse capítulo é interessante porque conecta o papo de transformação digital com a ideia de agilidade organizacional.

Criar um app bonito ou lançar uma campanha digital não é transformação.

Transformação mesmo exige repensar toda a jornada do cliente — e isso só acontece quando as áreas colaboram de verdade, com metas compartilhadas e estruturas que permitem adaptação.

Ele também critica o modelo de TI bimodal (aquele do Gartner que divide entre “lento e seguro” e “rápido e ágil”) e o sistema de operação dupla do Kotter.

Narayan mostra que o foco aqui é outro: tornar a tal “TI rápida” uma realidade — e não só um discurso bonito.

O capítulo termina com um mapa do livro: a proposta é explorar o design organizacional da TI por vários ângulos — estrutura, cultura, operação, política interna e até o espaço físico — pra ajudar líderes a construir organizações realmente ágeis.

Capítulo 2 – O Credo Ágil

Esse capítulo vai direto na essência do que significa ser ágil — e mostra por que isso vai muito além de uma simples metodologia de desenvolvimento.

Narayan começa lembrando o Manifesto Ágil e chama atenção pra um detalhe curioso: só um dos quatro valores fala diretamente de software.

Na real, os valores do manifesto — como valorizar pessoas e interações, soluções funcionando, colaboração com o cliente e resposta a mudanças — servem pra muito mais do que apenas os times de desenvolvimento.

Por isso, se a estrutura e a cultura de uma organização batem de frente com esses princípios, dificilmente ela vai alcançar agilidade de verdade.

Em outras palavras: Agile não é só coisa de desenvolvedor. Precisa influenciar a forma como toda a TI funciona — desde o design da organização até o jeito como o trabalho acontece no dia a dia.

Colocando os valores em prática

Pra tirar isso do papel, o capítulo traz exemplos simples. Um deles mostra um desenvolvedor e um testador resolvendo um bug juntos, em tempo real — sem abrir chamado, sem burocracia.

Isso é o espírito ágil: resolver logo, conversar, colaborar.

Outro exemplo fala de como as demonstrações frequentes de produto ajudam a receber feedback e ajustar o escopo, sem medo de mudar o plano. Isso é colaboração com o cliente no lugar de contratos rígidos.

Esses não são só ajustes de processo. São mudanças culturais.

O Agile aqui é visto como uma mentalidade, que aparece no jeito como as pessoas se tratam, como resolvem problemas, como tomam decisões em toda a TI.

Entrega contínua, DevOps e cultura

Depois, o autor amplia o papo: princípios ágeis precisam estar presentes também no processo de entrega.

A entrega contínua garante que o software esteja sempre pronto pra ser lançado. Mas quem torna isso possível é o DevOps — unindo desenvolvimento e operação numa responsabilidade compartilhada.

Em vez de cada time empurrar suas próprias metas, eles trabalham juntos desde o início.

Só que essa mudança só acontece com cultura.

E aí entra o modelo CAMS: Culture, Automation, Measurement e Sharing — Cultura, Automação, Medição e Compartilhamento. Não tem nada a ver com ambiente descolado ou sexta-feira sem dress code.

É sobre como o trabalho realmente acontece e como as pessoas se relacionam.

Conceitos fundamentais do Agile

O capítulo também traz ideias fundamentais: errar rápido, ciclos curtos de feedback e a diferença entre desenvolvimento iterativo e incremental. Iterativo é aprender enquanto faz.

Incremental, sozinho, pode virar só um mini waterfall.

Outro conceito importante é a otimização do fluxo de valor: olhar o processo completo, do surgimento da ideia até a entrega de valor real — e não só ficar tentando melhorar pedaços isolados.

E sim, os famosos quadros visuais, como Kanban e burnups, também aparecem.

Mais do que enfeite, eles ajudam a dar visibilidade e a gerar conversas importantes.

Não servem só para o time, mas também ajudam a alinhar toda a organização.

O perigo do Agile de mentirinha

No fim, o autor dá um recado importante: muita empresa diz que “faz Agile”, mas ignora o que realmente importa.

Equipes quebradas em silos, product owners ausentes, decisões isoladas... tudo isso são sinais de um Agile só na casca.

Cumprir cerimônia não é o suficiente. Agilidade exige colaboração de verdade, transparência e melhoria contínua. Não é só flexibilidade, é disciplina.

E se as organizações esquecem disso, o risco é grande: abandonar o Agile antes mesmo de terem tentado pra valer.

Capítulo 3 – Temas Centrais

Esse capítulo apresenta as três grandes ideias que guiam o livro inteiro.

Dá pra pensar nelas como princípios norteadores pra quem quer desenhar uma organização de TI realmente ágil.

A primeira ideia é governar com foco em valor, não em previsibilidade.

A segunda é organizar pensando em resposta rápida, não só em eficiência de custos.

E a terceira é criar estruturas que incentivem a motivação interna das pessoas.

Esses três temas vão aparecer o tempo todo ao longo do livro. Tudo que o autor recomenda mais pra frente volta, de algum jeito, pra essas três ideias.

Governar com foco em valor, não previsibilidade

Essa talvez seja a ideia mais ousada do capítulo: desenvolvimento de software não é um processo de produção — é um processo de design.

E isso muda completamente a lógica. A gente foi acostumado a tratar software como linha de montagem: definir escopo, prever prazos, controlar entregas.

Só que, segundo o autor, isso não funciona porque a base da criação de software é aprendizado e adaptação.

O código-fonte não é o produto final. Ele é só o design. O produto de verdade é o que o usuário experimenta.

E tentar gerenciar isso como se fosse fábrica acaba criando metas de previsibilidade onde não faz sentido.

A saída é mudar o foco: resolver problemas reais de forma útil, mesmo que isso signifique ajustar planos no meio do caminho.

A agilidade verdadeira mede sucesso por resultado, não por aderência à planilha do projeto.

Organizar para resposta rápida, não só eficiência

A segunda ideia confronta outro dogma: o de que a eficiência operacional é sempre o principal objetivo.

No contexto da TI-B (build and operate), o autor defende que o mais importante é responder rápido e bem.

Os clientes ligam menos pro quanto a sua operação é enxuta, e muito mais pro quanto você resolve bem o problema deles.

Ele traz o exemplo da Zappos, que mantinha o centro de distribuição funcionando 24h por dia.

Não porque era mais barato, mas porque criava uma experiência impressionante pro cliente.

Do mesmo jeito, times de TI talvez precisem abrir mão de um pouco de eficiência pra estarem mais disponíveis e adaptáveis.

Fazer multitarefa e lidar com demandas fragmentadas pode não ser o ideal em termos de produtividade, mas é o tipo de flexibilidade que a transformação digital exige.

No final das contas, quem responde melhor vence.

Criar estruturas que incentivem motivação interna

A terceira ideia volta o foco pra onde tudo começa: nas pessoas.

Organizações ágeis dependem de colaboração real — não só a que está marcada na agenda, mas aquela que acontece naturalmente, quando as pessoas estão engajadas de verdade.

E isso só rola quando existe motivação interna.

Inspirado nos estudos do Dan Pink, o autor lembra dos três pilares da motivação intrínseca: autonomia, maestria e propósito.

Ou seja, times precisam ter espaço pra tomar decisões, oportunidades pra evoluir nas habilidades e clareza de que o trabalho deles conecta com algo maior.

Se isso não acontece, a colaboração vira obrigação, e a agilidade fica só na superfície.

Os próximos capítulos vão explorar como desenhar estruturas e culturas que sustentam esses valores na prática.

Capítulo 4 – Superestrutura

Esse capítulo olha o todo: como a estrutura da organização influencia — e muito — a agilidade dos times.

A ideia central é simples, mas poderosa: times devem ser organizados em torno de resultados de negócio, não só em torno de atividades.

Pode parecer detalhe, mas faz uma baita diferença.

Um resultado é algo que tem valor por si só. Tipo aumentar vendas, melhorar a satisfação do cliente ou reduzir o tempo de entrega.

Já uma atividade é só uma parte do caminho — como escrever um conteúdo de marketing ou testar uma funcionalidade.

Quando o time é montado só em cima de atividades, ele tende a perder de vista o que realmente importa.

Mas quando o time é responsável por um resultado, ele trabalha com mais autonomia, mais propósito e muito mais motivação.

Por que os resultados importam

Narayan mostra que não tem problema dividir um resultado em resultados menores, desde que cada parte continue tendo valor real e possa ser alcançada de forma independente.

É o mesmo raciocínio do Agile quando a gente quebra uma funcionalidade em histórias de usuário.

Ele até apresenta um teste pra isso: TVIN — testável, valioso, independente e negociável.

Se um time trabalha com um resultado que passa nesse teste, dá pra confiar mais. Porque o que eles entregam tem impacto direto no negócio.

E mais: quando você entrega responsabilidade por um resultado, você também está entregando propósito.

E isso alimenta a motivação das pessoas de um jeito que nenhuma cerimônia ágil consegue.

Agora, quando você monta times baseados em atividades — tipo um time só de testes ou só de conteúdo — eles viram silos.

Focados só no próprio pedaço, sem se importar muito com o que vem antes ou depois. E aí a agilidade escorre pelo ralo.

Autonomia e descentralização

Depois, o capítulo entra no equilíbrio entre centralizar e descentralizar. E aqui não tem receita pronta.

Como diz Jim Highsmith (que o autor cita), isso é uma resolução — não uma solução única. Ou seja: vai mudando conforme a empresa cresce.

Produtos em fase inicial se beneficiam mais da autonomia descentralizada.

Mas, conforme amadurecem, pode ser que algumas funções precisem ser centralizadas pra garantir escala e consistência.

O ponto central aqui é: a descentralização deve seguir os resultados de negócio, não os departamentos.

Então é melhor descentralizar por linhas de produto ou regiões, do que por áreas como marketing ou vendas.

Isso ajuda a evitar os famosos silos — estruturas fechadas onde cada time protege seu “território” e a colaboração vai pro espaço.

Entendendo os silos

O livro define os silos como o resultado da autonomia mal aplicada. Eles aparecem quando os times estão tão preocupados com o próprio sucesso que esquecem o todo.

Atrapalham colaboração, desaceleram decisões e deixam o cliente pra segundo plano.

Esses silos podem ser funcionais (marketing vs. vendas), regionais ou por produto.

Mas os piores, segundo o autor, estão dentro da própria TI — quando desenvolvimento, testes, QA e operação vivem separados.

Esses silos internos aumentam os repasses, reduzem a velocidade e fazem com que cada time fique mais na defensiva do que colaborativo.

Nem todo silo precisa ser eliminado de cara. Alguns, em níveis mais altos, podem ser tolerados por um tempo.

Mas o foco deve ser remover os silos que atrapalham a entrega de valor real — aqueles que travam o básico.

Dono do resultado e estrutura

Um ponto importante que o capítulo traz é o papel do dono do resultado — alguém que tenha responsabilidade total por aquele resultado e poder de decisão.

Não é um novo cargo, é um papel que pode ser assumido por um product manager, líder de projeto ou outra pessoa do time.

Esse papel evita travamentos internos e ajuda a manter o time alinhado com o que importa.

E pra fechar, o autor deixa um alerta: não tente criar grandes sinergias entre produtos (tipo integrações complexas ou padrões unificados) antes de garantir que cada produto ou time está funcionando bem por conta própria.

Primeiro, fortaleça as unidades menores. Depois, se fizer sentido, pense na coordenação maior.

Capítulo 5 – Design de Times

Este é o primeiro mergulho profundo do livro, e já dá o tom de como as organizações devem repensar a estrutura dos seus times se realmente querem entregar software rápido e de forma eficaz.

O capítulo começa destacando um problema comum: muitos times são coletivamente responsáveis pelo mesmo resultado de negócio.

Isso costuma acontecer por causa de estruturas antigas, divisões regionais, terceirização ou funções especializadas.

Mas o problema é o seguinte: colaboração dentro de um time é fluida e constante. Entre times? É lenta, formal e cheia de atrito.

A entrega contínua exige colaboração contínua — e o design dos times tem um papel crucial nisso.

O problema dos times orientados a atividades

O autor critica os setups tradicionais, em que os times são organizados em torno de atividades especializadas — como testes, operações, marketing ou UX — e não em torno de resultados de negócio.

Esses times orientados a atividades geram muitos repasses. Cada repasse traz atraso, força o uso de lotes maiores e faz o ciclo total de entrega ser mais demorado.

Por exemplo: se os testadores ficam separados dos desenvolvedores, eles não vão receber novas versões de código o tempo todo.

Ao contrário, esperam por grandes entregas, o que leva a um feedback mais lento e mais defeitos.

Para ser ágil, os times precisam reduzir o tamanho dos lotes e trabalhar com pedaços menores de trabalho — mas isso só é possível se os repasses forem rápidos e baratos, o que não acontece com times organizados por função.

Por que times multifuncionais funcionam melhor

Times multifuncionais resolvem isso ao reunir todas as habilidades necessárias para entregar um resultado dentro de um único grupo.

O autor vai além da tradicional combinação de desenvolvedor e testador e inclui funções como product owners, operações, suporte e até vendas e marketing, quando necessário.

Essa organização reduz os atrasos, aumenta a autonomia e permite que os times respondam às mudanças de forma mais rápida.

Exemplos da vida real, como os squads do Spotify e os times de produto da Apple, mostram como essa abordagem funciona na prática.

Esses times estão alinhados a missões claras e incluem todas as competências necessárias para agir rapidamente.

Além disso, são mais motivantes de se trabalhar, pois todos conseguem ver o impacto direto do seu trabalho.

Os custos ocultos de serviços compartilhados e silos

O capítulo também faz uma crítica aos serviços compartilhados — como times de testes ou suporte centralizados que atendem a vários produtos.

Esses times podem parecer eficientes no papel, mas frequentemente carecem de propósito e acabam atrasando o progresso.

Como não são responsáveis por um único resultado, suas interações acabam sendo transacionais e não colaborativas.

O mesmo vale para os times de manutenção separados, que o autor considera um resquício do passado.

Com DevOps e entrega contínua, o time deveria ser responsável por construir, operar e melhorar o produto — dividir essa responsabilidade só cria repasses e atrasos desnecessários.

Matar a matriz

Por fim, o autor ataca a organização matricial — aquele modelo em que os membros do time reportam tanto a um líder funcional (como o chefe de desenvolvimento) quanto a um gerente de projeto.

Na TI, isso cria uma bagunça do tipo "função dentro de função", que acaba travando tudo. Gera prioridades concorrentes, falta de clareza de responsabilidades e ciclos de entrega longos.

A recomendação é clara: dissolva a matriz e mova-se para times totalmente responsáveis e orientados a resultados.

Se um time ficar grande demais, é melhor dividir por sub-resultados (como módulos de produto) do que por função.

Assim, você mantém o foco e a autonomia.

Resumindo, o capítulo defende que resposta rápida é mais importante que eficiência de custos.

Times multifuncionais, organizados em torno de resultados, são o melhor caminho para isso.

Não se trata de eliminar a especialização — mas de desenhar times onde a especialização serve à agilidade, e não aos silos.

Capítulo 6 – Responsabilidade

Se os capítulos anteriores pareceram uma celebração da autonomia, esse aqui nos lembra: autonomia sem responsabilidade é receita para o caos.

A responsabilidade é o que equilibra a liberdade de agir com a responsabilidade de tomar boas decisões.

Sem ela, corremos o risco de brigas de poder, decisões atrasadas e reuniões intermináveis, sem dono claro.

O autor começa destacando uma verdade que muitas organizações preferem ignorar: o poder ainda existe.

Influência é legal na teoria, mas na prática, quem tem autoridade formal costuma ser quem toma as decisões.

Por isso, as organizações precisam reconhecer o poder, e não fingir que ele não existe — e depois criar sistemas para usá-lo de forma inteligente.

Poder, hierarquia e clareza

Narayan não é contra a hierarquia. Ele até defende que alguma hierarquia é necessária para evitar disfunções.

Mas a hierarquia precisa ser desenhada com cuidado. Demais hierarquia leva a silos e política; de menos, leva a confusão e jogos de poder escondidos.

Um exemplo que ele usa é o vácuo de poder — quando ninguém é claramente responsável, as decisões ficam travadas ou são feitas nas costas de todo mundo.

A resposta não é eliminar a hierarquia, mas esclarecer autoridade e responsabilidade.

Assim, todo mundo sabe quem é responsável por quê e quem pode tomar quais decisões.

Delegação e alinhamento

Aqui, um ponto importante: autonomia não é só dar espaço para as pessoas, é também dar autoridade para agir — e deixar claro quando um superior pode intervir.

O livro descreve diferentes estilos de delegação e mostra como, em culturas ágeis, o estilo de delegação funciona melhor: o subordinado tem direito de decisão, mas o gerente pode intervir, se necessário.

Esse modelo ajuda na resposta rápida, mantendo o alinhamento com os objetivos de negócios.

Designando donos de resultados claros

O capítulo traz um exemplo poderoso da vida real: o fracasso no lançamento do HealthCare.gov.

Um dos maiores problemas?

Ninguém sabia quem era o responsável final.

Esse é o perigo da propriedade compartilhada sem responsabilidade clara.

Para corrigir isso, Narayan apresenta a ideia dos donos de resultado — uma única pessoa, em tempo integral, com autoridade e responsabilidade pelo resultado de um negócio.

Sem isso, surgem jogos de culpa e o progresso fica parado.

Mapeamento de responsabilidade e clareza de decisões

Uma ferramenta prática que o autor introduz é o mapeamento de responsabilidade.

Imagine um mapa visual mostrando quem é responsável por quais resultados.

É uma forma de expor e corrigir a sobrecarga ou falta de propriedade.

Sem esse tipo de clareza, o que acontece é o que ele chama de "desapropriação coletiva da responsabilidade".

As pessoas participam de reuniões intermináveis, copiam todo mundo nos e-mails, só pra "ficar por dentro", e não porque sabem pelo que são responsáveis.

Um mapa de responsabilidades claro ajuda a cortar o ruído e evitar escalonamentos desnecessários.

Evitando brigas de poder com a estrutura

Narayan critica tanto as organizações matriciais quanto as hierarquias absolutas.

A primeira cria brigas territoriais de poder, onde líderes funcionais guardam recursos e entram em conflito com donos de resultados.

A segunda dá todo o poder aos donos de resultados, o que pode desmotivar os líderes funcionais.

A alternativa que ele propõe é o modelo professor-empreendedor.

Nesse modelo, os donos de resultado (empreendedores) têm autoridade e são responsáveis pelos resultados, enquanto os líderes funcionais (professores) orientam suas especialidades, mas não controlam pessoas ou orçamentos.

Assim, você tem influência sem brigas de poder, e todos ficam focados no que realmente importa: os resultados.

Registros de decisões e transparência

Para evitar a decisão do HiPPO (a opinião da pessoa mais bem paga) e impedir que erros sejam enterrados, o capítulo sugere o uso de registros de decisão.

Esse conceito, emprestado da engenharia de software, cria um registro transparente das decisões, entradas e justificativas.

Isso ajuda a evitar apontar dedos e promove o aprendizado com os erros.

Narayan até sugere ferramentas como Loomio para apoiar esse processo.

Importante: não se trata de transformar cada decisão em uma votação democrática — é sobre convidar contribuições enquanto mantém a clareza de responsabilidade.

Planejamento vs. execução — e por que a sobreposição importa

Um grande problema em muitas organizações é a separação entre planejamento e execução.

Os gerentes planejam; os outros executam.

Isso não só mata a autonomia e a credibilidade, mas também leva a decisões ruins.

Narayan argumenta que quem planeja também deve estar em contato com a execução, pelo menos 20% do tempo.

Seja testando, programando ou conversando com os clientes, estar conectado com a execução mantém os líderes mais realistas.

Isso conquista respeito e melhora a tomada de decisões.

Quem planeja sem estar conectado à realidade de execução corre o risco de tomar decisões que não refletem o que está acontecendo de verdade — e depois colocar a culpa em quem está executando quando as coisas dão errado.

Dívida de organograma e a necessidade de repensar a estrutura

O capítulo termina com uma analogia inteligente: assim como as equipes de software precisam pagar a dívida técnica, as organizações precisam pagar a dívida de organograma — os desalinhamentos, silos e desequilíbrios de poder que se acumulam ao longo do tempo.

Isso significa revisar periodicamente papéis, responsabilidades e estruturas para garantir que ainda servem ao objetivo de agilidade.

Não é sobre reorganizações constantes, mas sobre redesenho intencional quando as coisas começam a sair do caminho.

Capítulo 7 – Alinhamento

Depois de defender a autonomia dos times, esse capítulo responde uma pergunta importante: como manter tudo alinhado?

Autonomia sem alinhamento pode gerar silos e confusão.

Por isso, aqui o autor oferece formas práticas de garantir que TI e negócios sigam conectados, mesmo com a independência dos times aumentando.

A mensagem é clara: alinhamento não exige controle rígido, mas clareza, compreensão compartilhada e comunicação constante.

Clarificando a estratégia através de trocas diárias

O autor diz que estratégia só é útil se ajudar a guiar as decisões do dia a dia. Falar "desenhar para alta disponibilidade" é vago.

Já dizer "priorizar disponibilidade sobre consistência" oferece uma troca clara de prioridades.

Esse tipo de orientação ajuda os times a tomarem decisões alinhadas com os objetivos da empresa.

O livro também introduz a ideia das disciplinas de valor — excelência operacional, liderança de produto e intimidade com o cliente.

A empresa precisa escolher uma delas para orientar suas prioridades.

Por exemplo, um time focado em liderança de produto vai valorizar mais a resposta rápida do que a eficiência de custos.

O autor cita o exemplo da Koparati Inc., que tem negócios de serviços e produtos.

O time de serviços está alinhado com a intimidade com o cliente, enquanto o time de produto foca em inovação e liderança de produto.

Reconhecer essa diferença ajuda os funcionários a tomarem as decisões e atitudes certas.

Superando a lacuna entre TI e negócios

O autor aponta um problema real: em muitas empresas, TI tenta se alinhar aos negócios, mas a estratégia de negócios não está bem definida ou não é compartilhada claramente.

Às vezes, ela nem está escrita. Em outros casos, TI assume que é co-responsável pela estratégia e começa a financiar iniciativas que os negócios não apoiam.

Esse desconexão resulta em desperdício de recursos e colaboração fraca.

O livro enfatiza que os líderes de negócios precisam articular e compartilhar claramente a estratégia antes de esperar o alinhamento de TI.

Sem essa base, o alinhamento é impossível.

Ferramentas para o alinhamento

Para tornar o alinhamento visível e acionável, o livro apresenta vários modelos.

Um deles é o Modelo Operacional MIT, que ajuda as organizações a entender se suas unidades de negócios precisam de alta integração, alta padronização, ambos ou nenhum dos dois.

Outro modelo é a estratégia de aplicação em camadas da Gartner, que classifica os sistemas de TI em sistemas de registro, diferenciação e inovação.

Essas camadas ajudam os times a decidirem onde investir, quão rápido se mover e qual nível de controle é apropriado.

Uma ferramenta mais prática é o mapa de alinhamento.

Ele conecta os imperativos de negócios às áreas da arquitetura e às histórias técnicas.

Esse é um mapa visual que os times podem usar para mostrar como o trabalho atual contribui para os objetivos de negócio.

Por exemplo, um time pode estar trabalhando para auto-deploy em ambientes de teste para melhorar o tempo de ciclo.

Outro time pode estar extraindo um banco de dados de clientes para apoiar a separação de produtos. Ver isso mapeado ajuda tanto TI quanto negócios a se manterem alinhados.

Alinhamento estrutural e mútuo

O capítulo também enfatiza o alinhamento estrutural — organizar os times de TI-B em torno de unidades de negócio, como aquisição de clientes ou gestão de sinistros.

Isso ajuda os times de TI a ficarem mais próximos dos objetivos do negócio, ao invés de serem tratados apenas como um pool de recursos atribuídos a projetos aleatórios.

Mas o alinhamento é uma via de mão dupla. Os líderes de negócios também precisam se alinhar com a forma de trabalho de TI.

Se eles querem resultados ágeis, precisam entrar no processo ágil. Isso significa fazer tempo para colaboração e abraçar o desenvolvimento iterativo.

O papel do IT Business Partner

Para superar essas lacunas, o livro sugere a criação de um papel formal: o IT Business Partner.

Essa pessoa não só traduz as necessidades de negócios para TI, mas também ajuda os negócios a entenderem os métodos, prioridades e limitações da TI.

Eles garantem que ambos os lados falem a mesma língua e se mantenham alinhados.

É um papel de alto nível, diferente de um analista de negócios tradicional.

Trata-se de construir uma relação entre TI e negócios para que ambos tenham sucesso juntos.

Capítulo 8 – Projetos

Este capítulo traz uma das maiores mudanças do livro.

Ele desafia todo o modelo tradicional de gerenciar o trabalho de TI por meio de projetos e, em vez disso, defende uma execução orientada por valor, organizada em torno de capacidades duradouras.

Se você já ficou preso em um projeto que atrasou, queimou todos os membros do time e teve que ser repassado de forma desajeitada para outro time, esse capítulo explica exatamente por que isso acontece sempre — e o que fazer para mudar.

Por que projetos tradicionais não funcionam

O autor começa explicando o que está errado com os projetos tradicionais, baseados em planejamento.

A definição padrão — com escopo fixo, cronograma fixo e time temporário — está profundamente enraizada na ideia de previsibilidade.

Mas, como ele lembra, desenvolvimento de software é um processo de design, não de produção.

Tentar planejar tudo de antemão raramente funciona.

Em vez de perguntar “Quando vai estar pronto?”, a pergunta certa é: "Quais resultados valiosos podemos entregar até essa data?" O foco deve ser em resolver problemas, e não em seguir uma lista de tarefas pré-definida.

A pressão para entregar “no prazo e no orçamento” faz com que os times priorizem a previsibilidade sobre o valor — o que não faz sentido, já que a previsibilidade nunca foi realista no início.

De projetos para capacidades

Uma grande mudança que o livro propõe é mover-se de times de projetos temporários para times de capacidades permanentes.

Esses times são organizados em torno de capacidades de negócio, como gestão de pedidos ou processamento de sinistros, e não apenas em torno de tecnologias ou fases de trabalho.

Os times de capacidade são estáveis, multifuncionais e responsáveis tanto por construir quanto por operar seus sistemas.

Eles não se desintegram quando um projeto termina, porque sua missão continua.

Essa estabilidade permite que o time construa um entendimento real do negócio que está apoiando — algo difícil de alcançar com equipes rotativas de projeto.

O novo trabalho simplesmente vira itens no roadmap do time, em vez de criar um novo projeto toda vez.

Orçamento por capacidade, não por projetos

Esse novo modelo exige uma maneira diferente de orçar.

Em vez de financiar projetos individuais, as organizações devem financiar a capacidade dos times com base nas necessidades estratégicas de negócio.

Isso se alinha melhor com a forma como o software realmente é construído e evita a situação desconfortável e ineficaz em que um time de projeto é desfeito, e depois um time de manutenção luta para manter tudo funcionando.

Com o financiamento baseado em capacidade, os donos de resultados decidem como gastar o tempo do time, e os times ficam focados em entrega contínua e melhoria.

Isso também torna o processo orçamentário mais simples e mais responsivo.

A verdade sobre business cases

Outro ponto importante no capítulo é a crítica aos business cases financeiros.

Muitas vezes, esses casos estão cheios de suposições e benefícios inflacionados, só para garantir o financiamento.

Os benefícios reais quase nunca são rastreados depois da entrega e, quando as coisas saem do caminho, os números são ajustados para fazer o caso parecer viável novamente.

Em vez disso, o autor sugere usar entrega contínua e análises de uso para validar os benefícios conforme eles acontecem.

Lançamentos pequenos e incrementais permitem que você meça o impacto e se ajuste rapidamente.

Quando você consegue acompanhar se uma nova funcionalidade realmente melhorou o comportamento do usuário, não é preciso um plano de 30 páginas no início — você só precisa da liberdade para aprender e ajustar ao longo do caminho.

Repensando o papel dos gerentes de projeto

Nesse novo modelo, os gerentes de projeto não são eliminados, mas precisam evoluir.

Em vez de apenas controlar planos e administrar tarefas, eles devem ajudar a entregar valor.

Muitos PMs tradicionais ficam presos em papéis sem conteúdo real, focando em gráficos, listas de tarefas e coordenação, sem entender o produto real.

O livro sugere liberar o tempo dos PMs introduzindo assistentes de projeto — papéis mais júniores que cuidam das tarefas logísticas, permitindo que os gerentes se concentrem mais na execução real e na liderança.

Lidando com programas de mudança e transformação digital

O capítulo também critica programas de mudança em larga escala que criam unidades de transformação separadas, desconectadas do resto da organização.

Esses programas frequentemente falham porque ignoraram sistemas e equipes existentes.

A solução?

Não isole a mudança, mas integre-a nas equipes de capacidades existentes.

Isso é especialmente importante na transformação digital, onde o sucesso depende de uma integração profunda entre sistemas novos e antigos.

Organizar por capacidade, e não por canal (como mobile vs. web), evita fragmentação e proporciona melhores experiências para o cliente.

Limitando o trabalho em progresso

Por fim, o livro introduz um conceito simples, mas poderoso: limitar o trabalho em progresso (WIP).

Quando muitos projetos estão ativos ao mesmo tempo, o progresso desacelera, a entrega de valor diminui, e os times ficam sobrecarregados.

Em vez de começar tudo, é melhor terminar menos coisas, mas mais valiosas.

Os quadros Kanban em nível de portfólio podem ajudar a visualizar isso e manter todos focados no que realmente importa.

Este capítulo não é apenas uma crítica aos projetos tradicionais — é um plano de ação para como as organizações de TI modernas podem finalmente sair da corrida de previsibilidade falsa e começar a entregar valor contínuo e significativo.

Capítulo 9 – Finanças

Este capítulo revela uma das barreiras mais silenciosas, mas poderosas, para a agilidade na TI: as práticas tradicionais de finanças e orçamento.

Embora pareça estranho falar sobre contabilidade em um livro sobre design de organização ágil, o autor argumenta que as finanças se tornaram um gargalo escondido, assim como antes eram os times isolados ou a governança rígida.

Usando a teoria das restrições, ele mostra que, uma vez que você resolve um gargalo, outro aparece — e, hoje, o orçamento é muitas vezes onde a agilidade se quebra.

A mentalidade de centro de custos

Grande parte do problema vem de como a TI é rotulada. A maioria dos departamentos de TI em empresas são tratados como centros de custo, e não como centros de lucro.

Isso significa que eles são vistos como despesas gerais — algo que deve ser minimizado.

Essa mentalidade leva a um modelo de financiamento baseado em projetos, onde a TI é tratada como uma espécie de "fábrica", recebendo projetos com escopo, tempo e custo fixos.

O problema? Desenvolvimento de software não é um processo previsível e repetível — é um processo de design, cheio de aprendizado e iteração. Tratá-lo como manufatura é um erro que prejudica a colaboração, a entrega de valor e a saúde dos times a longo prazo.

Complicações de CapEx, OpEx e DevOps

As finanças também influenciam como os times são estruturados por meio das despesas de capital (CapEx) e operacionais (OpEx).

Tradicionalmente, desenvolvimento é CapEx e operações é OpEx. Isso gera fricção quando as equipes tentam adotar DevOps, porque agora um time faz ambos e a contabilidade não sabe como categorizar os custos.

Dividir os times para se encaixar nas categorias contábeis é comum, mas é a otimização errada.

A solução prática que o livro sugere é: marcar as histórias como geradoras de ativos (CapEx) ou operacionais (OpEx) nas ferramentas ágeis.

Isso permite que as empresas relatem CapEx vs. OpEx com precisão, sem precisar preencher timesheets, o que ninguém gosta de fazer.

Repensando o orçamento convencional

O orçamento convencional foca fortemente no controle — os planos são feitos uma vez por ano, desvios são mal vistos e incentivos estão atrelados a manter tudo dentro do orçamento.

Mas isso é o oposto do que o Agile prega, onde a mudança é esperada e bem-vinda.

O resultado é um descompasso: a TI é orientada a ser ágil, mas é mantida sob rígidas restrições financeiras.

Os gerentes se veem forçados a planejar demais, inflar os benefícios para garantir o financiamento e gastar os orçamentos rapidamente antes do final do ano — todos sintomas do que o autor chama de "budgeteering".

Orçamento ágil e colaborativo

O capítulo propõe uma mudança para o orçamento ágil, onde os donos de resultados recebem fundos pré-aprovados e autonomia para ajustar seus planos.

Não se trata de controlar cada centavo, mas de entregar valor.

É como substituir semáforos por rotatórias: ainda há estrutura, mas ela depende de cooperação e responsabilidade, não de regras rígidas.

Algumas empresas já estão fazendo isso.

Por exemplo, o Svenska Handelsbanken, um banco sueco de 140 anos, trabalha sem orçamentos ou metas centrais de vendas há décadas — dando aos gerentes de filial alta autonomia.

Outro exemplo é a Enspiral, uma coletividade que usa orçamento colaborativo por meio de uma ferramenta chamada Cobudget.

Eles reúnem fundos, alocam em conjunto e focam nos objetivos maiores, não nos interesses pessoais.

Não é perfeito, mas cria transparência e propriedade compartilhada.

Financiamento de risco como modelo

Finalmente, o livro introduz a ideia de aplicar a lógica de financiamento de risco ao IT corporativo.

Nesse modelo, os gerentes de portfólio agem como VCs (venture capitalists), liberando fundos em estágios, com base no desempenho.

Os donos de resultado são como empreendedores, e os times de capacidade são como startups.

Isso permite mais experimentação, decisões mais rápidas e a capacidade de parar ou escalar o trabalho baseado no valor, não nos planos.

A mensagem principal? Finanças ágeis são possíveis — e necessárias.

Sem elas, até os melhores times ágeis vão ficar presos em padrões antigos, bloqueados por um sistema feito para controle, não para aprendizado.

Se queremos resposta rápida, precisamos financiar isso da maneira certa.

Capítulo 10 – Staffing

Este capítulo foca em uma parte crucial, mas muitas vezes negligenciada, da transformação ágil: quem está no time e como ele é formado.

Enquanto os capítulos anteriores abordaram finanças e governança, aqui o autor se concentra nas pessoas — suas habilidades, estrutura, papéis e o que mantém elas motivadas.

A ideia central é simples, mas poderosa: a agilidade a longo prazo depende de times estáveis, bem compostos e motivados, com habilidades variadas.

Não dá para entregar grandes resultados com times que ficam sendo formados e desfeitos, como esquadrões temporários baseados em projetos.

A escassez de talentos e como lidar com isso

Não tem como escapar: bons talentos de TI são difíceis de encontrar e ainda mais difíceis de reter.

A indústria cresceu tanto que a demanda está muito à frente da oferta.

Embora treinamento e terceirização ajudem, ambos têm limitações.

Treinamento leva tempo e terceirização muitas vezes resulta em times sobrecarregados de novatos com poucos líderes experientes — o que o autor chama de "alavancagem".

Isso é arriscado, especialmente quando a alavancagem vem de planejamento e não da liderança real do time.

Para aliviar a pressão, as organizações devem preferir comprar do que construir para sistemas não estratégicos e manter o desenvolvimento personalizado focado em verdadeiros diferenciais.

E quando for necessário construir, deve-se limitar o escopo e a sofisticação para o que pode ser realisticamente entregue com o talento disponível.

Times duradouros vs. times de projeto

Um dos pontos mais importantes do capítulo é a mudança de times de projeto para times de capacidade duradoura.

Os times de projeto frequentemente desaparecem logo após a entrega, deixando sistemas que ninguém entende completamente. Isso leva a softwares legados difíceis de gerenciar.

A solução é times estáveis e multifuncionais que permaneçam com o sistema tempo suficiente para mantê-lo e evoluí-lo.

Esses times crescem juntos, aprendem juntos e retêm o conhecimento crítico.

Como a teoria de desenvolvimento de grupos de Tuckman explica, leva meses para um time realmente funcionar bem — desmantelá-los no momento em que começam a se entrosar é um desperdício.

Esses times duradouros não custam mais do que os times de projeto.

Na verdade, quando você planeja o trabalho com base na capacidade fixa do time, os custos se estabilizam e você evita o estresse e a rotatividade de ramp-ups e ramp-downs constantes.

Preocupações como tédio do time ou falta de inovação são gerenciáveis — com uma boa mistura de personalidades, algum turnover natural e um roadmap de capacidades em evolução, o time se mantém afiado.

Contratação por habilidades, não por papéis

Nos setups tradicionais, as pessoas são contratadas para papéis: desenvolvedor, testador, analista.

Mas em times ágeis de alto desempenho, esse modelo começa a quebrar.

À medida que os membros do time crescem, eles frequentemente se tornam pessoas em forma de T — com profundidade em uma habilidade e capacidade em várias outras.

Por isso, o livro defende a contratação baseada em habilidades, e não por papéis.

Isso permite mais flexibilidade, melhor colaboração e uma resposta mais forte. As pessoas não ficam presas a títulos de cargo — elas trocam de função conforme necessário.

Para isso funcionar bem, os times e as organizações precisam manter um inventário atualizado de habilidades, mostrando tanto as forças principais quanto as secundárias.

A mesma lógica se aplica aos títulos de cargos. Títulos estreitos e baseados em especialidade, como “engenheiro de QA” ou “analista de negócios”, podem acabar limitando como as pessoas contribuem — ou como são percebidas. Alguém rotulado como testador pode ter ótimas ideias de produto, mas elas podem ser ignoradas.

O autor sugere usar títulos mais amplos ou focar internamente em faixas salariais e habilidades, ao invés de rótulos.

Construindo times polivalentes e reduzindo o uso de part-time

Contratar não é só sobre encontrar talento — é também sobre desenvolver talento internamente.

Uma prática eficaz é o pairing, onde um especialista escasso trabalha com um membro do time menos experiente.

Isso ajuda a construir capacidade enquanto aumenta a responsabilidade e a resposta do time. Também reduz a dependência de especialistas part-time, que frequentemente se tornam gargalos devido ao foco dividido e ao baixo contexto.

O capítulo também aborda a mistura de personalidades do time e o equilíbrio de gênero. Isso pode parecer algo "soft", mas faz uma grande diferença na coesão, criatividade e resiliência do time.

Usar ferramentas como pesquisas confidenciais e avaliações pode ajudar os times a entenderem e apreciarem diferentes estilos e pontos fortes de trabalho.

Contratar não é só preencher vagas. É sobre desenhar times para o longo prazo, nutrir a versatilidade e remover as barreiras que mantêm as pessoas presas a papéis estreitos.

A entrega ágil só é possível com pessoas ágeis — e isso significa criar o ambiente certo para elas prosperarem.

Capítulo 11 – Ferramentas

Este capítulo nos chama a atenção para algo que muitas vezes passa despercebido nas conversas sobre Agile: as ferramentas.

Sriram Narayan argumenta que, enquanto frequentemente culpamos as pessoas ou os processos pelos problemas de colaboração, o landscape de ferramentas e acesso desempenha um papel silencioso, mas significativo, na forma como as pessoas trabalham juntas.

Ferramentas não são apenas ajudantes passivos — elas influenciam comportamentos, moldam hábitos e podem até mesmo causar ou prevenir silos.

Controle de acesso e colaboração

O capítulo começa desafiando o modelo tradicional de acesso baseado em "precisar saber".

A maioria das organizações restringe o acesso a ferramentas e informações, a menos que o funcionário consiga provar que precisa delas.

Mas Narayan inverte isso: em vez de perguntar "por que essa pessoa deve ter acesso?", a pergunta deve ser "por que ela não deveria ter?"

Ele defende uma abordagem de "precisar restringir" — bloquear o acesso apenas quando absolutamente necessário (por exemplo, por questões de conformidade) e, fora isso, permitir que as pessoas explorem livremente.

Ferramentas como wikis incorporam essa mentalidade. Todo mundo pode ler e, muitas vezes, editar tudo.

Essa abertura incentiva o compartilhamento e a autonomia, enquanto mantém o comportamento adequado sob controle, através de rastreabilidade e reversibilidade.

Os efeitos sutis das cadeias de ferramentas isoladas

Mesmo em times multifuncionais, silos podem se formar quando diferentes papéis dependem de ferramentas diferentes — o que o autor chama de silos de acesso às ferramentas.

Por exemplo, se os desenvolvedores não podem acessar os painéis de vendas ou ferramentas de monitoramento, eles perdem um contexto valioso.

Da mesma forma, se os analistas de produto não conseguem ver os dados dos clientes no Salesforce, eles têm que depender de intermediários.

Essa separação desacelera os times e enfraquece os insights.

O problema piora quando as ferramentas não oferecem licenças escalonadas (por exemplo, acesso só de leitura a um custo mais baixo), o que torna caro conceder acesso amplo.

As organizações precisam começar a pensar em acesso universal a informações radiadoras, e não apenas a ferramentas especializadas.

Há também uma camada comportamental — silos no uso das ferramentas. As pessoas criam vínculos emocionais com suas ferramentas favoritas.

Elas acabam se tornando parte de uma "tribo de ferramentas" (como vi vs. Emacs ou Windows vs. Mac) e acabam defendendo suas ferramentas, mesmo que isso crie atrito.

Isso pode parecer rivalidade amigável, mas pode dividir os times e dificultar a colaboração.

O mesmo vale para as especializações das ferramentas — quando um time usa um conjunto de ferramentas e outro usa um conjunto completamente diferente, até para tarefas semelhantes.

Ferramentas que apagaram as fronteiras e são compartilhadas entre papéis tornam a colaboração mais fácil e reduzem os repasses.

A tecnologia não é neutra

Narayan se apoia na ideia de Marshall McLuhan, de que “nós moldamos nossas ferramentas, e depois nossas ferramentas nos moldam”.

Assim como a linguagem influencia nosso pensamento, as ferramentas influenciam nosso comportamento.

E, embora alguns acreditem que as ferramentas são neutras e que são as pessoas que as usam incorretamente, o livro discorda. As ferramentas têm valores embutidos.

O e-mail, por exemplo, mudou completamente como nos comunicamos — ele se tornou a caixa de entrada, o arquivo, o quadro de avisos e o feed social, tudo em um.

Isso incentiva a verificação constante, a atenção dispersa e a documentação excessiva.

Portanto, ao projetar o landscape de ferramentas de uma organização, devemos perguntar não apenas o que as ferramentas fazem, mas como elas moldam o comportamento.

Avaliação e adoção de ferramentas

Escolher as ferramentas certas não é só uma questão de comparar funcionalidades.

Narayan enfatiza a melhor adequação, não a melhor ferramenta.

Uma ferramenta tecnicamente superior ainda pode falhar se não se encaixar no jeito de trabalhar do time ou se a adoção for difícil.

As avaliações de ferramentas devem envolver os usuários finais, considerar as necessidades de treinamento e evitar excessiva personalização, a menos que isso traga uma vantagem competitiva clara.

O mais importante: cada decisão sobre ferramentas precisa de um dono de resultado claro e um registro de decisão transparente, para garantir a responsabilidade — não apenas pela seleção, mas pela adoção e sucesso.

Um chamado para o design intencional

A grande mensagem aqui é que as ferramentas podem apoiar ou sabotar a colaboração.

Se queremos trabalho em equipe desestruturado e multifuncional, precisamos escolher ferramentas e modelos de acesso que permitam isso.

Isso significa repensar controle de acesso, políticas de compras e padronização de ferramentas — não para burocracia, mas para criar um ambiente digital que realmente apoie o jeito que os times ágeis devem trabalhar.

Capítulo 12 – Métricas

Este capítulo aborda um bloqueador sutil, mas poderoso, para a agilidade: a forma como medimos as coisas.

À primeira vista, as métricas parecem algo positivo — elas nos fornecem dados para orientar decisões.

Mas Sriram Narayan alerta que, quando mal utilizadas, as métricas podem causar mais danos do que benefícios.

Elas podem criar ilusões de controle, promover comportamentos errados e até diminuir o desempenho, especialmente quando estão atreladas a metas e incentivos.

Ele não é contra as métricas. Ele só é a favor de contexto, conversas, e é profundamente cético sobre gerenciar o trabalho de software como se fosse uma linha de produção.

Métricas não contam a história toda

O argumento central é que o desenvolvimento de software é uma atividade de design, não um processo de produção.

Isso significa que lidamos com aprendizado constante, mudanças e imprevisibilidade — então nenhum conjunto de métricas pode capturar totalmente a realidade.

Muitas vezes, medimos o que é fácil de medir, e não o que é realmente significativo.

Veja o exemplo da velocidade.

Ela pode ser útil, mas só se a definição de “pronto” incluir tudo, desde testes funcionais até performance e segurança.

Caso contrário, estamos apenas nos enganando. O pior é que, quando os times diluem o conceito de “pronto” ou relatam o progresso no nível das tarefas, em vez de histórias, a velocidade se torna uma métrica vaidosa.

Painéis e a ilusão de insights

Os painéis de controle (dashboards) têm como objetivo fornecer uma visão geral, como um resumo executivo. Mas frequentemente promovem uma compreensão superficial.

Um painel pode mostrar o status “verde” com base em dezenas de métricas acompanhadas, enquanto esconde problemas maiores que não estão sendo medidos.

Isso cria uma falsa sensação de segurança. As pessoas deixam de fazer perguntas difíceis e começam a confiar demais no painel.

E como os gerentes não querem reportar "vermelho" ou "âmbar", as equipes manipulam o sistema para manter tudo verde — mesmo quando isso não é a melhor solução.

O problema com metas e incentivos

Essa parte é dura. Quando dizemos: “faça isso e você ganhará aquilo”, as pessoas começam a perseguir a recompensa, e não o objetivo real. As metas distorcem o comportamento.

Os times otimizam para o que é medido, não para o que realmente importa.

Um exemplo mostra como uma equipe de testes se recusou a compartilhar seus casos de teste porque seu desempenho era medido pelo número de bugs encontrados.

Outro exemplo mostra um vendedor dando grandes descontos só para bater uma meta trimestral — perdendo receita a longo prazo no processo.

Esses são otimizações locais clássicas que prejudicam a visão geral.

As metas também levam a micromanagement, matam a motivação intrínseca e transformam organizações que deveriam ser de aprendizado em máquinas orientadas pela conformidade.

"Gamificação" e a Lei de Goodhart

Narayan traz a Lei de Goodhart: “Quando uma medida se torna uma meta, ela deixa de ser uma boa medida.”

As pessoas começam a “jogar” com as métricas, intencionalmente ou não. Recrutadores inundam os entrevistadores com candidatos de baixa qualidade para cumprir a meta de contratações.

Times de operações criam truques de uptime que enganam as ferramentas de monitoramento, mas frustram os usuários.

Até mesmo metas bem-intencionadas se tornam problemáticas porque as pessoas começam a focar em bater o número, não em resolver o problema.

Reformando o regime de métricas

Então, qual é a alternativa? O livro não só critica — ele oferece uma forma melhor. Primeiro, acabe com os incentivos.

Salários fixos funcionam melhor em culturas ágeis.

Depois, relaxe as metas gradualmente, movendo-se para métricas que são discutidas — e não impostas.

Apoie avaliações humanas em vez de relatórios mecânicos. Use indicadores RAG (Vermelho, Amarelo, Verde) com marcas de alta-baixa, em vez de perseguir números exatos.

E, o mais importante, use mapas de métricas para mostrar como cada métrica se conecta a um resultado de negócios.

Isso torna as métricas significativas, não aleatórias.

Desenhando melhores métricas

O capítulo fecha com um guia para desenho inteligente de métricas:

• Favor métricas orientadas a resultados em vez de métricas orientadas a atividades.

• Use agregados, como velocidade de valor ou toxicidade de código, em vez de micromanagement de detalhes.

• Prefira métricas de adaptabilidade (como tempo de ciclo) a falsas previsões (como datas de conclusão projetadas).

• Fique confortável com indicadores retardados. Se o seu ciclo de feedback for curto, eles ainda serão úteis.

• Introduza métricas compensatórias para equilibrar os pontos cegos das outras métricas.

Finalmente, o capítulo reconhece as objeções: “Mas meu time precisa de recompensas e punições.” Ou “Isso não vai escalar.”

Mas Narayan argumenta que o que realmente escala é autonomia com responsabilidade, não controle por números.

As métricas devem apoiar conversas significativas, e não substituí-las.

Capítulo 13 – Normas

Este capítulo marca uma mudança no tom do livro.

Após se concentrar fortemente em estruturas, processos e responsabilidade, agora o foco é na cultura organizacional — especificamente, nas regras informais e não escritas que moldam o comportamento diário.

Narayan argumenta que, embora grande parte da mudança cultural seja um efeito colateral da liderança, estrutura e políticas, o reforço deliberado de algumas normas-chave pode apoiar significativamente a agilidade.

Essas normas não são políticas. Elas são mais como crenças compartilhadas sobre “como as coisas são feitas aqui”.

E, se escolhidas com sabedoria e reforçadas de forma consistente, ajudam a descentralizar a tomada de decisões sem perder a coerência.

O que as normas fazem e como reforçá-las

O capítulo começa explicando o que são normas através de uma história fácil de entender.

Uma nova contratada na Edgy Inc. fica chocada ao descobrir que tem acesso total de admin no laptop — total confiança, ao contrário de seu trabalho anterior, que tratava os funcionários como riscos a serem gerenciados.

A mensagem é clara: as normas podem empoderar as pessoas ou limitá-las. Para fortalecer normas úteis, Narayan sugere usar contação de histórias — compartilhando exemplos reais que refletem a cultura desejada.

Por exemplo, histórias de confiança, iniciativa ou risco inteligente se tornam sinais para que outros ajam da mesma forma.

Ele propõe criar blogs internos para cada norma, crowdsourcing de histórias e permitindo que os funcionários interajam naturalmente com elas.

Os líderes devem comentar mais do que postar, e os incentivos devem ser evitados para manter a autenticidade.

Cooperação em vez de competição

Uma norma poderosa que Narayan incentiva é cooperação em vez de competição interna.

Embora a competição seja saudável no mercado, dentro das organizações ela frequentemente leva à inveja, otimização local e comportamentos disfuncionais.

Ele dá exemplos de como recompensas como “funcionário mais inovador” ou caçadas de bugs gamificadas podem fazer com que as pessoas guarde informações ou manipulem o sistema.

A abordagem melhor?

Reconhecer múltiplos contribuintes, em vez de nomear um único vencedor. Evitar concursos baseados em escassez e criar um ambiente onde as pessoas se apoiam em vez de se prejudicarem.

Políticas vivas e consistência

Narayan introduz a ideia de “políticas vivas” — políticas que evoluem abertamente com o feedback dos funcionários.

Em vez de ficarem presas em PDFs que ninguém lê, elas vivem em plataformas colaborativas, abertas a comentários e revisadas regularmente.

Isso incentiva transparência, respostas rápidas e adaptabilidade.

Junto com isso, ele faz um ponto sutil sobre consistência versus uniformidade.

Consistência verdadeira significa alinhar-se com a intenção e o contexto, e não impor uniformidade em tudo.

Ele usa o exemplo de design de UI ou políticas de crédito para mostrar como a uniformidade rígida pode frustrar usuários ou funcionários, enquanto a consistência cuidadosa constrói confiança.

Cultura de permissão e confiança

Outra ideia marcante é a norma de “pedir perdão, não permissão”. Trata-se de empoderar as pessoas a agir no interesse do negócio, sem ficarem presas esperando aprovações.

Sim, essa norma pode ser abusada, mas quando usada com sabedoria, ela sinaliza confiança e incentiva a iniciativa.

Narayan sugere que as organizações não devem anunciar essa norma com muito destaque, mas devem tratar quebras inteligentes e éticas das regras em prol do bem maior como aceitáveis — até elogiáveis — em vez de puni-las por padrão.

Usando pesquisas confidenciais de forma inteligente

O capítulo também apresenta pesquisas confidenciais como uma maneira de equilibrar transparência com segurança psicológica.

Elas permitem que os times recolham feedback honesto sem transformar tudo em um concurso de popularidade ou em um campo de batalha de ataques anônimos.

É um meio-termo que apoia melhorias contínuas enquanto evita extremos.

Valorizando a prática informada pela teoria

Finalmente, o capítulo chama para uma mudança de mentalidade: não apenas agir — pensar enquanto age.

Muitas organizações se orgulham de serem “fazedoras” que descartam a teoria.

Mas, em um mundo que muda rapidamente, ação cega não é suficiente.

Narayan argumenta que é preciso abraçar a prática informada pela teoria — aprender com livros, palestras e modelos, enquanto se mantém enraizado na realidade.

Essa norma incentiva experimentos pensados e tomada de decisão fundamentada no entendimento, não apenas no instinto.

Este capítulo mostra como a cultura não é apenas um subproduto — ela pode ser moldada, uma norma e uma história de cada vez.

Quando feita corretamente, as normas apoiam autonomia, fortalecem colaboração e mantêm as pessoas alinhadas, mesmo em um sistema descentralizado.

Capítulo 14 – Comunicação

Este último capítulo explora como a comunicação molda a cultura de uma organização e, em última instância, sua agilidade.

Sriram Narayan argumenta que, além dos organogramas e papéis, são os hábitos diários de comunicação que refletem (e às vezes sabotam) a agilidade.

Ele analisa de forma incisiva hierarquia, tom, ferramentas e até metáforas, mostrando como comportamentos pequenos podem ter um impacto enorme na colaboração, confiança e tomada de decisões.

Cultura de comunicação e motivação

Uma cultura de comunicação saudável aumenta a motivação intrínseca. Se as pessoas se sentem seguras, ouvidas e respeitadas, é mais provável que fiquem engajadas e criativas.

Mas, quando a comunicação é moldada por hierarquias rígidas ou protocolos não falados (como precisar de permissão para falar com o chefe do seu chefe), a colaboração sofre.

O capítulo defende uma comunicação intencional e igualitária — não apenas aberta em teoria, mas ativamente projetada para quebrar formalidades desnecessárias e fomentar o entendimento compartilhado.

Microagressões e hierarquia sutil

Narayan dedica uma grande parte do capítulo às microagressões, tanto verbais quanto não verbais.

Estas são as formas sutis (e nem tão sutis) de como o poder é exercido nas interações rotineiras.

Pense: o chefe que sempre faz ligações, mas nunca responde; que espera convites no calendário, mas os ignora; que zomba das ideias, mas não tolera discordância.

Esses comportamentos, embora pequenos isoladamente, corroem confiança e propósito.

O capítulo não os desculpa como peculiaridades de “altos desempenhos” — ao contrário, chama-os de prejudiciais para a cultura ágil.

Abordar esses padrões começa com conscientização, treinamento (como incluí-los na orientação de novos contratados) e ferramentas visuais, como gráficos de pulso, para refletir o clima emocional do time.

Comunicação bidirecional em escala

Escalar a comunicação além de pequenos times é desafiador.

Conversas um a um não escalonam, e grandes reuniões frequentemente se tornam transmissões unidimensionais.

Narayan critica canais típicos como all-hands, blogs internos e pesquisas, argumentando que são rasos demais para um engajamento real.

A melhor opção? Fóruns online — espaços assíncronos, pesquisáveis, onde os funcionários podem contribuir de maneira significativa.

Ele dá um ótimo exemplo de como uma empresa lidou com uma mudança de política controversa (terminando com o home office) ao abrir uma discussão de 10 dias, reconhecendo o feedback e explicando de forma transparente a decisão final.

Não fez todo mundo feliz, mas ajudou a construir confiança.

Deliberação escrita para melhores decisões

Uma das sugestões mais ousadas do capítulo é deliberar por escrito. Reuniões geralmente favorecem os falantes rápidos, os fluentes em inglês ou aqueles com mais senioridade.

Fóruns escritos nivelam o jogo. Eles permitem tempo para reflexão, reduzem reações emocionais e deixam um registro das decisões e argumentos.

Não se trata apenas de inclusão — é sobre melhor pensamento.

Narayan compara isso com o desenvolvimento de software: argumentos falados são como implantar em produção sem testes.

Escrever desacelera as coisas, sim — mas da melhor forma possível.

Auxílios visuais e a cultura de pitch

O capítulo critica os slide decks e a comunicação visual-first, especialmente quando usados sem contexto narrativo.

Apresentações em slides podem enganar, simplificar demais e priorizar a estética em vez da clareza. Narayan incentiva o retorno aos memorandos escritos, citando o famoso formato de seis páginas da Amazon.

Ele também critica a crescente cultura de pitch, onde apresentações sofisticadas superam substância e os tomadores de decisão agem como investidores esperando serem impressionados.

Em organizações ágeis, os líderes devem ser ouvintes, não apenas guardiões.

O objetivo é decisões ponderadas, não apresentações teatrais.

Modelos e documentação

Por fim, o capítulo aborda documentos e modelos. Narayan desafia a crença de que modelos padrão garantem consistência. Em vez disso, eles frequentemente impõem uniformidade e burocracia.

Organizações ágeis se saem melhor com diretrizes e listas de verificação opcionais, permitindo que os times se comuniquem de forma clara sem se prenderem a formatação rígida.

Este capítulo é um lembrete poderoso de que como falamos, ouvimos, escrevemos e compartilhamos é tão importante quanto qualquer framework ágil ou estrutura de time.

A cultura não é apenas o que dizemos nas town halls — é como nos tratamos nos corredores, caixas de entrada e chamadas de Zoom.

Capítulo 15 – O Escritório

Neste capítulo final, Sriram Narayan traz o foco para um espaço que todos nós habitamos diariamente, mas raramente consideramos como uma ferramenta estratégica: o escritório em si.

Embora o layout físico possa parecer um ponto secundário na transformação ágil, o autor argumenta que o design do escritório influencia diretamente colaboração, autonomia, comunicação e até a cultura organizacional.

O objetivo é criar um ambiente que apoie interações espontâneas e intencionais — sem sacrificar privacidade, conforto ou foco.

Layouts abertos e proximidade das equipes

Escritórios em layout aberto são preferidos para fomentar a colaboração presencial. Mas isso não significa colocar mesas grandes aleatoriamente pelo escritório.

O layout deve estar alinhado aos resultados de negócios: equipes que trabalham em direção aos mesmos objetivos devem sentar juntas, sem serem separadas por funções como desenvolvimento ou testes.

Paredes móveis podem ser usadas para reduzir distrações e recuperar espaço nas paredes para informações radiadoras — quadros físicos, pôsteres e lousas que apoiam o pensamento visual e a consciência compartilhada.

Salas de reunião centralizadas ajudam a quebrar o layout do escritório naturalmente, enquanto maximizam o acesso às janelas para os espaços de trabalho das equipes.

Privacidade, solidão e necessidades ergonômicas

Layouts abertos também têm desvantagens.

As pessoas precisam de espaços silenciosos para trabalho focado — como escrever, pensar ou fazer ligações privadas.

Por isso, o livro recomenda oferecer salas privadas para uso individual, zonas silenciosas e ferramentas de privacidade para telas.

A remoção de cubículos implica em perda de armazenamento pessoal, então armários podem ser uma adição útil.

Ergonomicamente, apenas laptops não são ideais. Monitores externos, bandejas retráteis, mesas de pé e tapetes contribuem para espaços de trabalho mais saudáveis e funcionais.

Críticas aos layouts abertos e perspectivas equilibradas

Narayan não ignora as crescentes críticas aos escritórios em plano aberto.

Ele cita estudos e autores como Susan Cain, que argumentam que tais layouts reduzem produtividade e bem-estar.

Mas o autor também aponta que distrações existem em todos os ambientes — redes sociais, e-mails e mensagens estão sempre presentes.

A verdadeira solução não é sobre paredes, mas sobre design inteligente para equilibrar interação e foco.

Trabalho remoto: entre flexibilidade e interação presencial

A seção final explora o trabalho remoto, apresentando uma visão equilibrada dos prós e contras.

Os benefícios incluem menos interrupções, melhor recrutamento de talentos e avaliação baseada em resultados.

Mas surgem desafios em contextos IT-B, onde feedback rápido, aprendizado iterativo e co-criação são críticos.

Narayan sugere uma abordagem híbrida: permitir ocasionalmente o trabalho de casa, mas incentivar pelo menos dois dias por semana em que toda a equipe esteja no escritório.

Ele também compartilha dicas práticas para trabalho remoto eficaz, como usar salas de chat em equipe, compartilhamento de tela e acesso via VPN.

Curiosamente, ele compartilha sua própria mudança de mentalidade — de ser contra o trabalho remoto para ver seu valor quando relacionamentos fortes são construídos.

O espaço físico de trabalho não é apenas um cenário — ele é um facilitador poderoso (ou um bloqueador) para comportamentos ágeis.

Quando projetado com intenção, o escritório pode refletir e reforçar os valores de colaboração, igualdade e adaptabilidade.

Capítulo 16 – Conclusão

O capítulo final conecta tudo e oferece tanto um resumo quanto um alerta realista. Sriram Narayan revisita o propósito central do livro: ajudar as organizações a desenharem para agilidade, não apenas a adotarem métodos ágeis.

A grande ideia tem sido consistente ao longo de todo o livro — otimizar para valor em vez de previsibilidade, resposta em vez de eficiência de custo e motivação intrínseca em vez de extrínseca.

Esses não são apenas slogans — são os temas orientadores que moldaram toda a conversa sobre como as organizações de TI podem funcionar melhor, mais rápido e de forma mais humana.

Resumindo os problemas e soluções

O capítulo começa com uma tabela que organiza de forma clara os problemas organizacionais comuns e como abordá-los, categorizados pelos três temas principais do Capítulo 3.

Por exemplo, se você está preso a projetos dirigidos por planos que priorizam previsibilidade, a solução é migrar para equipes de capacidade orientadas para o valor.

Se serviços compartilhados ou ferramentas com base em permissão estão desacelerando a resposta, mude para equipes multifuncionais e acesso padrão aberto.

E quando a autonomia está sendo esmagada pela centralização ou metas, é necessário equipes orientadas a resultados, políticas vivas e normas operacionais claras.

Como adotar as mudanças

A transformação é difícil, e o autor não suaviza isso. Em vez disso, ele oferece um guia realista sobre o que abordar primeiro.

Algumas mudanças são mais fáceis — como publicar a estratégia de negócios ou esclarecer os direitos de decisão.

Outras, como mudar para um modelo de contratação baseado em habilidades ou eliminar serviços compartilhados, são mais difíceis, mas oferecem alto retorno.

A ideia é começar onde você pode fazer uma diferença significativa, sem sobrecarregar o sistema.

Serviços de TI e Centros de Serviços Internos Globais (GICs)

Uma grande parte da conclusão aborda empresas de serviços de TI e GICs, reconhecendo os desafios especiais que enfrentam.

As empresas de serviços muitas vezes operam sob contratos rígidos, dependem de métricas de utilização e seguem modelos centrados em projetos — todos os quais contrariam os princípios ágeis.

O autor argumenta que, a menos que essas empresas evoluam — em direção a equipes de capacidade, melhor colaboração com clientes e apoio à motivação intrínseca — elas ficarão para trás.

Da mesma forma, os GICs muitas vezes ficam presos em modelos ultrapassados, moldados por mentalidades legadas, culturas hierárquicas e processos excessivamente prescritivos dos tempos do CMMI.

A mudança é possível, mas exige liderança, humildade e a disposição para desaprender.

Além da TI

Curiosamente, os insights do livro não se limitam ao software ou à tecnologia.

Narayan admite que, embora o livro tenha se concentrado em TI, muitos de seus princípios — como equipes multifuncionais, planejamento orientado ao valor e trabalho centrado no propósito — se aplicam a diversos setores.

Ele dá exemplos da saúde, educação, bancos e mais, mostrando que a agilidade é uma mentalidade e um desafio de design do sistema, não apenas algo relacionado a software.

Uma mudança centrada no humano

A mensagem final é ao mesmo tempo prática e otimista.

Agile não é a única maneira de construir uma organização, mas é uma abordagem centrada nas pessoas, e é para onde o mundo parece estar indo.

Empresas que antes prosperavam com competição interna e previsibilidade rígida estão começando a se mover em direção à colaboração, confiança e flexibilidade.

É uma jornada longa, frequentemente desconfortável, mas que vale a pena.

E esse é o grande ensinamento: desenhe sua organização ao redor das pessoas — não apenas processos, estruturas ou métricas — e a agilidade virá.

Conclusão

Agile IT Organization Design é um livro que vai além das metodologias e cerimônias ágeis que estamos acostumados a ver.

Ele nos provoca a repensar a forma como estruturamos nossas organizações para que a verdadeira agilidade seja alcançada, e não apenas algo que fazemos dentro de um time.

Sriram Narayan nos ensina que a agilidade precisa ser um reflexo de como a empresa está desenhada como um todo, e não uma prática isolada de desenvolvimento de software.

O conceito de equipes permanentes, que são responsáveis por resultados reais de negócios ao invés de apenas entregar projetos temporários, é um dos maiores insights do livro.

Isso elimina as transferências intermináveis de conhecimento e cria um ambiente onde a evolução contínua se torna a norma, em vez de um esforço pontual.

Organizações que estruturam suas equipes dessa forma garantem que o aprendizado, a colaboração e a melhoria constante se tornam parte do dia a dia.

Outro ponto fundamental é a crítica à busca desenfreada pela previsibilidade.

O autor nos mostra que quando focamos apenas em cumprir prazos, perdemos o que realmente importa: resolver problemas reais de forma contínua.

A ideia de valor em vez de previsibilidade é libertadora.

Ela nos ensina a aprender com o que entregamos, adaptando o caminho e não nos prendendo a um cronograma rígido.

Essa mentalidade ajuda a criar um ambiente onde o erro é visto como uma oportunidade de aprendizado, não como um fracasso.

O livro também vai além de ser uma leitura para líderes de TI.

Ele oferece lições que qualquer um que esteja passando por uma transformação organizacional pode aplicar, seja no setor de saúde, educação ou até mesmo no financeiro.

A chave é construir uma estrutura organizacional que libere a autonomia das pessoas, criando ambientes de confiança, colaboração e propósito.

Agile IT Organization Design é um convite para refletir profundamente sobre como podemos construir empresas mais ágeis, não apenas em suas operações, mas em sua essência.