Can’t be bothered to watch the whole video at work so I apologize if this is in TFV.
If you can’t find one technically minded person who believes enough in your vision to drop everything and help you make it, that is not a good sign for your vision.
That's why the willingness of a software developer to drop everything to work with you might not necessarily signal anything wrong with your vision.
If you can't find a single software developer who believes in your plan for better APIs or project management tools or consumer internet apps, it's a pretty good heuristic that your vision or ability to sell it sucks, or that you add less value than the dozen other people that talked to them about chatbots for X this week. Any prospective technical co-founder has a huge amount of insight into those markets. On the other hand, unwillingness of software developers to believe that the dullest sounding CRUD app going will be very exciting to grey suited men controlling a little known niche (probably precisely because hardly anyone's writing software for it) doesn't actually mean there isn't a market there.
Your product could be boring and useless except to a niche audience, but still a great business opportunity. In that case, people will only work on it for the money, and that is fine. Some ideas are simply harder to sell to potential employees:
“We’re making the world a better place through paxos algorithms for consensus protocols.”
“We’re making the world a better place though software defined data centers for cloud computing.”
“We’re making the world a better place through canonical data models to communicate between end points.”
“We’re making the world a better place through scalable, fault tolerant distributed databases with acid transactions.”
Yeah, I think the big difference is that devs might actually [be the only people to] think those sound like interesting problems to work on, whereas making the world a better place through [equivalent jargon in niche logistics/tax/pensions etc] only excites a small number of people who aren't devs, especially if it's not that much of a technical challenge and the hypothetical moat is just sales and business logic. Which leaves money, and unless the founder with the business model hires rather than looking for tech cofounders, it's really only a possibility of future money for working unpaid on something they don't understand on offer...
I don't think it's about the audience, but the company type. If someone is starting (random example) a food company based on their superior hot-sauce recipe and existing retail relationships, they probably don't need a technical co-founder. If someone is starting a company that "uses AI" to craft and target hot sauce recommendations, but doens't really know what that means and assumes they can get a shop to code them an app, that's going to be a problem. I think the latter case is what this is usually about. Many (most) business owners don't have technical co-founders and are fine, not so in tech.
In your first hot-sauce recipe example, that person IS the technical founder. Just technical in the field relevant to the business, which happens to not be tech.
The scenario in tech is more often comparable to some dude saying "I want to make a business selling the greatest hot sauce ever" and then having to go looking for someone who actually knows anything about hot sauce.
I think the idea that the person with the specialised knowledge of how to make hot sauce is the technical founder is an interesting point, but I think in YC/HN contexts it's usually considered to mean "engineer"; even in cases like accounting software where the founder who doesn't write software's specialised knowledge of the field is at least as critical as their partner's ability to convert that to code, the latter founder is the only "technical" one. Although tbh I don't think accountants or lawyers get offended by the insinuation they're the "non-technical founder".
The video goes into why that's the wrong mindset. If you're looking for people who "believe in your vision", there's a good chance you're looking for an employee, not a cofounder. Strong candidates have their own vision, and strong teams build something out of everyone's vision.
It can still be the case that one person has an awesome idea that everybody else in the company signs off on. But chances are, everybody on the team is going to have to make some room for other people's ideas and takes on things.
The inverse side of this is, that depending on the business, you may need another type of co-founder as well. Two technical co-founders aren't the right fit for every business.
This is what I constantly tell my students: The hard part about doing a tech product for the most part isn't the what beginners think makes tech hard — the hard part is wrangling systemic complexity in a good, sustainable and reliable way.
Many non-tech people e.g. look at programmers and think the hard part is knowing what this garble of weird text means. But this is the easy part. And if you are a person who would think it is hard, you probably don't know about all the demons out there that will come to haunt you if you don't build a foundation that helps you actively keeping them away.
>This is what I constantly tell my students: The hard part about doing a tech >product for the most part isn't the what beginners think makes tech hard — the >hard part is wrangling systemic complexity in a good, sustainable and reliable >way.
I teach the same thing, seemingly every day to my teams. It doesn't work, until it works reliably, within reason.
High-5 from the doers to the teachers! (Both are needed)
For the record, my partner teaches at a major university, just not tech. ;)
I don’t know, I’ve mostly followed this approach over my 20 year career, but it really depends on your surroundings, and honestly hasn’t led to great success.
E.g. If you’re surrounded by yes men who will code whatever without question, product people greatly prefer that, and you end up sidelined.
There’s also plenty of companies who don’t want engineers getting involved with decisions, and product and UX people work upfront and in isolation until you’re handed tiny Jira tickets with Figma mockups attached. Discussion at that point is considered “disruptive“.
It honestly seems like this has gotten worse in the past 5 to 10 years.
> note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer
> sad but true: learn "yes" then learn blame other grugs when fail, ideal career advice
> but grug must to grug be true, and "no" is magic grug word. Hard say at first, especially if you nice grug and don't like disappoint people (many such grugs!) but easier over time even though shiney rock pile not as high as might otherwise be
> is ok: how many shiney rock grug really need anyway?
> E.g. If you’re surrounded by yes men who will code whatever without question, product people greatly prefer that, and you end up sidelined.
I'm amazed at how non-obvious this seems to most engineers and how often this angst gets repeated in online tech communities. I mean, when I was in academia there was a tension between publishing impactful results or cozying up with the right professors into the right conferences vs outputting meaningful work (pressures into p-hacking or having big names author suspicious results is par for the course.) In industry it's the tension between product folks and engineers. Have you ever talked to high-level finance folks who deal with the tension of product folks just wanting to do things and finance folks who remind them how money works?
It turns out that the hardest thing about getting things done with people is... dealing with people. I wish there was a way to remove this weird somewhat-ascetic blockage found in tech communities about this. Many of the more physical engineering occupations have to deal with this in the form of contractors and supervisors. Wait until you have to work on a government contract lol.
When I mentor junior engineers with these feelings, I like to use an adage: "Where there are people there are politics." Look at pretty much any prominent FOSS project and you'll see tons of it (by dint of transparency) and those folks generally focus on the project and not a product!
I can see this in academia, because you're working on reputation as much as anything, if not more so, sorta prone to being like this in a way.
Finance however, not once[0] have I either observed nor heard of someone working in finance being overruled by a product person. If finance says no go its no go, simple as that. People tend to listen to the money folks, even at a high-level.
[0]: I work both in fintech and have lots of professional colleagues that work at other financial firms from big banks to all manner of investment firms and much in-between, as well as several generations of family who have all worked in finance on various levels. Honestly, its high level finance people trying to pressure others into getting things done faster when they want something done, not the other way around.
> Finance however, not once[0] have I either observed nor heard of someone working in finance being overruled by a product person. If finance says no go its no go, simple as that. People tend to listen to the money folks, even at a high-level.
Totally, but finance people want to see the company succeed too, and even if finance says it's a no-go, product people will still keep trying to push around them. I just mean that this tension exists between different stakeholders in every organization. If we knew ways out of this, we'd revolutionize government bureaucracies, vastly increase firm efficiencies, sort out FOSS issues, the world would be our oyster! But human coordination problems are really hard. The hardest problems out there really. That's my general point. Too much airtime is given to tech people who seem to not understand this. It's a bit like complaining that when I jump I fall down. I also can't imagine spending 20 years bemoaning this aspect of human nature.
The real human element that I've observed, having been both in management and as an IC, and more broadly from research I've done as a whole, is that ENG is often the profit driver but has the least amount of say in their own workload.
I think this is where the tension comes from in the lasting, I'm still complaining about 20 years later sorta thing. Once you realize the value you are delivering to the company, naturally, you start to want to have some more say over the value chain, I think this is innante to human behavior, but there is alot of gates between ENG and the rest of the org, most of the time, from what I've observed.
Look at, for example, how "Agile" is implemented at a company. It focuses on ENG having to address stakeholders, without really saying that ENG should be its own stakeholder too. With SCRUM and other systems, the emphasis tends to be on outside stakeholders and what they want, rather than bringing ENG to parity with other stakeholders so everyone has more equal input on the work streams - which ultimately, when this is actually done, prevents more problems than it creates, nearly every time - yet you can feel the resistance in most orgs to giving ENG a full table stake
It has, because embracing agile as it was laid out in 12 principles put too much power in these "technical" people by giving them a stake at the table, to anyone who doesn't work in an ENG first / ENG focused company.
If you look at how "Agile" is implemented in most organizations - even in technology companies! - there's alot of barrier process put up to sideline / minimize engineering input by focusing on stakeholders where stakeholder is defined by everyone telling engineering what to do as opposed to engineering being seen as a valid and reasonable stakeholder too.
I think its because in part there is a linear pipeline that the non technical business side sees as how things go: you plan X, it gets designed by Y, and then "manufactured" by engineers, if you will.
Engineers - good ones, in my estimation - want more stake in each step, both in planning and design, because often its engineers that work on the system the closest (you'd be shocked how many designers don't use their own products on a daily basis, same goes for alot of business oriented folks) and this is not "the way the world works".
So let others add ideas to the backlog and the product owners triage? I would be worried about ideas getting drowned, leading to a disincentive in participation. I would probably add a layer of voting or something to allow good ideas to surface.
I meant that product still writes the high level user stories, but eng figures out the solution along side UX, product, etc. Not handed broken down tasks and mockups first.
Kind of, and it usually works. Even as a founder you can trick yourself into doing things that way. I've found that 20/80, Pareto style, is even better. 20% of the features can achieve 80% of the sales, and you'll be a lot happier if you're not constantly chasing the long tail.
80% of the features/details for 20% of the code/complexity. Even minor tweaks can have an outsized effect on the final code. A large part of my job is doing this in such a way that satisfies the stakeholders.
You do 80% of the functionality with 20% of the required code and pretend that this is what the project manager asked for. Likely they'll never notice the missing bits which may have seemed like a good idea at the time .If they insist you do 80% of what remains with another 20% of the code.
But with some luck your project managers' butterfly mind will have flitted on to greener pastures and everybody is happy. No need for Grug to reach for his club (while remaining calm).
I mean, this is largely true in software engineering in general. Programming is easy. Perhaps being an excellent programmer is much harder but for many things being mediocre is good enough.
The hard part is building things sustainably at scale (people wise or performance wise). That's when a combination of knowing how to manage systemic complexity and knowing how to communicate very well (soft skills) really come into play.
IMHO the hard part with a startup is you don't want to build something that works sustainably at scale. You want to build something that could plausibly morph into something that is sustainable at scale.
I've started to look at scaling like you're killing a golden-egg-laying goose but there's a 1 in n chance that it'll pay off for you. n starts higher than you'd hope and rises as you make tradeoffs.
I've been thinking about scaling a bit because I've been digging into a large SaaS product for a client and find I am able to replicate their locally relevant output at a fraction of the cost. Scaling up has allowed this SaaS to serve an entire country but a majority of their user base think in terms of one or two local counties. Consuming their output means subsidizing work they do that's irrelevant to (or might actually compete with) your own interests.
There is a weird local optimisation problem where being an excellent programmer can make one a bad software engineer. (Another: unparalleledly excellent Excel skills making one a worse financier.)
I've seen this so many times in my career. It happens because interviews (especially at the junior level) focus almost exclusively on line-by-line programming acumen. People who excel at those interviews don't always make great software engineers, and sometimes they make terrible ones.
suppose you need to either be in the top percentile of handsome and the top percentile of emotionally aware to get a job as a hollywood actor, but these attributes are uncorrelated in the general population, so 99% of top-percentile-of-handsome people will be top-percentile-of-sensitive and vice versa
then the pool of hollywood actors you observe will contain, out of every 199 people, 99 who are top-percentile-of-handsome but not of sensitivity, 99 who are top-percentile-of-sensitive but not of handsomeness, and 1 who is both
someone observing this result but not understanding the process that led up to it might think that emotional sensitivity makes you ugly or that being handsome makes you emotionally oblivious, even though (by hypothesis) the traits are uncorrelated. in fact, this negative correlation in the selected group can survive even a fair bit of positive correlation between the traits in the general population
similarly, it's easier to get a programming job if you have a history of delivering successful products, or if you have a lot of line-by-line coding acumen
This is what I always say. In college/studying you learn programming, CS, algorithms etc. Once you're a software engineer, you realize that programming, CS, algorithms etc are the easiest part of your job. If the code is too hard for you you're most definitely losing on other things. It sounds very obvious, but think about it, part of being a good software engineer is that programming should be trivial.
The business degree kids with an idea need to realize the tech cofounders can learn and understand business.
Having an idea is like having a thought.
A startup needs product and distribution. If a tech cofounder builds what’s asked of him and the sales cofounder can’t sell, should the ownership revert to the tech cofounder?
I love the way you put this. It also doubles as a great explanation for why programmers shouldn't be worried that ChatGPT is going to steal their jobs: ChatGPT is good at the garble of weird text, but it's terrible at the "wrangling systemic complexity in a good, sustainable and reliable way" piece.
I think ChatGPT will eventually be good at the garble of weird text. It's immensely helpful already but you really must be checking up on what it is telling you. Plausible but non-existent or incorrectly used APIs are routine still. I definitely bet on it eventually getting there though.
You know what computers couldn’t do 10 years ago? Understand and write coherent code. Why do you feel confident in your opinion that they won’t be able to do that in the next 10 years?
2) a strong history of understanding the limits of functional automation (why are there still project managers? Asana exists!)
3) an understanding that progress will slow in this space considerably once we have made the big wins and the hype cycle dies down. (see also; every tech hype cycle)
I go the exact opposite way on number 3. It seems more likely to me this follows the growth trend of the internet, mobile phones and computer graphics than blockchain and VR. 10 more year of growth like the last would be pretty wild to experience.
If they can "wrangle systemic complexity in a good, sustainable and reliable way" then I think that's AGI. If we hit AGI we'll have plenty of other things to worry about beyond being able to make a living as programmers.
What we describe as common sense isn't actually common. That is, over-hyped things like microservice architectures saturate the Internet. Since content of the Internet is generally what will become content for LLMs etc it stands to reason they'll be similarly biased towards hype.
Yes, it's certainly possible for content to be curated and models to become biased in other ways but...
"Grog, 10 years ago in 30,000 BC, we didn't even have wheels. We've gone from no wheel, to wheel, in only 10 years. What makes you so sure that self-driving cars aren't just around the corner?"
depends on what part of "doing a tech product" you're talking about
> the hard part is wrangling systemic complexity in a good, sustainable and reliable way
in an early startup, this thinking is one of the most common ways to failure. people optimise their technology for its scalability, reliability, and "cleanliness", when none of that matters yet. all that matters is finding product market fit
To rephrase your point with tongue-firmly-in-cheek: "many technical people look at products and think the hard part is wrangling systemic complexity in a good, sustainable and reliable way" but in reality, that's not the hard part.
If your product is successful enough that systemic complexity is your chief problem, congratulations, you've made it further than most startups - which die from lack of demand, lack of paying customers, and lack of users giving feedback.
That may be more of a personality conflict. There's no more important choice than who you co-found with, and both parties should have high regard for each other's value to the business.
Of course that’s how it _should_ be. After working at enough startups in very early and/or founder roles, I can tell you it’s more common than not to get treated like a second class citizen when the “business” dinners come.
A tale as old as time. Gotta love the classic spin on the same trope of “the C suite drives the sales tho” to justify their insane salaries and bonuses. like they’d have anything to sell in the first place.
I’m not diminishing the effort and skill necessary to be a good salesperson. I am, however, commenting on how often that turns into engineers being kept “in the back” when the paperwork starts.
Might I suggest not being "just a programmer" then?
In a startup it's extremely important for founders to wear many hats and share many burdens.
If you're the person that just goes off into a cave and emerges with beautiful code 6 weeks later and then expects everything to be great - you're wrong. There's a massive amount of foundational work to do to support a startup that technical people don't even think about.
As someone who's rarely been "just a programmer" or "just a designer," that hasn't stopped me from being viewed as such by managers if it's convenient for them to mentally classify me as such.
The point is you can act like whatever you want, and so can everybody else, and often that means they'll be idiots, often in consequential ways. That's life.
The point is if you act like an employee, you will be treated as an employee.
Starting a company is not easy. If you stand around and only do tech, then you're not a founder, you are an employee. If you have to ask "what needs to be done next?" you are not a founder, you are an employee.
If you call someone your manager, then you are an employee.
If that's happening then you're not really a cofounder - you're acting like an employee.
If you're a cofounder you do not have a manager...
Starting a company requires a diverse set of skills, almost none of which are technical. A technical person can excel at those tasks, but they have to have the desire to figure out what needs to be done before asking what needs to be done.
It's interesting, how all this stuff is written for the biz-bros, too -- try doing a google search on how to find a non-technical cofounder. Like, say you're an eng, with a technical idea you think would make the foundation of a good startup, and you're looking for someone to "found" the PM/marketing/bizdev side of things. From what I can see, the content/advice doesn't exist, even via YCombinator.
why would you want a nontechnical cofounder to do the pm/marketing/bizdev side of things? a nontechnical person might be able to do those things, but technical ignorance or incompetence are not necessary for them, and aren't even assets; they're just less serious drawbacks there than elsewhere
you might genuinely need some nontechnical people in your startup, but if you have some money you can always pay people to come be part of a focus group or user test when that's necessary
yes. why would you want the three people doing those three specialized full-time roles to be nontechnical?
it seems to me that, given a nontechnical person who's good at one or more of those roles, they'd obviously be even better at it if they also understood the technology. ignorance and incompetence are weaknesses, not strengths
as for having some money, the context of this discussion is startups with angel or vc funding, which is plenty for focus groups and some user tests
Because good luck finding those three roles where they’re from a technical background?
I’ve worked with a grand total of one PM who was from a technical background. He was actually a great engineer but he was absolutely the exception to the rule.
Sure, if you can flesh your team out with entirely technical people filling those roles, great for you, but that’s like asking why you wouldn’t only hire 10x engineers. Well of course if you could find and hire only 10x engineers you would, but it doesn’t work like that. Especially considering those are all industry positions that are typically taken by people who never went into technical roles.
right, so people who are looking for a cofounder to fill those roles aren't looking for a nontechnical cofounder; they're looking for a cofounder. they may have to accept a nontechnical cofounder, but that's not what they're looking for. that's why there's no advice to be found on finding a nontechnical cofounder
i feel that my first comment in this thread already explained this with perfect clarity and you've just been trolling
to correct your error: nontechnical skills like marketing, grit, forgiveness, and negotiation are far more critical to business success than any technical skill
you are the third person here to incorrectly attribute to me an undervaluing of non-tech skills, but that's on you three, not me; you're just pattern-matching what i said to some kind of stereotype and guessing what kinds of opinions i might hold on questions i haven't talked about. it's as if i had advocated abortion rights and you attacked me for advocating gun control
but i'm not in favor of gun control, and i value non-tech skills very highly. you guessed wrong, and you should be ashamed of yourself for falling into fox-news-style stereotype-based reasoning instead of thinking about what i actually said
the particular communication skill i need in this case is the skill to avoid communicating with people who will ignore what i actually said and substitute something they would prefer to argue with
Wow - that's an irrelevant tangent. HN guidelines are to avoid flamebait and politics.
> why would you want a nontechnical cofounder to do the pm/marketing/bizdev side of things?
This is what my comment relates to. It seems to me that you are dismissing the potential value of a non-tech co-founder. A co-founder is not telling the dev what to do. Partners whos skills complement each other. I helped co-found a successful business with 4 founders: 1 sales, 1 BA, and 2 dev - although we were all tech types with far wider skills than the stereotypes of the labels I used suggest.
To be clear: some people don't need a non-tech co-founder, but I have seen devs try to start businesses where I felt the devs would have done better partnering up with non-dev co-founders. Also if one can't sell a business to a high-value co-founder, then my guess is one likely lacks the skills to be successful.
> case is the skill to avoid communicating with people who will ignore what i actually said and substitute something they would prefer to argue with
I am replying because I felt you ignored what I said, and you substituted something you preferred to argue with.
I'm not trying to change your mind - I'm just trying to explain how your comments come across to me - it is about me not you. I'm not trolling to make you angry - HN is not for that and why waste your time or mine. All good.
you guessed how highly i valued non-technical skills, based on literally zero information. i explained how highly i actually value non-technical skills, which is utterly contrary to your guess. you maintain you 'made no error', which i suppose means that you believe your initial baseless guess was correct, and i'm either mistaken or lying about my own beliefs
and somehow you think i'm the condescending and rude one?
my initial comment didn't even say how highly i value technical skills; it only said that the sign of the value i assign to technical skills is positive rather than negative—in the context of looking for a cofounder (as opposed to certain other contexts, such as finding user testing subjects, where the sign might be negative)
i explained that, by answering my comment in the way you did, you are engaging in the same kind of flamebait and politics that kills rational discussion around topics like abortion rights and gun control. (please stop doing that and respond to what i actually wrote.)
in response, you're implicitly claiming that i'm the one who's bringing in the flamebait and politics?
i don't know what you expect to achieve with this kind of darvo bullshit
no reasonable person could claim that when i say 'nontechnical skills like marketing, grit, forgiveness, and negotiation are far more critical to business success than any technical skill' i am 'dismissing the potential value of a non-tech co-founder'
but you did make that claim
what i'm dismissing, as i've explained at exhaustive and exhausting length, is the idea that they're valuable because of their lack of technical skills, rather than despite it (and because of their other skills, which, as i explained repeatedly, are even more crucial to business success)
I think the amount of technical expertise needed varies by field. I work in a small biotech startup. In this space, you aren't going to get anywhere without deep technical knowledge.
Maybe. Those posts offer preposterously low equity, so I wonder whom it is supposed to attract. Suckers?
Y Combinator sincerely wants people to succeed, I don’t think it’s reactionary or myopic like that.
That said, to fill whatever hundreds of spots nowadays, they’ve exhausted Math 55, it graduates all of 12 people every year.
They’re dipping into a far greater supply of nepo babies than ever before. Those jagoffs can’t do anything - not programming, let alone sales - so whom is this advice really for? Those companies will “succeed” anyway, I mean they won’t fail. You can make a ton of money as a technical cofounder, but for the minimally intellectually stimulating problems of some moron's meaningless app, for that moron to get all the glory? Just to polish life off by marrying your subordinate and sending the kids to Day School? And shoveling all that money right back into meaningless angel investments?
This is a stylized comment of course, but it's just to say, yeah, you need a technical co-founder, really easy for Y Combinator to say. I too would like extremely talented people to give everything and take nothing.
Do you mean the “founding engineer” jobs? It can be misleading, but those are not founder roles. They are regular employee roles where the “founding” part of the title is just an honorary indication that the person joined the company early.
YC won’t count someone as a founder unless they have at least 10% equity in the company. Founding engineers are typically getting 2% or less (from what I understand).
Founding Engineer = Engineer making under-market salary for tiny sliver of equity who can be laid off anytime because the company is fledgling, works 70hrs a week, puts in major % of work a founder would contribute, but has little upside.
To be honest, for someone who cant land market salaries (e.g. non typical background), who finds a good team, this might be a good opportunity.
The inverse is also true. As a technical founder, and maybe even an introvert like me, you should definitely look for a non-technical co-founder who can help you with networking, etc... I found my dream co-founder through YC Co-founder match and what can I say, it's going great. We're focusing on enterprise GraphQL/API solutions (https://wundergraph.com) and I benefit from the networking and communication abilities of Stefan, while I answer all technical questions. Tldr, I highly recommend to team up with people who complement your skills.
You hit the nail on the head with complimentary piece - and extending that to personality as well.
You need a mix of technical skills (engineering, product, marketing, etc) but also personalities (which manifest in different behaviors which are all useful & compliment each other - eg bias for action and hitting targets vs careful analysis).
I'm very strong in logical analysis and strategic thinking. My problem though is that I have a natural tendency to not talk to people. Ask me a question and I'm happy to answer, but I don't like to initiate conversations. Stefan is the opposite. Everybody loves him. He can talk to everyone and he's very creative in finding leads and building connections with other companies. But he's a really bad developer. Together, we're a really strong team. I'd say without him, I would still not have a strong network.
Honest question: Why can't this person be employee #(single digit), SVP of sales or something, hired during product development? Why the need to elevate to co-founder? Does an introverted technical founder really need an extraverted non-tech networking expert from day one?
When you build a startup, you have to go through so much crap, a lot of people wouldn't do that for money. But there's another aspect. Early on in the startup life, sales is not just about selling but "exploring". You have to learn about the market, what people want, what your ICP is, how to target them, etc... Does an employee care enough? Do you really want to put this responsibility into someone else's hands? I'd say no.
I think this trope of 'technical people = awkward introvertive nerd' is becoming less and less true. The normies have learned our craft, and they're not necessarily worse at it.
I am developer who spend 2 decades developing things. First decade it was hardware and now I moved to software. I can always guess which idea from “idea person” will work and which is not technically feasible. In my limited experience the “idea persons” are not really listening why stuff does not work. Sometimes simple laws of physics are ignored.
Having started a small business I respect greatly the skills of great sales people and fund raisers and people who are great with people. But I don't respect them when they think they can start a business where they don't take what they actually make seriously and think the product will just work its self out if they sell hard enough.
Most religions spread virally, which means the marketers are the customers, which is usually a testament to the product/service being one that customers value. I say this as an atheist who's not a fan of religion, but people clearly get a lot out of it, or at least believe they do.
Probably neither. People like to belong to a group where they feel they "belong" and that in itself is sufficient explanation for the spread of religions IMO.
Propagation of societal values and/or fear of hell and/or fear of death assuaged by the assurance of an afterlife and/or being able to rationalize away the vagaries of nature as the will of god(s) are just optimizations after the core system was already invented.
There is a place for religion. Something that pushes you to be better than you are. Along with the happiness and fulfillment that comes from that effort. Selflessness, love, compassion, truth.
Plenty of bad religions telling you that you are perfect the way that you are. Just give me money, fame, or influence and I will flatter you and pump your ego.
Another form of this is flattery in exchange for hating something. Many doomsday cults fit this category. All your life problems are because of 'insert target X'. But I, I have the answers you need.
Religion is more attuned with purpose, where your heart is, than the belief in God. Though the two are often paired.
There are plenty of things that deliver the above without the dogmatic slaughter of hundreds of millions of humans throughout history and at this very moment.
There's also plenty of religious people who have never murdered anyone in their lives, and there have been plenty of dogmatic massacres for reasons entirely unrelated to religion. The two issues seem to be quite uncorrelated tbh.
Religion requires belief without evidence. (Or flimsy evidence like ancient testimony.) It's uniquely positioned as a tool to manipulate people to do things they wouldn't otherwise do.
Windows (especially v3.1, Windows 95 and Windows XP) was leaps and bounds better than its contemporaries when it came to normal desktop use. You can have the most technologically advanced OS in the world but if it is too difficult to use for 99% of potential users then it it not a good product. Microsoft was one of the first few companies to really get this right.
Yeah, perhaps I should have said MSDOS. But even still, I think perhaps your rose-colored hindsight is probably miscoloring your memory. The initial releases of Windows was a nightmare, with Bill's mom consoling him after a particularly disasterous demo, and if it wasn't on the back of the brilliant--or lucky--marketing maneuverings that cemented MSDOS as the preeminent PC OS at the time, I firmly believe that Windows would not have become the preeminent desktop OS powerhouse that it is today.
In fact, I think that behind the scenes of the ominous MS investment in Apple (with the whole big-brotheresque Bill Gates appearance) there was an explicit--business, not technical--agreement between Gates and Jobs that Apple would not venture out of their own hardware, specifically to allow Windows to continue its PC dominance.
Meh. Was early Windows (and/or MSDOS) perfect? Obviously not. Was it better than its competitors? Yes. Absolutely. Compared to what we have today they were all shit tbh and MSDOS was better than most.
Don't get me wrong, the marketing game of early MS was absolutely phenomenal. I just want to say that they succeeded to the degree they did because BOTH marketing AND the tech were good.
The fundamental core engineering -- the motors, the inverters, the control systems, battery management in their cars are pretty damn fantastic and they were consistently ahead of most others. And the Model S, while a dubious luxury car in terms of fit and finish, was a piece of amazing engineering when it came out.
The Model 3 and its variants I think are meh from a UX POV (stupid centre iPad distracto-slab etc) and I won't pay for them because of who is behind them... and the lies about full self driving, and the crap support etc... suck.... but I think it's disingenuous to call Tesla product crap.
This doesn't track for me. I saw a Tesla dealership and supercharging station in my city before ever seeing an advert for Tesla. That's why Tesla was successful where others weren't.
>> History has shown them to be right.
>> There are many terrible products in this world that were successful only because of good sales and marketing. And vice versa.
Just because technologists have been marginalized, abused, and extracted from successfully thru history -- does not mean it should be accepted and it does not mean I want that for myself or my technical friends.
In am not in Sales but I imagine good at Sales overlaps alot with good at product design/ownership. They are talking to the customer alot. Both the ones who
buy a competing product and also buy the one being sold. They probably have done
some account management so they know the concerns with onboarding and getting value from the product.
The original title on this (which was there when I started this post) was infuriating - but it is still bad.
Is it speaking to the 'true' co-founder who is above the technical one? Maybe the other co-founder who is an 'idea innovator' could up-skill a little and stop pretending that you can build a business by putting on a power suit and making presentations with upturned hands and studied pauses?
I like Michael's take that the real value in a founder is their ability to recruit the right team. What I don't think was said explicitly here is that typically technical people are progressively marginalized as the business grows. We get some harrowing stories where that doesn't happen, but I don't think that's the standard story. Like they allude to, it's a story of what the people who handle the money and investments value.
Context: Michael is a non-technical founder from Justin.tv and Twitch.
Typically stories I hear where technical people maintained equity it was through a lot of maneuvering. It wasn't given to them by the merits of their accomplishments.
> typically technical people are progressively marginalized as the business grows
I know three YC technical co-founders who were ousted by their CEOs, and a justintv alumn who got nothing from the follow-on exits. When YC says “you need a technical co-founder” they mean it like you need a disposable lawyer. The essay here is about targeting growth and flipping, not high-performance teamwork.
This does seem to be the pattern. I was a technical cofounder in one startup (not YC), even though I do have the chops and experience as a startup CEO. You have to focus so much on the tech and tech hiring early on that you are left out of a lot of the deal making and fund raising. It seems to slide you over into the same bucket as early employees pretty quickly.
Hmmm, an extremely interesting thought! Basically, agentifying might be the next programming.
Do you have a guess how that would play out or how likely that might be? It seems like the main blocker here would be if the agents remain relatively weak in pure reasoning.
I have no clue how it will play out, but Autogen looks like it's going down the right path + has MS behind it.
I am able to get some pretty nice ideas out of LLMs by gaslighting them into larping as tenured professors at <insert good university for subject here>.
I haven't really tested yet if using actual people's names helps or hurts.
That's explainable, Dunning-Kruger effect. Whole custom development industry is based on it. Otherwise it will never exist as there are whole agencies with 20-30 year history that never seen a tiny bit of what they produced working in production: everything is a throwaway paid for by these would-be founders.
It's like clouds: AWS exists because enough stupid people don't understand available hosting options and can't make simple cost calculations.
This will never change simply because no one makes money if it does. If those people started looking for a tech-cofounder, then two options:
- they never find one, thus give up on the idea, the money they spend/waste on it will never be spent, thus GDP from this final consumption (which nearly all of custom development is: final consumption, a hobby), will not be created.
- they find someone who will pretend or will falsely believe to be technical. essentially same guy as the original one. and he will waste some time and money with freelancers, become convinced they are all fraud (because this is what happens when you ask for idiotic stuff to be built on impossible budgets - everyone except scammers, decline), then hire some agencies, and waste some money on them, aaaaand it's gone!
How do you explain to people who are not capable of starting a business, that they shouldn't start one?
Bigger question: WHY would you do it? Why not just benefit from them?
This is generally true. I had a technical cofounder for the first 4 years or so, but once our tools were built it was less clear what his ongoing role would be.
This is because at that point, our focus turned to licensing our (patented) technology to businesses. We still have B2C customers who use the tools that he originally built (and which have been updated by contractors after he left), but now the vast majority of our revenue comes from our B2B licensing.
We are pretty unique in this regard, since most startups aren't able to generate much revenue from licensing in this way. Specifically, when we work with our licensees, we provide a JS library that they plug into their own platform. We don't need engineers to do integration work, or provide support.
My technical cofounder provided a lot of value in getting us to where we are, for sure. But needing a technical cofounder to launch doesn't necessarily mean you need one all the way along.
The clients don't want us mucking around in their code, which is why they have their devs do the work. There are some cases where having a dev on our end could help unblock their devs, but these are pretty rare cases. In general, it's very easy for folks to use our tech, and I'm able (thanks to a couple years of CS back in the day) to help out with the vast majority of questions that come up.
In terms of changes, there aren't any material changes. We've had licensees up and running for 7 years without changing any code.
What so the person who "provided a lot of value in getting us to where we are" got ditched in the end? Is that your story? Use people and then chuck them to the curb once everything u need has been extracted?
Absolutely not — he vested founder's shares just like me. And then I continued to work with no salary and no additional vesting for years after that. Also, I was working full-time while he was working nights/weekends.
I assumed he got some $$$ - but did he want to be removed or did you tell him he was no longer needed? Was he just as sure that he was no longer needed as u were?
>> What so the person who "provided a lot of value in getting us to where we are" got ditched in the end? Is that your story? Use people and then chuck them to the curb once everything u need has been extracted?
Technologists beware -- some business co-founders will treat you honestly and you'll be paid fairly. And some will not. You need to read this comment and realize that both outcomes are possibles, especially once lawyers, VCs, and other business people get into the mix.
> especially once lawyers, VCs, and other business people get into the mix.
This is unfortunately true, since the VCs are only interested in the forward-looking value of the enterprise. They would prefer to dilute other shareholders (including founders — and especially former founders) to maximize future fundraising. And lawyers, of course, are happy to tell the VCs how to do this, regardless of what protections were put in place initially.
Usually a company with software need to develop new features, reengineering to reduce infrastructure costs and improving performance bottlenecks, maintenance, etc. Do not you have that in your company? And if you do, who is leading those initiatives?
We are not innovating on the core product, which has remained static for many years. Instead, we are pushing adoption through our licensing partnerships. We now have over 250k students using our reading tech through education platforms that we work with. Building more of these partnerships, based on the data we have gathered from our existing partners, is the focus.
If we were riding on momentum I would expect our revenue to be stable/shrinking, not growing (as it is). I agree that in the long term this is true, but when you start as a tiny speck, you can grow for a long time as awareness spreads. For example, we started our in education and are now getting interest from news/media organizations. This is without changing the core functionality at all.
I mean not all businesses need to thrive. If the thing generates significant profits for a while then the founder can retire and either sell it or just let it die. If it's not a publicly-traded company there's no fiduciary duty to do anything more than that.
Sounds like at that point you're not really a tech company. Your tech might as well be some off-the-shelf stuff as far as you're concerned, if you're not actually working on it any more.
Interesting perspective! So if Dolby had stopped making new versions of its technology and just licensed what it had until people stopped buying it, then it wouldn't have been a tech company? What kind of company would it have been?
A sound company, or whatever the technology in question does? If you're in a position where it's viable to not be making new versions of your tech then presumably that means you're in a field that's at least somewhat mature as its own thing. I think there's a temptation to equate "on computers" with "tech" whereas for a lot of fields doing it on computers is pretty much commodified now.
In our case, we're growing via adoption of our first generation core product. I could definitely make a second version, but it wouldn't help overcome the primary challenge we face with adoption, which is that the technology looks unconventional, and isn't well-enough known yet. Making a more complicated version wouldn't help with this, and might not even improve the efficacy. It would also require internationalization, whereas our current version is language agnostic.
So it's not that we won't ever create a newer version, just that it's not the primary focus.
>> My technical cofounder provided a lot of value in getting us to where we are, for sure. But needing a technical cofounder to launch doesn't necessarily mean you need one all the way along.
This is a good point, but it should be clear that you would not have gotten to this point w/o the technical co-founder.
The problem is that once you get to this point, less than honest non-technical people seek to marginalize and eventually consume the equity/payout of the technical co-founder that often took the original risk.
It is critical that technical co-founders maintain equity and FIGHT hard for what they have earned and enabled, do a fair extent of the value they added.
Corollary: you do not need a non-technical co-founder.
My advice to engineers is that it's nearly always easier to learn business/sales than to learn to like a co-founder, especially the type generally drawn to being a "business" founder.
It is good to have a co-founder in general though, get one of those if you can. Just don't worry about finding complementary skills, bias entirely towards someone you can work with.
I generally agree but if you're developing a product for a niche industry and that non-technical co-founder has a shit ton of insight and connections, it will 1000% open doors. Then again, perhaps you can partner with those folks in other ways vs giving away 50% equity.
By that logic the person with that domain knowledge can partner with technical folks for less than 50% equity. Which is what normally happens in my experience
This is more likely to be true where you are selling to other technical people. But it becomes much less likely to be true when you are selling B2C, or to non-technical businesspeople. And of course, the ability of a technical person to learn sales varies quite a bit. Some technical folks pick it up easily, but others do not (or find important non-technical bits like fundraising and sales to be very distasteful/annoying).
And of course the reverse is true. Some "business people" can pick up a huge amount about UX, client priorities, process automation and what is and isn't technically possible and make useful product management contributions even if they never touch the codebase, and some simply aren't interested in that level of implementation detail even if they're really good at selling the big picture and someone really needs to get a handle on that side of the business.
I'm currently the technical guy and would love to learn how to also be the business guy - what do I need to do to develop those skills?
Getting your hands dirty is the best way to learn anyhting, so with technical topics, especially programming, I would just dive into projects and start coding, building things, and that's how I learned. In terms of business skills, what projects can I realistically undertake on my own that would help me develop those skills? Should I start a low-stakes business selling soap on Etsy or something? Is that adequate? Completely different ballgame from the corporate startup world - but would any of the skills from such a humble venture transfer to the larger stakes ones?
How might a technical guy become the business guy?
You become a business guy the same way you became a technical guy!
Don't waste time selling soap though (unless you really love soap) - my best advice is to try to sell something you've made. It could be your time (as a consultant), or it could be a product.
I would suggest waiting to develop these skills until you know what product you want to bring to market as an entrepreneur. No sense in learning B2C growth hacking when you end up in enterprise sales (or vice-versa).
This sounds like a typical engineer's summary. It is a dismissal - just like the video talks about tech being dismissed.
Recruiting a co-founder is not "just sales". The video is taking about an archetypical salesperson who still can't buy a tech guy (maybe their sales skills are not so good).
Absolutely true. Of course, a non-technical cofounder probably knows more than just marketing. He may add a lot of value in terms of fundraising, product management, and other areas. Teaching all of these things to an engineer wouldn't be trivial.
Nonetheless, I think most business functions are more societally established, and for that reason they can be more easily outsourced.
You can find a "pre-packaged" MBA, attorney, etc. because society is very good at churning out those roles. Just go the most recently graduated Wharton batch and hire the top grad for $300k, and you have someone who can do your legal, fundraising, operations, etc.
It's much harder to find someone with unique technical insight and the ability to deliver, which is the true value of a good "engineer".
This is like saying you can go hire the top graduate of your local bootcamp and they can be a decent tech lead. Experience matters for legal and business roles just as much for engineering, much as we devs like to pretend otherwise.
Sounds like a chicken-and-egg problem: how do you get the $300k to pay this Wharton grad? (And BTW, trusting a Wharton grad with legal work is a very bad idea — bschool teaches networking, not legal skills. Even a law school graduate would not be prepared to be the lawyer at a startup — 2+ years of relevant legal experience would be required.)
Engineers do very well in Leadership/Management/Marketing/Sales/etc. which i consider ancillary domains in the Tech. Industry.
The reason is that Engineering is primarily quantitative and hence Engineers are taught to breakdown their Problems into smaller pieces and solve them one-by-one by using constraining/limiting abstractions so that each piece can be solved and then integrated into a whole.
In Non-Engineering fields this problem-solving approach is never taught and enforced. Most parameters are nebulous/qualitative/interlinked and more heuristics/opinion based with the result that they never learn to break a problem into manageable pieces and solve them one by one.
I would say the reason is actually that teaching engineering requires first teaching a good deal of math and software development, which most marketers don't have (though well-educated ones may have some). Teaching marketing doesn't have as many dependencies that are rare in the general population.
Second this. I worked in Sales Engineering for 5 years, ended that career selling a $25MM solution to the CEO of a fortune 100. There is no secret sauce, and it is all learnable. The key skills are interpersonal. I know its hard to do as an engineer, but most of (enterprise) sales is shutting the F up, listening, carefully listening, earning trust, and learning to navigate stakeholders and what their potential incentives are to help you.
I think sometimes the salary market would disagree with that.
At many companies a sales engineer can make more money than a developer.
Personally I think it’s too nuanced a question to answer generally. Depending on who it is and the context “the right” person in either role can make all the difference.
To put some context here, SEs often make so much because of commissions, not due to some crazy salary.
Commission based sales seem like a good thing -- it is pay to perform. "Business co-founders" are not the same thing as SEs, because "Business co-founders" are often paid upfront (via equity) for the future promise of performing. That is not a setup with good alignment of interests.
Let's just say - there are some critical things you have to be good enough at and those correlate with commonly observed corporate structures. Some degree of Sales, Marketing, Legal, Security, R & D, and Finance competencies need to exist across the founders. Sometimes one person can do it, but they also need to know how and when to bring in experts if they are lucky enough to need to scale up.
On a very basic level, not having a cofounder in any capacity can create a structural bottleneck when two important things have to happen at the same time. A trusted second party provides resiliency.
> My advice to engineers is that it's nearly always easier to learn business/sales
Technical people mispredict the value of a business co-founder in a similar way to how this video talks about tech co-founders being misvalued. Cue jokes about sales-droids. But there is a mirror between businessy people undervaluing tech and tech undervaluing business.
A key point of the video is recruiting (albeit a form of sales): it is hard to sell "adventure" and belief.
We see this every time an engineer tries to shift to a managerial rôle and fails. In theory business skills can be learnt, in practice it is hard and perhaps easier to co-found with someone with the skills already. There are risks, but if you can't judge ability and integrity then you're already hosed.
The best example I can think of who cogently explains how they learnt is Jim Keller - talking about how he changed AMD.
Fair point. The risks are huge. Makes sense if you've got 30% of the cap table. The risk is worth it. Esp if you are founder and on the board directing the company and fending off risks.
Not sure it makes sense if you've got 0.5% equity.
Definitely does not make sense if you are being given X,000 shares and have no access to the cap table.
Any engineer who thinks they can value a fraction with a numerator and no denominator is fooling themselves.
Startup employees -- if you were given 50,000 shares but told you arent allowed to see the cap table, please UPVOTE/DOWNVOTE accordingly if you think the pay-cut to market was worth the money you got at the IPO.
I have made this mistake exactly twice in my career and the simplest advice I have... I won't categorically say that you should never accept "a lower salary right now but when we bring in investment/sales we'll bump it" because, well, sometimes there are companies/projects/founders that you meet and truly believe in and want to be a part of their team. But... the absolutely critical piece of it is to get in writing:
- what the triggering events are (investment, revenue thresholds, etc), and make sure to include "hiring other team members for similar roles at higher salaries" as one of the triggers
- what the salary bump will be
- whether or not there will be retroactive compensation included
The first time around I ended up leaving the role before any of the usual triggers would have been activated. Management was toxic, salaries sucked, morale was in the shitter anyway. The second time around I discovered after tendering my resignation that someone who reported to me was making $40k/yr more than I was. It would have been an amicable parting (I was moving on to something that was much better aligned with my interests) but it got pretty sour when I found that out. I got asked a couple times to come back to consult on a few projects and the rate I quoted them (and they begrudgingly accepted) was steep.
those companies will happily outsource the development of their core competitive advantages to another company who does appreciate its value; they will then sell it to their competitors
This is dated. There's no rules to founding your own company.
As a non-technical founder I can
A) Get a technical cofounder which takes me weeks to find, dilutes my ownership, and with whom I have no recourse if their work is sub-par (or we end up just not liking/trusting/vibing with each other)
or
B) Build an MVP with any number of offshoring partners in a matter of weeks and for far cheaper (money, time, opportunity cost). If I don't like the work, we can modify the contract, or I can quickly pivot to another team.
This is also true for technical founders as well, to be clear. You can probably do a lot of the business stuff by outsourcing. You can worry about gelling a team once you've got to 1.
Heh, good luck. As a tech cofounder, I attempted to do just this and I have extensive development and management experience. It was a nightmare, EVERY SINGLE offshoring company tried to play us as a group that didn't know their stuff, and when put to the iron they couldn't produce anything that would stand up--technically--against a mild sneeze.
If I hadn't been there, my other founders would have gotten up to their eyeballs in offshore dev debt and would have a giant hairball that even the most experienced tech people would be unable or unwilling to make additional progress against once the offshore team stops delivering.
So, good luck trying to lead an offshore team that's only interested in absorbing as much money from you as possible before moving onto the next sucker. If you don't think a tech cofounder is worth their ask, then you deserve to get exactly what you pay for.
I'm not the GP, but I know many of the tricks to watch out for:
- Offshore partner delivers software, but you dont have any code. Successive rounds of updates become more expensive. You cant walk away because you have none of the code. (Business co-founder has no idea and goes to new partner with binaries expecting updates to be delivered, then gets told they need to start from scratch)
- Offshore partner delivers software and code, but not the code corresponding to the software. You try to switch partners, but realize you start from zero, because you dont have the code
- Offshore partner delivers software and correct code, but only for the app/UI. Only they retain code for the backend.
- Offshre partner delivers code for UI and backend, but not the right code, UI is secretly pointing to a different backend with different code
- Offshore partner delivers correct code all around, but only they have the build scripts, dependencies, and cloud images required to run it.
- Offshore partner delivers everything, but only they have the data required to start up the system. New partner spends as much time figuring things out and eventually wants to re-code the whole system.
For each of the above, business co-founder goes thru the rounds two or three times. Each time, they spend 20 or 30k and each time they walk away with binaries they cant do much with. Eventually they give up, or find a technical co-founder.
whoa. these are obvious in retrospect (they're the same ftbfs and saas tricks debian spends most of its time fighting) but i wouldn't have thought to expect them in this context. thank you
Sorry you've had those experiences, but mine have been consistently profitable and pleasant. I think a big part of that was that I asked around before I selected an offshore partner, instead of just choosing the cheapest or the first.
to get from zero to one, which i think is what you're referring to with your 'once you've got to 1' line at the end, you need to first find a market that's at zero; a product/service that doesn't exist. but that isn't enough; then you have to take it to one, a product that does exist. there are three piles here:
1. product categories that are technically feasible and profitable and where products already exist;
2. product categories that are technically feasible and profitable and where no products already exist;
3. product categories that are not technically feasible, so no products already exist.
anyone can tell the difference between pile 1 and piles 2 and 3. but you need a technical cofounder to be able to distinguish between pile 2, which is very small, and pile 3, which is enormous. and that's not something you do once; it's an ongoing process that happens at many levels of detail in your product, and even at the largest scale it's a gradual process of reduction of uncertainty, because you don't really know that something is technically possible until it's been done
then, you need to actually build the first product in that category, which involves identifying, prioritizing, and mitigating the risks that could destroy it. probably in banking a lot of this is things like regulators, market moves, and bank runs, but in companies built on software, a lot of those risks are software risks, and you need technical acumen to do this
as a nontechnical cofounder, what value are you bringing to the table? your family's money? invest in a vc fund, or start one, though without technical cofounders you'll waste all your money on companies in pile 3. your business knowledge? that's worthwhile in some cases. your leadership and management skills? likewise. but you're going to have to offer convincing evidence of something like this to be a good option for anyone to invest their money in
> you need a technical cofounder to be able to distinguish between pile 2, which is very small, and pile 3, which is enormous
Huh? A technical cofounder doesn't have any sort of monopoly on feasibility, and there's dozens of ways to understand opportunity space, PMF, and all the many other key considerations early-on.
As a nontechnical cofounder, what I bring to the table is enough wisdom and experience to get to a stage where I do need a CTO and technical team.
> technical cofounder doesn't have any sort of monopoly on feasibility,
it's hard to tell what you're trying to say here, but people with the technical understanding of a field do in fact have a 'monopoly' on understanding what is and isn't technically feasible in that field, to the extent that anyone understands it at all
for some products they also have a 'monopoly' on understanding what products there's a market for in the field. if you're developing a new kind of swiss lathe, your customers are going to buy it, or not, in large part based on technical features like mrr, repeatability, and cycle time. if you don't understand the technical field, not only won't you understand what is technically feasible, you won't understand your product's value proposition. this obviously doesn't apply to mass-market products
in a gold rush, though, selling shovels to gold miners is more reliably profitable than mining gold
Nothing you just described requires an entanglement with full-time technical cofounder. I could get a ROM estimate on, say, your lathe from a product design/engineering firm for a few thousand bucks, use that as PRD + go/no-go, then take it to prototype/evt/dvt/pvt with any number of experienced partners on contract.
Don't know why we're having this argument. Outsourcing is a very common thing.
Honestly as a technical guy: You come off as greedy.
As a technical founder, I face the EXACT same risks. What if the business guy can't drum up money? What if he can't sell the damn pen.
Most companies fail, the strongest firms will have strong business and technical people.
If you want to stand on one leg. Go for it. You'll piss your money away overseas. When you need someone to help you get across that line... there is nobody at your side.
Founding a successful company is hard. You will face days where you don't have the answer. Things will happen that are outside your experience... and yes, you can buy, buy, buy your way there... but remember, you are buying mercs. I've been a merc. Win or lose... I get paid, so, yes sir. How high sir?
Rework is just more money.
... You sure you want to be on the other side of the table from someone like me, without someone like me at your side?
Because all those off-shore firms... are more merc than I am.
I just mitigate as much risk as I can, as early as I can, and it's worked so far. Tech is littered with hundreds of companies that died because of personality conflicts - which can be readily mitigated with an MSA and SOW.
As I note in my original comment, my approach can absolutely be utilized by technical founders.
No contract can save you from what you don't know, and don't understand.
Different points of view, if they can stay respectful. Can be a great strength.
I see the world in terms of risk. If X will help me derisk something. Even if it isn't totally EV+ it can be a good play, because risk of ruin is real. Especially with large amounts of money, and small numbers of trials.
25% less to have a 10% better chance at making 75m vs 100m? Probably worth it a that level. Because 75m or 100m is life changing money for 99.99% of people at least. The amount won't matter as much as your chance of getting to it.
Disagree, and I say this as a technical founder with no cofounder. Once things start to take off, a majority of the things you deal with are non-technical. There’s so much that goes into building a company, and you really need someone who understands how businesses work and can run G2M.
Sure, you can hire for it… but you’ll almost never find someone as invested in it as the founder, and it’s just as important as the product.
I'm the technical co-founder and my co-founder non-technical; he's brought in so many soft skills around process, finance, sales, recruiting, etc.. that I would have (and would still) struggle at to replace.
He's also a domain expert in our field so for me it was definitely the right choice to make.
he doesn't sound nontechnical if he's a domain expert in your field, but presumably he would be even better if he also had whatever technical skills you're saying he lacks, not worse
what i was saying wasn't either of those, but it's closer to the former: some technical people have a proper superset of the skills of some nontechnical people, because that's kind of the definition of “technical people”
while it is true that nobody is both as good at soccer as lionel messi and as good at programming as jeff dean, you can definitely be good enough at everything to start a company. and lots of people are bad at everything. everyone starts out bad at everything
being bad at programming or biology or whatever the relevant technical field is doesn't make someone good at management or bizdev
so don't look for nontechnical cofounders
just look for cofounders who don't have to be technical
Agreed, I think it depends on the technical complexity of the product & model.
Declaring it an absolute requirement feels a bit like an exclusive club without real merit or consideration. I say this as a former exec at a YC company founded by a pair of eng degrees that couldn't build a thing (not even a prototype).
380 comments
[ 4.5 ms ] story [ 286 ms ] threadIf you can’t find one technically minded person who believes enough in your vision to drop everything and help you make it, that is not a good sign for your vision.
If you can't find a single software developer who believes in your plan for better APIs or project management tools or consumer internet apps, it's a pretty good heuristic that your vision or ability to sell it sucks, or that you add less value than the dozen other people that talked to them about chatbots for X this week. Any prospective technical co-founder has a huge amount of insight into those markets. On the other hand, unwillingness of software developers to believe that the dullest sounding CRUD app going will be very exciting to grey suited men controlling a little known niche (probably precisely because hardly anyone's writing software for it) doesn't actually mean there isn't a market there.
The scenario in tech is more often comparable to some dude saying "I want to make a business selling the greatest hot sauce ever" and then having to go looking for someone who actually knows anything about hot sauce.
It can still be the case that one person has an awesome idea that everybody else in the company signs off on. But chances are, everybody on the team is going to have to make some room for other people's ideas and takes on things.
Many non-tech people e.g. look at programmers and think the hard part is knowing what this garble of weird text means. But this is the easy part. And if you are a person who would think it is hard, you probably don't know about all the demons out there that will come to haunt you if you don't build a foundation that helps you actively keeping them away.
I teach the same thing, seemingly every day to my teams. It doesn't work, until it works reliably, within reason.
High-5 from the doers to the teachers! (Both are needed)
For the record, my partner teaches at a major university, just not tech. ;)
E.g. If you’re surrounded by yes men who will code whatever without question, product people greatly prefer that, and you end up sidelined.
There’s also plenty of companies who don’t want engineers getting involved with decisions, and product and UX people work upfront and in isolation until you’re handed tiny Jira tickets with Figma mockups attached. Discussion at that point is considered “disruptive“.
It honestly seems like this has gotten worse in the past 5 to 10 years.
> sad but true: learn "yes" then learn blame other grugs when fail, ideal career advice
> but grug must to grug be true, and "no" is magic grug word. Hard say at first, especially if you nice grug and don't like disappoint people (many such grugs!) but easier over time even though shiney rock pile not as high as might otherwise be
> is ok: how many shiney rock grug really need anyway?
I'm amazed at how non-obvious this seems to most engineers and how often this angst gets repeated in online tech communities. I mean, when I was in academia there was a tension between publishing impactful results or cozying up with the right professors into the right conferences vs outputting meaningful work (pressures into p-hacking or having big names author suspicious results is par for the course.) In industry it's the tension between product folks and engineers. Have you ever talked to high-level finance folks who deal with the tension of product folks just wanting to do things and finance folks who remind them how money works?
It turns out that the hardest thing about getting things done with people is... dealing with people. I wish there was a way to remove this weird somewhat-ascetic blockage found in tech communities about this. Many of the more physical engineering occupations have to deal with this in the form of contractors and supervisors. Wait until you have to work on a government contract lol.
When I mentor junior engineers with these feelings, I like to use an adage: "Where there are people there are politics." Look at pretty much any prominent FOSS project and you'll see tons of it (by dint of transparency) and those folks generally focus on the project and not a product!
Finance however, not once[0] have I either observed nor heard of someone working in finance being overruled by a product person. If finance says no go its no go, simple as that. People tend to listen to the money folks, even at a high-level.
[0]: I work both in fintech and have lots of professional colleagues that work at other financial firms from big banks to all manner of investment firms and much in-between, as well as several generations of family who have all worked in finance on various levels. Honestly, its high level finance people trying to pressure others into getting things done faster when they want something done, not the other way around.
Totally, but finance people want to see the company succeed too, and even if finance says it's a no-go, product people will still keep trying to push around them. I just mean that this tension exists between different stakeholders in every organization. If we knew ways out of this, we'd revolutionize government bureaucracies, vastly increase firm efficiencies, sort out FOSS issues, the world would be our oyster! But human coordination problems are really hard. The hardest problems out there really. That's my general point. Too much airtime is given to tech people who seem to not understand this. It's a bit like complaining that when I jump I fall down. I also can't imagine spending 20 years bemoaning this aspect of human nature.
I think this is where the tension comes from in the lasting, I'm still complaining about 20 years later sorta thing. Once you realize the value you are delivering to the company, naturally, you start to want to have some more say over the value chain, I think this is innante to human behavior, but there is alot of gates between ENG and the rest of the org, most of the time, from what I've observed.
Look at, for example, how "Agile" is implemented at a company. It focuses on ENG having to address stakeholders, without really saying that ENG should be its own stakeholder too. With SCRUM and other systems, the emphasis tends to be on outside stakeholders and what they want, rather than bringing ENG to parity with other stakeholders so everyone has more equal input on the work streams - which ultimately, when this is actually done, prevents more problems than it creates, nearly every time - yet you can feel the resistance in most orgs to giving ENG a full table stake
If you look at how "Agile" is implemented in most organizations - even in technology companies! - there's alot of barrier process put up to sideline / minimize engineering input by focusing on stakeholders where stakeholder is defined by everyone telling engineering what to do as opposed to engineering being seen as a valid and reasonable stakeholder too.
I think its because in part there is a linear pipeline that the non technical business side sees as how things go: you plan X, it gets designed by Y, and then "manufactured" by engineers, if you will.
Engineers - good ones, in my estimation - want more stake in each step, both in planning and design, because often its engineers that work on the system the closest (you'd be shocked how many designers don't use their own products on a daily basis, same goes for alot of business oriented folks) and this is not "the way the world works".
Thats my thesis anyway
*sometimes probably best just not tell project manager and do it 80/20 way.*
Does 80/20 in this context mean that we'll implement 80% of what is asked for an leave out the remaining complex parts?
What you don't want is for the last 20% to occupy 80% of the time.
But with some luck your project managers' butterfly mind will have flitted on to greener pastures and everybody is happy. No need for Grug to reach for his club (while remaining calm).
> best weapon against complexity spirit demon is magic word: "no"
> "no, grug not build that feature"
> "no, grug not build that abstraction"
> "no, grug not put water on body every day or drink less black think juice you stop repeat ask now"
> note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer
Perfection
complexity very, very bad!
This site has more knowledge condensed in one page than a stack of randomly assorted books on software development do.
The hard part is building things sustainably at scale (people wise or performance wise). That's when a combination of knowing how to manage systemic complexity and knowing how to communicate very well (soft skills) really come into play.
But in general, reaching profitability (which is the real hard part) will require making scaling efficient and operations smooth.
I've been thinking about scaling a bit because I've been digging into a large SaaS product for a client and find I am able to replicate their locally relevant output at a fraction of the cost. Scaling up has allowed this SaaS to serve an entire country but a majority of their user base think in terms of one or two local counties. Consuming their output means subsidizing work they do that's irrelevant to (or might actually compete with) your own interests.
suppose you need to either be in the top percentile of handsome and the top percentile of emotionally aware to get a job as a hollywood actor, but these attributes are uncorrelated in the general population, so 99% of top-percentile-of-handsome people will be top-percentile-of-sensitive and vice versa
then the pool of hollywood actors you observe will contain, out of every 199 people, 99 who are top-percentile-of-handsome but not of sensitivity, 99 who are top-percentile-of-sensitive but not of handsomeness, and 1 who is both
someone observing this result but not understanding the process that led up to it might think that emotional sensitivity makes you ugly or that being handsome makes you emotionally oblivious, even though (by hypothesis) the traits are uncorrelated. in fact, this negative correlation in the selected group can survive even a fair bit of positive correlation between the traits in the general population
similarly, it's easier to get a programming job if you have a history of delivering successful products, or if you have a lot of line-by-line coding acumen
https://en.m.wikipedia.org/wiki/Berkson%27s_paradox#:~:text=....
Having an idea is like having a thought.
A startup needs product and distribution. If a tech cofounder builds what’s asked of him and the sales cofounder can’t sell, should the ownership revert to the tech cofounder?
2) a strong history of understanding the limits of functional automation (why are there still project managers? Asana exists!)
3) an understanding that progress will slow in this space considerably once we have made the big wins and the hype cycle dies down. (see also; every tech hype cycle)
Yes, it's certainly possible for content to be curated and models to become biased in other ways but...
> the hard part is wrangling systemic complexity in a good, sustainable and reliable way
in an early startup, this thinking is one of the most common ways to failure. people optimise their technology for its scalability, reliability, and "cleanliness", when none of that matters yet. all that matters is finding product market fit
If your product is successful enough that systemic complexity is your chief problem, congratulations, you've made it further than most startups - which die from lack of demand, lack of paying customers, and lack of users giving feedback.
I thought this headline meant a technical founder needs a technical co-founder even.
In a startup it's extremely important for founders to wear many hats and share many burdens.
If you're the person that just goes off into a cave and emerges with beautiful code 6 weeks later and then expects everything to be great - you're wrong. There's a massive amount of foundational work to do to support a startup that technical people don't even think about.
Starting a company is not easy. If you stand around and only do tech, then you're not a founder, you are an employee. If you have to ask "what needs to be done next?" you are not a founder, you are an employee.
If you call someone your manager, then you are an employee.
If you're a cofounder you do not have a manager...
Starting a company requires a diverse set of skills, almost none of which are technical. A technical person can excel at those tasks, but they have to have the desire to figure out what needs to be done before asking what needs to be done.
you might genuinely need some nontechnical people in your startup, but if you have some money you can always pay people to come be part of a focus group or user test when that's necessary
> but if you have some money
lol . Just… lol.
it seems to me that, given a nontechnical person who's good at one or more of those roles, they'd obviously be even better at it if they also understood the technology. ignorance and incompetence are weaknesses, not strengths
as for having some money, the context of this discussion is startups with angel or vc funding, which is plenty for focus groups and some user tests
I’ve worked with a grand total of one PM who was from a technical background. He was actually a great engineer but he was absolutely the exception to the rule.
Sure, if you can flesh your team out with entirely technical people filling those roles, great for you, but that’s like asking why you wouldn’t only hire 10x engineers. Well of course if you could find and hire only 10x engineers you would, but it doesn’t work like that. Especially considering those are all industry positions that are typically taken by people who never went into technical roles.
i feel that my first comment in this thread already explained this with perfect clarity and you've just been trolling
Ironic given that you are commenting on a vid where tech is undervalued; plus your comments are getting flagged for your communication skills.
I suggest you learn not to make the same mistake as those plonker non-tech guys.
my single comment at https://news.ycombinator.com/item?id=38479157 got flagged, i think, for being extremely rude, not for failing to communicate
you are the third person here to incorrectly attribute to me an undervaluing of non-tech skills, but that's on you three, not me; you're just pattern-matching what i said to some kind of stereotype and guessing what kinds of opinions i might hold on questions i haven't talked about. it's as if i had advocated abortion rights and you attacked me for advocating gun control
but i'm not in favor of gun control, and i value non-tech skills very highly. you guessed wrong, and you should be ashamed of yourself for falling into fox-news-style stereotype-based reasoning instead of thinking about what i actually said
the particular communication skill i need in this case is the skill to avoid communicating with people who will ignore what i actually said and substitute something they would prefer to argue with
Condescending and rude. I made no error.
> abortion rights > gun control
Wow - that's an irrelevant tangent. HN guidelines are to avoid flamebait and politics.
> why would you want a nontechnical cofounder to do the pm/marketing/bizdev side of things?
This is what my comment relates to. It seems to me that you are dismissing the potential value of a non-tech co-founder. A co-founder is not telling the dev what to do. Partners whos skills complement each other. I helped co-found a successful business with 4 founders: 1 sales, 1 BA, and 2 dev - although we were all tech types with far wider skills than the stereotypes of the labels I used suggest.
To be clear: some people don't need a non-tech co-founder, but I have seen devs try to start businesses where I felt the devs would have done better partnering up with non-dev co-founders. Also if one can't sell a business to a high-value co-founder, then my guess is one likely lacks the skills to be successful.
> case is the skill to avoid communicating with people who will ignore what i actually said and substitute something they would prefer to argue with
I am replying because I felt you ignored what I said, and you substituted something you preferred to argue with.
I'm not trying to change your mind - I'm just trying to explain how your comments come across to me - it is about me not you. I'm not trolling to make you angry - HN is not for that and why waste your time or mine. All good.
and somehow you think i'm the condescending and rude one?
my initial comment didn't even say how highly i value technical skills; it only said that the sign of the value i assign to technical skills is positive rather than negative—in the context of looking for a cofounder (as opposed to certain other contexts, such as finding user testing subjects, where the sign might be negative)
i explained that, by answering my comment in the way you did, you are engaging in the same kind of flamebait and politics that kills rational discussion around topics like abortion rights and gun control. (please stop doing that and respond to what i actually wrote.)
in response, you're implicitly claiming that i'm the one who's bringing in the flamebait and politics?
i don't know what you expect to achieve with this kind of darvo bullshit
no reasonable person could claim that when i say 'nontechnical skills like marketing, grit, forgiveness, and negotiation are far more critical to business success than any technical skill' i am 'dismissing the potential value of a non-tech co-founder'
but you did make that claim
what i'm dismissing, as i've explained at exhaustive and exhausting length, is the idea that they're valuable because of their lack of technical skills, rather than despite it (and because of their other skills, which, as i explained repeatedly, are even more crucial to business success)
So, is this post correlated?
Y Combinator sincerely wants people to succeed, I don’t think it’s reactionary or myopic like that.
That said, to fill whatever hundreds of spots nowadays, they’ve exhausted Math 55, it graduates all of 12 people every year.
They’re dipping into a far greater supply of nepo babies than ever before. Those jagoffs can’t do anything - not programming, let alone sales - so whom is this advice really for? Those companies will “succeed” anyway, I mean they won’t fail. You can make a ton of money as a technical cofounder, but for the minimally intellectually stimulating problems of some moron's meaningless app, for that moron to get all the glory? Just to polish life off by marrying your subordinate and sending the kids to Day School? And shoveling all that money right back into meaningless angel investments?
This is a stylized comment of course, but it's just to say, yeah, you need a technical co-founder, really easy for Y Combinator to say. I too would like extremely talented people to give everything and take nothing.
YC won’t count someone as a founder unless they have at least 10% equity in the company. Founding engineers are typically getting 2% or less (from what I understand).
To be honest, for someone who cant land market salaries (e.g. non typical background), who finds a good team, this might be a good opportunity.
You need a mix of technical skills (engineering, product, marketing, etc) but also personalities (which manifest in different behaviors which are all useful & compliment each other - eg bias for action and hitting targets vs careful analysis).
"Get started for free in 3 minutes No credit card required, no vendor lock-in, but the convencience of a fully managed service."
which could mean soon-to-be-underperforming companies fail to attract technical co-founders
There are many terrible products in this world that were successful only because of good sales and marketing. And vice versa.
Name one.
Propagation of societal values and/or fear of hell and/or fear of death assuaged by the assurance of an afterlife and/or being able to rationalize away the vagaries of nature as the will of god(s) are just optimizations after the core system was already invented.
There is a place for religion. Something that pushes you to be better than you are. Along with the happiness and fulfillment that comes from that effort. Selflessness, love, compassion, truth.
Plenty of bad religions telling you that you are perfect the way that you are. Just give me money, fame, or influence and I will flatter you and pump your ego.
Another form of this is flattery in exchange for hating something. Many doomsday cults fit this category. All your life problems are because of 'insert target X'. But I, I have the answers you need.
Religion is more attuned with purpose, where your heart is, than the belief in God. Though the two are often paired.
And yes, we crave purpose.
Making a giant bucket of lots of things and declaring it bad because there is something bad in there shows your ignorance.
Ignoring reasoning shows an unwillingness to learn about stuff.
In fact, I think that behind the scenes of the ominous MS investment in Apple (with the whole big-brotheresque Bill Gates appearance) there was an explicit--business, not technical--agreement between Gates and Jobs that Apple would not venture out of their own hardware, specifically to allow Windows to continue its PC dominance.
Don't get me wrong, the marketing game of early MS was absolutely phenomenal. I just want to say that they succeeded to the degree they did because BOTH marketing AND the tech were good.
The Model 3 and its variants I think are meh from a UX POV (stupid centre iPad distracto-slab etc) and I won't pay for them because of who is behind them... and the lies about full self driving, and the crap support etc... suck.... but I think it's disingenuous to call Tesla product crap.
Just because technologists have been marginalized, abused, and extracted from successfully thru history -- does not mean it should be accepted and it does not mean I want that for myself or my technical friends.
Context: Michael is a non-technical founder from Justin.tv and Twitch.
I know three YC technical co-founders who were ousted by their CEOs, and a justintv alumn who got nothing from the follow-on exits. When YC says “you need a technical co-founder” they mean it like you need a disposable lawyer. The essay here is about targeting growth and flipping, not high-performance teamwork.
Even if it's mediocre, it's basically free, and has almost no costs.
Compare that to the incalculable potential switching costs of us meatbags and our many non-linearities.
Do you have a guess how that would play out or how likely that might be? It seems like the main blocker here would be if the agents remain relatively weak in pure reasoning.
I am able to get some pretty nice ideas out of LLMs by gaslighting them into larping as tenured professors at <insert good university for subject here>.
I haven't really tested yet if using actual people's names helps or hurts.
It's like clouds: AWS exists because enough stupid people don't understand available hosting options and can't make simple cost calculations.
This will never change simply because no one makes money if it does. If those people started looking for a tech-cofounder, then two options:
- they never find one, thus give up on the idea, the money they spend/waste on it will never be spent, thus GDP from this final consumption (which nearly all of custom development is: final consumption, a hobby), will not be created.
- they find someone who will pretend or will falsely believe to be technical. essentially same guy as the original one. and he will waste some time and money with freelancers, become convinced they are all fraud (because this is what happens when you ask for idiotic stuff to be built on impossible budgets - everyone except scammers, decline), then hire some agencies, and waste some money on them, aaaaand it's gone!
How do you explain to people who are not capable of starting a business, that they shouldn't start one?
Bigger question: WHY would you do it? Why not just benefit from them?
This is because at that point, our focus turned to licensing our (patented) technology to businesses. We still have B2C customers who use the tools that he originally built (and which have been updated by contractors after he left), but now the vast majority of our revenue comes from our B2B licensing.
We are pretty unique in this regard, since most startups aren't able to generate much revenue from licensing in this way. Specifically, when we work with our licensees, we provide a JS library that they plug into their own platform. We don't need engineers to do integration work, or provide support.
My technical cofounder provided a lot of value in getting us to where we are, for sure. But needing a technical cofounder to launch doesn't necessarily mean you need one all the way along.
Finally, someone made a proper JS library.
In terms of changes, there aren't any material changes. We've had licensees up and running for 7 years without changing any code.
Perhaps don't assume the worst?
Technologists beware -- some business co-founders will treat you honestly and you'll be paid fairly. And some will not. You need to read this comment and realize that both outcomes are possibles, especially once lawyers, VCs, and other business people get into the mix.
This is unfortunately true, since the VCs are only interested in the forward-looking value of the enterprise. They would prefer to dilute other shareholders (including founders — and especially former founders) to maximize future fundraising. And lawyers, of course, are happy to tell the VCs how to do this, regardless of what protections were put in place initially.
Usually a company with software need to develop new features, reengineering to reduce infrastructure costs and improving performance bottlenecks, maintenance, etc. Do not you have that in your company? And if you do, who is leading those initiatives?
So it's not that we won't ever create a newer version, just that it's not the primary focus.
This is a good point, but it should be clear that you would not have gotten to this point w/o the technical co-founder.
The problem is that once you get to this point, less than honest non-technical people seek to marginalize and eventually consume the equity/payout of the technical co-founder that often took the original risk.
It is critical that technical co-founders maintain equity and FIGHT hard for what they have earned and enabled, do a fair extent of the value they added.
My advice to engineers is that it's nearly always easier to learn business/sales than to learn to like a co-founder, especially the type generally drawn to being a "business" founder.
It is good to have a co-founder in general though, get one of those if you can. Just don't worry about finding complementary skills, bias entirely towards someone you can work with.
Getting your hands dirty is the best way to learn anyhting, so with technical topics, especially programming, I would just dive into projects and start coding, building things, and that's how I learned. In terms of business skills, what projects can I realistically undertake on my own that would help me develop those skills? Should I start a low-stakes business selling soap on Etsy or something? Is that adequate? Completely different ballgame from the corporate startup world - but would any of the skills from such a humble venture transfer to the larger stakes ones?
How might a technical guy become the business guy?
https://about.gitlab.com/handbook/
And if you think that it is too much information to learn then don't be a CEO. Because you are going to be expected to know all of it.
Don't waste time selling soap though (unless you really love soap) - my best advice is to try to sell something you've made. It could be your time (as a consultant), or it could be a product.
I would suggest waiting to develop these skills until you know what product you want to bring to market as an entrepreneur. No sense in learning B2C growth hacking when you end up in enterprise sales (or vice-versa).
I've found it rare that engineers will find that natural, it takes a lot of time and discomfort to get good at
This sounds like a typical engineer's summary. It is a dismissal - just like the video talks about tech being dismissed.
Recruiting a co-founder is not "just sales". The video is taking about an archetypical salesperson who still can't buy a tech guy (maybe their sales skills are not so good).
sales is everything at the start, and a huge amount of the reason why technical people usually need non-technical.
(i would have second thoughts about a non-tech founder without sales skills)
> Bill Gates famously paraphrases this as, “I’d rather teach an engineer marketing, than a marketer engineering.”
You can find a "pre-packaged" MBA, attorney, etc. because society is very good at churning out those roles. Just go the most recently graduated Wharton batch and hire the top grad for $300k, and you have someone who can do your legal, fundraising, operations, etc.
It's much harder to find someone with unique technical insight and the ability to deliver, which is the true value of a good "engineer".
Engineers do very well in Leadership/Management/Marketing/Sales/etc. which i consider ancillary domains in the Tech. Industry.
The reason is that Engineering is primarily quantitative and hence Engineers are taught to breakdown their Problems into smaller pieces and solve them one-by-one by using constraining/limiting abstractions so that each piece can be solved and then integrated into a whole.
In Non-Engineering fields this problem-solving approach is never taught and enforced. Most parameters are nebulous/qualitative/interlinked and more heuristics/opinion based with the result that they never learn to break a problem into manageable pieces and solve them one by one.
At many companies a sales engineer can make more money than a developer.
Personally I think it’s too nuanced a question to answer generally. Depending on who it is and the context “the right” person in either role can make all the difference.
Commission based sales seem like a good thing -- it is pay to perform. "Business co-founders" are not the same thing as SEs, because "Business co-founders" are often paid upfront (via equity) for the future promise of performing. That is not a setup with good alignment of interests.
On a very basic level, not having a cofounder in any capacity can create a structural bottleneck when two important things have to happen at the same time. A trusted second party provides resiliency.
Technical people mispredict the value of a business co-founder in a similar way to how this video talks about tech co-founders being misvalued. Cue jokes about sales-droids. But there is a mirror between businessy people undervaluing tech and tech undervaluing business.
A key point of the video is recruiting (albeit a form of sales): it is hard to sell "adventure" and belief.
We see this every time an engineer tries to shift to a managerial rôle and fails. In theory business skills can be learnt, in practice it is hard and perhaps easier to co-found with someone with the skills already. There are risks, but if you can't judge ability and integrity then you're already hosed.
The best example I can think of who cogently explains how they learnt is Jim Keller - talking about how he changed AMD.
Take that into account if you're the technical guy working for the startup.
So basically, lottery tickets that you get to cash out in 7yrs if you are lucky.
You are better off working at market rates, and buying Nasdaq options with your pay difference.
You're skipping the part about early hires having outsized impact over the fate of the company and the value of their equity.
Not sure it makes sense if you've got 0.5% equity.
Definitely does not make sense if you are being given X,000 shares and have no access to the cap table.
Any engineer who thinks they can value a fraction with a numerator and no denominator is fooling themselves.
Startup employees -- if you were given 50,000 shares but told you arent allowed to see the cap table, please UPVOTE/DOWNVOTE accordingly if you think the pay-cut to market was worth the money you got at the IPO.
- what the triggering events are (investment, revenue thresholds, etc), and make sure to include "hiring other team members for similar roles at higher salaries" as one of the triggers
- what the salary bump will be
- whether or not there will be retroactive compensation included
The first time around I ended up leaving the role before any of the usual triggers would have been activated. Management was toxic, salaries sucked, morale was in the shitter anyway. The second time around I discovered after tendering my resignation that someone who reported to me was making $40k/yr more than I was. It would have been an amicable parting (I was moving on to something that was much better aligned with my interests) but it got pretty sour when I found that out. I got asked a couple times to come back to consult on a few projects and the rate I quoted them (and they begrudgingly accepted) was steep.
The one that seemed more open and therefore more interesting: do you need a non-technical co-founder?
It's easy to run services on the internet when you don't know what you are doing wrong...
As a non-technical founder I can
A) Get a technical cofounder which takes me weeks to find, dilutes my ownership, and with whom I have no recourse if their work is sub-par (or we end up just not liking/trusting/vibing with each other)
or
B) Build an MVP with any number of offshoring partners in a matter of weeks and for far cheaper (money, time, opportunity cost). If I don't like the work, we can modify the contract, or I can quickly pivot to another team.
This is also true for technical founders as well, to be clear. You can probably do a lot of the business stuff by outsourcing. You can worry about gelling a team once you've got to 1.
If I hadn't been there, my other founders would have gotten up to their eyeballs in offshore dev debt and would have a giant hairball that even the most experienced tech people would be unable or unwilling to make additional progress against once the offshore team stops delivering.
So, good luck trying to lead an offshore team that's only interested in absorbing as much money from you as possible before moving onto the next sucker. If you don't think a tech cofounder is worth their ask, then you deserve to get exactly what you pay for.
- Offshore partner delivers software, but you dont have any code. Successive rounds of updates become more expensive. You cant walk away because you have none of the code. (Business co-founder has no idea and goes to new partner with binaries expecting updates to be delivered, then gets told they need to start from scratch)
- Offshore partner delivers software and code, but not the code corresponding to the software. You try to switch partners, but realize you start from zero, because you dont have the code
- Offshore partner delivers software and correct code, but only for the app/UI. Only they retain code for the backend.
- Offshre partner delivers code for UI and backend, but not the right code, UI is secretly pointing to a different backend with different code
- Offshore partner delivers correct code all around, but only they have the build scripts, dependencies, and cloud images required to run it.
- Offshore partner delivers everything, but only they have the data required to start up the system. New partner spends as much time figuring things out and eventually wants to re-code the whole system.
For each of the above, business co-founder goes thru the rounds two or three times. Each time, they spend 20 or 30k and each time they walk away with binaries they cant do much with. Eventually they give up, or find a technical co-founder.
1. product categories that are technically feasible and profitable and where products already exist;
2. product categories that are technically feasible and profitable and where no products already exist;
3. product categories that are not technically feasible, so no products already exist.
anyone can tell the difference between pile 1 and piles 2 and 3. but you need a technical cofounder to be able to distinguish between pile 2, which is very small, and pile 3, which is enormous. and that's not something you do once; it's an ongoing process that happens at many levels of detail in your product, and even at the largest scale it's a gradual process of reduction of uncertainty, because you don't really know that something is technically possible until it's been done
then, you need to actually build the first product in that category, which involves identifying, prioritizing, and mitigating the risks that could destroy it. probably in banking a lot of this is things like regulators, market moves, and bank runs, but in companies built on software, a lot of those risks are software risks, and you need technical acumen to do this
as a nontechnical cofounder, what value are you bringing to the table? your family's money? invest in a vc fund, or start one, though without technical cofounders you'll waste all your money on companies in pile 3. your business knowledge? that's worthwhile in some cases. your leadership and management skills? likewise. but you're going to have to offer convincing evidence of something like this to be a good option for anyone to invest their money in
Huh? A technical cofounder doesn't have any sort of monopoly on feasibility, and there's dozens of ways to understand opportunity space, PMF, and all the many other key considerations early-on.
As a nontechnical cofounder, what I bring to the table is enough wisdom and experience to get to a stage where I do need a CTO and technical team.
it's hard to tell what you're trying to say here, but people with the technical understanding of a field do in fact have a 'monopoly' on understanding what is and isn't technically feasible in that field, to the extent that anyone understands it at all
for some products they also have a 'monopoly' on understanding what products there's a market for in the field. if you're developing a new kind of swiss lathe, your customers are going to buy it, or not, in large part based on technical features like mrr, repeatability, and cycle time. if you don't understand the technical field, not only won't you understand what is technically feasible, you won't understand your product's value proposition. this obviously doesn't apply to mass-market products
in a gold rush, though, selling shovels to gold miners is more reliably profitable than mining gold
Don't know why we're having this argument. Outsourcing is a very common thing.
As a technical founder, I face the EXACT same risks. What if the business guy can't drum up money? What if he can't sell the damn pen.
Most companies fail, the strongest firms will have strong business and technical people.
If you want to stand on one leg. Go for it. You'll piss your money away overseas. When you need someone to help you get across that line... there is nobody at your side.
Founding a successful company is hard. You will face days where you don't have the answer. Things will happen that are outside your experience... and yes, you can buy, buy, buy your way there... but remember, you are buying mercs. I've been a merc. Win or lose... I get paid, so, yes sir. How high sir?
Rework is just more money.
... You sure you want to be on the other side of the table from someone like me, without someone like me at your side?
Because all those off-shore firms... are more merc than I am.
As I note in my original comment, my approach can absolutely be utilized by technical founders.
Different points of view, if they can stay respectful. Can be a great strength.
I see the world in terms of risk. If X will help me derisk something. Even if it isn't totally EV+ it can be a good play, because risk of ruin is real. Especially with large amounts of money, and small numbers of trials.
25% less to have a 10% better chance at making 75m vs 100m? Probably worth it a that level. Because 75m or 100m is life changing money for 99.99% of people at least. The amount won't matter as much as your chance of getting to it.
Sure, you can hire for it… but you’ll almost never find someone as invested in it as the founder, and it’s just as important as the product.
your attempt to attribute absurd opinions to me is deplorable and repellent
I'm the technical co-founder and my co-founder non-technical; he's brought in so many soft skills around process, finance, sales, recruiting, etc.. that I would have (and would still) struggle at to replace.
He's also a domain expert in our field so for me it was definitely the right choice to make.
There are very little businesses where the latter is true. For the former, no one can be good at everything.
while it is true that nobody is both as good at soccer as lionel messi and as good at programming as jeff dean, you can definitely be good enough at everything to start a company. and lots of people are bad at everything. everyone starts out bad at everything
being bad at programming or biology or whatever the relevant technical field is doesn't make someone good at management or bizdev
so don't look for nontechnical cofounders
just look for cofounders who don't have to be technical
It's relatively rare nowadays to see tech solopreneurs. (At least, for something more than a lifestyle business.)
Often you need someone with experience/connections/insight into the industry: medicine, construction, ecommerce, finance, logistics, whatever.
Declaring it an absolute requirement feels a bit like an exclusive club without real merit or consideration. I say this as a former exec at a YC company founded by a pair of eng degrees that couldn't build a thing (not even a prototype).
Downside: they are too much looking around , probably a lot of people around or screens with prompters. Disturbing me