I've Been a Founding Engineer Four Times. Here's What the Role Actually Is.

The Title Means Nothing. The Pattern Means Everything.

LinkedIn is full of people who call themselves "founding engineer" because they were the second hire at a Series A startup. That's a real thing. It's also not what the role is.

A founding engineer is the person who makes the first technical decisions that everything else builds on. Language, framework, architecture, data model, deployment strategy — decisions made in the first weeks that are still constraining or enabling the system five years later. It's not about headcount. It's not about equity. It's about being the person who decides what the foundation looks like, and then living with those decisions as the system scales.

I've done this four times. Each time the title was different — Solution Architect, CTO, Product Manager, Lead Engineer. The actual work was identical: start with nothing, make foundational decisions under uncertainty, build until it works, scale until it serves real customers.

Four platforms. Four different company sizes. Four different titles. Same role.

Zero to One, Four Times Over

The defining characteristic is the 0-to-1 transition. Not 1-to-10 — that's scaling. Not 10-to-100 — that's optimisation. Zero to one: from "this doesn't exist" to "this works and people depend on it."

Advania, 2016. The company had HPC customers who needed cloud-like flexibility with bare metal performance. The product didn't exist. I integrated OpenStack Ironic, Packer, SLURM, and Ceph into a unified IaaS platform that delivered HPC clusters as a service. I was the sole engineer for the first two years.

The early decision to use OpenStack's Ironic for bare metal provisioning — rather than building custom — was the one that mattered most. It meant we could ride the community's development for hardware lifecycle management instead of maintaining our own. When the platform scaled to 1,000+ nodes across multiple regions, that decision still held. If I'd built custom provisioning in 2016, I'd still be maintaining it today.

atNorth, 2018-2021. HPCFLOW moved with me and I became its CTO. The solo project scaled to multi-regional HPC-as-a-Service serving enterprise customers, including Stanford University's Living Heart Project — cardiac simulations running on infrastructure that started as one person writing OpenStack Heat templates or Terraform stack. I grew the engineering team from just me to a full group. The architecture remained fundamentally what I'd designed in year one.

That's the test of founding decisions. Not whether they're clever — whether they hold.

Canonical, 2022-2023. At a 1,000+ person company, with the title Product Manager, doing the same job. Ubuntu had 14% market share in HPC cluster deployments but no dedicated strategy. I built the entire HPC portfolio from scratch — product strategy, reference architectures, the NVIDIA partnership for InfiniBand driver optimisation, an enterprise benchmarking initiative. The title said Product Manager. The work was founding engineer.

Millennium, 2023-present. A global quantitative hedge fund needed an HPC platform built from nothing. Modern SLURM with everything around it — containerisation, monitoring, self-service interfaces, hybrid cloud. I'm the sole architect and developer. Ansible automation, Go APIs and CLIs, a React web interface, custom AWS EC2 plugin for elastic capacity management. Hundreds of technical initiatives tracked, 90% reduction in manual intervention.

The Loneliness Problem

The founding engineer role is lonely in a way that other engineering roles aren't.

There's no one to code review your architecture decisions. No established patterns to follow — you're creating the patterns. When something breaks at 2am, there's no on-call rotation. You are the on-call rotation.

At Advania in 2016, when I was integrating OpenStack Ironic with SLURM for bare metal HPC provisioning, there was no Stack Overflow answer for that. No blog post. No reference architecture. The two ecosystems didn't talk to each other, and making them talk required understanding both deeply enough to bridge them. When the integration broke, I was the only person who understood both sides.

At Millennium, the same pattern. Building this platform requires SLURM internals, Go systems programming, React frontends, Ansible automation, AWS EC2 APIs, and quantitative finance workflows. No single hire covers that breadth. The founding engineer carries all of it until the system is stable enough to share.

The flip side is leverage. The HPCFLOW architecture decisions I made in 2016 were still serving enterprise customers in 2021. That's not brilliance — it's consequence. The founding engineer role forces you to think about longevity because you know you'll be living with these decisions. So you make them carefully.

The Instinct Doesn't Turn Off

When I need a tool and it doesn't exist, I build it. This is the founding engineer instinct at a smaller scale, and it's the same pattern every time.

I needed a Go SDK for SLURM's REST API that handled the version churn between v0.0.40 and v0.0.44. Nothing existed. So I built slurm-client — a multi-version SDK with adapter pattern, code generation from 88,000+ lines of OpenAPI specs, and capability detection.

I needed a terminal UI for SLURM that worked like k9s works for Kubernetes. It didn't exist. So I built s9s.

I needed to orchestrate SLURM jobs through Apache Airflow. No provider existed. So I built airflow-provider-slurm.

Each one is a founding engineer project in miniature — zero to one, making architectural decisions under uncertainty, building until it works.

What Actually Differentiates the Role

The critical difference from adjacent roles is decision-making under zero context.

When you join an existing system, the architecture tells you what decisions have been made. The test suite tells you what behaviours are expected. The deployment pipeline tells you how code reaches production. When there's nothing, every decision is load-bearing. The programming language you choose determines who you can hire. The database you pick determines your scaling characteristics for years. The API design determines your integration surface.

A senior engineer joins an existing system and makes it better. A staff engineer operates across teams, setting direction over existing complexity. A tech lead coordinates a team's output on an existing product.

A founding engineer has no system, no complexity, no team. There's just them and the problem. The team comes later, after the foundation exists.

What I'd Do Differently

I've made the same mistake at every company: documenting too late. The founding engineer's biggest failure mode is building something only they can maintain. The system works, the users depend on it, and all the knowledge lives in one person's head.

At Millennium, I've written 20+ operational runbooks. Not because I enjoy documentation — because I learned the hard way that the system needs to outlast my daily involvement. I should have started writing them at Advania. I didn't, and the knowledge transfer when I left was harder than it needed to be.

The other mistake: not accepting when the role should end. The founding engineer builds the foundation. Eventually the system grows past what one person can hold. Specialisation happens, the team grows, and the founding engineer's role needs to evolve into something else — CTO, staff engineer, architect, or the person who goes and founds something else. That transition is the goal, not the failure mode. I held on too long at atNorth before recognising it was time to let the team own what I'd built.

Why I Keep Doing It

Founding engineer is the best role in engineering. Not the most comfortable. Not the most predictable. But the best in terms of impact-per-person.

When a Stanford researcher runs cardiac simulations on infrastructure you built from nothing. When a Millennium trader submits a GPU workload through a self-service interface you designed. When someone installs your open-source terminal UI and it makes their daily workflow easier. Those are founding engineer outcomes — direct lines from your decisions to real impact.

The role gives you permission to care about everything. Most engineering roles have scope boundaries — frontend, backend, infrastructure, product. The founding engineer's scope is "whatever needs to exist for this thing to work."

That breadth is exhausting. It's also what makes the work worth doing.