01 · Built for one application, kept for what it taught me

CONTEXT FIRST

Context before credentials.

I built the original version of this presentation as my application for the Context Engineer role on PostHog's Wizard & Docs team, and my first production implementation of PostHog. I didn't get the role. What I took from the process was worth keeping anyway, so this is that: the same working implementation, the same evidence, and an honest account of what I'd do differently.

02 · What I look for

What I look for

I value teams that write decisions down, ship useful work, and learn from real usage. PostHog is the clearest example I've found of an engineering culture built that way.

  • Autonomy over process theater
  • Written-down context over tribal knowledge
  • Small teams where writing and code are the same job
  • Shipped and observed over polished in private

03 · Why Context Engineering

The throughline in my work

Software engineering, reliability, interaction design, technical communication, and AI workflow engineering all depend on clear context. It is the thread that connects my work across those disciplines.

Make the next step clear for the person or system doing the work.

See the evidence on /about

04 · How I work

How I work

I start by understanding the problem, then structure the work, build it, test it, observe the result, and document what changed. This presentation followed that same process.

05 · Evidence

Relevant work

Three projects that show how I approach context, systems, and documentation.

localcrew

Local inference orchestration

A local-first harness that connects Ollama and OpenAI endpoints across a LAN into one usable inference network.

View source

promptpad

Local-first prompt refinement

A tool that turns brief instructions into polished, copy-ready prompts, running entirely on local LLM inference via Ollama.

View source

prehog

The original PostHog case study

The application this grew out of: a small PostHog implementation with Playwright coverage, a reviewer-facing README, and structured context for coding agents.

View source

06 · Learning PostHog through implementation

What I am measuring

This began as my first production PostHog install. I started with a short list of questions, then added only the events needed to answer them.

Question Signal
Do people meaningfully progress through the deck?contextfirst_slide_viewed
Where do sessions stop?contextfirst_slide_viewed vs. contextfirst_completed
Is the navigation discoverable on mobile?contextfirst_navigation_used + masked replay
Do reviewers inspect the repository?contextfirst_outbound_clicked
Does anyone let it auto-play, or take control?contextfirst_autoplay_toggled

That question-first approach spread beyond this one page. Building it properly here showed what a real analytics architecture actually needs: a shared consent layer, generalized into a small library now used across the site's primary public surfaces. It carries the same discipline everywhere: specific, meaningful interactions, with visitor control designed in from the start.

See what it covers

07 · Context for humans and agents

Documentation for people and agents

The project keeps its architecture notes, decisions, and analytics rules in the repository. The README.md gives a reviewer the story; AGENTS.md gives a coding agent the working context.

Read AGENTS.md

08 · What I'm carrying forward

What stuck with me

Ten-plus years building full-stack products, QA automation, documentation systems, and AI-assisted workflows led me to apply for a specific role at PostHog. I didn't get it. What stuck with me was how they say they work, verified against their own public handbook rather than taken on faith.

  • PostHog's culture handbook: fully remote across 20+ countries, Tuesdays and Thursdays kept free of internal meetings, and a default to "not asking for permission" if you're acting in the company's interest, a bias toward shipping.
  • PostHog's communication handbook: async-first, with internal email avoided "in nearly all cases," with exceptions carved out for legal approvals, official company documents, and communication with external partners.
  • PostHog's small-teams handbook: each team runs "as close to its own startup as possible," with the final call on what ships and no need for external QA or control.
  • No Rules Rules (Hastings & Meyer) argues: give people context, not control, and trust them to act on it.
  • PostHog names that book directly, twice: its company story lists No Rules Rules under "Things that influenced us," and its spending-money handbook names it as the direct influence behind its context-based expense policy.

That's a company-level influence, well beyond the one HR policy. The same context-over-control instinct, teams trusted with the final call, a default toward action over permission, shows up independently across the culture, small-teams, and communication handbooks too. That pattern is the standard I'm holding the rest of my job search to now, and it's close to how I already try to work. My resume has the specifics.

09 · Inspect the work

Take a look

GitHub github.com/benmcnulty/context-first The retrospective How this page came to exist The original benlive.tv/prehog Resume benlive.tv/about Portfolio benlive.tv/portfolio Home benlive.tv

A short feedback survey may appear here after you finish the presentation.