Estrutura de Engenharia na Avenue
Olá, pessoal!
Hoje quero falar sobre um tema que nem sempre recebe a devida atenção: a complexidade de gerenciar times grandes de engenharia de software e dados.
Vou compartilhar um pouco sobre como estamos estruturados na Avenue em termos de times e stack tecnológica, mas antes, um pouco de contexto...
Iniciei minha carreira na área de tecnologia em 2004 e fui crescendo profissionalmente até assumir a liderança do meu primeiro time (ainda não existia o conceito de squad naquela época, rs). Nesse momento, pude aplicar muitas práticas que aprendi em cursos e treinamentos de gestão, além de aprimorar minhas soft skills, promovendo 1:1s, construindo PDIs, etc.
Os times naturalmente foram crescendo e, em 2022, minha equipe já contava com mais de 200 engenheiros (incluindo lideranças, desenvolvedores BE, FE, Mobile, QA e Agile Masters). Nesse ponto, você se pergunta: e agora? Não é mais viável agendar 200 1:1s ou construir 200 PDIs. É aí que entra a rede de liderança (coordenadores e gerentes) que apoia o time no dia a dia e sente as dores mais de perto, permitindo um fluxo de melhoria contínua saudável.
Com um time desse tamanho, as lideranças entre gestores e especialistas somavam cerca de 30 pessoas. Como manter esse grupo homogêneo e transmitir a mesma mensagem sobre estratégia, pivotamento, troca de prioridades e outros desafios do dia a dia, sem criar vieses e evitando a comunicação estilo "telefone sem fio"?
Voltando ao presente… Como estamos hoje na Avenue.
Atualmente nosso time de engenharia conta com mais de 100 pessoas e estamos organizados em formato de tribos para cobrir grandes contextos como investimentos, banking e aquisição. Dentro das tribos, temos squads que trabalham em um produto de ponta a ponta (exemplos: squad de cartões, squad de pagamentos, etc).
Nossa liderança é composta por 5 gerentes (engineering managers) que reportam diretamente para mim, e estamos na estrutura executiva do CTO (que também abrange as áreas de fraudes, cyber, infra, produtos e design).
Temos 27 squads divididas entre 7 tribos, incluindo um time de plataforma (assunto para outro post). Contamos com 9 coordenadores (engineering leads) e 14 especialistas (incluindo staffs e staffs Sr). Considero essa escala bem equilibrada, com uma média de 1 staff para cada 10 engenheiros de software ou 1 EL para cada 8 engenheiros de software.
Nossa stack tecnológica inclui GCP – Google Cloud, Golang, .NET, React, Dart/Flutter, RabbitMQ, entre outras. Desde o D0, nosso sistema foi concebido com o conceito de módulos e microserviços, o que nos trouxe o grande benefício de evitar monolitos ou acoplamentos críticos que poderiam colocar o negócio em risco. Utilizamos um híbrido de repositórios no github, conforme explicado pelo Rafael Vargas neste post: Monorepo vs Polyrepo, qual escolher ?
Quais são nossos maiores desafios. E quais ferramentas utilizamos para trabalhar com isso.
Ótimo contexto, mas como gerir tudo isso e garantir harmonia, equilíbrio, felicidade e alta performance?
Do último ano pra cá, procuramos alinhar muito bem o roadmap de tecnologia com os OKRs e a estratégia da companhia, garantindo que cada iniciativa seja discutida quanto ao valor agregado para a empresa e trade-offs. Esse roadmap é desdobrado e fatiado em trimestres pelas tríades de liderança (compostas por um Design Lead, um GPM e um Engineering Manager), alinhado com os stakeholders de cada área.
Cada tribo tem a liberdade de escolher a metodologia de desenvolvimento que mais se adequa à sua realidade. Temos tribos que utilizam Kanban, outras que utilizam Scrum e algumas que utilizam Shape Up (confira mais sobre Shape Up neste post: https://avenuetech.substack.com/p/a-metodologia-shape-up-na-avenue).
Tudo é automatizado no Jira e visível para toda a companhia.
E como garantimos a troca de conhecimento e a qualidade? Além de todas as práticas de qualidade, temos um chapter para cada disciplina: Backend, Frontend, Mobile e QA. Também temos fóruns recorrentes e intercalados entre grupos como EMs, EMs + Staff Sr, EM + ELs e Staffs, para tocar iniciativas comuns para toda a engenharia, como padrões de arquitetura, building blocks, melhorias e requisitos não funcionais (tempo de inicialização, throughput, taxa de APDEX, ANR, Crash Free, etc.). Em gestão de times, abordamos temas como reconhecimentos não financeiros, melhoria de clima, equilíbrio de vida e performance/produtividade (como medir pode ser um tema para outro artigo também).
Para comunicação com todo o time, temos um update bimestral com toda a área e, intercalado, um papo com cada tribo onde trazemos ideias, novidades, tiramos dúvidas e trocamos experiências. Além dos 1:1s que fomentamos com os liderados diretos e, dependendo do cargo, um nível abaixo (por exemplo, EMs com ELs e com Sr mais sólidos também). Nesses fóruns, abordamos temas como trilha de carreira, PDIs, métricas de saúde da área como eNPS, taxa de turnover e capacidade de contratação com a força da marca tech. Também incentivamos bastante a comunicação assíncrona através do nosso Slack.
E tecnicamente, como orquestramos as iniciativas de negócios junto as necessidades de ganho de robustez no ecossistema de arquitetura.
Além disso, é importante destacar a iniciativa que os times têm de se planejar quanto a atacar itens de engenharia e débitos técnicos além das metas de engenharia definidas. Na tribo, por exemplo, fazemos isso através de um pipeline externo, de sustentação e engenharia, onde as pessoas que estão em sustentação eventualmente têm mais tempo para atacar coisas nesse sentido, e também os cooldowns (do shape up), onde a galera geralmente usa para debtec e bugs. Cada time vai atacar de um jeito diferente, mas todos têm essa preocupação e autonomia.
Também temos o time de plataforma que procura automatizar soluções práticas para os desenvolvedores conseguirem passar menos tempo em trabalhos manuais e/ou repetitivos e utilizar cada vez mais o capital cognitivo voltado para resolver um problema que esteja ligado a missão e estratégia da área e da empresa.
Este é um pequeno resumo das dinâmicas e ritos que encontramos para manter a troca de conhecimento entre tribos, a hegemonia de conceitos e um bom ritmo de melhoria contínua. Claro que, para tudo isso acontecer e atingirmos alta performance, a régua técnica do time é bem elevada, algo que não abrimos mão no processo seletivo, mesmo que isso impacte o timing de contratação. E para isso contamos com um time muito fera composto por uma Tech Recruiter e uma BP.
Conclusão
Não existe uma fórmula mágica ou bala de prata ou framework para tratar todas as dores e evoluções de uma área com mais de 100 pessoas. Mas sim pequenas ações de melhoria contínua dia após dia para superar essas barreiras e desenvolver cada vez mais o time. Ás vezes pequenas ações ou ajustes para a causa raiz correta, pode gerar um enorme resultado. E aqui eu procurei trazer algumas das práticas que temos para continuar nos desenvolvendo sempre.
E ai, gostou do conteúdo? Como funciona na empresa de vocês? Se quiser trocar ideias deixe seu comentário ou marque um papo comigo. Vamos continuar essa conversa!