Usando o caos organizado para escalar uma equipe de sucesso

equipe de sucesso

Aqui na x.ai, desenvolvemos um assistente pessoal com Inteligência Artificial que agenda reuniões para você. Parece simples, mas não se deixe enganar. A inteligência artificial é um problema técnico extremamente desafiador.

Seis meses atrás, enfrentamos um dilema: nossa equipe de tecnologia cresceu de cerca de 15 pessoas para mais de 30 muito rapidamente. Queríamos ter a certeza de que, apesar do crescimento enorme, poderíamos facilmente identificar o que precisávamos fazer e como fazer isso direito e sem demora.

Normalmente, há um equilíbrio bastante básico quando se quer aumentar uma equipe de sucesso sem perder a agilidade: à medida que sua equipe fica maior, cada indivíduo adquire um maior grau de liberdade, e seu impacto na organização fica menor. Mas nós não queríamos isso.

Queríamos um ambiente onde, à medida que crescemos, os membros da equipe ainda tinham o potencial de ter grande impacto operacional e fazer o melhor trabalho de suas carreiras, dentro de uma equipe de sucesso.

Na época (no final do verão de 2016) estávamos bastante sossegados, com diferentes funções sendo responsáveis por diferentes tarefas.

Um efeito colateral deste arranjo foi uma grande variação em nossa maneira de gerenciar as equipes. Basicamente, não fomos capazes de priorizar o nosso trabalho adequadamente.

Por isso, nós testamos um monte de coisas novas em uma tentativa de escalar nossa equipe sem sobrecarregar nossa estrutura com áreas e departamentos fechados.

Primeiro: quais são os objetivos?

metas

Nós tínhamos implementado OKRs individuais e de equipe assim que nosso time cresceu além de um grupo unido de engenheiros e cientistas de dados.

Com o tempo, aprendemos que os OKRs, que são acompanhados ao longo de três meses, eram muito rígidos, considerando a velocidade como as coisas estavam mudando em nossa empresa.

Em vez disso, decidimos que deveríamos alinhar a equipe em torno de um pequeno conjunto de metas trimestrais da empresa – e se qualquer projeto único não contribuísse de forma significativa para uma meta específica (e não havia mais de cinco), então esse projeto não deveria ser posto em operação.

Esses objetivos englobavam todo o trabalho que queríamos realizar.

Agora, precisávamos decidir em quais projetos específicos focar, como designar membros da equipe para projetos específicos sem replicar uma estrutura de grupos fechados e quais outros processos poderiam nos ajudar a escalar nossas equipes de sucesso.

Discussões transparentes usando solicitações de comentários

equipe de sucesso

As Solicitações de Comentários (RFCs, ou Requests for Comment, em inglês) se tornaram os alicerces de nosso processo. Estes documentos compartilhados e altamente estruturados permitem que qualquer pessoa com uma ideia para um novo processo ou nova abordagem para o nosso trabalho compartilhe com a equipe, receba comentários e, em seguida, se ela for aceita, implementa essa ideia.

Essas ideias podem vir de qualquer lugar. Um exemplo agora clássico na empresa foi a nossa "night’s watch" (guarda noturna), proposta por um de nossos cientistas de dados. Basicamente, ele observou que não estávamos fazendo um trabalho adequado para resolver bugs críticos e pior, estávamos retirando engenheiros de projetos importantes de uma forma imediatista para apagar incêndios.

Precisávamos encontrar uma maneira de apagar esses incêndios em tempo hábil sem comprometer o tempo dos técnicos e manter nossa equipe de sucesso trabalhando de forma produtiva.

Este RFC particular tinha todos os elementos necessários:

  • Uma declaração do problema a ser resolvido.
  • Uma solução: Um plantão com revezamento semanal de três técnicos.
  • Quaisquer requisitos relevantes. Neste caso, havia um tema com a famosa “Night’s Watch” do seriado Game of Thrones, inclusive com um texto com o votos de compromisso dos participantes.

Uma vez que nosso cientista de dados abriu o RFC (através de um Google Doc), qualquer pessoa na empresa poderia comentar. Como todos os RFCs, este foi aberto para comentários por apenas duas semanas. Uma breve discussão se seguiu e dentro de cerca de 10 dias, o RFC foi aceito. Em seguida, implementamos nossa "Night’s Watch " como descrito.

equipe de sucesso

As RFCs funcionaram como um primeiro passo na implementação de novos processos. O objetivo não era conseguir um consenso. Em vez disso, queríamos aumentar o nível de transparência em torno das iniciativas da empresa e incentivar a conversa, algo essencial para criar equipes de sucesso. E porque nós usamos documentos compartilhados para todos os RFCs, essa conversa se tornou parte de nosso registro público.

Autosseleção de gestores

equipe de sucesso

Também queríamos ter certeza de que a equipe de tecnologia se sentisse bastante autônoma - e com um senso de responsabilidade perceptível - à medida que crescíamos.

Estávamos certos de que qualquer estilo gerencial do tipo "comando e controle" (no qual os gerentes de tecnologia atribuíam trabalho aos técnicos) não daria a nossa equipe o senso de responsabilidade que acreditamos ser necessário para uma equipe de sucesso conseguir enviar códigos de alta qualidade semana após semana.

Por isso, permitimos que todos os funcionários autosselecionassem seus próprios gerentes, projetos e líderes de projeto (chamamos isso de autosseleção em todos os níveis do processo).

Embora possa parecer radical, não fomos nós que criamos esse tipo de auto-organização, nós pegamos muito disso emprestado do Processo de Priorização de Pandora.

Alguns elementos centrais da auto-organização funcionaram muito bem para nós. Selecionar seu próprio gerente, por exemplo, foi em grande parte algo que ocorreu normalmente.

Isso reforça a liberdade real das pessoas para escolher seu gerente (porque eles sempre poderiam escolher outro, se quisessem).

Selecionar seus projetos também funcionou bem. As pessoas geralmente sabem seus pontos fortes e como eles podem ajudar a empresa a ter sucesso.

Transparência usando dias de demonstração

equipe de sucesso

Finalmente, instituímos um Dia de Demonstração a ser realizado a cada duas semanas. Havia duas partes no o Dia de Demonstração. A primeira metade era como uma mini reunião geral da empresa. Todos participavam, e a equipe de tecnologia podia compartilhar os projetos que eles concluíram.

Nossa equipe de Customer Experience também compartilhava dados importantes sobre a aquisição e o engajamento dos clientes, bem como as dores dos clientes (por exemplo, bugs e pontos de dor que chegavam através do Suporte ao Cliente).

Depois disso, nos dividimos em grupos menores, e a equipe de tecnologia selecionava em quais projetos eles queriam trabalhar.

Durante o Dia de Demonstração, dávamos a todos "moedas" da empresa. Usávamos notas adesivas e atribuímos um valor a cada nota - cinco dias de tempo de um único técnico. Cada pessoa na empresa receberia 25 dias de tempo de técnico, ou cinco adesivos.

Calcule tudo isso, e a soma representava a quantidade de tempo que nossos técnicos teriam que empregar para realizar todos os projetos nesse trimestre.

Ou seja, se nossos projetos levassem mais tempo para serem completados do que a quantidade de moeda que tínhamos para distribuir por eles, teríamos que descobrir quais não seriam implementados.

Era bem nessa hora que começava a diversão . Todos queriam “financiar" os projetos que julgavam necessitar de mais tempo e esforço neste trimestre.

Isso imediatamente cancelaria alguns projetos (aqueles que não foram totalmente financiados). Assim, dávamos mais um passo na seleção, reduzindo o conjunto de projetos financiados mais uma vez, com base nos argumentos dos membros da equipe (prós e contras) e no alinhamento com os objetivos da empresa.

Isso funcionou?

Em geral, nossa nova abordagem é muito mais colaborativa e multifuncional, o que significa que produzimos um trabalho melhor de forma mais eficiente.

Também multiplicamos as oportunidades para as pessoas liderarem. Hoje, qualquer pessoa pode liderar mudanças técnicas - independentemente do seu título ou nível em nossa (ainda bastante horizontal) hierarquia. Esta é uma vitória enorme para nós e para os membros individuais de equipes de sucesso.

Fizemos essas mudanças há seis meses e, nesse ínterim, construímos e implementamos:

  • Uma enorme parte nova de software (uma parte-chave do sistema que processa os dados de programação de entrada);
  • Lançamos dois novos produtos (as edições Professional e Business do nosso assistente de agendamento de IA); e,
  • Implementamos uma camada muito mais sofisticada de monitoramento de sistemas.

Fizemos isso com uma equipe de se sucesso de aproximadamente 40 engenheiros e cientistas de dados. Só de ler essa lista, você pode dizer que o que fizemos foi um sucesso esmagador.

Mas a realidade, no entanto, nunca é tão simples assim.

Houve perdas, também. Por exemplo, falhamos feio no início para desenvolver um processo de planejamento que fosse disciplinado, eficiente e verdadeiramente alinhado aos objetivos da empresa.

Em vez disso, passamos muitos ciclos (e muito tempo) falando sobre um monte de coisas que seria bom a gente fazer, mas que não tivemos tempo para fazer.

Nós finalmente conseguimos "inflar a lista de projetos", significando que tínhamos um número absurdo de projetos no backlog.

Em termos de autosseleção, houve desvios, também. A autonomia só funciona se você estruturar o processo de uma forma que esclareça restrições, prioridades e compromissos.

Infelizmente, parte do nosso planejamento obscureceu a importância relativa e a urgência de diferentes projetos.

Por exemplo, alguns técnicos decidiram explorar mais um modelo de aprendizagem de máquina, quando precisávamos de quase todas as mãos disponíveis para reconstruir uma parte-chave de nossa infraestrutura.

Assim como a produção de softwares, nós trabalhamos com iterações

Felizmente, aprendemos rápido. Vimos rapidamente que a autosseleção em todos os níveis da empresa requer uma equipe que é bem equilibrada e madura no que diz respeito à negociação de aspectos técnicos do nosso sistema, clientes e as necessidades do negócio, e até mesmo os desejos individuais dos próprios engenheiros.

Não temos agora (e talvez nunca) o equilíbrio perfeito de habilidades e maturidade, o que significa que vamos continuamente ajustar os nossos sistemas de priorização para melhorar isso.

Por exemplo, agora afinamos uma lista de projetos propostos periodicamente. Também criamos fóruns para que a equipe de Customer Experience possa nos dar feedback em tempo real e ajudar a priorizar projetos.

E uma vez que percebemos que os ciclos de duas semanas não correspondiam ao nosso ritmo real de desenvolvimento de software, criamos grupos avulsos para trabalhar em projetos de ciclos maiores, de quatro a seis semanas.

Queremos enfatizar que para a ter uma equipe de sucesso, ela deve entender que algumas das coisas que precisamos construir exigem um compromisso mais sustentado do que insistir na correção constante do curso.

Agora, nossa equipe tem um comprometimento mais profundo nos objetivos de longo prazo, o que ajuda a empurrar projetos em direção da linha de chegada com mais confiabilidade.

Também estamos trabalhando constantemente em maneiras de ajudar as pessoas a se tornarem responsáveis pela autosseleção.

Para conseguir ocupar funções com este modelo de organização, nós explicitamente estamos testando a capacidade de liderança e de mentoria quando entrevistamos candidatos.

E treinamos os colaboradores para selecionar projetos que correspondam às suas habilidades e interesses, e que lhes dão oportunidades de trabalhar com nossos líderes técnicos.

Uma vantagem da autosseleção em todos os níveis da empresa é que não há quase nenhuma estrutura rígida. E sendo tudo leve, a própria estrutura se torna bastante adaptável.

Enquanto estivermos continuamente aprendendo sobre nossa equipe de sucesso e ajustando nosso processo para apoiá-la, cada iteração deve ser melhor do que a última.

Jeff Smith, Wesley Harris, Alex Poon e Joey Betras também contribuíram para este artigo.