Design organizacional – Times, plataformas ou competências compartilhadas: como organizar tecnologia sem duplicar estruturas

Um modelo prático para decidir quais competências precisam estar dentro dos times, quais podem gerar capacidades reutilizáveis de plataforma e quais devem permanecer compartilhadas.

Quando módulos, APIs, competências e soluções começam a se repetir entre diferentes times, uma pergunta costuma aparecer rapidamente:

Precisamos reorganizar a estrutura?

Recentemente, recebi uma pergunta de um consultor que estava apoiando um Head de Tecnologia exatamente nesse cenário.

A empresa tinha um time relativamente enxuto, estava revisando seu planejamento estratégico para os próximos anos e começava a perceber redundâncias na utilização de módulos e APIs da sua plataforma.

Diferentes times precisavam de competências semelhantes. Algumas soluções estavam sendo construídas mais de uma vez. Componentes que poderiam ser reutilizados nem sempre eram compartilhados.

A pergunta que chegou até mim foi:

Qual é a melhor forma de organizar um time, virtual ou não, para reduzir essas redundâncias e tornar a plataforma mais modular e reutilizável?

É tentador responder imediatamente com um desenho.

Um time de plataforma? Um chapter? Um grupo virtual de arquitetura? Uma estrutura matricial?

Frameworks como Team Topologies, unFIX e Org Topologies nos dão várias possibilidades.

Mas eu começaria antes disso.

Antes de desenhar os times, precisamos entender quais resultados eles precisam ser capazes de entregar.

O desenho não deveria começar pela movimentação de pessoas

Quando discutimos design organizacional, é muito fácil transformar a conversa em um exercício de movimentação de caixas.

• Onde colocamos arquitetura?
• Onde colocamos dados?
• Precisamos de um time de IA?
• SAP deveria ser uma área compartilhada?
• Quem fica responsável pelas APIs?

São perguntas importantes. Só não deveriam ser as primeiras.

A pergunta anterior é:

Quais são os fluxos que precisam conseguir entregar resultado ponta a ponta?

Essa mudança parece pequena, mas altera bastante o desenho.

Em vez de começarmos pela estrutura atual e tentarmos redistribuir pessoas, começamos pelo trabalho que a organização precisa realizar e pelos resultados que precisa produzir.

Primeiro, identificamos os fluxos de valor, produtos, serviços ou domínios que precisam assumir responsabilidade clara por resultados.

Visualmente, o primeiro desenho deveria ser algo simples:

Antes de definir a estrutura dos times, identifique quais fluxos precisam assumir responsabilidade por resultados ponta a ponta.

Não começamos por SAP, dados, IA ou arquitetura. Primeiro desenhamos os fluxos.

Depois perguntamos:

Quais competências esses times precisam ter para conseguir entregar esse resultado?

Só então começamos a discutir a estrutura.

Autonomia não significa colocar todas as competências em todos os times

Aqui aparece outro risco.

Se queremos times mais autônomos, parece lógico colocar dentro de cada time todas as competências necessárias.

Produto. Engenharia. UX. Dados. Arquitetura. Segurança. IA. Infraestrutura.

Mas podemos simplesmente trocar um tipo de dependência por outro tipo de desperdício.

Antes tínhamos dependências demais.

Agora podemos passar a ter duplicação demais.

Em organizações com times mais enxutos, isso fica ainda mais evidente. Muitas vezes não existe escala suficiente para replicar cada especialidade dentro de cada fluxo.

Por isso, a pergunta não deveria ser:

Como tornamos cada time completamente autossuficiente?

Uma pergunta mais útil é:

Qual é a menor combinação sustentável de competências que permite a esse time assumir responsabilidade real pelo resultado?

A partir daí, podemos analisar cada competência de três formas.

1. Essa competência precisa estar próxima do fluxo?

Comece perguntando:

Essa competência precisa estar próxima do fluxo para que o time consiga entregar resultado ponta a ponta?

Se a ausência daquela competência cria dependências frequentes, handoffs ou impede decisões cotidianas, existe um bom argumento para aproximá-la do time responsável pelo fluxo.

É uma lógica próxima aos Stream-aligned Teams, do Team Topologies, e aos Value Stream Crews, do unFIX.

Mas o nome é secundário.

O que buscamos é criar times com escopo de atuação suficiente para assumir responsabilidade sobre um fluxo relevante de trabalho e seus resultados.

Nesse cenário, a competência se aproxima do fluxo:

Quando uma competência é necessária de forma recorrente para entregar o resultado ponta a ponta, faz sentido mantê-la próxima ao fluxo e incorporada ao time.

Quando aquela competência é necessária de forma recorrente para entregar o resultado, aproximá-la do fluxo reduz handoffs e dependências.

O ponto importante é que não estamos desenhando times para ocupar uma estrutura.

Estamos desenhando uma estrutura capaz de produzir determinados resultados.

2. Essa competência pode gerar uma capacidade de plataforma?

Agora imagine outra situação.

Diferentes produtos precisam utilizar autenticação, pagamentos, notificações, análise de risco, determinados serviços de infraestrutura ou APIs comuns.

Construir essas soluções novamente dentro de cada fluxo provavelmente não aumenta a autonomia.

Aumenta custo, inconsistência e manutenção.

Nesse caso, a pergunta muda:

Essa competência produz algo utilizado repetidamente por diferentes fluxos e que pode ser oferecido com uma interface clara e baixo acoplamento?

Se a resposta for sim, aquilo que essa competência produz pode ser uma boa candidata a se transformar em uma capacidade de plataforma.

Essa distinção é importante.

A competência está nas pessoas e nos times: conhecimento de engenharia de plataforma, segurança, pagamentos, infraestrutura ou arquitetura, por exemplo.

A plataforma transforma parte desse conhecimento em algo que a organização consegue oferecer e reutilizar: APIs, módulos, serviços, componentes, ferramentas ou infraestrutura consumível pelos demais times.

O desenho muda:

Quando o resultado de uma competência pode ser reutilizado por vários fluxos com uma interface clara, ele pode ser oferecido como uma capacidade de plataforma.

A ideia é simples:

o que é comum não precisa ser duplicado; pode ser disponibilizado para que diferentes times consumam quando precisarem.

Mas existe uma distinção importante.

Centralizar uma competência não a transforma automaticamente em plataforma.

Se criamos um “Platform Team” que recebe tickets dos outros times, acumula uma fila de demandas e precisa participar de cada implementação, apenas mudamos o nome de uma dependência.

Uma plataforma deveria fazer justamente o contrário:

reduzir a necessidade de coordenação entre os times.

Quanto mais uma capacidade puder ser descoberta, compreendida e consumida pelos próprios times, maior seu potencial de funcionar verdadeiramente como plataforma.

Por isso, “todo mundo usa” não é critério suficiente.

Precisamos perguntar:

Conseguimos transformar o resultado dessa competência em algo reutilizável e consumível pelos diferentes fluxos com baixo acoplamento?

Se sim, temos uma boa candidata a plataforma.

3. Essa competência precisa mesmo estar em todos os times?

Existe ainda uma terceira possibilidade que costuma receber menos atenção.

Nem toda competência precisa estar dentro de todos os times.

E nem toda competência compartilhada precisa virar plataforma.

Imagine uma empresa com três fluxos de produto, mas apenas alguns deles utilizam intensivamente Machine Learning.

Faria pouco sentido replicar especialistas em ML nos demais apenas para manter a ideia de que todos os times precisam possuir as mesmas competências.

Da mesma forma, competências especializadas em dados, segurança ou arquitetura podem ser necessárias em diferentes contextos, mas não com frequência suficiente para justificar sua presença permanente em cada fluxo.

Nesse caso, podemos manter uma competência especializada compartilhada.

Competências raras ou altamente especializadas podem ser compartilhadas entre alguns times sem precisar fazer parte de todos os fluxos de valor.

Observe uma característica importante do desenho:

o Produto A nem sequer utiliza aquela competência.

E está tudo bem.

Autonomia não exige que todos os times possuam exatamente as mesmas competências.

Frameworks diferentes oferecem maneiras diferentes de estruturar essa relação.

O unFIX trabalha com diferentes tipos de Crews e Capabilities. Team Topologies oferece conceitos como Enabling Teams e Complicated Subsystem Teams.

Mais importante do que escolher a nomenclatura correta é entender qual interação precisamos criar.

• A competência precisa estar permanentemente próxima do fluxo?
• O resultado dessa competência pode ser consumido como serviço?
• Ou essa competência precisa entrar apenas em determinados momentos?

Essa resposta muda o desenho.

Competência no fluxo, plataforma ou competência especializada?

Podemos transformar todo esse raciocínio em três perguntas simples:

Três perguntas ajudam a escolher uma estrutura coerente com a forma como cada competência contribui para os fluxos de valor.

Esse exercício é mais importante do que escolher previamente um framework.

A lógica pode ser resumida assim:

O desenho começa pelos fluxos de valor e pelas competências necessárias para entregar resultados, não pela estrutura organizacional existente.

Primeiro desenhe os fluxos. Depois identifique as competências necessárias.

• O que precisa estar próximo do fluxo fica no time.
• O que pode ser transformado em algo reutilizável e consumido como serviço é candidato a plataforma.
• O que é específico, raro ou contextual pode permanecer como competência especializada compartilhada.

Só depois disso o desenho organizacional começa a ganhar forma.

E quando não temos pessoas suficientes para criar um Platform Team?

Esse era um aspecto importante da situação que originou essa discussão.

O time era enxuto.

Criar uma nova estrutura dedicada poderia simplesmente aumentar o custo organizacional sem resolver a causa das redundâncias.

Nesse cenário, não precisamos transformar toda decisão de design organizacional imediatamente em uma nova estrutura formal.

Podemos começar menor.

Pessoas que hoje estão distribuídas pelos diferentes times podem assumir conjuntamente a responsabilidade de identificar redundâncias, definir padrões e descobrir quais soluções realmente merecem ser transformadas em componentes compartilhados.

Pode ser um crew virtual de plataforma, por exemplo.

Uma plataforma pode começar de forma enxuta, reunindo virtualmente pessoas de diferentes times para identificar padrões, reduzir duplicidades e habilitar reuso.

As pessoas continuam pertencendo aos seus times.

O que muda inicialmente é a responsabilidade transversal que algumas delas passam a assumir.

O objetivo não é criar mais uma área.

É descobrir se existe ali uma responsabilidade recorrente que justifique uma estrutura dedicada.

Se, com o tempo, surgir um conjunto contínuo de capacidades compartilhadas, consumidores internos claros e trabalho suficiente para justificar dedicação exclusiva, esse arranjo pode evoluir.

Nem toda plataforma precisa começar como um time dedicado. A estrutura pode evoluir conforme a recorrência do problema, a responsabilidade e a necessidade de escala aumentam.

Isso cria uma evolução muito mais saudável:

coordenação → ownership → produto interno

em vez de:

problema → nova área.

Não precisamos criar uma nova área para descobrir se precisamos de uma nova área.

Org Topologies ajuda a enxergar outro aspecto do desenho

Existe ainda outra lente útil nessa discussão.

O Org Topologies propõe observar uma unidade organizacional considerando, entre outros elementos, duas dimensões particularmente interessantes para esse problema:

• o escopo de atuação que damos ao time;
• as competências disponíveis para executar aquele trabalho.

Traduzindo isso para uma conversa executiva:

Quanto daquele resultado o time realmente consegue assumir?

Ele possui acesso às competências necessárias para fazer isso acontecer?

Em organizações altamente especializadas, é comum encontrarmos times com escopos de atuação estreitos.

Cada área possui uma parte do conhecimento.

Cada área executa uma parte do trabalho.

E o resultado precisa atravessar várias delas.

Podemos representar o movimento desejado de maneira simplificada:

O desenho dos times pode ser orientado pela combinação entre escopo de trabalho e amplitude das competências necessárias para entregar resultados.

Não significa que toda a organização precisa migrar para o mesmo ponto.

Esse é justamente o cuidado.

Quando aproximamos determinadas competências dos fluxos de valor, ampliamos o escopo de atuação desses times e aumentamos sua capacidade de responder por resultados mais completos.

Mas aumentar a autonomia não significa eliminar todas as dependências.

Algumas competências continuam compartilhadas.

Algumas dão origem a capacidades oferecidas como plataforma.

Outras permanecem próximas dos fluxos.

O objetivo não é construir uma organização em que ninguém dependa de ninguém.

Isso provavelmente nem seria desejável.

O objetivo é construir uma organização na qual as dependências existentes sejam intencionais, claras e façam sentido para o resultado que queremos produzir.

O debate não é centralizar ou descentralizar

Quando começamos pela estrutura, discussões de design organizacional frequentemente terminam em escolhas binárias.

• Centralizar ou descentralizar?
• Times funcionais ou times de produto?
• Especialistas ou generalistas?
• Plataforma ou autonomia?

Na prática, organizações precisam combinar essas soluções.

O desafio da liderança é decidir onde cada uma delas faz sentido.

Por isso, quando você olhar para uma organização com APIs duplicadas, competências espalhadas e times excessivamente dependentes uns dos outros, resista à vontade de começar desenhando o novo organograma.

Comece com três perguntas:

1. Quais fluxos precisam assumir responsabilidade por resultados ponta a ponta?
2. Quais competências precisam estar próximas desses fluxos para que isso seja possível?
3. Entre as competências restantes, quais podem gerar capacidades reutilizáveis de plataforma e quais precisam continuar compartilhadas?

Depois desenhe os times.

Porque design organizacional não deveria começar pela pergunta:

“Onde colocamos as pessoas?”

Deveria começar por outra:

“Que resultados precisamos ser capazes de produzir — e que organização torna isso possível?”

Para continuar a discussão

Esse raciocínio complementa duas discussões que já exploramos anteriormente na Nower:

• Os 4 Estágios de Maturidade Organizacional: Uma Jornada Para Mapear e Evoluir Sua Empresa — uma visão sobre como diferentes estruturas respondem a diferentes contextos e objetivos.
• Design Organizacional na Prática: Modelos de Time por Estágio de Maturidade — uma exploração dos tipos de times que começam a surgir conforme ampliamos autonomia e orientação a resultados.

Neste artigo, avançamos mais um passo:

como decidir, na prática, quais competências precisam estar dentro desses times, quais podem gerar capacidades reutilizáveis de plataforma e quais devem permanecer compartilhadas.

Frameworks como Team Topologies, unFIX e Org Topologies são ótimas referências para fazer esse desenho.

Mas são justamente isso: referências.

O ponto de partida continua sendo o problema que queremos resolver.