Founding Engineers, Part 1

Qualifications for early stage startups

I’m hiring founding engineers. I reached out to a few of my past connections, and one of them asked me: “what you are looking for in this founding engineer role”.

This triggered me to document my thoughts:

• Motivation

• Ownership

• Agility

• Collaboration

• Communication

Note that even though I wrote this in the context of engineering (which is the biggest function needed for a tech startup), the concepts here easily translate to non-engineering functions too.

Motivation

Why does an engineer want to work in a specific early stage startup? This is the most critical question.

Some excellent examples:

• In 5-10 years I want to start my own company, so I’m here to learn.

• I believe in this problem space, and want to solve this for the users.

• I just enjoy working with the founders of this startup.

Some bad examples:

• I hate my current big-tech job and want something different.

• It’s cool to have a “founding engineer” title on my LinkedIn profile.

• I want to become rich and retire by <age>.

One thing to call out though, some people might start with a bad answer (because they haven’t fully figured it out yet), so it requires some conversation to go beyond the surface answer and dig out the real motivation. (Note to myself: “I don’t know what I want yet” is a great topic for a future article.)

Ownership

In early stage companies, every team member needs to demonstrate a sense of ownership. Do whatever it takes. Take initiative, jump through hoops, make things happen.

For a founding engineer, ownership has extra focus on building the technical solutions, and resolving technical hurdles.

Following are some examples of what you’d hear from a founding engineer:

• The build is broken? I’ll fix it.

• The API call is too slow? I’ll make it fast.

• The UI is cut off for a smaller phone size? I’ll adjust the rendering.

• The LLM recommendation is not ideal? I’ll tune it.

This technical ownership has a hidden assumption: technical ability. When a founding engineer says “I’ll make it fast”, it’s both a willingness statement and a capability statement.

Oh, in case this wasn’t obvious, there’s no room for professional people-only managers in early stage startups. Everyone in the engineering department needs to do hands-on coding. It’s totally fine to consider people-only managers as long as they are willing to get back to coding. This time, I took nearly a week just to refamiliarize myself with github, but looking from the other angle, it only took me a week to get back to the groove after 4 years of coding hiatus.

Agility

In the above examples, I purposely put 4 categories together: setup / backend / frontend (web & mobile) / ML. This covers common technical areas for many startups. Founding engineers do not say “this is not my area, someone else should fix this”. Founding engineers cover all technical areas.

Requirements also change frequently in early stage startups. Iterations, pivots, these happen on a weekly / monthly basis, if not daily. We are constantly tweaking the product and adjusting based on user feedback, and before reaching product market fit (PMF), the product will go through a lot of fast iterations. This requires founding engineers to be very agile, and solve whatever technical challenges needed given the latest requirements.

Collaboration

This agility puts an extra challenge on collaboration.

While founding engineers can cover all, it doesn’t imply that founding engineers are egoistic, and step onto others’ toes all the time. Each founding engineer still has their respective super strength in certain areas, and relative weakness in other areas. They respect others’ domain expertise, and let domain experts own their areas first. Founding engineers are backups to each other, and to the entire company.

“Make things happen” could mean in practice “help unblock the domain experts, so that the domain experts can make things happen”.

In fact, “help unblock others” is such a critical aspect in an early stage startup. An early stage startup can’t afford a single person without that mentality.

Communication

The ownership and collaboration pieces demand high communication skills: timely, authentic, and respectful.

• Timely

  • In an early stage startup, team members need to be on the same page when assessing relative priority of each task. Oftentimes such assessments are not even communicated in written nor verbal. (Of course, when critical, they will be communicated both verbally and written; but those represent a small portion of tasks.)

  • For most tasks, we rely on each other’s timely proactive communication.

  • What’s “timely”? It’s before the unspoken-but-hiddenly-assumed ETA.

• Authentic

  • In big corporations, overly polite and backchannel is common practice, mostly because people don’t want to criticize in public. Thus appraises are thrown everywhere, and real opinions are only shared in backchannel.

  • Small startups can’t afford these.

  • If anyone has criticism, say it out loud, in front of everyone. That’s the best way to help the product and the company.

  • If there is bad news, share it with the team right away, so that the team can discuss how to handle and adjust.

• Respectful

  • Authenticity doesn’t mean acting like a jerk.

  • It’s fine to say “I have a different opinion”; it’s not okay to say, or mean, “You must be an idiot to not realize this already”.

  • Emotions will run high from time to time in early stage startups; that's the nature of the business. When they do, heated debates will occur. Still need to be respectful even during heated debates.

  • How a team does heated debates is the most truth revealing part of a team’s dynamics, which often is the best predictor of the team’s outcome.

Are you ready to be a founding engineer?