Git With It: Founding Engineer Panel

Let’s talk about a role with great power and great responsibility: the founding engineer. 

On the surface the role might look like all the risk and stress of being a founder with a fraction of the upside.

And yet, many bright and promising engineers fill these roles each year. So, what is the role of a founding engineer? How is it different to being a CTO or an early engineer? How do you go about building an early technical stack? And what separates the good from the great?

Like any startup employee, the actual job description for a founding engineer can vary wildly – from building out the early stack to spending a surprising amount of time on hiring teammates. In this episode of Git With It, I sat down with three founding engineers to unpack some of the misconceptions around the role: Nuno Campos (LangChain), Nikhil Thota (Perplexity), and Alex Zaldastani (Stytch).

Some highlights from our discussion, which you can watch in full below:

Speed matters more than perfection

The emphasis from all three panelists was on moving quickly in the early days, in favor of getting the product out there. You can always refactor later (and you will). Nikhil mentioned that Perplexity had to do a lot of “funny” things they rearchitected later, mostly due to knowledge gaps on the team. This is better than the alternative: focusing too much on perfect engineering and architecture, when you haven’t even proven if people will use your product.

The allure of greenfields can lead to the temptation to build for scale long before it’s necessary, or to try out a shiny new framework instead of using what you know. Nikhil recalled trying to make everything a microservice at Perplexity, when their frontend, backend, mobile apps, search index, and inference code were all isolated in separate repositories. Getting everything to communicate and coordinate was “a mess” and they ended up deciding to consolidate it all into a monorepo. 

Don’t paint yourself into a corner

If you’re moving fast, you want to make sure your decisions can be undone later. Alex and the Stytch team used a sort of decision matrix:

The idea is that if something is both easy to do and easy to change, just go do it. If you’re on the other side of the quadrant, slow down and make sure you get input from the people who will be affected by your decision.

Always be hiring

Being an early employee always involves wearing many hats, and founding engineers are no different. Expect to spend just as much – if not more – time on non-engineering activities that you probably won’t see on any job description. Beyond recruiting and interviewing, good founding engineers make sure that new teammates have a great onboarding experience. As Nuno put it, “Growing the engineering team is one of the most important things to be doing when you’re growing the company.”  

Watch the full panel discussion for assessing product-market fit, compensation for founding engineers, and more.