Demystifying the Cult of the Founding Engineer: Talking to Customers and Discovering “Hidden” Talent

Problem

I first joined this company as the first engineer onboard. The experience is comparatively different from the job description of an engineer at a large corporate company or mature startups. To do this job, I had to balance my responsibilities in multiple facets especially management and IC, creating a unique experience. I found it challenging to have a successful workflow while I had to balance my different duties. I found a course of action where I could canvas our customers while building a product simultaneously. Later on, in the company's history, I found myself tasked with hiring the second and third engineers. Since the company was young, our hiring process was special, and we looked for specific skills and qualities in our candidates.

Actions taken

Balancing priorities between product building and talking with customers is quite arduous and tricky. I first set up a regularly scheduled meeting with customers to get feedback on the product. At first, these meetings were every week but moved to a bi-weekly or an asynchronous check-in as our product grew. The first call introduced the product and the customer's point of contact within the company. After that, each scheduled meeting involved receiving feedback for that week's updates and new versions of the product. After the customers and I had developed a sense of rapport, we created a Whatsapp group directed to keep customers informed about our product and business. These meetings positively impacted our product and a better understanding of how to architect the system because of our customer's feedback.

Early on, it was easy to schedule meetings since we had a minimum amount of customers. As the company and product popularized, it became challenging to speak with each customer, and we needed to create a prioritized list. Not all customers provided helpful feedback, so we created a system where we talked to customers based on certain criterias such as revenue, integration speed, and the number of API calls. These allowed us to receive feedback that was worthwhile and meaningful to our product.

As our company began to grow, we had to hire other engineers. We hired purely based on our network, but we didn't have many connections since our company was relatively young. To build out this network, we joined tech communities and attended hackathons, computer programming competitions. My goal at the hackathons was not to win but rather find and observe other engineers and reach out to them if I deemed them worthy. From here, I was able to build my network and find undiscovered engineers who believe in the vision of the company and were willing to go through the hiring funnels.

Our hiring process was unique in comparison to other companies. Since we were looking to hire our first few engineers, we did not feel that an interview or coding assessment would give us information about their actual technical acumen. Instead, we let these candidates come to our office and work on a project for a Trial or Experience Day. Doing so enabled us to determine the compatibility of our candidates, and we felt more confident in our hiring decisions. Our organization was looking for someone with experience managing an end-to-end deployment and specializing in areas that our CTO and I did not. Having a new engineer with specialties in a new department would uplift the quality of our product.

Lessons learned

• When working with an early-stage company, one person could significantly impact the trajectory of the company. Tailoring a hiring process specific to your company, like how we added in a Trial Day, will make a candidate's compatibility apparent. Having new partners that are compatible with your company will also increase the longevity of these new hires.
• It is essential for you as an engineer and your team to have a systematic way to determine what kind of prioritization you want when ranking customers to regularly talk to. Basing it on revenue will create a different list rather than the number of API calls. Without having a concerted way to agree on this system, your company may be receiving feedback from customers without valuable knowledge and improvements to your product.