A founder escalation should arrive as a decision packet

Some commercial decisions should reach the founder. A material pricing exception, a new promise, unusual risk, or a category defining relationship may require authority that the normal sales path does not have.

The problem is not escalation. It is context reconstruction.

A message says, “Can you look at this deal?” The founder opens the CRM, searches for notes, asks what the buyer wants, discovers two conflicting versions, and schedules a meeting to learn what decision is actually pending. The team calls this founder involvement. Operationally, it is an unbuilt decision interface.

A better escalation compresses the case before it moves. The founder receives one bounded question, the evidence that matters, the available choices, and what happens after the answer.

Definition

Definition: A founder escalation packet is the minimum trusted context, authority boundary, options, timing, and follow through required for a founder to make one exceptional commercial decision without reconstructing the opportunity.

The word exceptional matters. Normal qualification, routing, follow up, and proposal movement belong in the Playbook. Escalation is for a decision whose risk, precedent, strategic value, or irreversibility genuinely requires founder authority.

The packet also has a system role. Truth supplies the buyer evidence. The Playbook states the normal rule and why this case is outside it. Architecture assembles and routes the packet. The Operator protects the decision deadline and propagates the result.

Escalate authority, not uncertainty

A weak escalation transfers an uncertain situation upward. A strong escalation keeps uncertainty visible while asking for a precise use of authority.

Compare two requests:

“Should we make an exception for this account?”

“Should we extend the implementation boundary to include ongoing execution for this buyer, despite the approved offer excluding it?”

The second question can still be difficult. But it names the decision. It lets the founder examine scope, precedent, delivery impact, and buyer evidence instead of first translating a vague request.

Atlassian's DACI framework separates the person who drives a decision from the one approver who makes it, the contributors who provide specialist input, and the people who need the result. A GTM escalation does not need to copy the whole framework. It should keep the same boundary: assembling evidence is work, approving is authority, contributing is not a hidden veto, and informing is part of completion.

The person closest to the opportunity should not simply forward the record. That person should drive the packet until the decision and its follow through are closed.

Build the seven part packet

Use one short block with seven parts. If a part is unknown, mark it unknown rather than filling the gap with confidence.

1. Decision requested

Write one question that can produce an action. Avoid “thoughts?” and “please review.” The founder should know what choice is waiting.

2. Authority reason

State why the normal owner cannot decide. Examples include a new commercial promise, an exception to approved pricing logic, material permission risk, or a precedent that changes the offer.

3. Buyer evidence

Include only the observations that can change the decision. Separate the buyer's words, behavior, and commitments from the team's interpretation. Link to the source rather than pasting an entire history.

4. Options and tradeoffs

Present the viable choices, including the normal path. State what each option changes for the buyer, offer, capacity, risk, and precedent. Do not smuggle a recommendation in as the only complete option.

5. Reversibility

Explain what can be undone and what cannot. A change to meeting sequence is different from a promise that affects delivery or a price that creates a reusable precedent.

Amazon's 2016 shareholder letter distinguishes decisions that are easy to reverse from those that are hard to reverse and argues against one process for both. This is a useful governance lens, not a GTM benchmark. Reversible choices can often stay closer to the team. Hard to reverse commitments deserve more deliberate evidence and authority.

6. Decision clock and default

Name the buyer event that starts the clock, the real deadline, and what happens if no answer arrives. “Urgent” is not a timer. A default might preserve the normal offer, pause the promise, or tell the buyer when a decision will be available.

7. Propagation owner

Name who will record the answer, contact the buyer, update the opportunity, and revise any affected Playbook or Architecture. A founder reply is not complete until the commercial system knows what changed.

Decision rule

Use this boundary before sending a case upward:

Escalate when the pending choice sits outside a published commercial boundary and requires founder authority because of risk, precedent, strategic value, or limited reversibility. Keep the decision with the normal owner when the Playbook already grants the authority and the evidence needed to act.

Then test the packet:

• Is there exactly one decision question?
• Does the normal rule appear beside the proposed exception?
• Can the founder inspect the buyer evidence at its source?
• Are at least two viable paths visible when a choice truly exists?
• Is reversibility explicit?
• Is the deadline tied to a buyer or operating event?
• Is the default action safe and honest?
• Does one person own propagation?

If the question cannot be stated, repair the Playbook or the diagnosis before escalating. If evidence is missing, repair Truth. If the packet exists but cannot reach the founder with its source links and timer, repair Architecture. If answered packets remain open, the Operator cadence is failing.

The default action protects both sides

Many escalation paths define a deadline but not the no answer state. That creates a silent policy: keep asking until the founder responds. The buyer waits, the seller improvises, or the founder becomes the hidden owner of every pending case.

The default should preserve the approved commercial boundary. For example:

• Do not promise the expanded scope until approved.
• Continue diagnosis without issuing a custom proposal.
• Give the buyer a truthful date for the decision.
• Use the standard price and offer unless an exception is explicitly accepted.

A default is not a way to pressure the approver. It is how the system behaves safely when exceptional authority is unavailable.

Close the record after the answer

The Google Cloud guide to architecture decision records emphasizes preserving the reason for a decision so future owners can understand the current state and avoid reopening the same discussion. The technical artifact is different, but the operating principle transfers cleanly.

Record the decision, reason, conditions, owner, and activation moment. Link it to the opportunity. Then choose what the system should learn:

• Case only: The answer applies to this buyer and does not alter the normal rule.
• Bounded precedent: Future cases may use the answer only when named conditions match.
• Playbook change: The normal commercial decision has changed.
• Architecture change: The decision exposed missing evidence, routing, permissions, or automation.
• Open question: The founder declined to decide until specific evidence arrives.

This is how founder judgment multiplies capability instead of generating another private instruction.

Checklist

Audit the last three decisions sent to the founder:

• Recover the exact question that required founder authority.
• Identify how much context had to be rebuilt after escalation.
• Separate buyer evidence from internal interpretation.
• Name the normal rule and the reason the case crossed it.
• Reconstruct the options and tradeoffs that were available.
• Mark what was reversible and what created precedent.
• Find the real decision deadline and the implied default.
• Check whether one owner propagated the answer.
• Convert one recurring normal decision into the Playbook.
• Build the seven part packet into the live commercial workflow.

The desired result is not fewer founder conversations at any cost. It is fewer conversations spent reconstructing a case that the system already touched.

What this is not

A founder escalation packet is not bureaucracy for every opportunity. If normal deals need a packet for basic movement, the escalation route is masking an incomplete Playbook.

It is not a guarantee of a fast answer. Some decisions deserve deliberation. The packet makes the reason, deadline, and default visible.

It does not remove commercial judgment from the team. It keeps normal authority close to the work while reserving founder attention for choices that can change risk, precedent, or direction.

If strategic decisions keep reaching the founder as open ended requests, a Lorde GTM diagnosis can trace whether the missing interface sits in Truth, Playbook, Architecture, or Operator ownership.

FAQ

Which GTM decisions should reach the founder?

Those outside the normal commercial boundary whose risk, precedent, strategic value, or irreversibility requires founder authority. Routine movement should remain with the owner defined in the Playbook.

How long should a founder have to decide?

There is no universal time. Use the buyer promise, commercial risk, reversibility, and evidence availability to set a real deadline. Always define what happens if the deadline passes without an answer.

Does the packet replace a conversation?

No. It makes any conversation decision ready. A complex choice may still need discussion, but participants begin with one question, shared evidence, visible options, and a known owner for follow through.

Uma escalada ao fundador deve chegar como um pacote de decisão

Algumas decisões comerciais realmente devem chegar ao fundador. Uma exceção relevante de preço, uma promessa nova, um risco incomum ou um relacionamento capaz de mexer com a categoria pode exigir autoridade fora do caminho normal de vendas.

O problema não é escalar. É a reconstrução de contexto.

A mensagem diz: “Você pode olhar este negócio?” O fundador abre o CRM, procura anotações, pergunta o que o comprador deseja, encontra duas versões diferentes e marca uma reunião para descobrir qual decisão está pendente. O time chama isso de envolvimento do fundador. Na operação, o que existe é uma interface de decisão que nunca foi construída.

Uma escalada melhor comprime o caso antes de movê lo. O fundador recebe uma pergunta delimitada, a evidência relevante, as opções disponíveis e o que acontecerá depois da resposta.

Definição

Definição: Um pacote de escalada ao fundador reúne o contexto confiável mínimo, o limite de autoridade, as opções, o prazo e o encaminhamento necessários para que o fundador tome uma decisão comercial excepcional sem reconstruir a oportunidade.

A palavra excepcional é importante. Qualificação normal, roteamento, follow up e avanço de proposta pertencem ao Playbook. A escalada existe para uma decisão cujo risco, precedente, valor estratégico ou baixa reversibilidade realmente exija autoridade do fundador.

O pacote também tem uma função no sistema. Truth fornece a evidência do comprador. O Playbook mostra a regra normal e por que o caso saiu dela. A Arquitetura monta e encaminha o pacote. O Operador protege o prazo e propaga o resultado.

Escale autoridade, não incerteza

Uma escalada fraca transfere uma situação confusa para cima. Uma escalada forte mantém a incerteza visível, mas pede um uso preciso de autoridade.

Compare dois pedidos:

“Devemos abrir uma exceção para esta conta?”

“Devemos ampliar o limite da implantação para incluir execução contínua para este comprador, embora a oferta aprovada exclua esse escopo?”

A segunda pergunta ainda pode ser difícil. A diferença é que ela nomeia a decisão. O fundador pode examinar escopo, precedente, impacto na entrega e evidência do comprador sem antes traduzir um pedido vago.

O modelo DACI da Atlassian separa quem conduz a decisão, a única pessoa que aprova, quem contribui com conhecimento e quem precisa conhecer o resultado. Uma escalada de GTM não precisa copiar o modelo inteiro. Vale preservar o limite: reunir evidências é trabalho, aprovar é autoridade, contribuir não cria veto escondido e informar faz parte da conclusão.

A pessoa mais próxima da oportunidade não deve apenas encaminhar o registro. Ela conduz o pacote até a decisão e o fechamento dos próximos passos.

Monte o pacote em sete partes

Use um bloco curto com sete componentes. Quando algo não for conhecido, marque como desconhecido em vez de preencher a lacuna com segurança artificial.

1. Decisão solicitada

Escreva uma pergunta capaz de gerar ação. Evite “o que acha?” ou “pode revisar?”. O fundador precisa saber qual escolha está esperando.

2. Motivo da autoridade

Explique por que o responsável normal não pode decidir. Pode ser uma promessa comercial nova, uma exceção à lógica aprovada de preço, um risco relevante de permissão ou um precedente que muda a oferta.

3. Evidência do comprador

Inclua apenas as observações que podem alterar a decisão. Separe palavras, comportamentos e compromissos do comprador da interpretação do time. Aponte para a fonte, sem colar todo o histórico.

4. Opções e trocas

Apresente os caminhos viáveis, inclusive o padrão. Mostre o que cada opção muda para o comprador, a oferta, a capacidade, o risco e o precedente. Não esconda uma recomendação ao completar somente uma alternativa.

5. Reversibilidade

Diga o que pode ser desfeito e o que não pode. Alterar a sequência de uma reunião é diferente de assumir uma promessa que afeta a entrega ou um preço capaz de criar precedente.

A carta de 2016 aos acionistas da Amazon distingue decisões fáceis de reverter daquelas difíceis de desfazer e rejeita um processo único para ambas. Trata se aqui de uma lente de governança, não de uma referência de desempenho em GTM. Escolhas reversíveis podem ficar mais perto do time. Compromissos difíceis de desfazer pedem evidência e autoridade mais deliberadas.

6. Relógio da decisão e padrão de segurança

Nomeie o evento do comprador que inicia a contagem, o prazo real e o que acontecerá se não houver resposta. “Urgente” não é prazo. O padrão pode manter a oferta normal, impedir uma promessa ainda não aprovada ou informar ao comprador quando a decisão estará disponível.

7. Responsável pela propagação

Defina quem registrará a resposta, falará com o comprador, atualizará a oportunidade e revisará Playbook ou Arquitetura quando necessário. A resposta do fundador não conclui a decisão enquanto o sistema comercial não souber o que mudou.

Regra de decisão

Use este limite antes de levar um caso ao fundador:

Escale quando a escolha pendente estiver fora de um limite comercial publicado e exigir autoridade do fundador por risco, precedente, valor estratégico ou baixa reversibilidade. Mantenha a decisão com o responsável normal quando o Playbook já conceder autoridade e houver evidência suficiente para agir.

Depois, teste o pacote:

• Existe exatamente uma pergunta de decisão?
• A regra normal aparece ao lado da exceção proposta?
• O fundador consegue verificar a evidência na fonte?
• Há pelo menos dois caminhos viáveis quando uma escolha realmente existe?
• A reversibilidade está clara?
• O prazo está ligado a um evento do comprador ou da operação?
• O padrão de segurança é seguro e honesto?
• Uma pessoa responde pela propagação?

Se a pergunta não puder ser formulada, melhore o Playbook ou o diagnóstico antes de escalar. Se faltar evidência, repare Truth. Se o pacote existe, mas não chega ao fundador com fontes e prazo, repare a Arquitetura. Se pacotes respondidos continuam abertos, a cadência do Operador está falhando.

O padrão de segurança protege os dois lados

Muitos caminhos de escalada definem um prazo, mas não definem o estado sem resposta. Surge então uma política silenciosa: continuar cobrando o fundador. O comprador espera, quem vende improvisa ou o fundador vira dono escondido de todo caso pendente.

O padrão deve preservar o limite comercial aprovado. Por exemplo:

• Não prometer o escopo ampliado antes da aprovação.
• Continuar o diagnóstico sem emitir proposta personalizada.
• Informar ao comprador uma data verdadeira para a decisão.
• Manter preço e oferta padrão enquanto a exceção não for aceita.

O padrão de segurança não serve para pressionar quem aprova. Ele define como o sistema se comporta com honestidade quando a autoridade excepcional não está disponível.

Feche o registro depois da resposta

A orientação do Google Cloud sobre registros de decisões de arquitetura destaca a preservação do motivo de uma escolha para que futuros responsáveis entendam o estado atual e evitem repetir a mesma discussão. O artefato técnico é diferente, mas o princípio operacional pode ser aproveitado.

Registre decisão, motivo, condições, responsável e momento de ativação. Ligue o registro à oportunidade. Depois, escolha o aprendizado adequado:

• Somente este caso: A resposta vale para o comprador e não altera a regra normal.
• Precedente delimitado: Casos futuros podem usar a resposta apenas quando condições nomeadas coincidirem.
• Mudança de Playbook: A decisão comercial normal mudou.
• Mudança de Arquitetura: A escolha revelou falta de evidência, roteamento, permissão ou automação.
• Pergunta aberta: O fundador decidiu esperar por uma evidência específica.

É assim que o julgamento do fundador multiplica capacidade em vez de gerar outra instrução privada.

Checklist

Revise as últimas três decisões enviadas ao fundador:

• Recupere a pergunta exata que exigiu a autoridade dele.
• Identifique quanto contexto precisou ser reconstruído após a escalada.
• Separe evidência do comprador e interpretação interna.
• Nomeie a regra normal e o motivo que levou o caso além dela.
• Reconstrua as opções e trocas que estavam disponíveis.
• Marque o que era reversível e o que criava precedente.
• Encontre o prazo real e o padrão implícito sem resposta.
• Verifique se uma pessoa propagou a decisão.
• Transforme uma decisão normal recorrente em parte do Playbook.
• Instale o pacote de sete partes no fluxo comercial real.

O resultado desejado não é reduzir conversas com o fundador a qualquer custo. É evitar conversas gastas na reconstrução de um caso pelo qual o sistema já passou.

O que isto não é

O pacote não é burocracia para toda oportunidade. Se negócios normais precisam dele para avançar, a escalada está escondendo um Playbook incompleto.

Também não promete resposta rápida. Algumas decisões merecem análise. O pacote torna visíveis o motivo, o prazo e o padrão sem resposta.

Por fim, ele não remove julgamento comercial do time. A autoridade normal continua perto do trabalho. A atenção do fundador fica reservada para escolhas capazes de alterar risco, precedente ou direção.

Se decisões estratégicas continuam chegando ao fundador como pedidos abertos, um diagnóstico de GTM da Lorde pode localizar a interface ausente entre Truth, Playbook, Arquitetura e responsabilidade do Operador.

Perguntas frequentes

Quais decisões de GTM devem chegar ao fundador?

Aquelas fora do limite comercial normal cujo risco, precedente, valor estratégico ou dificuldade de reversão exige a autoridade dele. O avanço rotineiro deve continuar com o responsável definido no Playbook.

Quanto tempo o fundador deve ter para decidir?

Não existe prazo universal. Use a promessa feita ao comprador, o risco comercial, a reversibilidade e a disponibilidade de evidência para definir o limite real. Também determine o que acontecerá se a resposta não vier.

O pacote substitui uma conversa?

Não. Ele deixa qualquer conversa pronta para uma decisão. Uma escolha complexa ainda pode exigir discussão, mas todos começam com uma pergunta, a mesma evidência, opções visíveis e um responsável pelos próximos passos.