O Perigo de Ser o Único no Elevador: Construindo Comunidades de Arquitetos

Neste artigo · 8 seções

1. Quando só tem um arquiteto, tudo depende demais de uma pessoa só
2. Arquitetura não é talento individual, é capacidade organizacional
3. Por que comunidades de arquitetos resolvem esse problema
4. Não é sobre criar um comitê pesado, é sobre criar um fórum útil
5. Subindo e descendo o elevador em grupo
6. Comunidade forte depende de ego fraco
7. Conclusão: um arquiteto sozinho é sintoma, não solução
8. Insights & Takeaways

Tem um padrão que aparece em muita empresa: existe “o arquiteto”. Um só. Todo mundo sabe o nome dessa pessoa. Tudo que é decisão difícil, desenho complicado, conversa com diretoria, cai nela. Parece elogio, parece reconhecimento. Mas, na prática, isso costuma ser um sinal de problema estrutural sério.

Gregor Hohpe, em “The Software Architect Elevator”, fala do arquiteto que sobe e desce o elevador entre a sala de máquinas e a cobertura, conectando código com estratégia, times com liderança, realidade com PowerPoint. A imagem é ótima. O problema começa quando só tem uma pessoa fazendo esse papel. Aí você tem um gargalo ambulante.

Este artigo é sobre isso. Por que ser o único no elevador é perigoso para a pessoa e para a empresa, e como construir uma comunidade de arquitetos muda completamente a maturidade arquitetural de uma organização.

Quando só tem um arquiteto, tudo depende demais de uma pessoa só

Vamos ser bem literais: se só existe “o arquiteto”, essa pessoa vira dependência crítica. Planejamento, revisão de desenho, definição de padrões, alinhamento com negócio, negociação com fornecedores, tudo passa por ela.

Na prática, isso cria alguns efeitos bem previsíveis:

Primeiro, gargalo. As decisões demoram, não porque são complicadas, mas porque a agenda de quem decide está sempre lotada. Time fica esperando “o ok da arquitetura”, arquitetura fica sempre “apagando incêndio” em vez de pensar com calma. Hohpe comenta como arquitetos podem ser puxados para toda crise possível, virando “bombeiros de luxo”. Com um só arquiteto, isso é praticamente garantido.

Segundo, risco concentrado. Se essa pessoa sai, entra de férias, adoece, ou simplesmente queima, a organização perde contexto crítico. Conexões com stakeholders, histórico de decisões, visão de longo prazo. Tudo estava na cabeça de uma única pessoa.

Terceiro, cultura de delegar responsabilidade. Como “tem o arquiteto”, todo mundo empurra decisão difícil para ele. O time deixa de desenvolver musculatura arquitetural. Os tech leads deixam de praticar pensamento sistêmico. O resultado: toda a organização fica mais fraca, dependente de um especialista.

Na teoria, parece “ótimo” ter um arquiteto forte que resolve tudo. Na prática, é um modelo frágil, lento e caro.

Arquitetura não é talento individual, é capacidade organizacional

Esse é o ponto central. Arquitetura não deveria ser vista como atributo de uma pessoa, e sim como capacidade da organização.

Hohpe trabalha muito essa ideia: bons arquitetos constroem estruturas, processos e formas de pensar que continuam funcionando mesmo quando eles não estão na sala. A organização aprende a fazer melhores perguntas, a explicitar decisões, a enxergar sistemas em termos de trade-offs.

Se tudo depende de um arquiteto herói, essa capacidade não se espalha. Você tem um especialista, não uma competência organizacional.

A diferença é sutil, mas decisiva: Quando a capacidade está em uma pessoa, qualquer projeto que não passa por ela tende a sair torto. Quando a capacidade está na organização, vários times conseguem tomar boas decisões, com consistência mínima, sem depender de uma aprovação central para tudo.

Comunidade de arquitetos é justamente o mecanismo para transformar um talento isolado em algo que se multiplica.

Por que comunidades de arquitetos resolvem esse problema

Construir uma comunidade de arquitetos não é criar um “conselho pesado” que decide tudo, mas sim um grupo recorrente de pessoas que pensam arquitetura juntos. Isso inclui arquitetos formais, tech leads, engenheiros seniores que gostam de olhar para o sistema como um todo.

Hohpe, falando de arquitetos como “super glue”, já traz essa ideia de conexão entre partes distintas da organização. Uma comunidade de arquitetos é essa cola em modo ampliado. Alguns efeitos práticos:

O conhecimento se distribui. Em vez de um arquiteto conhecer tudo de integração, outro tudo de dados, outro tudo de segurança, você cria espaço para atravessar fronteiras. Um apresenta uma solução, outro questiona dependências, outro traz uma experiência de outro domínio. Isso evita cegueira e reforça o pensamento crítico coletivo.

As decisões ficam mais transparentes. Quando você discute decisões arquiteturais em grupo, com registro mínimo, o porquê das escolhas deixa de ficar preso na cabeça de uma pessoa. Qualquer time pode revisitar a decisão depois e entender o contexto. Hohpe insiste na importância de tornar decisões explícitas em vez de tratá-las como “verdades caídas do céu”.

O padrão mental se espalha pelos times. Com o tempo, tech leads aprendem a raciocinar como arquitetos. Começam a levar para a comunidade casos estruturados, com opções, trade-offs, riscos. Isso reduz a distância entre “quem projeta” e “quem implementa”.

Não é sobre criar um comitê pesado, é sobre criar um fórum útil

Muita gente, ao ouvir “comunidade de arquitetos”, pensa em comitê de governança chato, com ata, aprovações formais, blocos de veto. Isso é tudo que a gente não quer aqui.

A ideia, inspirada na visão prática de Hohpe, é muito mais leve. Algo na linha de: Reuniões regulares, com foco em casos reais. Menos “teoria geral da arquitetura”, mais “como vamos evoluir esse sistema crítico sem paralisar o negócio”. Formato de revisão colaborativa. Um time traz um desenho, explica o contexto, abre para perguntas, recebe sugestões. Não é tribunal, é consultoria coletiva. Registro simples de decisões importantes. Não um tratado, mas um “Decision Record” claro: qual era o problema, quais opções foram consideradas, qual foi a escolhida e por quê.

O resultado é que a comunidade vira um mecanismo de aprendizado organizacional. Quem participa leva repertório de um caso para outro. Quem está chegando aprende rápido, ao ver como a empresa pensa arquitetura.

Subindo e descendo o elevador em grupo

No livro, o arquiteto que usa o “elevador” é aquele que conversa tanto com a base técnica quanto com a liderança, traduzindo um mundo para o outro. Quando só uma pessoa faz isso, você tem um tradutor oficial. Quando você constrói uma comunidade, você começa a formar vários tradutores.

Alguns arquitetos são naturalmente mais fortes na parte técnica profunda. Outros sabem conversar com diretoria em termos de risco, retorno, prazo. Outros têm mais habilidade em navegar a política entre áreas.

Na comunidade, essas habilidades se somam. Quando um tema exige falar com negócio, um leva o outro. Quando um assunto é sensível tecnicamente, o arquiteto mais próximo do código ajuda a dar lastro à discussão.

Isso reduz o risco do “arquiteto estrela” que sobe sozinho, se desconecta da base técnica e acaba virando mais político do que técnico, exatamente o tipo de figura que Hohpe critica quando fala da torre de marfim.

Comunidade forte depende de ego fraco

Tem um componente humano que não dá para ignorar. Construir comunidade exige que os arquitetos (e aspirantes) larguem um pouco o apego ao papel de “dono da verdade”.

Quando só existe um arquiteto, é fácil cair no modo “guardião da arquitetura”, a pessoa que aprova ou reprova. Em comunidade, o jogo muda. Você continua tendo responsabilidade, mas distribui autoria. Decisão é mais discutida, o crédito é mais compartilhado.

Isso é mais saudável e mais escalável, mas fere um pouco aquela vaidade de ser o único que “entende tudo”. Hohpe, ao falar de arquitetos como agentes de mudança, deixa claro que mudança real não acontece sozinho, e que a tentativa de ser o herói único é insustentável em sistemas grandes.

Comunidade boa é aquela em que todo mundo entra para aprender e contribuir, não para defender território.

Conclusão: um arquiteto sozinho é sintoma, não solução

Se a sua organização depende de um único arquiteto para tomar decisões importantes, isso não é uma medalha. É um alerta. Significa que a capacidade arquitetural ainda está concentrada demais, que o pensamento sistêmico não espalhou e que o risco organizacional está alto.

Construir uma comunidade de arquitetos é um passo natural de maturidade. Não é burocracia, é criar um espaço onde decisões são discutidas, conhecimentos convergem e pessoas aprendem a pensar arquitetura juntas.

Quando isso acontece, o elevador deixa de ser um transporte privado de uma pessoa e vira algo que mais gente usa. Vários arquitetos, tech leads e engenheiros seniores passam a subir e descer, levar problemas reais, trazer respostas melhores. A organização fica menos dependente de heróis e mais capaz de mudar com consistência.

Em resumo, o perigo de ser o único no elevador é achar que isso é bom. O próximo nível é quando você não é mais o único, e isso, longe de diminuir sua importância, aumenta o alcance daquilo que você sabe fazer.

Insights & Takeaways

• Um único arquiteto centralizador vira gargalo e ponto de falha; isso reduz velocidade de decisão, aumenta risco e impede a organização de desenvolver capacidade arquitetural própria.
• Arquitetura deve ser tratada como competência organizacional, não como talento individual; comunidades de arquitetos são o mecanismo natural para espalhar esse modo de pensar.
• Uma boa comunidade de arquitetos funciona como fórum prático, focado em casos reais, revisão colaborativa e decisões explícitas, não como comitê burocrático.
• Vários arquitetos subindo e descendo o “elevador” juntos permitem combinar habilidades diferentes, mantendo conexão com código e com estratégia, evitando a famosa torre de marfim.
• Comunidade sólida depende de ego controlado; quanto menos o arquiteto se vê como “dono da verdade” e mais como facilitador, mais a organização cresce em maturidade arquitetural.