Qual a relação?

Preocupação constante do RH de empresas de tecnologia é estabelecer uma cultura de colaboração e integração entre os times, visando tanto o bem-estar quanto a geração de resultados.

Para isso, são realizadas diversas iniciativas, como desenvolvimento da liderança, team building, onboarding, avaliação 360°, plano de comunicação, entre outras, todas com o objetivo de reforçar os valores da empresa.

Entretanto, a formação de silos, os atritos e a competição interna por recursos parecem nunca diminuir, e aquela cultura baseada na colaboração e integração entre os times fica cada vez mais distante.

Por que isso acontece?

Uma das principais causas que alimentam a formação de silos e impedem a colaboração entre os times está diretamente relacionada à arquitetura de software.

Como assim?

Imagine que uma empresa de tecnologia pode operar tanto como um prédio de torre única quanto como um condomínio de várias casas.

🏢 Quando ocorre um vazamento em um andar do prédio, outros andares precisam ser acionados para conter o problema. Ou, quando falta luz no prédio, todos os apartamentos são impactados.

🏘️ Já em um condomínio de casas, o vazamento ou a falta de luz em uma casa não afeta as casas vizinhas, podendo inclusive ser consertado sem impactar as demais.

Na arquitetura de software, temos cenários parecidos.

Hoje, os dois principais tipos de arquitetura são: monolítica e microsserviços. 

A primeira se assemelha à estrutura de um prédio; a segunda, a casas de condomínio.

Existem prós e contras técnicos para cada uma delas, e há empresas que ainda combinam ambas as arquiteturas.

A questão é que, em uma estrutura monolítica, é quase impossível operar no modelo funcional de OKRs (onde cada time tem seus próprios OKRs), dada a alta interdependência entre as áreas.

Um time só consegue implementar mudanças se outros times também participarem da ação. Mas, se esses outros times têm seus próprios OKRs, eles também têm outras prioridades e mudanças a realizar.

É nesse momento que a formação de silos, a falta de colaboração e a competição interna por recursos se acentuam. E, infelizmente, não há liderança, team building, onboarding, avaliação 360° ou plano de comunicação que resolva essa situação.

A única forma de mitigar esse problema é alterando a estrutura dos OKRs: saindo do modo funcional para operar no modo matricial.

No modo matricial, não existem mais OKRs individuais por time. O que passa a existir são OKRs estratégicos, desdobrados em processos que, por sua vez, são compartilhados entre os times.

Os times funcionam como ligas multifuncionais, que trabalham para atender a um ou mais processos.

O sucesso dos processos viabiliza o sucesso dos OKRs.

Essa lógica funciona tanto para arquiteturas monolíticas quanto para microsserviços.

Portanto, minha dica para líderes de RH: conversem com os líderes de tecnologia, entendam como está modularizada a arquitetura de software e planejem a migração dos OKRs para o modo matricial.