Aula 4 — Peculiaridades da Gestão Tática e Estratégica

01 Ativos × passivos gerenciais

A distinção que organiza toda a aula: resultado pontual × sistema auto-reproduzível.

Pessoal, olá! Hoje vamos falar sobre ativos e passivos, e também um pouco sobre delegação. Uma empresa tem muitos ativos — expertise, dinheiro, experiência, RH, bases de dados. Mas, em gestão, administrar a empresa começa por classificar os passivos e ativos gerenciais.

Um passivo (recurso passivo) é algo que dá um resultado rápido e imediato, mas não é escalável nem auto-reproduzível. Exemplos: dailies (as reuniões rápidas de alinhamento), sessões estratégicas pontuais, um evento corporativo. É algo que você faz pra resolver uma situação específica — e mesmo que repita várias vezes, continua sendo ação avulsa: só acontece de novo se alguém fizer de novo.

Os ativos se reproduzem sozinhos. Um passivo até pode ser repetido de novo e de novo — mas sempre depende de alguém pra repetir. Sem uma pessoa empurrando, o passivo não acontece.

Passivo raramente dá resultado de longo prazo — a exceção é quando ele se apoia num ativo (um sistema de dailies, sessões estratégicas recorrentes). Onde o passivo brilha: quando você precisa de uma virada rápida num segmento, de mudar o rumo de um projeto ou de um feedback urgente.

Muita gente quer a gestão aplicada (como motivar sales/buyers hoje, como um owner motiva o Head of Sales a converter mais). Isso é ferramenta de passivo — gestão operacional aplicada. E tudo bem: se você ainda está no MVP, correndo atrás do primeiro faturamento, pensar em ativo gerencial é cedo. Mas numa empresa que já passou dessa fase — pequena, média ou grande —, a prioridade inverte: primeiro construir ativos, não passivos — porque ativo dá resultado de longo prazo e continua rodando sem depender de você.

02 Passivo vira ativo: a sistematização

A diferença não está na ação — está em transformá-la em sistema regulamentado.

Tudo que vira sistema dá resultado de longo prazo. A ferramenta sozinha é um passivo: ela precisa ser entendida funcionando dentro do mecanismo inteiro, ao longo do tempo — não basta aplicar uma vez. E o sistema se constrói com perguntas simples:

• Nós precisamos disso?
• Se sim, com que periodicidade? Quando?
• Qual o regulamento da ferramenta?
• Em relação a quem / com quem?
• Quem é o responsável por ela?
• Como funciona em conjunto com as outras ferramentas?

Vale para tudo — do sistema disciplinar ao trabalho do HR/recrutador. Qualquer coisa feita de forma caótica, sem recorrência, até dá resultado no momento — mas nunca de forma constante, nem no volume que poderia.

03 Por que sistematizar importa

Inovação que não vira ativo é inovação que você esquece.

Se você não aprender a transformar seus passivos em ativos regulamentados e a sistematizá-los, muitas das suas inovações e iterações vão virar ferramentas que ninguém consegue aplicar.

O padrão típico: você ouve algo interessante num curso, faz uma reunião sobre isso, não fica claro se ajudou, segue em frente — e esquece. Se o que você aprendeu não vira ativo — se você não cobra do time que vire, se não sistematiza a mudança logo de cara como algo que roda sozinho —, a ferramenta nunca chega a funcionar de verdade no longo prazo.

Exemplo: ter um bom sistema de controle e prestação de contas não te torna eficaz se falta um sistema igualmente bom de planejamento, coordenação, feedback e disciplina (com penalidades).

04 Treinamento inicial e adaptação de gestores

No operacional, o gestor faz um mês no nível de colaborador — legitimidade e diagnóstico.

Quando um gestor novo entra em treinamento inicial, a gente dá um período de adaptação obrigatório. Não vale pro C-Level, mas vale pro nível operacional: em buying e sales, o gestor passa um mês mostrando resultado como colaborador comum.

Exceção: um team lead já legítimo (cases, time grande, grandes lucros). Mas se a legitimidade está em dúvida (o time não o recebe bem, ele não mostra números reais), então o mês é obrigatório. E não é só para conquistar o time mostrando resultado — é para ele mesmo enxergar os gargalos e os pontos de crescimento nas interações (colaborador com colaborador, gestor com gestor, gestão com time) e nos processos.

É impossível gerir bem um departamento operacional se você não olhou tudo pela ótica do colaborador daquele departamento. Você não foi contratado só para tocar os processos do dia a dia — foi contratado para bater recordes.

Dica no período de adaptação: se você tem sistema de tríades/esquadrões, ponha a pessoa como chefe de uma tríade/esquadrão (3–4 pessoas) para experimentar gerir. Ótimo se entregar um case marcante; se não, ao menos entende o nível operacional intermediário.

05 Delegação: o gestor constrói o próprio roadmap

Quem não monta o roadmap não carrega a responsabilidade dele.

Dois princípios: a pessoa não consegue fazer aquilo que não consegue nomear; e ela não veste uma visão se não for capaz de enxergar e construir o roadmap dela.

Se você chega e diz "faça isto, aquilo, assim e assim", você montou o roadmap dele. Para um colaborador operacional (nível diretivo/mentoria), tudo bem. Mas para um C-Level ou gestor tático/estratégico, é erro grave.

Quando é você quem chega no owner e constrói o roadmap — com etapas, deadlines e checkpoints —, o roadmap é obra sua. Se falhar, não foi a visão do owner que falhou, nem é o owner o culpado por ter te dado prazos irreais: foi você que inventou um sistema que não conseguiu reproduzir e escolheu deadlines que não conseguiu cumprir. Isso dá uma responsabilidade pessoal enorme a quem destrincha, ele mesmo, a visão pro gestor acima.

Por isso: eu detesto "vamos construir o roadmap juntos". O colaborador constrói; eu posso corrigir. Se o gestor pensar, nem que 1%, "foi o owner que construiu" ou "a responsabilidade é dividida", ele ganha uma justificativa interna pronta: "se falhar, a culpa não é minha — ou é só metade". E não funciona assim. O gestor deve tratar o roadmap como responsabilidade pessoal — e não só executá-lo, mas formulá-lo corretamente, porque isso influencia a avaliação do resultado dele.

Ele me vende a visão dele de solução. Não sou eu que vendo a minha, nem "fazemos juntos". A visão é o produto dele — e a minha confiança é a minha avaliação desse produto.

06 Extrair o roadmap por perguntas

A correção nunca é diretiva — é induzida, para a pessoa "comprar" a decisão como sua.

Quando alguém traz um problema, você faz com que ela construa o roadmap para você. As perguntas-guia:

Se discorda, você não corrige de forma diretiva — usa perguntas indutivas que provocam a pessoa a decidir, sozinha, que a sua correção é melhor: "E se fosse assim? Você concorda que, se fizermos assim, dá tal resultado? E que, se não, traz tais riscos? Concorda que assim fica melhor pro seu resultado?"

Se eu corrijo de forma diretiva, vira "o owner mudou tudo, não funcionou, a culpa é dele". Não: eu te perguntei se você concordava, você analisou e tomou a decisão. A decisão é sua — e é você que vai executá-la.

O roadmap é um acordo: a gestão dá confiança, dinheiro e recursos; o gestor apresenta o projeto de solução. Qualquer correção induzida é percebida como proposta que ela avaliou e decisão que ela tomou. Se você encontra ceticismo/sabotagem, o problema costuma ser que você não vendeu à pessoa a ideia de que a visão é dela.

07 Vender o problema antes da solução · deadlines

Primeiro você vende o problema; a correção vem como "intervenção vendida" — a pessoa compra a ideia como dela.

Para implementar iterações, você tem que vender a visão como visão pessoal da pessoa. Ao apontar um problema numa sessão estratégica, você mostra: "isto é um problema pra mim", explica por que é problema pra você e por que é problema pra ele, e por que o objetivo é bom pra ele pessoalmente. Só então pede que ele formule a visão dele.

Na hora de corrigir vem o que o instrutor chama de intervenção vendida e oculta — "vendida" porque a pessoa compra a ideia, "oculta" porque nem é percebida como intervenção. Você só entrega informação: "lembra que no curso os caras fazem assim? É sistema já testado, funciona há tempo e com muita gente. Dá pra adotarmos? Um modelo já testado não é melhor do que a gente ficar inventando algo do zero? Faça — é a sua decisão. Se você acha assim, eu concordo." Sempre reforçando: é a decisão dela, não a minha. Aí o gestor compra a ideia e te revende como parte da visão dele — assumindo a responsabilidade.

Deadlines

"Em quanto tempo você faz?" — "Três meses." — "Se durar três meses, você concorda que não bate com nossos planos? Outras empresas fazem mais rápido, e você ganharia menos. Eu acho que dá em um mês — e você ganha mais. Vamos combinar: se fizer no prazo, te dou um bônus. Talvez você não acredite em você, mas eu acredito. Você concorda que dá pra fazer mais rápido e pegar o bônus ainda este mês?"

08 Controle: calendário de checkpoints

Regra de ferro: alarme já no primeiro deadline estourado.

Você precisa de um calendário obrigatório de checkpoints. Quando a pessoa te vende a visão, você é o investidor que aloca dinheiro e recursos — então monte não só o ponto final, mas checkpoints intermediários com microdeadlines.

Regra de ouro: o alarme toca já no primeiro deadline estourado. Um único checkpoint atrasado já me deixa muito rígido — porque significa que alguma coisa já não vai bem.

O gestor vai dizer "são só probleminhas". Mesmo assim, você deixa claro: isso não é ok. É regra de ferro.

09 Expectativas, promessas e medos

A pior coisa na relação é a indefinição — o cérebro completa sozinho o que fica não dito.

Um gestor forte é o mais claro, legível e previsível para a empresa (o owner também). Por isso o esclarecimento de papéis, feito já no recrutamento, cobre três coisas — e não só duas:

Depois você pergunta: "e você, tem medos em relação a nós?" — ex.: "de que não me deem a infraestrutura pra crescer". Essas são objeções não ditas que viram uma lente de interpretação — especialmente em quem carrega histórico negativo (já quebrou a cara numa empresa por falta de infra).

Responder ao medo com uma promessa

"Se você cumprir todos os checkpoints do roadmap que você mesmo vai montar, prometo toda a infraestrutura: verba pra testes e pra subir campanhas, criativos, treinamento pro time de vendas, desenvolvimento técnico se precisar." Você responde às objeções com promessas — e precisa honrá-las.

Cada promessa vira um minicheckpoint — um tracker que mostra se os dois lados estão cumprindo o combinado. Assim você distribui sinais de alerta pequenos e claros. Sem isso, qualquer ação mal interpretada vira alarme: você cobra um checkpoint não cumprido e a pessoa lê como "implicância, estão me limitando" — porque os riscos não foram verbalizados no início.

Você troca o alarme geral da indefinição — aquele sino enorme que dispara a qualquer movimento seu — por sininhos de alarme pequenos e nomeados em cada frente: quando um toca, os dois sabem exatamente qual combinado foi tocado. E isso vale para os colaboradores também, não só para gestores.

10 Principais ensinamentos

O que tirar pra aplicar na operação.

1. Passivo = ação pontual; ativo = sistema auto-reproduzível. A diferença é a sistematização, não a ação em si.
2. Na empresa madura, priorize ativos. No MVP, foco em passivos (aplicado) é o certo.
3. Toda iteração precisa virar ativo (regulamento, periodicidade, responsável) — senão você a esquece.
4. Gestor operacional novo faz 1 mês como colaborador — legitimidade + diagnóstico real.
5. Delegue fazendo o gestor construir o próprio roadmap. Quem monta, assume a responsabilidade.
6. Nunca "construam juntos". Ele constrói, você corrige — mas não assume o roadmap dele.
7. Corrija por perguntas indutivas, nunca por ordem: a pessoa "compra" a decisão como sua.
8. Venda o problema antes da solução, inclusive por que é problema/objetivo pra ele.
9. Calendário de checkpoints com microdeadlines. Alarme já no 1º atraso — regra de ferro.
10. A pior coisa é a indefinição. Seja claro, legível e previsível.
11. No recrutamento, alinhe expectativas + promessas + medos (os medos, quase ninguém fala).
12. Responda cada medo com uma promessa — que vira tracker — e honre-a.

11 Anexo: slides (originais RU)

Capturas dos slides da aula, em russo — referência visual do conteúdo traduzido acima.