I'll handle the business side
Being "technical" and starting a venture
This is a stock image and I have no idea what it means.
I use to think that it was a common misconception that you had to be “technical” to have a job in tech. Every software company, whether a giant like Google or a smaller startup like Clearbit, is built with a balance of technical and non-technical people.
Roles like marketing, customer success, and sales are crucial to the growth and viability of a startup. So to answer that question outright, no — you don’t have to be technical to have a job / be successful in tech. With that out of the way, I’ll tackle the more controversial question of “do I need to be technical to start a tech company”.
In the first months of a startup, where the idea is still far from validation and the product is laughable, there is a definite need for technical people. In this post, I’ll dive into why I believe it’s incredibly difficult to build a tech company if you’re non-technical, why this is the case, and how I think it can be fixed.
No vision in building
It’s quite possible for non-technical founders to build products that can scale, in terms of purpose and product-market fit. When I refer to this, I’m speaking primarily to the business as a whole, not the product specifically.
From chats I’ve had, and personal experience, non-technical founders don’t have full visibility or understanding in how the product is being built, with relation to its purpose and feature set. For example, if you’re building a product like Slack, there are intentional directional changes you need to make at an early stage to ensure it scales properly.
I heard this via a fireside chat at the Startup Grind conference with the Head of Infrastructure Engineering at Slack. Had a strong technical backend not been taken into account, with regards to how Slack manages load, handles downtime, stores messages, etc, then Slack successfully scaling at the rate that it did would be near impossible.
It’s definitely possible to change products at the later stage, but it becomes increasingly difficult the larger you get. And if your core team is largely non-technical, this is something that won’t be seriously considered.
Building an MVP
This is a thorn that bugs me to this day, and pushes me (step by step) to learn how to code. In my opinion, getting a product validated and determining whether it’s feasible is not incredibly difficult. It requires lots of conversations, cold emails, and going back to the drawing board when things don’t make sense, but it’s definitely doable.
The rising popularity of venture capital, and subsequent willingness of investors (especially in the Bay Area) to take risks on largely undeveloped and untested ideas, means that raising capital (as a whole) is easier than ever. The explosion of Initial Coin Offers (ICOs) and angel investors makes that even easier — products, mainly involving cryptocurrency, can raise millions of dollars in capital with nothing more than a white paper (read: collection of thoughts with no product).
The challenge I consistently face, and have yet to hear an alternative to, is building that “Minimum Viable Product” (MVP). It’s possible to validate VERY simple ideas without being technical — a combination of fancy advertising and Google Forms can give you a sense of whether people are interested and wiling to pay for your product. For anything else (even if it might be simple), it’s hard to create an MVP. Without an MVP, you can’t fully commit to an idea of truly test it out with a cohort of customers / interested users.
In these cases, it’s possible to hire a developer / outsource the work, but I’ve outlined in a past post the challenges of this — namely that it can be incredibly costly, as the MVP will inevitably change drastically in the early days.
Gaining trust
Let’s run with the last example — you’ve spoken to numerous people and validated that your business problem exists (read: Step 1) and you’ve vetted an idea that MIGHT address that problem. Now the final step is to build an MVP and see how users react.
I outlined in the last section the challenges of building the MVP itself, but let’s evaluate the solution of finding a technical co-founder.
I’ll preface by saying there are a ton of jokes in the engineering community around finding a technical co-founder. There’s even a large Facebook group where people post threads and calls-for-submissions they’ve seen where the “business guy” will give equity to the engineer, assuming they are highly qualified (in their eyes). The extreme majority of these cases are based around foolish ideas, where the “business guy” did no validation around the problem OR idea, let alone would know how to find demand / sell the product if it ever materializes. So, for the sake of this scenario, let’s assume the business problem is already validated, there are potential pilot users, and all you need to do is build the product.
For someone that is largely non-technical, finding someone to join you on this arduous, early-stage journey is very difficult. The main reason is the aspect of trust; both in terms of your idea and how you plan to execute it.
What do I mean by this? Imagine you’re in this position, and you find an engineer willing to join you. The engineer builds an MVP, investing many hours into the project. Here is my understanding of their fears, in no particular order:
(1) You are unqualified
The business guy, despite having validated the business problem, is not able to handle pilot users, find demand, and effectively sell the product. Despite the idea having merit, the engineer now sees his co-founder as dead weight, unable to contribute to the project and leaving the engineer wondering “Damn, couldn’t I have just done this myself?”
(2) You are uncommitted:
It’s challenging to validate a business problem. I’ve sent about 400 cold emails and 6-7 strong chats with pilot users for a product I’ve been trying to build. This may have taken 2-3 months of on / off commitment, but to an engineer, often this isn’t considered as “real work”. Quite honestly, I don’t blame them — managing relationships can seem a lot less taxing than building a product that actually does something. The caveat is that this balance (and mutual respect) is needed for a business to function. It’s the exact reason why engineers at large tech companies have disdain for “sleazy salespeople” who make the same amount they do, through what they might see as simply emailing + calling various people. If a prospective engineer falls into this boat, they will be very hesitant to jump on board, expecting you to give up the second things don’t work out.
I’ll go out on a limb and say that the reason most successful software companies are started by two technical co-founders is not because that’s the only model that works, it’s because both people had a mutual respect for each other and were willing to figure out the “business side” together. I strongly believe that this would be a lot more effective if both parties were on the same page.
Conclusion
At the end of the day, I can rant and argue as much as I want, but this is the tech reality that we live in. So to the original question, of being “technical”, with the goal of starting a company, I find it harder and harder to refute this point.
The challenge, and what the note I’ll leave on, is that this is easier said than done. Being a developer requires an intrinsically different skillset than sales / marketing, the latter of which I fall into. Often developers are known as people that think logically or systemically, and have a strong math background. Salespeople, in contrast, are known as people that are relationship-focused — they understand how people function, can read reactions, and can frame problems and solutions in ways that many people understand.
So for the time being, I will be diving deeper into coding / development. I regret that this is the most effective option at the time — it’s definitely not the most efficient. But I believe it will benefit me the most in the long-term.