Construindo equipes de TI

Organizar times de TI que realmente entreguem valor de forma sustentável é um dos maiores desafios das empresas modernas. Assim, o livro Team Topologies, oferece um modelo claro e pragmático para lidar com esse problema, propondo uma estrutura de times que reduz a sobrecarga cognitiva, melhora a colaboração e acelera a entrega. Então, no artigo Construindo equipes de TI, vamos explorar como aplicar esse modelo na prática, entender suas relações com o design organizacional tradicional, conhecer os aprendizados da Spotify e refletir sobre como estruturar sua equipe para escalar sem se perder no caos.

Mas, além do artigo Construindo equipes de TI, aqui no blog também temos diversos outros artigos sobre kubernetes, desenvolvimento, gestão, devops, etc. Veja alguns exemplos: Diferenças entre Paradigmas, Axiomas e Hipóteses, Desenvolver na empresa ou comprar pronto, Fuja da otimização prematura, entre outros.

Design Organizacional

Em 1967 Melvin Conway fez a seguinte citação “Qualquer organização que projeta um sistema ou solução, produzirá um projeto cuja estrutura é uma cópia da estrutura de comunicação da organização”. Veja que incrível é essa frase ser muito poderosa mesmo na segunda década do século seguinte. A ideia é que se a empresa é centralizadora, seu software também será. Se a empresa é dividida em silos que pouco se comunicam, seu software será um bloco de monolitos distribuídos. Se ela é cooperativa e matricial, seu software será baseado em microcomponentes distribuídos e comunicantes. Essa teoria realmente é muito forte.

Muitas empresas trabalham com o modelo de design por função (vendas, marketing, operações), outros com o modelo matricial (TI, RH por exemplo, que atendem vários setores), e por aí vai. Veja que o design organizacional deve ser construído como um desmembramento da cultura corporativa, promovendo o fluxo de poder e influência desejado. Isso habilita uma comunicação adequada, o compartilhamento de valores, cultura, do modelo de liderança, e se não for bem feita gera fricção, processos desnecessários e redundantes. Outro ponto comum é designs ruins criarem níveis de gestão desnecessários e blocos com muitos caciques para poucos índios.

Modelo Spotify é para o Spotify

Compreendido isso fica claro que não se trata de simplesmente a construção de um organograma. Ele reflete apenas a visão meramente formal das relações de poder, mas não as informais, não demonstra processos, como as mudanças se dão, o que é central para o negócio ou secundário. Na verdade até pode dizer essas coisas, mas só se for muito bem construído.

Construindo equipes de TI

A Spotify criou um modelo de organização que foi muito adotado, pelo menos em partes, que traz uma forma particular de tratar esse problema, como um framework pré-definido. O conceito de squads vem daí, mas veja que tem empresas que a maturidade de ágil é -1, mas ainda assim eles chamam de squad. Veja que a Spotify estava tão madura em agilidade com ágil que foi criando particularidades e, daí, fez esse modelo.

Ele se baseaia em squads: menor célula, responsável pela criação dos incrementos de produtos ou features. É muito semelhante ao scrum team, sempre com um time multidiscuplinar, com total independência na evolução de um determinado produto ou feature. E os squads são agrupados em tribes.

No modelo há também estruturas não lineares, como os chapters, onde squads com características comuns se agrupam. Imagine uma empresa com 200 squads, mas 20 delas programam em C++: elas podem se organizar num capítulo. Há também a guilds onde pessoas de diversas squads de maneira mais independente tem ações particulares. Imagine, por exemplo, uma guilda bancos de dados.

Modelo unFIX é para todos?

Esse modelo se popularizou muito, mas muitos erraram porque não era para adotá-lo, e tiveram que voltar atras. Surge em 2022 o unFix, como uma proposta para uma flexibilidade na montagem do designs organizacionais. Ele não é um framework mas sim uma biblioteca para design organizacional. Ela tem uma proposta mais neutra e tem nomenclatura e características próprias. Ela tem conceitos como Crew (governance cres, partnership crew, platform crew, experience crew, facilitation crew) e vários elementos particulares que não serão detalhados nesse artigo (até porque não os domino).

Team Topologies

O Livro Team topologies é de 2019 e serve como uma fundamentação para estruturação de times de TI. Ele não é diferente do propósito do unFix. Entretanto o unFix se propoe a ser um modelo genérico, válido para qualquer organização sem necessariamente ter correlação com TI. Na prática o time responsável pelo design organizacional pode utilizar o modelo abstrato do unFix para definir uma organização e definir uma compatibilidade com team topologies.

Bom, os autores estudaram empresas como spotify, Ericsson, e diversas outras de diversos tamanhos. Eles observaram como os times crescem e como isso se estrutura. Eles notaram 4 tipos de time: stream-aligned team, enabling team, complicated-subsystem team e platform team. Além disso elas possuem 3 modelos de comunicação: collaboration, x-as-a-service, facilitating. O livro explora essas questões norteados pela ideia de reduzir o impacto cognitivo nos profissionais. Na visão deles a carga cognitiva impacta diretamente na qualidade e na escalabilidade dos times.

Modelos de time

Stream-Aligned Team: São os times de produto, alinhados a uma stream de valor. Ou seja: lidam com uma funcionalidade do início ao fim: da ideia ao código em produção. Esse time é o protagonista e deve ser preservado de distrações.

Enabling Team: São especialistas temporários que apoiam os stream-aligned em temas complexos como segurança, acessibilidade ou testes automatizados. São como consultores internos: ajudam temporariamente, cumprem suas missão e finalizam.

Complicated Subsystem Team: Cuidam de partes altamente especializadas e complexas. Pense, por exemplo, codecs de vídeo, algoritmos de machine learning ou qualquer coisa que precise de especialistas para tratar. O stream-aligned poderia tratar, mas gastaria uma energia que não compensa.

Platform Team: Dão suporte criando plataformas internas: CI/CD, observabilidade, autenticação, cloud, etc. Tudo aquilo que o time de produto precisa, mas não quer (nem deve) reinventar.

Formas de relação entre os times

Collaboration: quando é preciso trabalhar junto de forma intensa, como numa transferência de conhecimento ou criação conjunta.

X-as-a-Service: quando um time usa um serviço de outro, como se fosse uma API interna. Ideal para a plataforma.

Facilitating: quando um time ajuda o outro a evoluir, mas sem carregar a entrega final. Papel típico dos enabling teams.

Conclusão de Construindo equipes de TI

Mais do que uma nova modinha de organograma, Team Topologies nos convida a repensar a estrutura e como seguimos construindo equipes de TI com base em fluxo de valor, foco e clareza de responsabilidades. Quando combinamos esse modelo com uma boa leitura da cultura organizacional e com práticas modernas como as da Spotify ou do unFix, conseguimos montar times mais leves, eficientes e resilientes. Reduzir a carga cognitiva, evitar silos e promover colaboração saudável são fatores determinantes para que a tecnologia deixe de ser gargalo e passe a ser motor de inovação.