What is a Founding Engineer?

Values, Philosophy, and some Tips for the makers

There’s a lot of different engineering archetypes in the world of startups - the architect, the product engineer, the code machine - but the one that I find most interesting is the founding engineer. Anybody can “be” the first or second engineer at a startup, but a true founding engineer embodies a certain je ne sais quoi that can make or break a startup.

So what makes a founding engineer a founding engineer?

A founding engineer knows how to balance. For the ultimate founding engineer, balancing trade offs is at the core of every decision they make. How do I maximize short term gain and minimize medium term tech debt? How do I build 80% of what the user wants, with 20% of the features? How much information should I get to reasonably answer the question?

A founding engineer is a product engineer, through and through, but they also need to be technical enough to make important technical decisions that the business likely isn’t going to change. They need to move quickly and deliver value immediately, but also make sure they aren’t building a castle in a sinking swamp. 

Running fast at big, hard problems, asking good, insightful questions, and building valuable AND clean software are some of the things I love most in the world, and I’m lucky that I’ve gotten to do them at early startups. I’ve also learned some lessons through this: being a founding engineer requires a certain set of values and a specific way of thinking about problems. 

THE VALUES

A founding engineer is…

Really Fast

Founding engineers have to do everything fast, because there’s a lot to do. That doesn’t just mean shipping fast. It also means breaking down problems quickly, de-risking products as soon as possible, and being fast on behalf of others - tightening feedback loops between the users and the business, unblocking teammates, and communicating solutions and tradeoffs succinctly.

High Empathy

Founding engineers have to be empathetic, because everything they build will be (read: should be) used, and often it’ll be used for a long time (no, you probably won’t come back to it). When they sit down to build a feature, they should be asking themselves: how will the user respond to this? Is this easy enough? How can I make the user love this? Does this spark joy? 

There’s a classic hacker news comment on Dropbox’s YC app announcement. I’ll drop the quote here: 

you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.

This person is obviously an excellent engineer. They are obviously not a founding engineer.

Truth Seeking

If you don’t know, find out. Founding engineers have to be curious and unashamed, because they’ll inevitably be running up against problems they don’t know the answer to in domains they’re unfamiliar with. The child-like desire to know more, the will to ask “stupid” questions in order to more deeply understand something, and the ability to learn new skills quickly is absolutely critical when building novel things. 

There’s also a follow on effect of truth seeking - if you ask why five times, you tend to accidentally run through walls where other people get stuck. Having a clear picture of the battlefield is a massive advantage in any environment, and I’ve noticed that a lot of early engineers and technical founders are incredible systems thinkers who enjoy deconstructing problems across all domains. This generally results in a densely insightful way of thinking.

An Owner

Founding engineers have to be owners. Everything that a product has to be - excellent, joyful, impactful, simple - a founding engineer has to make it that way, and take pride in it being that way. When something is broken, they want to fix it. When something is dirty, they want to clean it. When something is a ticking time bomb, they want to defuse it. They proactively solve problems that will scare away customers because… why would you even build something if it isn’t going to be the best?

THE PHILOSOPHY

The philosophy of a founding engineer in many ways brushes up against the philosophy of value. What is value? What creates value? How do you discover value?

Value

Clearly there’s some brand of economic value that needs to be understood, and that’s a good place to start, but it’s certainly not the final question. In fact, some of the most valuable startups don’t figure out unit economics until a decade or more after they’ve started. Slack started as an online multiplayer game, and when they ran out money they realized players valued their chat features and pivoted. Airbnb had to sell cereal to keep them afloat while they learned that people didn’t want to sleep on a mattress on the floor. 

Great entrepreneurs don’t ask “how can I make more money?”, but they know that economic value follows humanistic value. The better questions are - How can I make someone’s life easier? How can I help them get to where they are going faster? How can I open up opportunities for them that they didn’t have before? Creating an abundance of human-centered value by asking and understanding what people need, and then helping them fulfill those needs, is typically a much more fruitful north star.

If you’re having trouble brainstorming here, odds are you need to get out of the house and talk to some people. These questions are rarely answered in isolation.

And how do you know if you’re onto something? Well, Start with Why. Understand your purpose. Understand your mission. 

Creating Makers

I’m on a mission to create makers. In order to be successful, I have to find people who are ambitious and capable and give them the skills and mindset to make them highly effective and productive.

Then I have to create a feedback loop - this helps me steer. Metrics, Metrics, Metrics. How many people? How does effectiveness and productivity change, before and after? By what measure? By how much? Is it sustained?

There’s always going to be interesting externalities as well, and you’ll only be able to capture these if you’re building qualitative feedback loops also. For me that means asking the people I work with - What do you like about working with me? What do you not? What is exceptionally helpful? What is blocking you from leveling up? What could I do to better support you?

The answers you get from qualitative feedback should always lead you to refine your definition of value, and you should refine and revisit these questions frequently. Recursive improvement is powerful.

The Most Important Thing

Once you have metrics, you should ask yourself regularly - what’s the most important thing?

Chances are you have a shortlist of things, and those things may or may not move the needle. I recommend outlining the things, and ranking them by expected impact. I’ve seen some effective frameworks here, like effort * impact on a high (3, 1), medium (2, 2), low (1, 3). With low effort * high impact (1 * 1) items ranking highest.

This is a good exercise for later stage product teams, but decidedly not the framework for a founding engineer. Why? It assumes that everything possible is already on the table, and the granularity of “how much” expected impact is very low. 

A founding engineer should have 2 modes - 0 to 1 and 1 to 100. If you have nothing, you should be building the smallest something. You need a baseline! You need metrics! If you have metrics, you should be evaluating how you can increase those by one or more orders of magnitude. Is that thing that results in 10-100x improvement on your shortlist? No? Throw your shortlist away and go back to the drawing board.

0 to 1 and 1 to 100.

Being a founding engineer means ruthless prioritization. It means understanding your purpose. You’re meant to make, to build, to create and to pull new things into the world.

Start with Why, clearly define your mission, create metrics, track metrics closely, and course correct frequently. Prioritize creation and impact.

THE TIPS

Tactically, I’ve seen some things that are really impactful for a founding engineer. These are pretty biased towards my own experience and mostly a reminder for myself, but hopefully they’ll connect some dots for you, if you’re building early products.

Know About the UX

Sure, you understand the user experience. But do you know each user experience? Early days your feedback loops should be extremely controlled, and often that means hand-holding the user. Get them on the phone or sit down with them in a coffee shop and look over their shoulder. You are not the user. They did not build the product, they do not know that clicking the 3rd button and then typing the secret password will make everyone lots of money.

Okay, now you have some users. You can’t be there for each one. I hope you have metrics and some light observability and alerting. If something goes wrong or there’s a bad experience, you need to understand why and reach out to that customer immediately. Not in 15 minutes, or tomorrow, but immediately. Oh, what’s that? You thought you were done with the phone calls and free customer coffees? Nope. And once you’ve handheld that customer through the experience, you need to make sure that it doesn’t happen again. Rinse, wash, repeat.

Incredible customer service is the feedback loop you need in order to build products for… customers. 

Get It to the User

There’s this interesting thing that some engineers do where everything is an engineering problem.

Engineers thrive in complexity, but founding engineers also understand the importance of simplicity.

Do you even need to write code?

Most things you want to do, someone already has an out of the box solution for, or it’s not even an engineering problem. Maybe it’s not even a problem at all. Before you invest time and energy shipping, always ask yourself - is there an easier way? Do people want this? Does it provide value? What about it provides value? You can probably scrape together a waitlist using typeform or do this Very Complicated Task™ manually a couple of times to see if it’s really that useful.

What’s the fastest way to get it to the user?

In other words, what’s the atomic unit of value that you can deliver? Do you need light mode/dark mode? Is that going to make or break the product? Focus on shipping, not optimizing. Focus on asking the user the question, not answering it yourself. Deliver things to users and see if they use them - the time to implement dark mode is when users are knocking down your door begging for it.

How will you get it to the user?

Distribution is part of the product. If you don’t build it, they won’t come. The perfect app, lurking in the depths of the app store, is fated to spend eternity in oblivion. One of my favorite people to learn from here is Nikita Bier. Almost everything he builds is completely useless, but he thinks about distribution first and because of that he hits home run after home run. Distribution is part of the product.

Write Good Enough Code

Understanding how to write code that makes goldilocks weep is a fine art. Not too heavy, not too light. Not too simple, not too complex. Not too WET, not too DRY. It’s good to be scrappy and move fast, but there’s really a couple of things that you need to slow down on and get right from the outset.

Data Models

Entity representation is extremely important. If you don’t know what you’re working with, or how those entities relate to each other, your life is going to be extremely painful in about a week, and that snowballs. 

There’s two schools of thought here - learn rapidly and refactor often, or be slow and intentional upfront. I think you should do both - give your entities and the relationships between them the respect that they deserve, and understand deeply how they interact. That bubbles up to the rest of everything you build. If by rock you really meant stone, it’s going to be painful when that junior you hired starts using it as a relationship table between lovers. 

If you come to a more fundamental understanding of what something is that isn’t reflected in the data models, refactor and migrate immediately.

Interfaces

“I’ll clean this up later.” Maybe you will, maybe you won’t, but when code starts hurting, it’s nice to know how to clean it up. By putting things behind well defined interfaces with good function and variable names(!), you can shove the garbage code you wrote into a self-contained module. This way, when things break later on, it’s a lot easier to isolate the pain. 

In my experience, 80% of bugs in a codebase without interfaces are due to bad code path dependencies or hijacking shared code to do something it wasn’t meant to do. The simple act of thinking about the shape of the interface - what is the purpose of this function(s) - can clean up a lot of these and prevent you from introducing bad shared code in the first place.

Wrapping Up

A founding engineer balances tradeoffs. They are fast, empathetic, truth-seeking, and they act like an owner. They drill down on important questions, and they think about what value and impact really mean and how to achieve those things. They build, they make, they test, they experiment. They don’t let anything get in the way of creating, and their passion for creation gives them a focus that’s hard to match.

PS - I’m building a community of makers with my friends in NYC - if you’re interested in art, tech, energy, or just making stuff in general, give me a shout on the bird app - @JakeZegil.