Forward Deployed
Forward deployed: holistic understanding of product and company, context switching between 3–4 projects a day, ~10 hats - including culture.
FDE - product + company, not just tickets
Forward deployed engineer (FDE) means a complete, holistic grasp of how
the product works and how the company operates - not a narrow IC lane. You
touch multiple corners: customer-facing surfaces, infra, billing, security,
narrative (docs, SEO/GEO, llms.txt), events, and often social chair
(escape rooms, restaurants, team rituals) so tribal knowledge and morale compound.
Source: User, 2026-05-11
The Operating Mode
Forward deployed means you're not behind the lines. You're at the point of contact - embedded in the product, the customer, the infrastructure, the fire drill, whatever needs you most right now. There's no buffer layer between you and the work. No PM filtering tickets. No team lead triaging priorities. The priorities arrive raw and you sort them yourself. Source: User, 2026-05-08
At Dedalus this manifests as context switching between 3-4 distinct projects in a single day. Not related projects. Distinct surface areas with different codebases, different stakeholders, different failure modes. The SDK in the morning. The billing system after lunch. DevRel prep in the afternoon. An infrastructure fire before dinner. Each one demands full attention, and the transitions are instant - there's no ramp-up time in a founding team. Source: User, 2026-05-08
The Ten Hats
A founding engineer at a YC startup doesn't have a job description - they have a responsibility surface. Kevin owns approximately ten hats at Dedalus:
- Core infrastructure - microVM workspaces, container orchestration, DCS
- Backend - API, SDK, MCP-powered agent framework
- Auth - DAuth multi-tenant auth system, Clerk bot detection
- Frontend - website, landing pages, dashboard UI, everything user-facing
- Billing - Stripe integration, Stripe Radar fraud detection, ledgers, credit grants, webhooks
- DevRel - HackPrinceton sponsorship, docs, developer experience, event demos
- Design - design system, motion, visual identity
- Security - Vercel firewalls, exploit response, postmortems, hardening
- Admin/ops - internal dashboards, observability, fleet management
- Social chair - escape rooms, team dinners, restaurant picks, culture ownership
Plus the invisible layer that cuts across all of them: llms.txt for agents, sitemaps for crawlers, SEO/GEO for AI search, creating solutions for customers and demoing at events. Not just an engineer - a full-stack product engineer who owns everything from the React UI to the sitemap. Source: User, 2026-05-09
Each hat is a full role at a larger company. Here, one person wears them all. The cost is depth - you can never go as deep on any single surface as a specialist would. The advantage is coherence - you see the entire system at once, so the decisions stay consistent and the architecture doesn't fracture along team boundaries. Source: User, 2026-05-08
Why Context Switching Works (at this scale)
Context switching is usually treated as a tax - the overhead of re-loading mental state. At startup scale, it's the opposite: it's the job. The ability to switch between billing, infra, and frontend in the same day is what allows a 3-person team to ship what a 30-person org plans.
The key is that the switches aren't random interruptions. They're different facets of the same product. You carry context across hats because you built all the layers. When you fix a billing bug, you already know how the webhook hits the API because you wrote the API. When you design the dashboard, you already know what the data shape looks like because you wrote the queries. The hats aren't independent - they're cross-linked, and the cross-links are your unfair advantage. Source: User, 2026-05-08
The Cost
The ten-hat model works in a founding team. It doesn't scale indefinitely. The risks:
- Depth debt - any single hat gets less attention than it would under a specialist. The billing system might be 80% as resilient, the design might be 80% as polished, but the product ships.
- Context bleed - at 3-4 switches per day, things slip through the cracks. You have to compensate with systems (postmortems, automations, wiki, CI) because your memory alone can't hold ten surfaces.
- Burnout surface area - when everything is your responsibility, every failure is your failure. There's no one to hand it off to.
The wiki itself is partially a response to this problem. When you context switch this aggressively, you need a persistent memory that doesn't depend on what you happen to remember today. The wiki, the automations, the skills - all of it is infrastructure to make the ten-hat model sustainable. Source: User, 2026-05-08; User, 2026-05-11
The Highest-Impact Question
The daily operating question is not "what's on fire?" It's: "What's the most important thing I can do today?"
Highest impact means: if you do this one thing today, it saves 10 hours next week. A refactor that prevents a class of bugs. A migration that unblocks three features. An automation that replaces a manual process forever. Most engineers default to squashing immediate problems. The forward-deployed default is thinking about the future - what system, if I build it today, makes everything after it easier? That's how a 3-person team ships what a 30-person org plans. Source: User, 2026-05-09
Curiosity as Operating Principle
Being forward deployed forces you to acquire knowledge across different disciplines. Billing, security, infrastructure, design, DevRel, SEO - not because anyone assigned them, but because they needed doing and there was nobody else. The skill isn't any single domain. The skill is the curiosity to download the next domain fast enough to be useful.
Tribal knowledge has to be shared effectively - written down, linked, automated - so the next person (or the same person next week) doesn't re-learn in silence. What one person learns at a startup either becomes organizational knowledge or it dies when they context switch to the next fire. The wiki, the docs, the skills library - all of it exists because tribal knowledge that stays in one head doesn't compound. Source: User, 2026-05-09; User, 2026-05-11
Self-Adjusting
The forward-deployed engineer treats themselves like a system to fine-tune. Proactively identifying problems and building solutions before anyone asks. Curiosity means deliberately downloading new domains and tools to build - skills, automations, playbooks, literally into the wiki - so capability stacks over time. Iterating on process, not just on code. The philosophy is self-adjusting and fine-tuning: always asking what to learn next to be more useful tomorrow than today. Source: User, 2026-05-09; User, 2026-05-11
This is the same compounding logic as No One-Off Work, but applied to the person instead of the system. Every skill codified, every automation built, every domain learned makes the next context switch cheaper. You don't get faster by working harder. You get faster by continuously reducing the cost of switching. Source: User, 2026-05-09
Lessons and Growth
FDE at Dedalus is also a personal belief system. The work is not only "I held ten responsibilities." The lesson is that capability grows when you keep putting yourself at the point of contact, then pressure-test what breaks. The belief is that useful people learn the surface area in front of them instead of waiting for a perfect lane. Source: User, 2026-05-12
The growth arc is from being good at code to being useful across the company. Product, infra, billing, design, security, DevRel, hiring, culture. Each one forces a different kind of judgment. The value is not pretending to be a specialist in all of them. The value is seeing how decisions in one surface affect the others and turning that knowledge into docs, skills, automations, and shared context. Source: User, 2026-05-12
That is why the spoken version of this story should sound personal: "I've been digging into where the company is slow, what keeps breaking, and what we keep relearning." It should not sound like labels being read off a resume. The spine is one flowing sentence: Dedalus taught Kevin to become useful wherever the company needed force, then turn the lesson into infrastructure. Source: User, 2026-05-12
SF Changed the Operator
SF made Kevin a different person. Before the gap semester: a Princeton CS student who could code. After: someone who thinks about consideration, agency, and seeking domain knowledge across disciplines - not one lane, but many, wired together. The biggest shift was from "that's not my job" to proactively seeking the next thing that needs building. The SF operating environment - high agency, high expectation, high surface area - is what shaped the forward-deployed identity. Source: User, 2026-05-09; User, 2026-05-11
Connections
| Connection | Implication |
|---|---|
| Ownership & Agency | Forward deployed is ownership at maximum surface area - you own everything because there's no one else to own it |
| Bet on Yourself | The gap semester bet is what put Kevin in the forward-deployed position. The reward for the bet is this operating mode |
| Builder Ethos | "Boil the Lake" at scale - many lakes, boiling simultaneously |
| Leadership | Forward deployed leadership isn't delegation. It's being the person who does the work across all surfaces |
| Want It Bad Enough | You can only sustain the ten-hat model if you want it bad enough. Without intrinsic motivation, this pace destroys you |
| No One-Off Work | The only way ten hats is survivable is if you codify everything. Manual processes across ten surfaces = collapse |
Timeline
- 2026-05-08 | Kevin articulated the forward-deployed operating mode: context switching between 3-4 projects per day, owning 9 hats of responsibility at Dedalus. Captures the founding engineer experience - not a job title but an operating posture. Source: User, 2026-05-08
- 2026-05-09 | Expanded from 9 to 10 hats - social chair added (escape rooms, team dinners, culture ownership). Added full-stack product engineer scope (Vercel firewalls, Stripe Radar, Clerk bot detection, llms.txt, SEO/GEO). New sections: highest-impact question, curiosity as operating principle, self-adjusting philosophy, SF transformation. Drafted 12 social media posts in the "Dedalus Learnings & Growth" content arc - see Content Plan Archive, April–May 2026 (then canonical Content Backlog). Source: User, 2026-05-09; wiki routing update, 2026-05-12
- 2026-05-11 | Added FDE framing: holistic product + company understanding; tribal knowledge shared effectively; curiosity as downloading tools/skills into the wiki; SF as consideration + multi-domain agency. Aligned cost section with ten hats. Content plan refreshed for operator arc. Source: User, 2026-05-11
- 2026-05-12 | Clarified publish status: those posts are draft copy in the content plan wiki page only - not treated as shipped to X/LinkedIn until Kevin posts. Ripeness column in Phase 3 fuel table corrected accordingly. Source: User, 2026-05-12
- 2026-05-12 | Live ship queue moved to Content Backlog; month-scoped plan and long drafts kept in Content Plan Archive, April–May 2026. Agents remind Kevin of rows not yet posted whenever he edits the backlog. Source: User, 2026-05-12
- 2026-05-12 | Added lessons/growth framing: FDE at Dedalus as a personal belief system about pressure-testing, becoming useful across company surfaces, and converting lessons into shared infrastructure. Source: User, 2026-05-12