Revenue OSby Arvennue
13Módulo 13

Organização, governança e liderança

Modelos de org, papéis, OKRs que não repetem a meta de vendas, LGPD e comunicação com C-level.

8 capítulos · 30 horas de estudo sugeridas

O Módulo 12 terminou com adoção medida e uma pergunta que a medição não responde. Você viu playbook vivo pegar numa área e morrer na outra, com o mesmo texto, o mesmo treinamento e a mesma reunião de lançamento. A diferença nunca foi de didática. Onde a mudança pegou, existia uma pessoa com o direito de alterar o campo, travar o estágio e dizer não ao pedido de exceção. Onde morreu, existia uma pessoa simpática pedindo por favor. Enablement entrega capacidade. Não entrega mandato.

A Órbita fecha o ano com R$ 24,8 milhões de ARR e 34,8% de crescimento, e com 6 objetos de receita cuja definição ninguém assinou: MQL, SQL, oportunidade, cliente ativo, churn e ARR. Desconto acima da regra é aprovado por WhatsApp, sobre uma regra que não está escrita. O roteamento de lead é feito à mão toda segunda-feira. O campo novo no CRM é criado em produção, na sexta-feira, sem ambiente de teste. Nada disso é falta de gente. A empresa tem 104 pessoas, 57 delas em GTM. É falta de dono nomeado por decisão, e enquanto a lista de decisões sem dono não existir no papel, cada reorganização vai mudar o endereço da briga.

Organograma não é organizaçãoAs mesmas 57 pessoas de GTM da Órbita em cinco arranjos. O bloco de cima não muda. As três linhas do meio mudam inteiras.O organograma, idêntico nas cinco colunasCRO1Gerentes2AE11SDR4Pré-venda2Marketing10CS6Implant.10Suporte9RevOps2Este bloco é o mesmo nos cinco modelos. Nenhuma caixa muda de lugar daqui para baixo.Centralizadoaté cerca de 5 FTEDescentralizadoo estado acidentalHub e raiosacima de 5 FTEPor segmentovariação por segmentoPor funçãovariação por funçãoQuem define o queé um MQLRevOpsMarketing eVendas, os doiso hubo par dosegmentoops de marketingQuem aprova camponovo no CRMRevOpscada áreao hubcomitê de dadosops de sistemasQuem assina o ARRque vai ao conselhoRevOpstrês versõeso hubcomitê de dadosops de analyticsOnde a pessoa deoperações sentano centrodentro da áreana área,decide no hubdentro do segmentodentro da funçãoO que o modelocompra e o que vendeganha definição únicaperde proximidadeganha proximidadeperde três verdadesganha as duas coisasperde exige 5+ FTEganha segue a variaçãoperde duplica trabalhoganha profundidadeperde a visão do cicloA Órbita tem 2 pessoas na linha de RevOps e Sales Ops para 57 de GTM. Só a primeira coluna é aplicável hoje:Partir as 2 pessoas em hub e raios não entrega nem a definição única do centro nem a proximidade das pontas.O bloco de cima é idêntico nas cinco colunas. Trocar de modelo sem trocar as linhas do meio muda o endereço da briga, não a briga.

Arraste o desenho para o lado para ver inteiro

Figura 13.0 O organograma é o mesmo nos cinco modelos. As três linhas do meio não. Leia de cima para baixo. A faixa do topo é o organograma de GTM da Órbita, desenhado uma única vez porque ele é idêntico nas cinco colunas. A grade de baixo pega três decisões nomeadas e mostra quem as assina em cada modelo: etiqueta verde quer dizer exatamente um aprovador, etiqueta vermelha quer dizer mais de um ou nenhum. A quarta linha é a que decide o modelo de verdade, porque hub e raios é o único arranjo em que onde a pessoa senta e onde ela decide são lugares diferentes. Esta é a figura mestra do módulo: o capítulo 13.1 mora nas três linhas do meio, o 13.2 nas cinco colunas, o 13.3 na linha de reporte que sustenta cada etiqueta verde e o 13.4 no tamanho do bloco RevOps lá em cima.

A tese deste módulo é a que está desenhada acima. Organograma é a sombra da distribuição de direitos de decisão na parede, e mexer na sombra não move o objeto. Os cinco modelos de organização que o mercado discute não são cinco desenhos concorrentes: são cinco alocações diferentes das mesmas quinze ou vinte decisões, e cada uma compra uma coisa vendendo outra. Quem escolhe o modelo sem ter escrito a grade de decisões escolhe no escuro, e descobre o próprio mandato do jeito mais caro possível, que é na primeira vez em que alguém o ignora e não acontece nada.

Daí em diante o módulo desce para as quatro perguntas que a diretoria realmente faz. A quem RevOps se reporta, sabendo que quem produz o número que julga as áreas não pode se reportar a uma área julgada. Quantas pessoas, por dois métodos que discordam quando aplicados à Órbita: o ratio de cobertura devolve 1,99 FTE e a fila de pedidos devolve 3,08, e a tarefa não é fazer os dois concordarem, é escolher um e sustentar a escolha. Por qual número o time aceita ser medido, sabendo que quem aceita ser pago pela receita aceita ser demitido por um trimestre macroeconômico. E sob qual base legal cada dado pessoal circula, com o artigo citado por fluxo, em uma empresa que carrega 84.000 contatos sem registro de base legal e nenhum encarregado nomeado.

Este é o último módulo da Fase 4 e o ensaio do Capstone. Tudo o que você escrever aqui, a grade de decisões, o memorando de dimensionamento, os OKRs e o pacote de governança de dados, entra no diagnóstico final como anexo e como argumento. O Capstone vai pedir um número confiável, um plano de capacidade e uma proposta de time. Os três dependem de alguém ter o direito de assinar embaixo. Este módulo é sobre conquistar esse direito e escrevê-lo antes de precisar dele.

Ao fim deste módulo você deve ser capaz de

  • Mapear os direitos de decisão de uma operação comercial numa grade RACI-D assinável, nomeando quem propõe, quem decide, quem é consultado, quem é informado e quem pode vetar, e identificando as decisões que hoje não têm aprovador único.
  • Classificar uma operação real em um dos cinco modelos de organização de RevOps, centralizado, descentralizado, hub e raios, por segmento e por função, e nomear os quatro sinais objetivos de que o modelo atual está saturado.
  • Avaliar a quem a liderança de RevOps deve se reportar numa empresa específica, dizendo qual viés estrutural cada linha de reporte compra e qual ela vende, e distinguir mandato escrito de autoridade real.
  • Dimensionar um time de RevOps por dois métodos independentes, ratio de cobertura ajustado por fator de complexidade e teoria de filas aplicada ao registro de pedidos, e sustentar uma recomendação quando os dois discordam.
  • Escrever OKRs de RevOps em que todo Key Result passe no teste de controlabilidade: baseline medido, unidade explícita, prazo, dono único e alavanca direta entre a ação do time e o número.
  • Produzir um registro de base legal para cada fluxo de dado pessoal de uma operação comercial B2B brasileira, com teste de balanceamento escrito, política de retenção como relógio por registro e atendimento a direito do titular dentro do prazo legal.
  • Identificar viés por proxy num modelo de priorização e desenhar as salvaguardas de revisão humana, auditoria de disparidade e fatia de controle exigidas por quem aloca atenção humana por algoritmo.
  • Montar um material de RevOps para diretoria e conselho com no máximo seis números, dois terços do tempo dedicados a decisões ainda não tomadas e uma lista explícita do que foi deixado de fora.
  • Sequenciar os primeiros 180 dias de uma liderança de RevOps que herda uma operação quebrada, decidindo o que medir antes de mudar e em que ordem atacar entrada de pedidos, processo, sistema e automação.

Capítulos

  1. 13.1Antes da caixinha: quem decide o quê
  2. 13.2Cinco formas de desenhar a mesma empresa
  3. 13.3A quem você responde decide o que você pode dizer
  4. 13.4Quantos e de que tipo: dois métodos que discordam
  5. 13.5A armadilha de ser pago pela receita
  6. 13.6LGPD na mesa do vendedor: o que muda na segunda-feira
  7. 13.7Seis números e uma decisão: falando com C-level e conselho
  8. 13.8Os primeiros 180 dias: quando você herda uma bagunça
  9. Laboratório 13A entrega do módulo, com critérios de avaliação.
Começar pelo capítulo 13.1

A Órbita Software é uma empresa fictícia, construída para este curso. Os números dela foram escolhidos para ensinar e calibrados contra referências públicas de mercado. Por que um caso fictício.