Skip to content
Contents

On this page

1,773 wordsby CONNOR J. LAUGHLIN

The operator.

How I work when the problem isn’t defined yet.

Act I

How I move

Speed and taste usually trade against each other. These are the habits that keep both: reading a problem fast, writing the spec before the work starts, and deciding well while the picture is still incomplete.

Chapter 01. Moving fast without losing taste

Recognizing what is good, true, sharp, useful, and on-brand fast enough to keep AI-native work from becoming a high volume of competent, forgettable output. Generation is cheap now. The bottleneck is recognition: knowing which brief, which angle, and which proof to spend the finish on.

This is the umbrella skill. I would rather pull a draft I have not sat with than ship one I cannot defend.

Proof

Chapter 02. Writing briefs a team can build from

Defining what good looks like with enough precision that a human team, vendor, or AI agent can execute without inventing the missing strategy. Weak briefs create expensive ambiguity for humans and over-compliant slop from LLMs. Modern leaders need to specify goals, constraints, inputs, outputs, review gates, and non-goals.

Most of my work is turning messy GTM intent into schemas, intake forms, routing logic, briefs, proof standards, and review loops. The thing I write most often is the spec the AI agent or junior teammate can execute against.

Proof

Chapter 03. Making the call with half the data

Making useful decisions when data is incomplete, incentives are mixed, and waiting for certainty would itself be a bad decision. Executive work is rarely deterministic. AI sharpens this: outputs are probabilistic, source quality varies, and the leader has to decide when evidence is sufficient.

I build decision layers before making claims. Attribution hygiene, proof governance, pipeline inspection, source maps, executive reporting that separates signal from noise.

Proof

Act II

How I make ambiguity legible

Most of the executive job is turning fog into something a team can act on. That takes a narrative that holds up under questioning, plus enough fluency in other functions' frames to argue in their language.

Chapter 04. Giving the team a story it can act on

Making ambiguity legible so an organization can act: what is happening, why it matters, what to believe, what not to claim, and what to do next. Executive work is mostly creating the shared mental model that lets teams coordinate in uncertainty.

The messaging work starts with what the buyer is purchasing, then the proof that survives a compliance read, then the words a rep can say out loud. I write it down so the story stops drifting by business unit.

Proof

Chapter 05. Changing my mind when the evidence says to

Holding a strong point of view while staying willing to update it when the evidence, source quality, or operating reality changes. AI-native executives need conviction to move and humility to avoid hallucinated certainty, vanity metrics, or overconfident strategy.

I put a stake in the ground while building claim governance, evidence tiers, public-safe language, and review gates around the claim. The thesis can be loud as long as the evidence tier behind it is current.

Proof

Chapter 06. Speaking finance, sales, and engineering

Thinking in finance, sales, product, compliance, engineering, and RevOps frames rather than translating marketing language at the surface. Modern GTM leaders have to reason across functions. The executive has to understand what each function optimizes for and what proof it trusts.

Each function trusts different proof. The artifacts have to be usable by finance, sales, product, and compliance without a translation layer in between.

Proof

  • the revenue funnel KPI architecture
  • PE-backed and board-ready GTM reporting
  • lead lifecycle architecture in CRM
  • post-acquisition M&A GTM integration
  • RFP/RFX workflow governance

Chapter 07. Deciding what to trust, and how much

Knowing when to trust an AI output, dashboard, vendor, team member, or source. When to sample, when to verify, and when to throw it away. Over-trusting an AI output costs credibility. Under-trusting it costs the productivity gain that justified the workflow.

I design guardrails that preserve the productivity gain. Source-backed libraries, human review gates, audit trails, approval statuses, QA loops, pipeline inspection. The review loop is what makes the productivity gain usable.

Proof

Act III

How I scale judgment

Judgment stops scaling the moment it only lives in your head. I taught myself to code, then built governed AI workflows with human approval gates and audit trails. Material productivity lift from a governed AI operating layer. The rest is delegation to people and to agents, governance that doesn't drag, skepticism about my own instrumentation, and designing for whoever runs the thing after me.

Operating cadenceThe standing cadence as run: a weekly pipeline review, a monthly performance ledger review, and quarterly sponsor reporting, spaced by how often each one happens, each with a named owner.WEEKLY PIPELINE REVIEWREVENUE LEADSMONTHLY LEDGER REVIEWMARKETINGQUARTERLY SPONSOR REPORTEXECUTIVE SPONSOR
FIG_015 [ Operating cadence ]The cadence artifacts, drawn on their review periods, with an owner named on each.

Chapter 08. Managing a team that includes agents

Treating AI agents as operating participants that need context, goals, constraints, feedback, memory, review cycles, and ownership boundaries. An agent needs the same things a new teammate needs: context, a defined output, an owner, and a review cycle.

I keep an agent roster with handoffs, source libraries, and QA gates written down. Each agent has a role, an owner, and a defined output, the same way I would onboard a teammate.

Proof

  • a governed AI GTM operating layer
  • a governed proposal AI workflow
  • a governed LLM wiki that humans and agents read for the same context
  • a multi-agent SEO and GEO content workflow

Chapter 09. Guardrails a team can ship through

Adding enough structure to make work safe, repeatable, and reviewable without turning the organization into a review process nobody can ship through. AI-native GTM will fail if governance is either absent or paralyzing. The executive skill is designing lightweight control systems.

Claim tiers, proof libraries, proposal gates, compliance-aware content systems, executive review loops. The gates are thin. Nothing with an unsupported claim gets past them.

Proof

  • a governed proposal AI workflow with source-backed answer libraries
  • a claims register with posture tiers
  • a public-safety claim subset for external surfaces
  • governed content workflows for SEO and GEO

Chapter 10. Knowing when a dashboard is lying

Finding the hidden signal in messy GTM data while questioning whether the system is measuring the right thing at all. AI and dashboards can amplify bad measurement. The better leader asks whether the signal path is broken before making people optimize the wrong metric.

Attribution false negatives, ghost pipeline, signal-to-touch SLAs, lead routing, lifecycle definitions. A lot of what looks like strategy failure is measurement failure wearing a strategy costume.

Proof

Chapter 11. Building systems people keep using

Designing systems people keep using: clear ownership, low-friction handoffs, feedback loops, and enough training to make the new behavior stick. The best GTM architecture fails if sales, marketing, proposal, finance, or executives do not adopt it. AI workflows make adoption more important because the process is new and psychologically unfamiliar.

I turn systems into usable operating habits. Playbooks, cadence, team lanes, sales handoffs, dashboards, intake, QA. Adoption is the test. A system nobody opens on a Tuesday did not work.

Proof