You are a non technical founder and have an idea that you think can be a potential market disruptor. You have done the market research, have talked with a few customers, fleshed out the product features and functionality and probably have started building a product requirements document. You have pitched your idea to a few investors (or friends and family) and have secured seed funding that will give you a 6 months to a year runway to build the product.
All you need now is an engineer who can help bring your vision into a functioning product. This is great but what traits are you going to look for in your first software engineering hires?
Besides obvious things like raw skills set, looking at past work examples (and credentials/pedigree if available), reference checks, technical knowledge etc, a non-technical founder should look for the following things in a software engineer.
Are they a “Self Starter”?
An engineer should be comfortable working with the entire tech stack on their own. A larger company has enough resources to spend time building and analyzing various technology options. A startup doesn’t have that flexibility and has to pick a tech stack which is easy to build upon and easy to onboard future engineers. All this means that the startup engineer should be self-sufficient so that they can decide for themselves which technologies to pick. Today there are a number of cloud based vendors which offer a lot of features and functionalities that earlier were not available. An early engineer at startup should be aware of these options so that they can stitch together various cloud based components and reduce the time it takes to bring the product to market.
Do they know how to understand when to take on “Technical Debt” (vs delay in GTM (Going to Market)?
The very first deliverable for an engineer in an early stage startup is a Minimum Viable Product (MVP). The aim should be to push an MVP as quickly as possible to the market. This helps the business folks in your organization to validate the product and gather feedback about how users are interacting with the product. For this reason, an engineer might have to cut corners and incur a technical debt. The understanding here is that, as a business, we are ok to build a feature which is half baked (i.e may not be as performant, the product flow is a bit bumpy, on some browsers the feature does not render properly etc.) for now and will be iterated on quickly if we see an improvement in user adoption of the feature. This scrappy mindset can be a bit hard to come by for most of the engineers working in more mature organizations where they are used to taking the time needed to achieve a level of quality that they are comfortable with before pushing it out.
Do they have a “Strong Product Sense”?
Engineers are going to work closely with the non technical founder to bring their vision to life. Therefore it helps significantly if engineers have a strong product sense. This reduces the feedback loop between engineer and product manager, it helps in sequencing of tasks and prioritization features thereby decreasing the time it takes to bring the MVP to market. his is a common trait of successful engineers working in companies of any size however, startup engineers do not always have the product manager resource available which means having a strong product sense goes a long way. This also means that these early engineers should have an empathy towards the user, the context in which the user is going to use the product and various scenarios that can occur while the user interacts with the product.
Can they “Context Switch” quickly?
Your technical team is going to work on various components like backend servers, front end user interfaces, databases, mobile clients, notification systems, email outreach systems etc. With so many moving parts, you are going to need someone who is technically strong and is ok with context switching from frontend to backend to DB quickly. It helps a lot if someone can keep the whole system in their head as this will help them to debug an issue quickly and put out any fire.
Are they “Full Stack” engineers?
Besides the technology aspect of full stack engineering, they should focus on the security requirements. User trust is a currency that once lost, is extremely hard to earn back. It becomes further important in cloud based systems as it is very easy to make a configuration mistake which can expose either the user’s or the company’s private data to the world. This leads to bad press and erosion of user’s trust in the service.
Can they think in terms of an “API First” approach?
An API can be thought of as the first user interface of the application. As such they need to be designed with the users of these APIs in mind. Although these APIs might not be used by other engineers right away but a well designed API will reduce the development efforts internal to the organization as well. APIs can be considered as lego blocks which allows one to make the platform easy to open for future integration. In addition, it provides a layer of abstraction that keeps all the business logic hidden from view while the API is able to be reused by both UI and API clients.
This abstraction layer helps to grow the platform without changing the UI or the API client. Once validated, your choice of technology component might change and because of this hidden implementation, it becomes a seamless transition for the API users.
Furthermore, it is important to consider a developer’s view on API documentation. A well documented API should be self explanatory and is documented using latest specs like (OpenAPI) which allows for client generation across various languages. They should also be aware of dev tools (like Postman) that significantly drive down the time needed for API development.
Finally, an understanding of how different approaches to API design such as when to use GraphQL versus a RESTful approach is important. Considering this upfront significantly helps in cutting down any future technical debt that you may incur. Some of the things to consider include the size of your response data, the types of API queries that will be made, whether users will need their data in realtime and, if your business operates in a geography with less than ideal network connections. This decision will also drive how the system is designed in terms of capacity planning i.e how many number of concurrent requests to support, how powerful your servers need to be, what is the CPU and memory requirements for the backend servers etc.
Can they “Embrace Ambiguity”?
If the early feedback for an MVP feature is not that promising, the team should be ok with throwing that early work out. Having a growth mindset helps and embracing ambiguity to achieve product market fit is of the highest priority. It becomes important to learn from the things that did not work and the team should understand how to use this knowledge for future projects.
Can they “Communicate Effectively”?
A non technical founder will have a lot of ideas and as the technical owner of the product, the engineer should be able to communicate effectively about what is possible and what is not. They should be able to explain the complex technical details in an easily understandable way to the rest of the teams in the organization. Effective communication also means that an early engineer should actively listen to get a better understanding of the product requirements, provide feedback when it does not make sense and bubble up observations when they see an issue with the product.
Building a startup is hard. How you build your initial team will have a huge impact on the product, culture and future growth of the startup. It is therefore very important to look for engineers who besides having strong technical skills, are looking to put their stamp and make a meaningful impact on the product. Having a strong product sense, self starting nature, ability to communicate effectively, context switch and embrace ambiguity all are common characteristics that I have seen of engineers who have been very successful in bringing products from scratch to a stage where they were used by millions.