Transformação foi sem dúvida o desafio que sempre encontrei em cada empresa por onde passei: transformar arquitetura, a forma de desenvolver software, de tomada de decisão, de modelo operacional, de sourcing e muito mais.
O mercado, as empresas e todos os tipos de organizações são compostos na sua unidade mais básica por humanos e como tal precisam sempre de se movimentar para permanecerem vivas, ativas e perseguidoras dos seus sonhos. Nos dias atuais (e ainda mais acentuado por este momento de pandemia que nos privou muito do mundo físico) as grandes empresas tradicionais querem ser digitais (no seu mais amplo sentido), as que conseguem êxito querem ser como as nativas digitais, que por sua vez crescem e querem voltar a comportar-se como start-ups que foram um dia. Logo, é possível que o leitor imagine que ao estar numa start-up não existiria o desafio de se transformar o tempo todo, dando lugar ao genuíno e natural desafio de simplesmente crescer, certo? Não, grande engano!
Escalar nunca é somente escalar, requer algo mais do que simplesmente crescer. Voltamos então à tal transformação, assim como nas grandes empresas só que com outras motivações. Empilhar mais do mesmo pode ser fatal para start-ups em fase de scale-up que querem ter uma vida longa e sustentável enquanto organização de tecnologia. As dores do crescimento são grandes para empresas que crescem em muitos casos três dígitos ao ano e, comparando novamente a nós humanos, são oriundas da necessidade do corpo em se transformar para aguentar um tamanho maior que vem pela frente. Começo hoje então a escrever sobre uma série de transformações necessárias às start-ups, scale-ups ao longo na sua jornada no que tange ao robustecimento do seu corpo de tecnologia.
Uma área de tecnologia de uma start-up muitas vezes nasce sendo a própria empresa e resumindo-se a uma mesa com dois engenheiros e um fundador em busca de um MVP. As coisas correm bem (e o dinheiro entra), logo essa mesa ganha mais dois ou três devs, que daqui a pouco já não cabem numa mesa e novas destas aparecem ao lado, e mais outra e outra e quando se percebem já não cabe mais numa sala ou um andar. Este ciclo virtuoso do crescimento traz mais atenção de investidores e fundos e junto com este fenómeno maravilhoso muita necessidade de se transformar. Sim, aquela start-up já é uma adolescente, ou melhor uma scale-up, e decisões importantes caberão ao CTO.
Um dos primeiros desafios que surge é especializar a equipa em funções que até então eram executadas pelos engenheiros. Aquele engenheiro que até então “era bom em tudo” e fazia de tudo um pouco continua a “ser bom em tudo”, mas não consegue mais fazer tudo aquilo que se espera dele. O tamanho do desafio de cloud engineering por exemplo já requer alguém especializado, segurança da informação já não consegue ser tratada totalmente descentralizada apesar de toda a prática DevSecOps nas equipas. Pronto, chegou a hora em que temos de falar sobre os diferentes percursos de carreira da equipa tech.
Criar estruturas verticalizadas por especialidade provoca sempre o receio da equipa (principalmente os engenheiros mais antigos e polivalentes) em “engessar”, perder agilidade, burocratizar e outros termos mais que sempre remetem a perda de velocidade e de um ambiente mais autónomo. E estão certos! Por isso, esta verticalização de especialidades deve ser feita com todo o cuidado que merece, mantendo o que chamo da teoria da centralidade mínima necessária; ou seja: todo o poder e liberdade deve ser preservada “na ponta”, que quer dizer nas equipas, nas squads, tribos ou seja lá o nome que se dá à organização multidisciplinar que entrega software em produção. Para que a centralidade seja realmente a mínima necessária, alguns modelos fazem muito sentido por conseguirem preservar a agilidade sem abrir mão de padrões importantes a um grupo e engenharia de software sustentável:
Uma competência organizada na forma “hub and spoke” significa criar uma camada mínima de engenheiros/especialistas chamada hub como uma estrutura central para desempenhar as atividades normalmente comuns a todas as equipas (como por exemplo a construção do pipeline de desenvolvimento e deployment que todos os engenheiros usarão para a entrega dos seus microsserviços) que por sua vez comunica diretamente com profissionais distribuídos nas equipas (spokes) que desempenham as suas tarefas de forma descentralizada e alinhadas ao contexto específico daquela equipa que tem certamente particularidades de negócio, arquiteturais entre outras.
Existem alguns casos onde a competência é tão fortemente acoplada a uma outra “competência irmã” que faz sentido não manter nem um pequeno hub centralizado para evitar maiores rupturas que prejudiquem a entrega de software. É o caso por exemplo das competências de arquitetura de solução, arquitetura de aplicação e o desenvolvimento em si. Estruturar uma área de arquitetura de soluções pode gerar uma sensação ruim de perda de autonomia pelos engenheiros que codificam reduzindo a responsabilidade saudável da equipa pela entrega final de valor. Neste caso então o mais recomendado seria estruturar chapters ou guilds com o grupo de engenheiros que trabalham mais próximos do refinamento dos épicos em soluções para que regularmente se reúnam para discutirem e definirem padrões arquiteturais, fazerem os alinhamentos necessários e tomarem decisões importantes para a arquitetura e para o negócio. Não há dúvida de que se perde um pouco a sensação de domínio, mas ganha-se muito no sentimento de accountability da equipa e, se bem liderado pelos chapters leads capacitados para tal missão consegue-se resultados surpreendentes.
Nas próximas edições vamos falar sobre outros desafios igualmente importantes na jornada de crescimento de organizações de tecnologia no que se refere a arquitetura, modelo operacional, inovação e tudo mais neste sentido.
Até a próxima!
Artigo de Bruno Martins, autor no MIT Technology Review Brasil (adaptado).
MIT Technology Review