Founding Engineers: How They Think, What They Care About, and How to Work With Them

The 2:13 a.m. moment that changed how I work with other founding engineers

‍

It was 2:13 a.m., the kind of hour when the terminal light feels like a campfire and you can hear your own keyboard echo. We were wrestling with an ugly integration that refused to handshake with our auth layer. That was when our founding engineer at the time, Marcos, pushed a tiny patch, taped a half‑diagram in Excalidraw, and dropped a Loom: “I think we’re anchoring on the wrong contract. Swap the interface, not the handler.”

Ten minutes later the service came alive. No ceremony. No Jira opera. Just someone who saw the system as a gearbox, felt the grind, and shimmed it with a washer made from intuition and a paperclip.

That’s the headspace of a founding engineer. We live to get a prototype breathing, but we stick around to make sure the brakes work.

A founding engineer is not just the first developer at a startup. They are a hybrid of engineer, product thinker, and systems owner who helps turn day-zero ambiguity into a working, scalable product.

This post is a field guide from the trenches. How founding engineers think, what they like, how to get the best from them, and what not to do. It complements the earlier piece on 10x’ing output by influence; this one zooms in on the humans who turn day‑zero fog into a working engine, and how to design the environment so founding engineers can do their best work without burning out or bouncing out.

‍

How Founding Engineers Think (and Why It Matters)

‍

Think of a founding engineer like a racing driver who’s also the mechanic. They’re constantly balancing traction vs. throttle:

• Full‑Stack Curiosity: happy to swap engines (infra), tweak suspension (data model), and adjust mirrors (UX copy) in the same afternoon.
  
  
• Systems Over Features. They notice the seam where a decision today becomes technical debt tomorrow. Not because they’re allergic to hacks, but because hacks should be intentional, with an exit ramp.
  
  
• Feedback Latency Beats Perfect Planning. They optimize for time-to-signal: the shortest path to a real user touchpoint or a live metric.
  
  
• Systems Empathy. They see how a support email, a K8s node, and the pricing page are secretly related.
  
  
• Ownership is oxygen. If they can’t touch the problem end‑to‑end, they suffocate.
  
  

Protip: When a founding engineer asks “Should we build or buy?” Pull out RPM:

• Risk: What’s the blast radius if we’re wrong? (users, data, brand)
• Pace: Will this make us faster next month, not just today?
• Meaning: Does this deepen our core advantage or is it busywork?

Two out of three isn’t enough; if it doesn’t help Pace and Meaning, don’t do it. If Risk is high, prototype in a sandbox with fake data first.

What they like (things that make a founding engineer light up)

‍

• Problem briefs, not ticket waterfalls. A one‑pager with “goal, constraints, users, risks, exit criteria” beats 27 granular tasks.
  
  
• Tight loops with real users. Shadow a customer call. Watch a session replay. Read raw feedback. It’s race‑day fuel.
  
  
• Clear boundaries. Tell me the guardrails (budget, risk tolerance, compliance) and the definition of done; leave the route open. That ambiguity is the playground.
  
  
• Drafts welcomed. Low‑fidelity sketches, throwaway branches, disposable environments – permission to be wrong quickly.
  
  
• One meaningful owner. A DRI per thing. “Everybody” is code for “nobody”
  
  
• Celebrations for stability, not just speed. We clap for green SLOs and clean rollbacks. Shipping without pager guilt is the win.
  
  
• Company context. Share insights, top risks, and why a decision matters. Ownership grows in the sunlight of truth.
  
  

Some of the tools we actually use (or have used) to enable all this

‍

• Excalidraw for napkin‑level systems thinking.
  
  
• Obsidian or Notion for a lightweight “engineering logbook”.
  
  
• GitHub Projects + Issues or Jira for thorough coordination.
  
  
• dbdiagram.io or Mermaid for quick schema/flow sketches.
  
  
• Loom for asynchronous walk‑throughs.
  
  
• Swagger, Readme, or HTTPie for APIs & contracts.
  
  
• Fly.io, Cloudflare Workers,  Netlify or Vercel for fast deploys.
  
  
• Unleash OSS or LaunchDarkly for flags and config.
  
  
• PostHog, OpenTelemetry, or Sentry for analytics and telemetry.
  
  
• Neon / Supabase for data experiments.
  
  
• Claude Code 24/7 extra pairs of eyes/sidekick.
  
  

What Not to Do When Working With a Founding Engineer (ask me how I know)

‍

1. Micromanage by proxy (tickets as handcuffs: Unless you are looking for motion, not momentum). If your “Definition of Done” reads like a legal contract, you’ll kill initiative. Replace with a one‑pager brief + demo requirement.
   
   
2. Change priorities every Monday. Nothing kills trust like steering input that contradicts last week’s steering input. Establish a cadence (we do two‑week “build windows”) and only break it for existential risks.
   
   
3. Hide the scoreboard. If people don’t see the runway or the user metrics, they’ll optimize for what’s visible: PR counts and perfect linting.
   
   
4. Weaponize the process. Lightweight checklists beat heavyweight committees.
   
   
5. Titles > outcomes. “CTO/Engineering Manager/Tech Lead” without authority is a trap. Give scope or don’t give the title.
   
   
6. Treat them as “the code person.” Founding engineers are also product thinkers. Keep them in discovery; don’t confine them to delivery.
   
   
7. Premature bureaucracy. SOC‑2 on day 10 is like putting traction control on a bicycle. Build the habit (logs, audit trails) without the ceremony.
   
   
8. Split ownership three ways. If it’s everyone’s baby, no one changes the diaper.
   
   

How to Get the Most Out of a Founding Engineer (Deverr’s Playbook) 

‍

Here’s the playbook we run at Deverr. Steal it, remix it, tell us what you change.

‍

1. The problem brief (our template)

Purpose: align on outcome, not tasks.

Title: <crispy, action‑oriented>

Goal: <what user behavior or metric moves>

Constraints: <time, budget, compliance, tech>

Interfaces touched: <APIs, tables, events>

Known risks: <top 3>

Exit criteria: <demoable proof + metric to watch>

Owner: <name>

Review window: <date range>

‍

We keep these in Notion; each brief links to the demo PR and a Loom walkthrough.

‍

2. The “build window”

Two weeks, single owner, one problem. No “drive‑by” priorities. Mid‑window we do a 20‑minute pilot demo to surface unknowns without derailing the work.

‍

3. The decision memo (one page, one owner)

When a call has real tradeoffs (e.g., build vs. buy), the owner writes a memo. We use a “Bias, Options, Bet, Blast radius” format:

• Bias: what we’d love to be true.
  
  
• Options: 3 viable paths with costs/risks.
  
  
• Bet: chosen path + why.
  
  
• Blast radius: what breaks if we’re wrong + rollback plan.
  
  

4. The Launch Bar

Bar is low for internal users, higher for external. We write the launch condition in the brief. Example:

• Internal alpha: happy path works, logs exist, rollback is one command.
  
  
• Private beta: metrics wired, error budget defined, onboarding doc.
  
  
• Public: SLOs + alerts, status page, runbook, data retention policy.
  
  

5. The Engine Room (our living doc)

A single page that answers, “How does the thing actually work?” We keep:

• Current architecture diagram (even if it’s ugly).
  
  
• Invariants (“this must never happen”), e.g., “A user can’t be in more than one workspace.”
  
  
• Top 5 known debts with a kill date.
  
  
• Links to decision memos.
  
  

6. Feedback without vibes

We use a “Code, Craft, Care” frame in reviews:

• Code: correctness, complexity, tests.
  
  
• Craft: naming, docs, operability, observability.
  
  
• Care: scope choices, user empathy, team impact.
  
  

Reviewer picks one praise and one request for each C. That’s it. Keeps reviews sharp and kind.

Hiring/partnering: signals I watch for (and the red flags)

‍

When hiring a founding engineer, past ownership and failure matter more than perfect resumes.

Green lights:

• Has shipped something end‑to‑end where failure would’ve been embarrassing (not just a school assignment).
  
  
• Talks in interfaces and invariants, not just frameworks.
  
  
• Can narrate a rollback they executed and what they learned.
  
  
• Comfortable saying “I don’t know. Here’s how I’d find out.”
  
  

Red flags:

• Optimizes for tech stack aesthetics over user outcomes.
  
  
• Needs perfect requirements before moving.
  
  
• Talks about “ownership” but avoids on‑call or migrations.
  
  
• Over‑indexes on title or headcount.
  
  

Bonus -  Starter prompts we use in interviews:

• “Tell me about a time your launch criteria were wrong.”
  
  
• “What’s a constraint you imposed on yourself that made the system better?”
  
  
• “Walk me through your default logging/alerting stack for a brand‑new service.”
  
  

Comp & agreements that respect the role (without drama)

‍

• Equity that vests on outcomes, not presence. Tie a small kicker to shipping a milestone that matters (e.g., first 50 paying users) rather than calendar time alone.
  
  
• Explicit carve‑outs for learning. 4–8 hours/month for exploring tools that might pay off later. It’s like dyno tuning – you don’t find extra torque without a few pulls.
  
  
• IP and moonlighting clarity. Put it in writing: what’s okay, what’s not. Ambiguity poisons trust.
  
  

A Lightweight Operating Agreement You Can Copy

‍

Use this as a shared “contract” between founder and founding engineer:

1. We ship in build windows. One owner, clear brief, demo at the end.
   
   
2. We default to transparency. Runway, risks, and metrics are visible.
   
   
3. We bias to action with reversible decisions. Time‑to‑signal beats elegance.
   
   
4. We document the minimum. Brief, Engine Room, decision memos – no novels.
   
   
5. We keep humans in the loop. Real user touchpoints every window.
   
   
6. We protect deep work. No surprise re‑prioritizations inside a window.
   
   
7. We respect the pager. If you build it, you help run it (humane rotations).
   
   

Print it. Sign it. Revisit it every quarter.

Car analogies I can’t resist (because… it’s me)

‍

• Torque vs. horsepower: Early on, you want torque – pull from low RPM. That’s your founding engineer: usable power right off idle. Fancy horsepower (framework purity, perfect abstractions) can wait for the straightaway.
  
  
• Brake early to go faster: Writing a decision memo feels like lifting before a corner. It’s not slowing you down; it’s setting your exit speed.
  
  
• Tire temps: Context is temperature. Without it, even the best driver slides. Share the heat – runway, risks, user pain, and watch grip appear.
  
  

Keep the following in mind: Founding engineers aren’t just builders; they’re leverage who care about outcomes more than ceremony, and they become extraordinary when paired with clear problems, honest constraints, and a founder who treats them like partners.

‍

‍