Getting Started For a Non-Technical Founder
You’re a non-technical person ready to start your first or second tech startup and you know that nothing will get in the way of your commitment! You’re ready to go all in and do what it takes to succeed when very few do. Just as most start out, you decide to bootstrap it and not take a salary until you receive some investment or funding. You have done the research and read all the important books on the topic or industry you’re jumping two-feet into. A question continues to run through your head, how does a non-technical person hire and run a development team?
How does someone without a computer science degree hire a front and backend developer? How are you supposed to look at their resume and infer what's good and bad about it? Well, you can start by networking and finding a Senior Dev or a CTO who’d be willing to review resumes for you, or you take the time and learn what you should be looking for. Can you get away with just hiring an intermediate Fullstack developer or do you stagger the hires to bring in a backend first to develop the database and then bring the frontend into code your designs?
We can’t say what the ideal way to do this is because every startup is unique, however, if you’re reading this and thinking this is exactly what I’m struggling with, you are ten steps ahead of where you should be. Your first couple hires should not be developers!
Your first hire should either be a Designer, or a Product Manager. We will dive into this in the next section.
We will describe to you each of the roles that should be on your founding team in the order they should be hired in. The speed that you plan on hiring these roles will depend on your runway or business plan. If you’re concerned about salaries, there are a lot of great intermediate individuals who will come at a less experienced level but will buy into the dream you’re selling for when your startup is successful.
An alternative to hiring a founding team is to leverage freelancers on websites like WeWork, however, the problem with platforms like that is the freelancers aren’t collaborating on the project. You’ll have to write crystal clear requirements in such language that you’re teaching a baby about your business to ensure everyone stays on the same page.
Then, there are platforms such as MarketplaceStudio.io where you get assigned a Project Manager who hand curates your freelancer team as you progress through the different stages. You simply communicate with that assigned Project Manager, and they communicate with the appropriate individuals or the whole team. You scale the team up or down as you need or as your budget allows. This Dev Shop is led by people who have been there and done that, but more importantly, they’ve learned what didn’t work for them and understood why it didn’t. That is why they begin on a clear requirements level and then move to design to iterate and validate at that stage instead of in the code.
The big problem when hiring at a startup is how do you write a “Job Description”? Anyone who has worked in a startup knows that you do what needs to be done, and you wear more hats than you should. That is why we believe a “Job Description” should immediately be changed to “Core Responsibilities” because that will give you more flexibility in the hiring process and allow you to set clear expectations.
Some people call the PM the CEO of the Product, and others call them a connector of the business. Their purpose is to deliver clear requirements to Design or Developers once they have collaborated with different teams/stakeholders and have solved a problem that the Users have. Once the PM has worked with you for enough time and has proved themselves, you can start allowing them to be more autonomous and work on higher-level areas such as the Roadmap, Product Plan & Vision, Technology Supplier Integrations, KPI Measurement Tools, etc.
In the first year, they will wear many hats, and they know that is what’s expected. It may feel like the PM is taking on a lot of the responsibility that you have as the Founder and CEO. Again, it is your responsibility to delegate to the PM and trust them (once they’ve proven themselves) to be the champion of the User and back up any hypotheses with data & research.
An amazing book that explains the PM role and how they should interact with the company and stakeholders is Inspired by Marty Cagan.
You can go the Technical PM route, they have come (usually) from a computer science degree or have taken some coding courses or you can choose a Non-Technical PM and they’re more so focused on research, user empowerment, and collaboration. Both have their pros and cons, but in Inspired, you will learn that this role is the most important hire you will have. “The successful product managers must be the very best versions of smart, creative, and persistent”.
If you haven’t already before you jumped two-feet into this idea, the PM should start doing some industry & competitive research to see and understand who you’re playing against. Gathering a list of the competition will help you and the Designer know what kind of value props will be above the fold on your website. It will help you hone in on the pain points you will solve with this new platform. Some columns that may be useful in your competitive tracking sheet if you were building a marketplace are:
Available Platforms (Desktop & App)
Funding Type (VC Backed or Private)
Core Tech Stack (Development Languages Used)
Core Value Propositions
Assumed Target Market
Insurance & Protection Amounts / Offerings
You are lucky if your competition launched years before you and have a mobile app because you can learn from their mistakes. You can find these mistakes by reading the “Most Critical” reviews on the App & Play Store. That will guide you through what an MVP (Minimum Viable Product) or MLP (Minimum Lovable Product) should look like.
Designer / UX
Most Designers will also include a level of UX sophistication in their work, so combining these roles, in the beginning, will make a lot of sense and help save on burn. There are a ton of different methodologies or frameworks that a Designer can use and follow, and there are a ton of programs out there that they need to know. Your Designer can be a double threat, both good at Product Design, and also Graphic Design to help Marketing.
This will be your second more important hire because they are charged with essentially bringing your idea in your imagination to life. The key here will be to clearly and precisely communicate your needs, ideas, and desires to the Designer about what they will need to create. This should be simple with the help of your Product Manager.
You then need to think about the type of product or platform that you are trying to build. If you’re building a marketplace, for example, SEO will be one of the most important pieces of Design. If your Designer has some knowledge of SEO and proper structure then you will be off to a great start. Here is a great resource if you plan on building your own A-Founding-Team, a Designer Fund article.
But how do you know when it is time to hire a Designer? Well, that will depend on yourself and the PM and the type of company you are building. Unless both you and your PM come from a design background, it may be wise to hire the PM & Designer close together. This is because as your PM is doing their magic, it will be important for them to create the wireframes that work for your brand and that can’t happen without a Design Guide or at the very least a Brand Guide.
The Designer’s first task should be to help you evolve your brand, run through the brand archetypes which will help define who your brand is directed to. Once you have that chess piece in place, you can move on to creating the Design Guide which will direct your PM and Development Teams on a design level. It will create a professional consistency for your company that most startups don’t have. Everything from the typography, to the colour pallet, and the messaging is dictated by the Design Guide, you can read more about it here.
Two important things that a lot of people don’t think about are a Designers (Even a PM’s) interview & listening skills. How are they supposed to build and create what your Users want if they do not possess the proper interview skills to dig into the User’s pain points? How do you know if you’re solving an actual problem or building a solution to a problem? All of this should be uncovered in the User interviews that both the PM and Designer should conduct.
Marketing Generalist (Writes HTML)
Now that you’ve got your brand defined and your value propositions sorted out, it is time to look at building and launching your website. Depending on the skill sets your first two hires have, you may be able to wait a bit longer on this hire and instead hire an Email Marketing or SEO Specialist. Hiring a Marketing generalist is a great way to start and ensure you’ll have clear messaging on your first version of the website.
You can use a simple website builder like Wix or WordPress to create a beautiful website without requiring a Developer. There are more and more low-code or no-code solutions that Marketers can take advantage of, but knowing how to write HTML may help speed up your progress.
This role can change depending on what skill sets you’re looking for. Do you only need someone writing content and running your social media, or do you need someone creating an SEO & Google Ads strategy? A Marketing Generalist has a wide range of skills and you need to clearly understand and define their Core Responsibilities before you begin searching for the perfect match. Here is an excellent article that will help you define when is the right time, who you should bring on, and their seniority level.
You should start by asking yourself why you need a Marketer? If you’re concerned about a Product Launch Plan, that is in your PM’s domain to create a plan. If you’re concerned about the User Journey and the touchpoints, an Email Marketer should help with that. If you’re concerned about your SEO score on the launch of your website, that can be handled by free tools like SEMRush.
Once you have the Marketer’s expectations defined, you can then calculate the marketing budget that they will have to use. A Marketer will have a hard time being successful with their hands tied behind their back in terms of no budget or one not defined. You don’t need to budget for thousands of dollars! You can get away with a few hundred dollars a month to pay for the marketing support tools and maybe some retargeting ads. If you ask your Founding Team to leverage their personal social media accounts, that will help spread the word and save on ads.
Sales / Operations
This role is going to be defined by the type of company you’re creating. Is it Product-Led, Sales-Led, or Marketing-Led? That is what you’ll need to decide first before hiring a Sales and Operations representative and probably something your Product Manager should’ve asked you.
If we continue to use the Marketplace example that you’re creating, you know that you need to build your Supply first before capturing Demand. You can hire a Business Development Rep to do some cold calling or cold walk-ins to businesses or residential communities to start gathering supply. The Sales Rep will hopefully be strong enough to be able to “sell” the Supply on the dream and value propositions that your company is solving for.
You can even start a referral program to build a wait-list before your launch so that you don’t open your doors to an empty parking lot. Here is an excellent article on how the Unicorn, Robinhood built a massive waiting list of Users for their product launch, read it here.
Intermediate to Senior Backend Developer/Ops
This is your first and important role that will define your technology stack and how much technical debt you may incur if you get it wrong. This individual is charged with creating the schema, designing the tables, choosing what Cloud provider to use, and most likely what kind of languages and frameworks you will start with.
This can not be done by a junior developer, they need to have some experience and ideally working for a startup because this will define a lot of how your product works. A Senior will come with experience and they will know what tools to leverage and will use their knowledge to define a development process. More importantly, the more experienced they are, the more likely they will possess leadership skills to help lead this team until you hire a Development Manager or a CTO.
It will be important to educate yourself on the types of backend languages and the benefits and cons each one has. Some are designed for text search, some are designed for functional web apps, and others are designed for numbers and calculations. Here is a helpful article to get you grounded on the basics, read it here.
Important considerations when choosing a backend language & framework:
Size of the development community?
For easy hiring purposes
For easy scaling or business continuity
For Support purposes
Age of the language?
What other large companies use that language?
The intended purpose of the language?
Other language compatibility issues
Hiring a Senior will also bring their preferred development process with them, most likely it will be tweaked from their previous company to better fit their needs, but it is a great place to start! When you only have a team of 1 to 2 developers, a process is not as needed until you start adding a third and beyond. Then you will need to add a process for code reviews, write automation test scripts, and create a release process to protect yourself from downtime.
The biggest worry about your backend development is security. Most languages have added security and encryption, but it is always smart to know your weak points to protect your company from any possible attacks. Keep in mind that most of the time you’re likely to experience a data breach from a manual mistake made by an employee than a successful penetration attack. That is because of the level of security Cloud infrastructure companies like AWS are legally obligated to provide you with.
Junior to Senior Frontend Developer
You will first need to decide what frontend languages and frameworks you want to follow. Again, the most important questions to answer first are:
Size of the development community?
For easy hiring purposes
For easy scaling or business continuity
For Support purposes
Age of the language?
What other large companies use that language?
The intended purpose of the language?
Other language compatibility issues
Continuing the use of the Marketplace example, SEO is going to be a key advantage, and you need to educate yourself on the most compatible languages for SEO and crawlability. Here is another article answering a few of those questions.
Your Backend Developer should be able to help you with this hiring process, but the most important trait you should consider is (this applies to everyone), curiosity. If they run into a blocker, will they perform the research and ask the questions needed to resolve the issue? If you’re hiring a Junior to Intermediate, they do not have someone to bounce ideas off of or have their questions quickly answered. They need to be fairly autonomous in this role to lay the groundwork that won’t end up as technical debt.
For both developers, you might want to consider these personality traits higher than their development capabilities because, in the end, they can Google the question for a technical blocker, they can’t do the same for who they are as a person. These are important traits to look for when hiring your first developers:
Organization & Cleanliness
Some important skills you can look for that doesn’t require a technical ability are the following:
Collaboration & Communication
For both Developers, you will need to make sure they possess the above-mentioned skills and traits because they will set the tone for the rest of the team you hire. To make any other hiring easy and more streamlined, make sure that both Developers are focused on documentation, and proper documentation at that. This will essentially turn into the training guide for any new Dev getting started on your company.
Junior to Intermediate Quality Assurance Engineer (Manual)
This is an extremely important hire and will likely be the sword that saves or kills your company. The attention to the level of detail that a QA must possess is highly important next to their ability to communicate. They are tasked with finding the large, medium, and low bugs that your first two developers are likely rushing to release and this first QA will determine the level of quality you are willing to release to production.
Ask yourself first what quality threshold you’re willing to accept in production before hiring for this role. That will help determine the seniority of the individual and the Core Responsibilities for the hiring process. The reason why we are suggesting a Manual QA instead of Automated is that the code is likely to go through a few iterations before landing on your MLP. Therefore, the test cases an Automated QA would spend their time writing would be a waste of time come release.
The Manual QA will be hunting for bugs and it is a huge bonus if they have some UX knowledge because there are common little details that Developers miss that should be coded for production. You can also have them run off of the basic heuristics to be grounded in what your Designer is attempting to achieve. You can read about those here.
This individual can be used in a few ways depending on their skill level and understanding. They will work closely with the Developers and also the Product Manager because if QA doesn’t understand the User Stories or Acceptance Criteria set by the PM, it is likely that the developers won’t either.
If the QA Professional is technical enough, they may be able to help the PM by writing the technical User Stories, or owning the Acceptance Criteria section of a Story based on the Business Requirements and Design Guidelines.
Validating Before Coding
To help save you time now and later down the road it would be helpful to land on a framework that you will adopt to build & ship products. A lot of people would assume that this starts with the two Developers you have already hired, but the truth is that it should start with your very first hire, the PM and Designer.
Are you going to use your Active Listening skills and build products your Users want and that solve their problems, or are you just going to build features… there is a huge difference! Ensure that your Founding Team is validating any ideas with quantitative or qualitative data before it is being sent to Development.
If you plan this right, and of course it depends on the depth of the platform your building, but you should be able to hire your developers a few months after your Designer comes on board. You should also ask yourself what a successful product looks like because that will help define how much effort you will need to invest in creating your masterpiece of a marketplace.
Again, using the Marketplace example, what would be a metric you can measure success against? How does one measure lovability? Well, it can be done by looking at your K-Factor or in simple terms, the success of your referral program. If you research why and how Casper became so successful you will stumble upon their word-of-mouth and their prized “Unboxing Experience” that is spread all over YouTube and other social media. When you interact, or consume a product and have such a positive UX that you want to tell everyone about it despite any form of compensation, that is what a successful product is. Now, how do you build this? It is easier than you think as long as you focus on solving problems for your Users and providing them with value.
That is when Design Thinking comes into the picture and helps explain why your PM & Designer should be the first two hires. Read more about Design Thinking here. The reason why we are suggesting this to be widely adopted by you and your Founding Team is that it is a way for anyone to become an expert on the industry you’re in, and become a champion for the Users you’re building for.
Again, you can’t just build and release features to your Users because it is unlikely that you will achieve PMF (Product Market Fit) and be ready to build Version 2 of your product. Design Thinking allows you to test and iterate on the Design level instead of in the code which is what most tech companies do. Iterating in the code will likely lead to a lot of dead-code and technical debt or general functionality confusion. It is also going to be more costly if you just compare your Developer’s salaries to your Designers.
If you adopt and follow it religiously, then you can end up with a living prototype you imagined when you began this journey. More importantly, it is what your Users want and it solves a key or many pain points for them. Once you have a high-fidelity prototype, business requirements, and design guide, all that is left is to create the User Stories and Design Specifications. Once these are completed, you can start coding the first version of your platform!
Trusting Your A-Team
As a non-technical founder, there will be times when you need to take the word of your employees and trust their judgment and decision-making skills. Your A-Team is built with individuals who thrive on encouragement and they understand that they were hired for a reason, to carry out your mission.
The best-case scenario is that you do not end up with a bunch of “Yes Men” or “Yes Women” because you need to be challenged on most, if not all of your assumptions. Challenged meaning that you uncover the WHY behind your reasoning and if available back it up with research and data.
What you don’t want is a team that is following you blindly into the abyss and taking your word for everything. It is completely okay for your Team to challenge you to think deeper about what you all are working to accomplish. Of course, this needs to be done respectfully or behind a virtual closed-door one-on-one meeting, and you as the Founder should be doing the same, challenging your Team even when you aren’t knowledgeable about their statement.
There will be times when you need to trust your Team’s judgment because the reason why you hired them was that they possess skills or traits that you do not. They are hired as professionals in their field, and that carries a lot of weight behind it.
Let’s use an example of letting your first Developer choose your tech stack (Languages & Frameworks). This is the area that you are least educated in and you need to trust that your Dev will make the correct decisions. That being said, there is no reason why you should request for them to show their work or evidence of why they landed on a certain option. You can request them to show the research behind their decision-making and then ask them to explain it to you without any jargon so that you become educated on the matter.
This allows you both to grow as a professional and ensures that you’re trusting the right people with the success of your startup!
Doing What Doesn’t Scale
There is a ton of advice out there for new entrepreneurs and tech startup founders and this is one of the best bits of advice, “Do things that don’t scale”. There are many reasons why this is so important in the early stages of your startup.
1. You Learn & Understand
In the early stages of Airbnb, the co-founders struggled to understand why the adoption metrics were plateauing in New York. An advisor at YC suggested that they fly there from California to get boots on the ground and talk to their Users. What they found was that the quality level of the images of the Host’s places was directly correlated to the number of bookings that the Host would receive.
The co-founders stayed in the city, found a camera, and went door-to-door of their Users explaining they were professional photographers providing a free service for Airbnb Hosts. While doing so, they were also talking to the Hosts about their experience with the platform and understood what they liked, what they loved, and more importantly what they hated.
This was information collected by doing something that doesn’t scale but would be the most important lesson learned, High-quality photos mean more bookings.
2. You Perform Actions Others Won’t
If you’re focused on only doing procedures or processes that scale, you’re in the same mindset as your competitors and are essentially putting on your own handcuffs. If you creatively think of ways to improve your marketplace in a way that won’t scale in the long-term, then most other companies will not adopt or implement it.
Start implementing processes or actions that don’t scale and understand the WHY because you can later leverage technology to help scale it or remove some of the manual processes.
3. You Learn What to Automate Later and How
It is important to understand and learn from your processes or action to improve them in some capacity. If you understand the WHY behind a process or action that doesn’t scale, you are very likely to or someone on your future Team is very likely to find a creative solution to help scale the process entirely.
This is much better because you’ve likely worked out any of the workflow kinks and have found the most optimal way to achieve your desired results. Once that is figured out, it is time to find a way to automate the process.