Hacker News new | past | comments | ask | show | jobs | submit login

I've had a related discussion with a few VCs in recent months. Some kinds of startups are effectively impossible to build given current structural constraints on financing them, creating an adverse selection for startups that fit the classic model rather than startups with the highest expected ROI.

Broadly speaking, engineers will work at a discount to market-clearing wages of maybe 20% if they really like the startup. This is not necessarily an issue if you are well-funded and require ordinary levels of skill from your engineering team, which is most startups. Some types of software startups can't be built without a team of engineers where the market-clearing wages are typically more like $500k-1M. Even at a 20% discount to market, the amount of capital involved just for headcount is far too large for early stage investors, and startups that try to fit within the capital they can raise by getting by with less qualified engineers always fail at technical execution. Consequently, startups that have this property are effectively un-investable because there is not enough capital available in the early stages to achieve technical viability even though they may be great investments in the abstract. This wasn't a serious issue a decade ago, but it is spreading to a larger set of startups as wages rapidly escalate.

Given a long-term glut of capital, this could be addressed in principle by designing a model that modifies the distribution of capital/equity over time to accommodate startups that have difficulty financing the initial wage gap. As the startups grow, one would expect the average wages to start reverting toward the mean, but these startups won't get out of the gate without that initial investment in capable and very expensive engineers.

I've had interesting and productive discussions around this, it is seen as a way to bring fresh blood into an early stage pipeline that is drying up. It is obvious to almost everyone that the classic model of how you finance and build a startup team is breaking down in the current market environment, with an adverse impact on expected returns.




This is a good summation of the current challenges with startups that are attempting to compete on technical merit. I know this first hand as I started a computer vision company right around 2012 when the "AI" boom was really picking up steam. I would never dream today of starting a very technical company because every major will poach your talent (happened to me), invest in your competitors or attempt to acquire you (some people don't want to be acquired).

Contrary to your points, I don't see any way this will change until some big technology revolution happens that puts power back into the hands of creators - though that might be a pipedream.

Note, that doesn't mean you can't start and be successful with a company. What I'm trying to point out is that the days of a scrappy upstart coming along to "unseat the leaders" doesn't seem anywhere near realistic.

The only counter to this might be worldwide competition - so for example I could see Tencent getting bigger than Facebook in total user numbers. I'm not sure if these are comparable because they are in segmented markets.


Your points are well taken, and I have thought about them at length because I like to build startups in areas where this situation is the norm.

One unorthodox strategy, which I've discussed with investors, is funding early stage such that you can pay comp that BigCo can't easily compete with -- their scale works against them. In early stage, the absolute amount of capital is trivial (and there are trillions sloshing around these days), but the quality of the initial engineering team will have an enormous impact on the success probability of the investment. A few extra million in wages can have enormously high leverage in generating billions in returns. Imagine poaching literally the best engineers in FAANG and the kind of core team that would give you to attack markets no one has attacked before.

I'd like to see top engineers in tech compensated like top professional athletes. Investors pay the wages for athletes because the returns justify it, the scale of the wages is not material if you are chasing results. I believe that model applies in tech as well.


I think we may be past the point where even this would work - too many startups are offering deals that are transparently awful in a way that discredits the startup ecosystem at large. I've gotten a few early-stage startup offers recently and every single one came out to be over a 50% paycut (even accepting their generous valuations) despite the fact that I made it relatively clear where the total comp needs to be for me to move forward and I was assured that at the end of the process they would be willing to make it work.

Meanwhile, if you apply the same math to the founders and their equity, in every single case they are paying themselves multiples of what they are offering me and significantly above their own market value, despite them not having done anything yet beyond getting seed funding.

What then happens is that startups like these end up getting what they pay for - they get the appropriate level of talent at market price. This maybe a market-optimal result but the cumulative effect of all these startups doing this is that most top people have sort of written off "working at a startup" as a reasonable career option, because of pay and what pay implies about the talent level of the people they would work with. This hurts all startups, even those that are willing to pay up to get the right talent. And if top engineers won't even consider your company, offering top-tier comp may backfire - you run the risk of overpaying for the same talent you could've gotten at a lower price. It's hard to break out of this cycle - consider how the same few schools are able to persistently attract the best students - and I suspect the entire startup ecosystem is trapped in it.


You are not wrong, and FWIW I am a force for sanity on the boards I am on. I am a comp realist and I will always pay for quality, I am strong advocate for that.

The behavior of startups is not intrinsic, it is the product of incentives. If I created a startup tomorrow, I am confident that I could pull world-class engineers out of FAANG. But to your point, I would not play games with compensation. I hire the people I would hire because they are clever, they aren't going to be fooled by bullshit nor would they respect me if I tried that. That is an essential quality of good startups that should not be lost in this mix.


> If I created a startup tomorrow, I am confident that I could pull world-class engineers out of FAANG.

This is easy. Offer relatively competitive TC with a real potential upside to the equity package and a work environment that's attractive. BigCorp is mired in politics and decision-making that's grounded in risk mitigation. Do something legitimately interesting and folks will come. Give them some agency and the ability to really get things done and they'll stay.


A blog post I read on why hard-tech startups are counter-intuitively easier (especially, in terms of attracting talent): https://blog.samaltman.com/hard-tech-is-back


I read an article a while back that described one trait of the "10x" engineer as dispassionate curiosity. Setting aside the argument of what a "10x" engineer actually is, I'm sure those of us working in the field can recall folks that were exceptionally talented. Every one of those people that I can recall have exhibited this trait.

It's easy to deduce that those folks would be more interested in hard tech than any paint-by-numbers startup. I've worked at startups and well-established companies, and have found it surprising how easily really good engineers will turn down lucrative but uninteresting opportunities at well-established companies and how readily they'll take an "interesting" role for less or sometimes way less money.


Could you elaborate on what “dispassionate” means in this context, or link to the article?

As an aside, I’ve just re-read a Terry Pratchett novel and your description of the good engineers’ behavior made me think of Leonardo da Quirm :)


I may be confusing the term with "disinterested curiosity". Wish I could fine the article if only to refer to again. Here's a bit of an explanation that seems to match my understanding of the concept:

https://www.tandfonline.com/doi/abs/10.1080/00221546.1943.11...

To my mind that's an engineer whose curiosity is uninvested in the outcome of the exploratory work.

I've known good engineers and great engineers and to some degree, they were all like Leonardo da Quirm, though not all quite as naive.


I don't feel like a top engineer. I think am no way near that tbh. I rank myself as an ok-ish engineer. I feel more like a hybrid though and I feel like I am valuable to a startup as I can bring on the table several things which include some photoshoping skills, being able to build a comprehensive front-end, can contribute to ideas as well as manage a db, build an api etc (to a level).

The past 2 years I was working part-time for a startup as I am running a business of my own which is almost on autopilot and allows me time to work on other things as well.

After 2 years I realized the positive and negative sides of working for a startup that is hard to find out before working for one.

First of all there were 3 main guys running the show. Only one of them was a tech guy, the other two came from a business background with no tech knowledge wanting to build up a tech startup. Joining that startup as an early employee didn't mean much apart from getting close to 1% in options (which is nothing considering my contribution to the cause was worth way more but obviously 1% is an industry standard).

The work became increasingly more demanding, although they knew I had other things to do and I was part-time, I was asked to work more than what was normal and almost reached working full-time helping them out (which was stupid of me, I was sacrificing time that I could be doing other things). The paycut I took also from my previous part-time gig was about 40% which is almost half. The cause of the startup also started changing increasingly and although at the start I was keen to have the paycut etc it felt like I didn't belong anymore (thats important for others wanting to work at a startup to know. The idea is not gonna remain the same as it is especially with business people driving research all the time).

The only positive was that I got some more experience on as a fullstack than before as I had to work a bit more on aws and backend systems and also was using "newish" tech.

My honest opinion and advice to anyone that is willing to try out working for a startup is:

Don't compromise your salary and well-being.

Startups will offer you options which is usually crap unless you are a co-creator. If you are taking a paycut but you support and like the cause of that startup then ask for a bigger %. Realise that most likely the startup is not gonna vest or sell and generally think of your options as a gamble.

Its most likely that the chances of you making real money out of your options is the same as you winning the lottery. If you are asked to work hard and stupid hours, then reconsider your well-being and ask yourself if its worth it.

Also look at the composition of that startup. For me personally it was stupid thinking that 2 business guys having the biggest % in the company would ever work for a tech startup. They contributed in writing long essays and doing research all the time, but at the end they couldn't attract more engineers by paying shit salaries and giving out 0.2-1% in options. The product failed because it couldn't be delivered on time due to having less people working on it than it initially required, and because those business people in order to justify their own % to the company were going on heavy research and constantly deciding shift changes on the product completely out of the blue just because they had nothing else to work on. (we were supposed to release within the 1st year which would be a year ahead of our competition. We released after 2 years which gave competition the lead of releasing before us and a much better product)

All in all - don't sacrifice your salary, thats how you feed yourself and your family and someone elses weird-ass dream is not gonna make you silly money out of the blue. And also remember that working should be taking some part of your day, but you also have one life and working your ass off for someone elses shitty dream aint worth it.


Thank you for your detailed take here. I'd like to nuance this a bit to a more general rule.

Every person taking equity needs to justify their value now

This means that a setup with two "business people" founders need to justify their worth immediately. Not with promises of future sales. Not with vague research.

Worthy ways to prove their worth could be raising a giant amount of funding, or putting their own money into the startup as a sign of skin-in-the-game, or purchase orders standing ready to purchase the product once it is complete, or paid PoCs. Or serious track record of delivery/wins.

If you find a setup where engineers are taking all the initial risk while "business founders" stay on the sidelines waiting for a product to be built until they start to work -- run away. Think about it this way -- they have all the upside (they can choose later to work or to flee) while you have all the risk (you invested your pay-cut for vague promises of future work.)


> I would never dream today of starting a very technical company because every major will poach your talent (happened to me), invest in your competitors or attempt to acquire you (some people don't want to be acquired).

Damn, this is exactly what I want to do. Computer vision too.

Do you have any advice other than "don't"?

Would basing the company on the East coast near a tier-1 research university help with talent?

Could you have strong software engineers support the research roles? Does that pattern work effectively?

Another thing I really want to do is offer a 4-day work week with the promise of sabbaticals and/or remote work. That might not be attractive to everyone, but it's something that would speak to me and that I would want in addition to equity and salary.

Are you still interested in computer vision? Want to chat sometime?


>Another thing I really want to do is offer a 4-day work week with the promise of sabbaticals and/or remote work. That might not be attractive to everyone, but it's something that would speak to me and that I would want in addition to equity and salary.

I think this would be a very strong advantage in the hiring market (assuming you can raise money from investors who're okay with it).

I'm not your target market (I'm just an in-demand software engineer who happens to be learning ML, not a top computer vision researcher), but this is something I'd be willing to accept substantially lower comp for.

Unfortunately most startups seem to require even higher work output than big tech.


Well, that's his big bet isn't it. There are a lot of studies that claim 4 day work week will keep productivity more or less the same.

The catch here is this will potentially enable you to hire those 10x people. Even at reduced productivity, 80% of 10x is more than double productivity for 100% of 3-4x people, and perhaps this work environment will foster other people to increase their productivity as well.

With the right people and product, I see this as the ultimate weapon against big tech, most of which will have shareholders that will act a lot more conservatively when it comes to risks compared to startups.

This is not something big tech will be able to accommodate in the current macro-economic environment, no board will approve basically a 20% salary bump to all employees and while risking a potential drop in productivity.


Just an anecdotal data point, but some places have a vibrant tech scene despite paying jack shit. Salt Lake City, where I live, is one of them.

FAANG don't have offices here and don't offer remote positions, so no one is competing with them. As a result senior developers are getting like $130k or something, and seem to be happy with that.

Some people (myself included) don't want to move anywhere else even for $500k. So it seems like a nice little arbitrage.


Indeed, I think $130k might go a lot further in Salt Lake City than $500k elsewhere


If your savings rate is 0, maybe


Suggestion: put your email in your ‘about’ field so someone can remedy that :)


Haha, yeah. I'll be waiting a while for that Director of Shitposting position to open up :)


lanstein is right. Or mail me or lanstein.


Happy to chat, first initial + last name at google.

I think the answer is, know exactly how you want to exit before you start and plan for that. Realize also that is 180 degrees polar opposite of how the major VC's want you to approach it - so if you wanted institutional money from Sequoia etc... they won't invest if they know that is the case. There are a lot of good reasons why they take that approach, power law and all.

The reality is, your best case scenario is most likely an acquisition. Which might be exactly what you want, and if so absolutely go for it, but you need to really understand how and why and when the companies you are targeting do their acquisitions. This is incredibly hard to do if you haven't gone through multiple acquisition Due Diligence processes before, but I know of people who have repeatedly done this, so it can be done.

As to the other points, there are too many variables to say whether those are good ideas or not, totally depends on what you're trying to do.


My first startup used computer vision to extract tables from PDFs. We had great engineers but my co-founder and I didn't know enough about ML back then to design a proper feedback loop.

My advice is to find a technical co-founder who has built and scaled a CV system at a larger tech company, but who is looking for a new challenge. There are a lot of annoying problems that can be solved with CV as long as you create a way for users to help you get labeled data.


So there are actually three tech revolutions going on in parallel:

1) Kuberentes 2) Microservices. 3) AI

All of them are based on open source, and all of them are permissionless (I.e. the startup does not need permission from a big company, e.g. an app store owner).

They also erode the build-in advantages of big tech:

1) Kubernetes erode cloud lock-in on compute/storage. 2) AI is best serve on the edge.

I would say that everything today is up for grab.


Kubernetes is a solution worse than the problem.

Microservices are unix pipes but slower.

AI is linear algebra that costs x1000 because of the brand name.

There is no revolution in software. We are just building crud as high and as fast as we can because the quality of developers tends to zero as the number of developers increases.


> Kubernetes is a solution worse than the problem.

Not if you're a 1,000+ engineer org with an SOA.

> Microservices are unix pipes but slower.

Humans are way more expensive than the machines running our code. You can always spend more on spinning up additional instances. In reality the overhead isn't that bad. The principles of immutable stateless deploys free up so much mental energy when it comes to thinking about how to get your code out and not break things that it more than pays for itself.

> AI is linear algebra that costs x1000 because of the brand name.

Tell that to my real time voice conversion system I just wrote. There's a lot of new magic happening right now.

> There is no revolution in software.

I'm on a fucking phone responding from hundreds of miles away. We're launching satellites that beam internet.

> We are just building crud

You can't speak for everyone here.

Are you in adtech or a social spyware company? Maybe don't work like that then.

Find meaningful work that speaks to you.

> quality of developers tends to zero as the number of developers increases.

I work with brilliant people.


>Not if you're a 1,000+ engineer org with an SOA.

That's the problem. With a sane simple architecture instead of 40 years of crap on top of crap you wouldn't need thousands of engineers to spin up instances.

>In reality the overhead isn't that bad.

Over 1e2 times if the solution is in software, over 1e5 times if it's an fpga. Around 1e8 if you do it in silicon. You make the savings from not hiring the 1000s of engineers to deploy your bloated horror.

>The principles of immutable stateless deploys

Has nothing to do with k8s. Nixos and Guix are two systems that are as close to functional as possible and they sure as hell aren't 'stateless', even though they come closer than any of the sexy trending tech.

>Tell that to my real time voice conversion system I just wrote.

Thank you project librevox for proving a near infinite training corpus, thank you nvidia for gpus to do linear algebra 1e5 more efficiently than you can on a cpu.

>I'm on a fucking phone responding from hundreds of miles away. We're launching satellites that beam internet.

Like everything else you listed there this is a hardware improvement. A Casio watch from the 90s had the same order of magnitude computational capability as the first generation IMPs. Good luck getting it connected to the internet using any software you could write for it.


> 40 years of crap on top of crap

It's all new.

> wouldn't need thousands of engineers to spin up instances

If thousands of engineers had to worry about deploys, that'd be a problem. The deploy team is small. K8S makes this dead simple.

> Over 1e2 times if the solution is in software

That's ridiculous. Where did you get those figures?

> 1e5 times if it's an fpga. Around 1e8 if you do it in silicon

If you're writing code for FGPAs or burning it to silicon, you're far removed from application server development. That would move at a glacial pace.

> bloated horror

Our containers are thin.

> Has nothing to do with k8s.

You're just hating on k8s at this point.

> Like everything else you listed there this is a hardware improvement.

Kubernetes. :P

Honestly there's been a metric ton of software improvements. Literally everywhere.

Git, modern kernels, Rust, Paxos (popularized in the 90s), LLVM, modern game engines, tmux, Wikis, bittorrent, blockchain, protobufs, gRPC, Bazel, Redis, modern PL idioms, futures, TOTP, U2F, Markdown, RSS/Atom, so many algorithms, seam carving...


> > 40 years of crap on top of crap

> It's all new.

Now I’m tempted to reply, “No wonder that 1000+ engineers can pile up crap that fast” :)


>> Kubernetes is a solution worse than the problem.

> Not if you're a 1,000+ engineer org with an SOA.

The fact that most FAANGs (Amazon especially) developed their own systems that are not Kubernetes, and often much simpler, should make you think. Many don't even use containers - by design.

(Source: direct experience)


Amazon didn't have the kernel expertise to develop kernel features required for containers like Google did, and had massive sunk costs in their bespoke hacky solution (Apollo environments).


They didn't adopt Kubernetes because it didn't exist at the time. The original paper came out, what, four years ago?

These companies had deployment needs that weren't at the time met by off the shelf open source software.


> They didn't adopt Kubernetes because it didn't exist at the time. The original paper came out, what, four years ago?

That's not what I wrote.

I wrote that the systems they came up with are much, much less bloated and provide very comparable features - if not better.


> Kubernetes is a solution worse than the problem.

I disagree. Maybe it's because we haven't gone "full Kubernetes" where every cronjob is now a Kubernetes cronjob, or what have you, but for all the complexity we've had to overcome, we've seen substantial benefits.

For example, autoscaling instances of my data pipeline apps based on Kafka lag.

Was it complex? Yes. We had to expose Kafka topic lag as a metric to Prometheus, then configure the k8s metrics server that HPAs (Horizontal Pod Autoscalers) use to scale to pull that in from Prometheus using k8s-prometheus-adapter as a custom metric, then set reasonable scaling limits in the data pipeline apps HPAs.

Was it worth it? Fuck yes. We no longer have to worry about data arriving out of time at our data warehouse, because the scaling we've configured (in YAML, god rest its dirty soul) ensures that our data will always arrive at the data warehouse within 5 minutes, which is ideal for a near real time reporting product that greatly enables our end users.

Is Kubernetes worth it? For us, definitely. For anyone else? Really depends on your use case, don't cargo cult this shit.


How much data do your "data pipeline apps" process with Kafka, Kubernetes and probably other K-named things?


Several terabytes a day, but it varies, hence why I love the auto-scaling.


That's 10tb = 10000gb = 10000/24/60/60 = .11gb/s. My 2015 desktop could handle that.

Where do you work? I'd like to pitch my radical idea of edge consolidated cloud computing.


"Big data" frameworks are very good at throwing a lot of hardware at problems. See eg the classic big data vs laptop treatment: http://www.frankmcsherry.org/graph/scalability/cost/2015/01/...


The inevitable comment lol. I'm sure it could. To clarify, when the app scales, it's pods (container instances) that are scaled, not necessarily machines,that is managed separately by k8s. Depending on how much of the cluster is currently being used.

Yep, we could handle it easily on one machine, if we gave it unfettered access to all the resource, but our throughput varies during the time of day, so dedicating a machine to it to handle the peak throughput wouldn't make financial sense at 3am at night. So it's far simpler to scale pods with known resource usage as needed.

It also helps prevent issues when throughput suddenly doubles because of a business decision that you're left out of the loop on.

So autoscaling pods is ideal for our use case.


Were talking about $5k of hardware to meet your needs 20 times over with the new threadrippers.

Is your aws bill really under $500 a month?


On AWS you would be paying for many other things besides elastic CPU power. CPU and bandwidth is infamously expensive there. (But I don't think AWS was mentioned anywhere in this thread...)


You don’t need kubernetes to do it, any cloud provider has api that will make it possible. Kube main point is declarative model, which comes with a big price (like sql had). Yaml - is error prone way to achieve anything.

Will see if history repeats itself and we will see be imperative systems.


Well, arguably that's true in the webcrap space. The HTML->CSS->JS->Webasm line of development really is crap on top of crap. Trying to fix the design problems of one layer by putting another layer on top of it only sort of works. It gets worse over time. "The mold seeps through the wallpaper" (a comment I usually make about C++ collection classes trying, but only partially succeeding, to hide the problems of C arrays).

I was doing "microservices" on QNX using MsgSend/MsgReceive for hard real time over 15 years ago. It doesn't have to suck; the mainstream is just using the wrong tools for doing it fast. The QNX people managed to shoot themselves in the foot by going closed-source -> open source -> closed source -> open source -> closed source, after which their developer community was fed up.

Machine learning is not linear algebra. It's nonlinear. That's what makes it useful.


> Well, arguably that's true in the webcrap space. (...) crap on top of crap

Not that you're wrong per say, but personally, I think you should take a look at the HN guidelines. Like don't be snarky, and don't post shallow dismissals.

Just categorizing the arguably most popular way of building software as "crap" doesn't seem like thoughtful or curious conversation.


> The HTML->CSS->JS->Webasm line of development really is crap on top of crap.

I completely get the hate for modern web, but in this case I think it's unrelated. The whole Kubernetes/microservice world exists basically to serve JSON and similar protocols. Maybe rarely some static HTML.

For HTML->CSS->JS->Webasm stuff it is more fashionable to compile at build time and service as static assets. That's the polar opposite of Kubernetes/microservices.


“ AI is linear algebra that costs x1000 because of the brand name.”

This doesn’t even make sense because it can be said about anything involving numerical work on a computer and it’s still roughly true. Also because all of the libraries are free anyway.


>AI is linear algebra that costs x1000 because of the brand name.

Sure, but we've learnt to apply linear algebra to achieving things we could only dream of 10 (or even 5) years ago.


Current AI is still mostly trash of the high school level project quality, linear algebra taken to the absolute possible level of insanity.


I'm pretty sure that no high school project can beat the world's best Go player.


^the account name that posted this comment is the single most honest thing i have seen on the internet today. well done!


I like that username... :D


> Some kinds of startups are effectively impossible to build given current structural constraints on financing them

There are a lot of things that are impossible to raise money for, that are possible to bootstrap. If you're willing to work on something for 5 or 6 years without getting paid, there are lots of opportunities that open up that have high barrier to entry because they essentially can't be copied by venture backed companies.


Very few people can afford to bootstrap 5-6 years, that is a privileged position, most viable startups will never be executed if that is the filter. Some startups require many man-years of engineering effort before they can produce an MVP, so after 5-6 years they may have no material traction. Furthermore, startups have a shelf-life beyond which they become borderline un-investable solely by virtue of age. There are always exceptions but I would not want to count on being an exception among exceptions.

Some startups may be amenable to slow bootstrap, but the ones that have this very high wage cost tend not to be those types startups. I love these kinds of hardcore tech startups and believe they are extraordinarily valuable, it is the kind of company I would start, but I am also very realistic about the economics of building a team that can execute within those constraints.


If you do 4 - 6 months of consulting per year then it's very doable, assuming you're a developer.


That means you are spending even less time on your startup. I've been there and done that. And despite eventually raising $20+M in VC (I was extremely lucky), it was a horrible idea that I've never repeated since (raising subsequent VC). The failure modes associated with this are well understood and nearly impossible to avoid.

Short version: you can either generate project revenue or product revenue. You build a fundamentally different company to do either, so if you spend a significant portion of your time in project mode, the time you spend in product mode is usually moot. Consulting companies are project companies, through and through. The widely regarded truism that project companies cannot be transformed into product companies exists for a reason.

I'd love for this to not be the case but I've lived it so many times that I thoroughly understand the reality of it.


> The widely regarded truism that project companies cannot be transformed into product companies exists for a reason.

A lot of the best SaaS companies have actually come from consulting businesses that were productized. C.f.: https://startupsocials.wistia.com/medias/e6ttk04b9e?fbclid=I...

I think this strategy has a bad reputation because it usually fails, but what people forget is that startups usually fail anyway.


Have you written about this phenomenon more extensively elsewhere? Would to love to read about it in detail.


If you'd like to share, I'm interested in the types.....


Imma say, a lot of these ones: https://www.indiehackers.com/products


I would just look at successful bootstrapped startups that didn't have traction for 4+ years after the last pivot. E.g. Global Relay, Mailchimp, Bubble.is, ProfitWell, etc. And I wouldn't count something like Kickstartr, which took seven years to launch but only because the founder was non-technical.


DuckDuckGo


> Some types of software startups can't be built without a team of engineers where the market-clearing wages are typically more like $500k-1M.

What types of software startups have these constraints?

And, as suggested in sibling comments, could building a highly technical founding team (e.g. bootstrapping) be a viable alternative to hiring with high wages? There ought to be a sizable subset of highly skilled engineers who have achieved financial independence and would enjoy tackling a challenging problem in a startup.


> There ought to be a sizable subset of highly skilled engineers who have achieved financial independence and would enjoy tackling a challenging problem in a startup.

The flip side of this equation is that those same engineers can tackle pretty much any challenging problem they choose, while continuing to take home those massive paycheques from a big tech firm.

Big tech operates in almost every part of industry simultaneously - want to work on Blockchain? AI? VR? Shipping and logistics? Silicon design? Drones? A valued engineer at a FAANG can switch between all of those at will without ever even interviewing.


> those same engineers can tackle pretty much any challenging problem they choose, while continuing to take home those massive paycheques from a big tech firm.

but usually not in the way they see it. There's enormous value in having freedom to do things the way you want, without being restricted by corporate culture and/or engineering conventions of a Big Co.


But not all engineers want to work at FAANG, there are some that are entrepreneurial at heart and would love to work on their own idea as a founder/co-founder.


Why do those engineers even need a cofounder? Why should they share a big chunk of equity with someone without the skills needed to launch?


Being a solo founder can be very lonely


> at will

Is it that easy to switch departments/focus? I thought internal transfers, while easier than interviews, were not trivial.


Internal transfers are close to mandatory in many cases. Veterans are strongly encouraged to move every 2-3 years to cross-polinate engineering knowledge and culture.

For someone at a senior level (Amazon SDE III/Facebook IC5), an internal transfer is at most a perfunctory whiteboard session, and often just a conversation - you already have passed an interview loop to get into the company, after all, and have an easily-verifiable track record thereafter.


> Some kinds of startups are effectively impossible to build given current structural constraints on financing them

I generally agree with this, except I would change "impossible" to "exceptionally hard." You're right that a lot of startups innovating on deep tech need to hire people who would earn $500k+ elsewhere, and that a typical startup can't afford that.

However, very exceptional founders can often raise unusually large rounds early on. I.e. some founders can raise a $10m or $20m "seed" round at inception, which allows them to afford to pay $500k salaries. It's the top 1% or 0.1% founders within their fields, but it is possible.

(Source: I'm a VC)


Most startups I see pay at 50% discount to wages compared to top public companies not 20%


Imagine Steve Jobs having to pay Steve Wozniak. The trick of the startup is that the key engineers are the founders.

Startups are not a place for an MBA to get engineers for free but a place for engineers to make bank if their egghead managers in their corporations don't get going with an interesting business idea of which they know that it is a missed opportunity.


Thank you for so succinctly responding. I'm going to expand a bit and ask the GP (rhetorically) - if you want 500k-1M engineers (R&D I'm presuming) to work for you, what are you bringing to a table?

If you are failing to attract these high-end engineers to a low paying job, perhaps it is because they dont see what unique skills the "business person" is bringing to the table to balance the risk.

As an extreme example, I'd guarantee if the "business person" was Elon Musk, people would flock this startup. What high-end Engineers do not want is to give away a lions share of equity in exchange for a pay cut with no real upside, that would make no sense.

The typical procedural founder with "business skills" may have solid business skills, but those can be hired anyway, the business founder needs to demonstrate equal 500k-1M level of skills/background/trackrecord/etc.


I think a solution is less hiring at early stages (until you can afford it) and having co-founders hyper-focused on what’s important to the business (the ip) and they build and do the work to get it or the gate.


This. I would even go so far as to say that if you can’t get the founder salaries up to market rate based on MRR you should either bootstrap some more if you’re really into the IP or product...or close the place down before you hire someone under what they should be paid.


> Some kinds of startups are effectively impossible to build given current structural constraints on financing them

what are those startups? asking for a friend


I know a lot of very good people who would take a very substantial (well over 20%) pay cut if being allowed to work (mostly) remotely (+ equity if it's a startup). Especially the senior engineers (like myself) I know really consider taking or did take very early retirement over having to commute any longer.


Why not bring on the early engineers as cofounders with sizeable equity in lieu of market-clearing wages?


Most engineers don't want to be co-founders, and this does not scale well in any case. That role comes with responsibilities that can't be executed by committee and drama/stress that many engineers would just as soon avoid. There is nothing stopping anyone from giving engineers a decent chunk of equity but it doesn't address the core issue of scaling reasonable comp.

A "founder" is not just another name for a very early employee. It is a wildly different experience. I've been both, multiple times.


That’s a title. I’ve never seen an accepted definition of cofounder but mine is anyone pre-money. Someone pre-money is taking a 100% pay cut and often invests their own money.


Cofounders typically get double digit or at least mid-high single digit grants in equity. Whereas employees typically have 1% or less in equity.

If they're this vital to the success of the startup, they should receive equity accordingly.


Cofounders do get equity but don't get paid until funding. Employees get equity and pay. If it's a startup, the employee will get value = equity + (K * market wage) + benefits where K is less than 1. That value should be competitive with the market and key contributors should get more equity but NOT in the range of cofounder because otherwise something doesn't add up.

There is an implicit startup social contract and the OP points out that maybe startups can't outbid the FAANGs for talent now. That may be but I think startups (and the VCs+lawyers who are guiding them) are absolutely pathetic at managing this social contract.

You want equity? Fine. Here's some equity in the form of an RSU (fuck you, Bill Gates) which won't qualify for either 83b or QSBS tax protection. Sure, it may crush the employee with AMT taxes. Yeah, the startup gets a minor tax benefit from this but then expects its employees to bleed for them. This is beyond stupid. This is beyond stupid by the founders, the employee (who knows nothing) and the VC+lawyers (aka the institutional memory of the Valley) who do know something.

It should be part of the startup social contract and best practices to inform and help manage the employees tax situation. Don't use RSUs. Put a gun their head and make them sign and file the 83b. Etc.


How exactly should they do it?


Or, you could go remote - $120-150k is an awesome package for a senior engineer or designer eg. in Czech Republic (where I live).


Open source technology that requires 500k skills so all can share in cost


Open sourcing does not share the cost of $500k engineers. People using open source typically aren't paying the wages of the people that wrote the code. There is minimal financial upside to contributing to open source for most people.

The challenges that open source faces are closely related to this subject. Many vibrant parts of the software world -- open source, startups, et al -- are essentially dependent on engineers willing to write code for the compensation (direct or indirect) offered. When it no longer makes sense for good engineers to write that code, everyone will suffer from their lack of contributions.


I don't like this "make money on the back of others" philosophy.


Consequently, startups that have this property are effectively un-investable because there is not enough capital available in the early stages to achieve technical viability

Well, this is the class system in action. Investors would rather sit on capital and moan about how they’re unable to spend it, than spend it in a way that would benefit engineers. They will endlessly try to keep that money circulating amongst their own class.

Note: I am not a Corbynista by any means, but there’s no other way to explain all this money with nowhere to go yet wages stagnating.




Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: