What is the most critical talent to master for great technical founders?
As software engineers, we always believed that the technical founders are the most critical element in building a startup.
When I first landed in San Francisco in 2008, I fell in love with the area’s energy and the importance assigned to technical people. It was the first time in my life that I saw programmers, system administrators, or security experts leading their companies. The extraordinary fact was that also investors wanted them to guide their companies: they wanted the vision, GTM strategy, and roadmap directly from the product's creator.
That was an epiphany for me because from where I come, the tech lead role was restricted to technical matters or, at most, to lead other technical people.
Silicon Valley has always been different, but even here, being a great technical founder is something you must learn over the years.
Why is that so different? Thanks to an excellent video from YC Group Partner Diana Hu — which I suggest you watch after reading this article — I decided it was time to write about why it is so hard to be a great technical founder. Let’s start with the “founder” part.
A founder never sleeps
The most crucial difference between the founding team and the rest of the crew is that a founder never sleeps, and I don’t mean that, just literally. As a founder, you end up being emotionally connected with your company, and even if you take some time off, your head is constantly attached to what you’re building. You don’t sense the difference between workdays and weekends because you are doing something you enjoy a lot. Every moment can bring you a new idea, and you feel the need always to be able to jot down new thoughts. When everything goes well, you think about improving, making your customers happier, and growing your business. When problems arise, you must find ways to fix them ASAP. The feeling is not always good because you put yourself constantly on call.
Now, every founder acts like this without anyone having to explain to them why. In a way, the founder of a startup is no different from any other entrepreneur.
So, how’s a technical founder profoundly dissimilar from an ordinary tech entrepreneur?
As I recently read in another article, in startups, speed reduces risk.
The fundamental difference between a technical startup founder and a tech entrepreneur is understanding how fast a startup needs to move to become and stay relevant—especially when it moves the first steps. This must impact each of the technical decisions the founder makes every day.
In my experience as a founder and investor, this is the most misunderstood point in the whole startup creation process.
There are many things I could say about those who are considered great qualities for a technical founder, but for this article, I will focus on what I believe to be the most crucial aspect of all: learning how to move fast.
If you miss this simple concept, then 90% of the time, you’re doomed to create maybe a good company, but not one of those rare realities who reach PMF very early and grow their business much faster than an ordinary successful company.
You need a method to apply to every phase of your journey to move quickly. You can’t keep up the pace if you miss one fundamental variable in the success equation: users.
No one will race to invest in a company that took too long to get out of the office and talk to users.
Releasing your product as fast as possible is vital.
Spoiler alert: Building a prototype or product that is larger, more complex, or over-refined than immediate goals require is the most common reason a startup doesn’t release fast enough. Often, because they don’t talk to users enough, this is what technical founders get wrong.
Diana Hu’s video effectively explains what sense of urgency you should have in the initial stages before launching the product. Here I’ll borrow some of her suggestions.
How fast should you move?
Ideation Stage
You always start with an idea and quickly need a prototype to put something in front of users. In this case, you must release it in days. Often it can be something other than a working prototype. It can be a Figma mockup, a fake product, or a landing page. You need to get users interested in your product and observe their reactions.
How do you know if they will need what you want to create? It’s easier to answer this question if you break it down into different ones.
Are they excited about what you’re creating?
If a product like yours was ready, would they want to use it?
Is there a subset of users for whom your product would be an urgent need?
The sooner you understand that, the better. And for sure, you don’t want to spend days and nights building 100,000 lines of code before you know that.
So, don’t say to yourself, “But in my case, it’s different,” or “That’s impossible; I need at least a couple of months because building takes time.”
You’re not building yet; you are gaining enough confidence — and possibly data — that a subset of your target users are thrilled about what you will make.
Getting data or, in general, evidence of this fact is crucial, especially if you want to raise capital before building the product.
That’s how it works every single time.
Building Stage
The goal here is to get users committed to adopting your product; you want to build only a minimal amount of it before getting to that point. That’s called an MVP where, even in a minimal case, most functions are not automated. Remember that, behind the scenes, your users don’t know if a software program manages their requests or if you and your co-founder are doing it manually. Actually, they don’t care.
In this phase, you want more data to consolidate your thesis: some users desperately want what you’re building.
You must release your MVP in weeks. You start from this last statement—weeks—and build backward, not vice versa. And that means tons of hacking, shortcuts, and third-party service integrations. Like Diana said in the video: “Kill the great engineer in you, and choose for speed instead of scaling.”
When you start, it is always necessary to have an extremely pragmatic approach and develop obsessive attention to release times. This way, trying multiple directions is possible; if the first or second idea does not get good results, you change promptly.
Data, even the scrappy ones, is what will make you raise capital when your startup is just a handful of slides.
Remember: “If you build it, they will come” never works, and you’re not Kevin Costner, anyway!
Getting used to acting this way as a technical founder is the biggest obstacle because it doesn’t come naturally to us. A software engineer would like to put his head down and write the best code possible, designing an architecture that scales infinitely. But no.
Great technical founders have understood that very well. They need to convince themselves first, and investors later, that their company has found a blind spot and users are eager to get their hands dirty.
As long as you work in a climate of extreme uncertainty, iterations will be your bread and butter. You may release a new software version several times over 24 hours.
It is, therefore, better to wait to hire more people. This may slow down the construction process, preventing the founding team from managing these early stages with the necessary agility and decisiveness.
I’m usually not a big fan of teams with more than 2 co-founders, but I make exceptions for N-person groups where N-1 are very technical. Technical founders are essential to quickly build and iterate without hiring.
P.S. But don’t exaggerate. Capital divided by 4 or 5 people can quickly leave everyone unhappy as the rounds follow one another and the dilution increases.
For those of you eager to explore this topic in more detail, here is the video of Diana Hu that I mentioned in the article.
