We are at times when the Idea Guy is the Hated Guy in the room. Yes, it’s becoming as strong as Hate. Everybody is pointing fingers at the idea guy. It’s that guy with nonsense business logic, I’ll keep pumping out great idea, you guys do the dirty work. No one wants to hear an idea guy talk. For founders with a technical or non-technical background, standalone, conversational ideas are worthless. Taking a single step towards proving the worth of an idea is more valuable than an assumption. If the Great Idea turns out not so great after all, at least we now know what its real value is.
Great entrepreneurs can take an OK idea and turn it into a great one. It all comes down to the entrepreneur. The worth of any idea is strongly associated with the value of entrepreneurs.
For decades, entrepreneurs with a non-technical background (business, marketing, finance, etc.), have been undervalued. It is logical when a programmer argues that non-technical entrepreneurs can hustle as hard as they can, be the best sales people in the world, prove their genius marketing strategies and tactics, but if they don’t have a product, their efforts are worthless. Non-technical founders in the other hand argue that programmers can build the best bug free software in the world, but without their hustle, sales and marketing expertise, the business loses potential.
This guide is specifically written for the non-technical founders who fall under one of these categories:
- Still believe their value is in their ideas.
- Want to build or enhance their technical knowledge.
- Want to become a non-technical target co-founder to the best technical founders.
Not understanding the technical side of your startup means:
- Failure to identify good developers.
- Difficulty to effectively manage software developers and projects.
- Projects costing more and taking longer than they should.
- Narrower innovation opportunities.
- Team and co-founder disagreement due to knowledge gap.
- Technical handicap even with simple technical needs.
Technical entrepreneurs: this guide will refresh your technical knowledge but most importantly show you what it means to be non-technical which will help you address, discuss and work better with complementary skills.
Let us begin by breaking down the roles and responsibilities for each member.
Just from a first look, any idea why solo founders do much worse than teams? it is clear that no human will be able to handle all the roles individually. The Kauffman Foundation finds that balanced teams raise 30% more money, grow 3X faster, and are less likely to scale prematurely, while the venture capital firm First Round Capital finds that teams with more than one founder outperformed solo founders by 163%. Furthermore, the seed valuation of teams with more than one founder is 25% higher.
Although in a startup, especially at the earliest stages, every role is everyone’s responsibility, never can one person do well enough at all roles. It is important however, as a non-technical founder, that you learn the different jobs that your tech co-founder/team is responsible for and vice versa.
A web or mobile app is an interface at its surface. Someone with limited tech understanding does not see beyond the screen. For the screen to display and navigate through user commands, there is a whole other world in the back. The tech person in the team is responsible for the front (what you see) as well as the back-end (what you don’t see) side of the app, and more. This demands certain set of skills and knowledge especially if the plan is to go beyond the early-testing versions of the technology.
The best technical founders are good product and operations managers. Again, although expertise is not essential at the beginning, it is imperative that the tech guy in the team is capable of ensuring that the service is operating with expected response times, that is, monitor and take actions. And more importantly, plan and execute product development under the chosen development methodology (agile, waterfall, etc.).
The main objective of this guide is to equip non-technical founders with the necessary technical information for better decision making in planning, management, hiring and contributing to the tech as well as the non-technical side. The last section is a summary of a technical person’s responsibilities in a startup. Find a lot more details in the rest of the guide.
Lesson 1: In recruiting or discussing potential co-founding relationships, look beyond the programming title. A front-end developer can go as far as building a site with limited navigation and functionality. You’re looking for a back-end engineer with front-end and strong back-end programming skills in one or two languages along with a capability to manage the whole development cycle.
For non-technical founders, the truth is that many responsibilities that fall under the profile of the business person in the team are not essential until later stages. For instance, sales, marketing, accountant management, accounting, customer support, partnerships and legal work are irrelevant to early stage startups whose main focus is to seek a scalable model. Until then, the work of the team is centered around customer understanding and development along with a series of development and iterations. And guess who can do all the work? the programmer. With 50% code and 50% customer understanding/development, the tech person in the team can accomplish most if not all the tasks until some traction is reached. But thanks to open source software, cloud-based tools and outsourcing, solo business and design founders can accomplish as much as programmers can.
Cohesive teams, ones with co-founders that have prior work relationship or friendship, don’t think about it this way. It is when two strangers approach each other that the “what do I need you for” mentality is most common. Unless they know the person, entrepreneurs are almost always wasting their time approaching strangers with an idea. The options are clear, build value first or start with a friend, colleague, classmate or family member.
Cohesive teams can speak business, marketing, tech and design. A team of 2 or 3 whereby each member is totally ignorant about their co-founders’ domain is as if 2 or 3 solo teams are combined in 1. You can’t have an honest conversation if one party knows all the answers. Many years ago, a team of technical freelancers prepared a 20-slide presentation just to convince my non-technical friend that WordPress is the best platform for his Fintech idea, seriously?
why is this a horrible idea? Take the example of Square, a mobile payment startup that went public in 2016. According to a Square employee, the company uses Ruby as its main web language, Java for back-end services, Ruby on Rails 3 running on JRuby as its web framework, they are developing their own service framework, PostgreSQL as their primary data store, Redis for caching and finally decided to self-host their servers for security reasons. WordPress which is a content management system is written in PHP for content management; mainly blogging. Imagine a Square like application built on WordPress!
Lesson 2: The most basics of all that a non-technical founder must know about tech is in differentiating between what it technically takes to build a blog as compared to a large-scale web or mobile application.
The infographic below displays a few of the programming languages and technologies that most startup teams use.
The meat of an application is in its back-end. Each one of the listed languages has advantages and disadvantages. I am in no position to discuss each language from a programmer stand point, but I will reinforce lesson 2 above. First, as you can see, more than one programming language can be used for one application. Each and every one of those languages can be used to accomplish the same goal; build the same features, but depending on the concept and its needs, some languages are better suited for certain concepts than others. For instance, real-time applications like Uber and Ebay’s auction, are better built using languages that offer concurrency options like Java, Scala and Go. High security applications such as stock trading and payment processing are better written in languages that offer stability and security such as Java and C#.
Lesson 3: One of the main technical responsibilities of a non-technical founder is to lead the technical team in choosing the best stack for the application. This requires good understanding of the technologies, languages and frameworks.
The next time you post a job proposal, you’re not going to entitle it: need to build a website. You should know what technologies and languages you need, how to pick the right candidate and what technical questions to ask. The best non-technical co-founders, not only add tangible value in leading the technical team to use the right resources but also goes above and beyond to learn the ins and outs of the chosen stack (list of tools, frameworks, languages, and databases) to evaluate team work and progress, and make interesting technical recommendations. Steve Jobs did just that. Even though he was not a programmer, he spent countless hours reading books to equip himself with technical knowledge to make a better technical and non-technical leader out of himself.
Because virtually all stacks can accomplish the same goals, an early stage startup can use whatever it is accustomed to until some level of validation is reached. This switch as you grow approach has been adopted by most agile startups. It isn’t a viable option, though, for startups using the waterfall project development methodology.
As a non-technical founder, you are responsible for the How part of building a startup. The How is about the process, in other words, which methodology should your team follow for project development. By online searching Project Development Methodologies, you will find a list of around 10 methodologies that small and large companies follow. The Waterfall and Agile methodologies are the most used ones.
As a startup entrepreneur, this paragraph should be the last minute you give to a waterfall methodology. You’d adopt this project development methodology when you know exactly what you need to build, how you will build it and how the end result should look and function. Writing a 30-page scope document, spending 9 months building the product then launching what seems to be the perfect bug free product is another description for this methodology. In a world like the one we live in, filled with uncertainty and unexpected events, pre-definition of the perfect product is a fairy tale. Let alone if the end goal is innovation and disruption. Within the development phase of a Waterfall methodology, the project, depending on size, is usually divided in sprints. Research shows that if a bug was not found and fixed immediately within a sprint, it takes 24 times as long to fix later. In other words, if you are using a Waterfall methodology and do not detect all bugs at the right time, you will waste months if not years in adjustments.
The Agile methodology, in the other hand, is about adaptation, flexibility, frequent delivery and customer involvement. Teams using an Agile methodology build, test and iterate fast. This comes in handy for products with unknown requirement and where user needs are yet to be quantitatively validated. The Standish Group shows that projects are 3 times more likely to end successfully under an Agile methodology as compared to Waterfall. The same study shows that development costs tend to be a lot lower.
Lesson 4: Become an Agile master. Learn the terms, proven tactics, best tools and resources to maximize the productivity and output of your team. The best non-technical founders are facilitators. They can predict and eliminate unnecessary bottlenecks.
Should you learn code?
Even the best programmers (technical founders) end up away from their computers after some startup milestones are met. In other words, once the startup is at scale, a technical founder, who is usually actively involved in the programming of the initial versions of the technology, ends up taking a leadership and management position. Rob Cromwell CTO and co-founder at Inkling writes,
“When starting out, I neglected most of these (recruiting, defining and reinforcing culture, establishing standards, tools, and engineering processes, developing an IP strategy, and being a business thought person) responsibilities and was focused entirely on coding. Through a combination of difficult conversations with my co-founder and CEO Matt, hiring mistakes, and a few very painful arguments over standards, I began to realize the breadth of the role I had taken on. While I initially gravitated toward the areas of responsibility that were closest to my technical comfort zone, I now realize technical leaders need to be excellent at all five in addition to being a technical leader and managing the team.”
The answer to our question is, you don’t need to. I met a lot of non-technical founders who saw a need to learn code so they can program their own applications. I suggest you look at it from a long-term perspective: since you will eventually lead, you are better off learning to become a better technical manager than a programmer per se. Furthermore, following the startup roles and responsibilities table above, it is clear that each person has a lot to handle already. This is an obvious reason why investors are more likely to fund teams. Regardless of how much programming, business, marketing and design a person knows, there is a limit to what they can accomplish by their own. The best founders know a little bit of everything but specialize in one or two things.
This is what the best non-technical leaders do.
They Learn The Stack
As we saw above, an application can be separated into front and back-end languages. There are many languages and technologies that a team can select for each one of the two groups based on suitability and team expertise. A stack includes the chosen languages plus the list of frameworks, databases and tools it needs to build the application. To use an example, this is the stack Instagram chose: they use Python as their main programming language, for their web framework, they use Django as web application and API server for mobile apps. Nginx and Amazon Elastic Load Balancer for the server, and PostgreSQL as the primary database. Redis is used for the activity feed, Memcache for cashing, AWS S3 for storing photos, Apache Solr for geo search, and Ubuntu Linux as operating system.
Your first responsibility as a non-technical leader is to be part of the technical stack conversation to steer the team in the right direction by asking the right questions. This requires some homework. It does not take long to learn the ins and outs of each tool, language, framework, database and what can best fit your needs.
They Define, Implement And Evaluate Processes
The best non-technical founders are process masters. Based on the chosen project management methodology and startup culture, it is non-technical founders’ responsibility to ensure that developers have the necessary resources, their actions and decisions are optimized, and contributions are well defined. For this to happen,
- End goal should be well articulated: one of the biggest milestones of a startup is to reach product-market fit. The technical team must know what reaching the fit looks like and what it takes to get there. One may ask, what does it take to reach product-market fit? understanding user needs, building to address the most urgent needs and solve the biggest problems one feature at a time, and finally doing it with discipline and quickly. For this to happen,
- Team members’ skills and the development/design tasks must be aligned: this is especially important for non-technical founders building a team of complementary skills. If you can control who you can have in the team (have the budget to hire), the right people should work on the right things. For instance, some engineers look for the challenge, others prefer to move fast and break things, others like to innovate, etc. Frankly, the skill-task alignment is unlikely to happen at an early stage startup but the idea is, if you can hire one person, make sure you optimize their involvement. Again, this requires planning, understanding of startup needs and clear end results/expectations.
- Systemize work flow: the truth is, just like with startups, a team goes through ups and downs until a repeatable process is reached. When a team reaches repeatability, less time is wasted and more things get done. Everything starts with as simple as a transparent work flow diagram. In the diagram, members see how the process goes from ideation to development, testing, deployment and further including the tools and members used and involved in each stage. Just like with startup ideas, the process evolves with testing, discussions and brainstorming. It is meant to clarify responsibilities, expectations and set standards for success.
They Master The Data
Mastering the data begins with an identification of the data that matters. It starts by defining the user, the channel, the funnel, and the metrics. Knowing what everyone should care about is the foundation. When everyone in the team is in line with the metrics and what needs to be done for those metrics to be taken from one point to the other, team and individual efforts will be maximized towards the set goals especially if the reward is based on meeting and exceeding those goals. Facebook early founders displayed live user growth so everyone can monitor and celebrate milestones. Your job as a non-technical founder is to define key performance indicators and construct an ROI model built on customer acquisition costs and their life time value. Finally, effectively communicate how members’ responsibilities contribute to the selected indicators and how their reward is dependent on their performance.
They Hire The Best
I find this being one of the most challenging responsibilities of a solo non-technical founder. A founder with a business background can evaluate members’ past performance, personality and intentions but, once hired, it is challenging to evaluate their work without a good understanding of code. The best non-technical founders do their requirement homework by making sure what exactly needs to be technically done for an application to be taken from one point to the other (idea to prototype or prototype to MVP or MVP to a scalable product, etc.). This entails more than a good understanding of the different technologies, languages and stack overall. Nonetheless, it has been shown over and over that hiring based on personality and attitude is good enough to find the best fit. Furthermore, founder mentors and advisors can be of great help in selecting the best candidates and monitoring their work.
Unqualified members can attribute failure to resource limitations, blaming the user, servers, time, ambiguity of scope, etc. While each one of these reasons can be valid causes, they are usually not. This is because the best members can expect and take proactive steps to complete tasks and exceed expectations. Blaming functionality on users is a red flag; unacceptable and should not be tolerated. Beware of unethical behaviors. Take your time hiring through interviews and tests. It can take months to find the right fit but when you do, it will more than pay off the wait. You’re looking for those who assume their responsibilities and take what they do very seriously.
Also, beware of the cheap development/design trap. The market doesn’t usually lie. When you see the average hourly rate of an experienced programmer ranging between 60 and 80 dollars an hour, hiring programmers for $5/hour (even in Asian countries) is a red flag. The best members know their worth and do not perform as well if they’re underpaid. Bargaining the hourly rate doesn’t work in the long term. You can get a good deal if you bargain the price of a product in a local market but not with human capital. Yes, you can invest less abroad but this can come at cost such as time difference, less accountability and monitoring. It is extremely important to take your time finding the right fit.
Internally, cheerleading is about the vibe, energy, moral and motivation. It’s when you step in when everyone or someone is down. It’s when you push, calm and remind everyone about the light at the end of the tunnel. Externally, cheerleading is about getting some weight off your team’s shoulders by resolving customer issues, addressing their needs, assuring them the problems will be fixed soon through constant communication. From a technical stand point, this responsibility does not involve programming but a good understanding of the used tools such as the chosen project management platform for reporting, assignment and feedback. Let this part also be in the work flow diagram such as person X is responsible for assigning issue Y to person Z otherwise W in case Z is out. There is no Right process, it is a matter of designing a process that is built around maximizing performance by reducing waste time and aligning tasks with members’ expertise and interest.
Lesson 5: It’s not only networking, fundraising and strategy sessions. The best non-technical founders bring tangible value to product development through planning, facilitation, process management, data analysis, recruitment, structure, leadership and motivation.
With this, you’re a strong asset that, unlike common trends, technical founders would want to fight for to attract as a co-founder or team member. The truth is, it takes roughly 10,000 hours of practice to achieve mastery and most likely you will never be able to replace a VP of Engineering or CTO and you shouldn’t because even these two leaders can’t operate a company without business leadership. What you will become is an invaluable member that investors want to fund, the best talents want to join and most importantly one that can take the startup from nothing to a scalable company worth acquiring or taking public.
If there is one thing you can do today what would it be?
No books, guides, conferences or degrees can teach technical or non-technical leadership. It is by doing, making mistakes and failing that you will cultivate and master the principles and lessons that you learn from this guide and others. Today, execute and don’t be afraid to break things. It takes time to connect the dots and only when you face a situation once or twice, make decisions and evaluate outcomes will you truly and practically understand what you’ve read over and over again.
Yes, starting a startup once seemed like all about building a website. The attitude sounded something like, I don’t care how, just build me a website with these features. I hope this guide has made it crystal clear that valuable startups are built on strong foundations that mainly consist of members with complementary skills and shared vision and passion. With these members, the best technologies can be built, promoted and scaled.