Being quite senior now, I'd feel comfortable asking:
1 - To see their CI dashboard
2 - To see a sample of their production systems stdout & stderr
3 - Asking to review a recent non-trivial commit (with the person/people who wrote it)
4 - If you're interviewing remotely for an on-site position, finding out if they have an open office
5 - Finding out how they do deploys / devops
In my opinion, if you're a start-up and you've got all those boxes checked, you're possibly doing the right things in the wrong order, and that's a red flag for me. What I hope to hear are responses like, "so this is how we're doing CI. It's awful, almost non-existent. But that's because at our scale it just wasn't important. But as we grow it will become VERY important, so here's what we're thinking about doing in the next 6-12 months..."
I've experienced a start-up with lots of tooling and process , none of which matters when you take forever to ship (and stay shipped).
Proper logging doesn't take more time, it just takes more discipline / giving a damn. People and companies that say:
we don't have time to do it right
we don't know how to do it right
If we are talking about a really young/small startup and you're a senior person, then you need to have a discussion about it with whoever you answer to.
If we're talking about a really young/small startup and you're a jr person, you'll just learn a bunch of shitty habits.
If we're talking about an older/larger startup, then you have a problem.
I definitely knew how to set up a build server, CI pipeline, etc. It just would have meant that every time I (not we!) changed the build, I would have to fix my own machine and the pipeline. I'd much rather spend that time fixing one more issue, or adding one more feature.
There are numerous things that increase velocity for a large team, but decrease it when the product is just getting started. Joel Spolsky wrote about something similar almost a decade ago, https://www.joelonsoftware.com/2009/09/23/the-duct-tape-prog...
Not everyone's app is a web page.
Maybe, if I were executing on someone else’s vision, I could justify taking time up front to set up CI. But I still think it’s a little dogmatic to state that this has to be the first order of business, always.
>> numerous things that increase velocity for a large team, but decrease it when the product is just getting started.
Irrespective of the team size, if the speed of delivery has to grow, a decent CI/CD helps make it faster, IMO.
You're not wrong. But we're talking startups here, not established companies. It's publish or perish time.
When the company has enough breathing room, circle back around and do it the way the big boys do.
If logging is fubar'd then all 3 of those are impacted.
If you're pushing a PoC out the door. Sure, go on ahead and forgo proper logging. But if you're secured some form of series funding and need to scale. Fix your boat before you launch.
Non shitty logging takes minimal time, like, so minimal. It will make many bugs and customer issues trivial to fix.
In the least, use something like Sentry. Makes up a lot for not logging because it adds the context with your uncaught exceptions.
Things that never happen.
The ideal order of tasks for a startup usually looks something like this (and I say "ideal" because very few startups actually take paths resembling anything close to this):
1.) Figure out what & for whom you're building the product. The founders should do this before hiring employees.
2.) Validate that the people for whom you're building the product will use it, and ideally will pay for it. The founders should do this before hiring employees.
3.) Take investment. Ideally this would get pushed as late as possible or skipped entirely, both because you get better terms for that money when you've made more progress and because it often comes with strings that prevent you from going back to step #1 if necessary, but it's usually a prerequisite for step #4.
4.) Build the product. If the founders can do this themselves, they're at a huge advantage, because oftentimes you find you need to go back to step #1 after this is complete. But usually you need employees for this.
5.) Charge money, so that it becomes a sustainable business.
6.) Everything else that goes with being an actual business, from getting HR policies right to development practices to career ladders for employees to working out company mission statements.
And if you're doing step #6 before you've completed step #5, there is a very large chance that you've made a critical error in judgment that will kill the company. Why? Because you haven't actually validated step #1, and all the work in steps #4-6 depends upon getting that right. You might have setup a beautiful CI dashboard with 100% test coverage, only to find that all your unit tests & continuous integration need to be thrown out because your product needs to be rewritten in another language because the product concept requires a large & critical library that's only available in another language. You might have spent months developing & building relationships with employees only to find they need to be fired because you need a completely different skillset to build a different product for a different market.
It's fine to want a nice, orderly, 100% tested with CI setup and a robust release process development process as your working environment. At an earlier point in my career, I certainly did. But if that's what you want, I would highly recommend not working at a startup and going to Google instead, where you have a full test suite run on 1000s of machines on every commit and the results of it are instantly visible on their code review dashboard. That's what I did, and it was only when I realized that Google in 1999 was about as far away from that as it's possible to get that I became more comfortable with the codebase being a complete mess as long as it works & has happy users.
But setting up CI is a day's worth of work, and pays off almost immediately.
Having reasonable logging in an app of any serious size is a cultural thing; it takes exactly as much time to write as bad logging, and saves oodles of time every day when you have to discover and fix issues.
Compare it to building a motorbike. Yes, you want a prototype fast. But if you have all your tools stored as one big pile, or have oil and fuel spilled next to your welding machine, it does not speed you up; it sets you for an accident after accident.
Unit/acceptance/integration tests, if done right, capture requirements. They verify that the code does what it should do, and continues doing it even when changed. You can't write meaningful tests until you have some basic idea what the code should do - what would your expected results even be?
Logging, if done right, is about being able to quickly answer questions about the operation of your system. You learn which questions to ask only through the experience of having people actually use it. Logging can easily tell you fine-grained details about how much wall-clock each phase of your program takes. Should it? Well, depends - if you're about to rip all the code out and rewrite it, or if it's just something that runs once to generate some data and never again, it doesn't matter if it's slow.
Similarly, good logging can tell you precise details about how people are using the product. Should it? Here's a counterintuitive lesson learned the hard way: not until after you've answered the question of are people using the product. If you're getting a bounce rate of 100% (which you can determine by slapping Google Analytics on the front page), you need a completely different product concept, and it's a waste of time to instrument each user action with fine-grained logs until people are actually using it. You can always go back and add the logging then.
A motorbike is a poor analogy. The consequences of failure for most tech startups are significantly less than the consequence of a motorbike crash, the software is a lot easier to change than motorbike parts, and the goal of what the software does is a lot more ambiguous than what a motorbike should do. Rather, I'd use the analogy of a novel. Your first draft of a novel is going to suck, it'll barely make sense, and the goal is just to get your thoughts down on paper. When you do revise it, you revise for plot & character first, then pacing and voice and realism and sensitivity, then you might clean up dialogue & wording, and only then do you look for typos. Why? Because there's no point in fixing typos for passages that are going to get ripped out and replaced anyway. Spelling and grammar is the part that everybody thinks of because it's the part everybody can do, but it's really the last part of putting together a finished story.
Similarly, unit tests & CI & logging & one-click builds are the parts that everybody thinks of when they hear "development" because they're the parts that everybody should be able to do, but they're the last phase of building a worthwhile product. The first questions are "Who is using this? What are they trying to accomplish? How does it deliver value? How is it different from other alternatives available?"
I say "usually" of course, because there are certain things that constitute expectations that precede users, such as apps that handle sensitive information. Expecting that the app handles sensitive information appropriately before users confirm that they want their sensitive information handled appropriately would properly not be considered a guess.
The point is that in a tech startup, you are attempting to solve a previously unsolved problem. If the problem has already been solved before, why shouldn't your customers just use the existing solution? And there's a generic set of best practices for startup coding, but it basically amounts to "Do absolutely nothing that doesn't help you validate the key unknowns of your business hypothesis." Basically if you know that something is going to work, you shouldn't be doing it - you should be integrating the library/service/tool that already does it, or hiring the person that's done it before.
There will of course be some outliers where these best practices don't apply, but I assert that those are very rare. Most startups aren't special.
However, my experience is that those opportunities are largely getting tapped out, and the ones that still exist in the market today are increasingly niche. Between YC & accelerators, services for startups (Clerky/Gusto/Stripe/AWS/etc.), availability of capital, and the amount of open-source software available to build systems, it's become incredibly easy to found a startup - which means that lots and lots of people have, and picked clean most of the markets where a viable product can be made by gluing together these components.
Continued success under capitalism means doing new things that haven't been done before. The web, mobile, and tablet were new platforms that opened up computing to huge new markets. However, all the new platforms since 2010 have fizzled and failed to get mass adoption - wearables, realtime web, AR, VR, cryptocurrency. That leaves tech startups founded today trying new things, either leveraging AI & data science for new insights, trying to get access to increasingly unruly data sources that have not yet been tapped, exploring variations on blockchains & cryptographic proofs, or combining various platforms & libraries in new ways to find new uses. All of these take a lot more experimentation and have much less defined best practices than web and mobile development, but the potential upside is much higher than leveraging a database-backed webapp to solve a new set of business problems.
What a refreshingly interesting perspective!
How did you come upon this?
Anyone care to disagree?
But you'll see this across the board. People who write well organized, readable, low coupled code do so naturally and at more or less the same speed as people who write piles of poo. They might both achieve the same functional output, but the clean code will pay dividends in the future (and not just long term, even next week when you have to make a little change)
Also, quality is pretty core to a number key principle of the Toyota Production System (which many startups _attempt_ to emulate). Kaizen, muda and jidoka.
Fred Brooks might have written "plan to throw one away; you will, anyhow." But he also wrote: "Study after study shows that the very best designers produce structures that are faster, smaller, simpler, clearer, and produced with less effort. The differences between the great and the average approach an order of magnitude. "
i.e. we have 95% coverage on our core IP and CI setup for all of our source code. But, we integrated X for that service to get off the ground quickly, which will be too expensive at scale so we didn’t implement testing around it yet.
In my opinion, that depends on the experience/background of your staff. I have even seen open source projects (not backed by companies) get all the boxes checked in a very short period of time. For a project maintainer who has prior experience, it just takes several hours at most to set up a git hosting server and the CI/CD infrastructure.
The time saved for fixing a single regressing can easily pay off the investment.
As I always say, "If you are building a startup, over-engineering is a far bigger sin than creating technical debt."
Of course, each of those pieces is at risk of becoming over engineered. But hopefully the team has a leader that knows when to move forward and when to pull back.
And CI doesn't immediately have to include everything you'll eventually want; just having automated build and deploy will make your life a lot easier. Add some automated testing as soon as you can afford to (which hopefully is right away, because it's not that hard to set up), and you're ready to move.
Tired memes can be tired because they're true.
I have seen my share of startups where a platform plagued with technical debt was the main limitation for growth, which is a very avoidable situation.
I've never seen a start-up fail on account of technical debt. Re-engineering is expensive, but it means you have something worth re-engineering. I've seen lots of start-ups fail because money that should have been spent attracting and retaining users got burned on an elaborate engineering process.
That's because noone ever says "XYZ startup failed because their code quality wasn't good enough." It's usually something closer to "Their customers didn't renew contracts, they had to slash headcount, and went into a death spiral from there."
If you press for details, the deeper reason might be "they couldn't turn around features fast enough" or "the app was slow or their servers went down too much" which is a symptom of too much technical debt (either directly, or because the better engineers on the team choose to leave as a consequence of the technical debt).
I agree that early startups don't fail because of technical debt, but I'd bet that many mid-size startups do fail because of it.
Poor code quality is rarely perceivable by customers, except in the most extreme cases.
The point is the middle ground exists closer to shitshow than well-oiled shop. If the CEO doesn't understand this, they won't be CEO for long.
Thing is, it can go to the moon or it can flame out but there is this giant middle part of the spectrum where there are good exits and those exits often involve supporting your product and having well documented and tested technology is a positive. Trust me on this, it really sucks to get bought and then explain that it’s going to be a year and a rewrite to do the 10 things the buyer wanted yesterday.
Using Clubhouse to manage mine and the other dev's work now and it all seamlessly links up.
Took at most 30 mins to a few hours to setup each integration. Only downside is the monthly cost of all of the above but in all honesty if even a small startup doesn't have most of the above I'd consider that worrying.
I would worry a lot more about the business itself. Does it make sense? Do you see a credible path to paying customers? And the most important of all: are the founders the right people to grow and lead this thing? Could be experience or passion (ideally they should score high on both).
I ask questions more along the lines of what is wrong, and how are they correcting it. Good answers there can show a good long-term result. Bad answers there... run away.
I wonder if it's simply the balls to tell top management that we need to invest in training, refactoring etc. And selling it that it will payoff.
The usual answer I get when I propose this, is that "we're too busy with projects".
It's not a magic bullet, but in my experience it's a very good indicator of how a company approaches an obvious problem, so you can get a really clear signal about whether or not you'd enjoy working there.
One of the startups I worked with didn't have "good" practices just like what is listed above, and it took a while to get there. The thing is, we're still pulling quite healthy numbers, and we have paying customers. What made it bearable was our engineers knew what needed to be done, and had the technical chops to get there. You'll probably want to avoid very elitist engineering cultures that aren't open to what's considered good practices.
Many successful startups run on the shadiest software architecture in the early days, but market pulled product out of the startup. Today, they have the engineering resources to make it a lot better.
But I do get where you're coming from. In my experience, it's better to ask about the team and its CTO to understand how decisions get made, and if the team is capable of recognizing quality. I don't care if CI isn't in place when I join as long as the team recognizes its importance and knows they need to get to it.
They might not even be able to hire a Senior Engineer in most cases. Maybe you wouldn't even want to talk to an early stage startup at your current seniority level.
Having said that for anybody who really wants to join an early stage startup the only thing that should probably matter is what is it that you're trying to do and how can I help you reach your goal? Will you be able to pay me enough on time and for how long?
- If you get the money and opportunity to hire really senior/well known dev to lead your eng. team, would yo do it
- Ummm no, we believe in our team, and their strong knowledge, there is no problem they cannot solve (or something along those lines)
To me, the red flags are absolutes. i.e. "Yes, we would absolutely replace our team lead because we only want the best" sounds like a toxic place, and it's not the kind of place I would expect to find (most of) the best engineers that I've worked with. And "No, we would never hire that person because our team is the best" sounds arrogant or naive.
I've seen this behaviour where existing employees were forming a "cult" to cover each other, and promote one another, while technical debt piled up, and at the end basically brought products to a halt.
I'm not saying that VIP hire is some magic stick that will fix everything, but if they consider a taboo to even mention such a thing, this is not a environment to be in.
PS: Yes! Shockingly not all startups use source control.
That's a good one, definitely gonna ask this at the final interview stage of my next job. It very much indicates how people work, whether they spend a lot of time fitting in features into a difficult code base or if things are just working a features a developed at a predictable pace. (On prod won't stop working on weekends)
Another idea would be to see their event and analytics dashboard for their infrastructure KPIs.
If they don't have one it's a bit of a red flag.
I disagree that it's important to note that early employees experience more dilution events. I know you're trying to educate but this type of advice unintentionally misinforms people and causes people to pay attention to the wrong thing. Ultimately, the more important math is number_of_shares multiplied by share_price. As long as that goes up, dilution is not as important. What employees will care about is whether the total money wealth went up and not whether their 5% ownership turned into 4% because a new investment round bought 20% of the company. I have no idea why dilution attracts so much verbiage that's out of proportion to its mathematical importance.
E.g. "Oh, company X got acquired for $250 million. We do something similar. If I own .025% of the company, I'd make $62,500 if we exited at that valuation. Cool."
It's important to be aware of dilution events so that you realize when you accept the offer that your .025% will be more like .008% if you're lucky enough to have a successful exit.
But you're repeating the same error of prioritizing the wrong thing: dilution.
What employees ultimately care about is their wealth calculation: shares_multiplied_by_price.
Example of the type of math people actually care about:
0.008% (because dilutions) a $1 billion company is $80k
0.025% (no dilution) of a $100 million company is $25k.
For most employees that are minority shareholders, dilution is a side-effect calculation in the realm of academic trivia. Dilution is not a purposeful strategy in this situation. Highlighting "dilution" in advice for employees in an attempt to make them more financially more sophisticated has the opposite effect!
The scenarios for dilution to be a calculated strategy would be something like a founder considering 2 different offers from potential investors. One VC offers $20 million for 15% of the company. Another offers $30 million for 25% of the company. Or some founders selling too much of a percentage such that the dilution crosses some boundary such as 51% ownership where they collectively lose control of the company. These deliberate decisions around dilution are very different from employees realistically worrying about dilution dropping them from 0.025% to 0.008%!
I’m sure you get this and I know the psychology of what an employee might hope for shouldn’t be relevant, but unfortunately it is.
(For those who don’t fully get this - what I mean is that folks often look at a potential outcome and say “other companies like this have been acquired for $1-2B vs $100B, so if I’m being given 1% at $10M my stake could be worth $10M!” When in reality after dilution, that stake might only be worth $2M, which is a very different outcome after 5-10 years of hard work at below market salaries.)
It's not dilution that is the problem. Dilution is just what happens when you bring in new money. It's that it is very hard to predict what a reasonable upper bound is for the future value of your shares.
Quite frankly, it is one of the big reasons I think trading salary for stock options is a horrible idea. Much better to treat those options are lotto tickets--the odds they pay out in any meaningful life changing way are very small.
Startups don't like to hear this because the truth is, when you work for a startup you almost always take a sizable hit to your salary.
A "billion dollar company" that raised $500M with a 2x liquidation preference will put many fewer dollars into an individual employee's pocket than a $100 million company that only raised $10m.
It’s not true that everyone will always be diluted equally. Someone who isn’t involved in politics or paying attention to investor terms (oh, like an engineer maybe?) is more vulnerable to this.
No, your logic would only hold for a public company with shares priced by a liquid market.
For a startup, percent ownership of fully-diluted shares is the key metric. (Other secondary factors, e.g. liquidation preference are also relevant.)
The strike price of the options is derived from the price that the most recent lead investor paid for the last shares purchased. This is not a market price -- the underlying value of the shares is often less.
But the options are effectively worthless until they are vested and a liquidation event, usually an IPO or acquisition, occurs.
We are talking about different things.
I was talking about "dilution" as a verb/action that describes a _change_ from a starting % of ownership to a lesser % of ownership. The post I responded to was talking about dilution events.
Employees cannot realistically make calculated strategies around dilution _events_ because they are not on the board-of-directors and can't veto the founders to not accept additional round of funding. In any case, whether the employee's shares experience 1, 3, or 4 dilution events is not something people typically care about. What they want to really know is if they get wealthier.
On the other hand, if an employee is offered a # of shares as an incentive to accept a job, then yes, it's good to know if that means 0.10% or 0.05% ownership. It's smart to know if an employee is getting typical equity percentages in the industry that's commensurate with the role and timeline of the startup. (Some examples.) However, that's a metric at a particular point in time and it's not a "dilution event" from the perspective of the employee.
Oh, wow! Worked three years of 80 hour weeks and here's 80K.
When you join early stage start-up you know only how much %% of a company is offered to you at the moment, not the future exit value.
But this "future exit value" is the same unknown for co-founders, angel investors, VCs, etc. Employees share the same unknown as everyone else as to what the eventual IPO or corporate acquisition valuation could be.
E.g. if an angel investor buys 5% of the company, he only knows his % ownership at that moment and not the eventual IPO price in 7 years. The angel also doesn't know what his eventual dilution will be. It really doesn't matter.
The angels and VCs ultimately cares about shares_times_price and that it has grown multiples of their investment. They already know they will get diluted because every owner gets diluted in the normal course of events. Selling equity to help it become a more valuable company means getting diluted.
E.g. When Accel Partners invested $12 million for 15% equity of Facebook in 2005, their investment got diluted when Microsoft later invested $240 million to buy 1.6% equity in 2007. That's how it mathematically works and it's normal. Dilution is a downstream math calculation side-effect of selling equity. The Accel partners didn't complain that they got screwed and owned less than 15% because the Microsoft investment diluted them. Also, neither Accel nor Microsoft knew what the eventual IPO price would be in 2012.
>how much %% of a company is offered to you at the moment
To be more precise, employees are typically offered a number of shares or options to buy shares instead of an explicit % of ownership. The % of ownership is a derived calculation at a point in time that's based on the number of shares. From that moment on, it's the price of the shares that ultimately matters and not the dilution because everybody's % of ownership will decrease as a normal event in growing companies that raise additional funding. Presumably, the startup hired employees that can contribute value so everybody's share price goes up which more than offsets the dilutive effects of accepting extra investment money.
Don’t also forget you can have down rounds that can lower both your ownership and your share price.
I've been through this several times, and ended up with car money or nothing, and I dont think I'm alone. a warning to fresh grads that they may not end up retiring after spending years of putting in time and a half seems in order.
To counter this perspective, usually founders take FAR less salary if at all.
If the value of your stake goes down, you shouldn't just blame dilution. You should blame the company for performing poorly.
They could have worked in a stable environment with guaranteed $1M in compensation after 4 years, vs unstable and very demanding job with a low likelyhood of $1M total compensation over the same time horizon.
Early Uber employees got diluted like crazy, but they will probably do well when they cash out (or already did in secondary offers).
That's more than my FIRE number haha, real estate in the Bay Area is so silly.
As for its overall importance, most companies simply aren't going to be homeruns. I was at one company that passed on an acquisition offer of $X and opted to take an additional round of funding. A year later, the company sold for the same $X that it passed on. For sure, it was hoping to go much bigger than it ultimately did. But in addition to having to wait for all liquidation preferences to be settled, the employees all got to experience additional dilution for no additional gain.
It's great to shoot for the stars and everyone joining a startup hope that's the outcome. But I don't think it's out of place to also think about the median case. An early stage employee takes a lot of risk with few protections.
The real reason employees should put up with dilution is because the share price doesn't always grow. Sometimes, the company runs out of steam and it drops to zero. They should put up with dilution because it gives the company a better chance to end up profitable and for their shares to be worth anything at a liquidity event.
It's the same reason why many SMB owners get caught up in the 50/50 vs 49/51 split (when there are other, better ways of resolving the voting right aspect) or squabbling over a couple of percent in an investment deal.
Logically, the differences are trivial, are likely to be diluted out anyways, and ultimately matter little compared to other factors.
Emotionally, it feels huge. It "feels" like you're giving something up. On a pizza, "50%" is better than "10%" because it's clearly more of the pizza. Same with many tangible things in life.
I want to emphasize one point. A company may offer you options, or restricted stock units, or any sort of equity in the company.
When they do this, they are asking you to invest in the company. They are asking you to buy your shares with your scarcest resource: time.
Do NOT be the slightest bit embarrassed to ask any question you want about the company's capital situation, funding prospects, premoney valuation at the last funding round, amount of "runway" left before they need revenue or another round of funding, names of major shareholders, preferred shares outstanding, etc.
Warren Buffett would ask lots of questions if they asked him to invest; so should you. Mr. Buffett probably would ask better questions, but that's OK. The company should encourage questions from YOU: they're asking YOU to invest.
If they bristle at your questions, it's a red flag. They may say, "look, that's confidential, can't answer specifically," and that's OK. But they shouldn't get annoyed.
And, remember, you can't pay your rent or buy groceries with unvested options. You need cash money for that.
You can't pay your rent or buy groceries with vested options either.
Then again the UK is saner when it comes to employee shares - and I am lucky that I have EMI options - which are taxed at 10% CGT and 0 income tax.
At my last company they had no equity going in, and added it on Jan 1st a year later.
When I spoke to the founders about raises for the engineering team, the CTO looked at me funny.
"we just gave everyone stock options, why do they need a raise?"
Because a few of the engineers had young kids that were just starting school, and equity on a 1 year cliff won't pay those fees.
Because in Sydney there are enough start-ups that any one of the engineers could get an offer for 10-50% more base salary with options on top.
The founders were genuinely great guys, but they couldn't see the wood for the trees.
You own 1% of options and company is bought for $10m.
He forgot to mention preferred shares given to VC’s with liquidation preferences that likely never disclosed to new engineers.
This is what makes new engineer to sacrifice his salary for a possible liquidation even that likely either never happens or there is no money left for him after VCs took their xN ratios off the payoff.
"How much would the company need to sell for before my equity has value?"
Key #2 (not mentioned ANYWHERE):
"Can you guarantee that my equity will always be worth at least that in case of acquisition for the above value?"
Key #2 stated in writing (congruent with typical verbal promises of implied future wealth) will actually protect you and possibly justify your salary sacrifices.
Without Key #2 guarantees - the next round of funding will likely push your equity value out of existence.
For an extreme example, say the VC invested $10M for 10% of the company, and then the company doesn't manage to grow, and gets acquired for the same $10M amount. The initial VC gets the $10M back from the acquisition (they make their money back, no profit). Then there is $0 left, and the common shareholders (early employees and often founders) get nothing.
It's a contrived example, and there are many other complexities to such a deal, but you get the idea.
Also note, you can end up with negative returns since you may have paid taxes on the options.
A company can't easily give you preferred shares. Someone has to define what preferred includes: rights to elect someone on the board, right to oversee spending decisions from the CEO, etc... It costs money to structure preferred shares. You also can't piggy-back on a preferred class that already exists, unless the investors that "own" that class are happy to dilute their privileges with you (highly unlikely).
Common stock always exists, by definition, in a corporation. So it's easy to give it to you.
Usually, the founders and VC have the preferred shares, while someone writing unit tests at 3am does not.
>Usually, the founders and VC have the preferred shares, while someone writing unit tests at 3am does not.
This. I moved into a VP Eng role at a startup and had options for common stock worth about 0.7% of the company. When we were acquired, those were worth zero, though I was decently compensated by the acquiring company with cash and stock. The money I made was due to my role/position rather than my equity.
Of course, the acquiring company can always opt to pay large signing/retention bonuses to founders if the acquirer believes they're valuable.
My understanding is that you're perfectly correct, however — I'm just trying to demonstrate how I don't really "get" it. I presume there's some other number involved in the "liquidation preference" that is visible to those involved that make it more than a mere n% of company calculation.
Edit: Googling this, it seems like these special investors get to recoup their investment if the company is selling for less than what they valued it at at their time of investment. (And since it seems like this generally applies to VC firms, I gotta say, this is really lame. It was a bad investment, but you know the actual employees took a lot more risk in it, and yet the VCs get a better return — albeit a loss.)
This can (and often does) eat into the common stockholders' (e.g. employees) liquidation amounts.
Agreed that more than a 1x liquidation preference these days would generally be surprising, but in a low end scenario or with a few big rounds, all it takes is a 1x to wipe out any upside for founders and employees, but if you're deemed worth it, the acquiring company can offer you a worthwhile incentive to stick around.
Most of the employees are not given access to those terms. For example, in my last job in start-up , senior only celebrated each investment rounds but never detailed any of its terms. So, I had no idea whatsoever of the actual reward I should expect and that seems to be the norm from what I hear.
This is why a lot of folks from Good Technology got screwed. Valued at 1.1 billion .. sold for 425 million. Preference stack was skewed to investors + mgmt.
This means that on an acquisition the original investor gets a minimum of 2x their original investment. In the case the start up is acquired for anything less than $10 million the original investor gets everything.
When joining the company, you might be granted a set of options which are described as comparable to 1% of total shares, but the number is almost always effectively lower than that.
If the company does well, future funding rounds will lead to dilution of your ownership.
If the company does poorly, VC's will have liquidation preferences meaning that they get paid back first. This can easily bring your ownership down to 0%.
If you can't get those, then unless the equity is just butter to you, walk .. as you don't really know what the comp looks like.
Taken another way, when companies refuse to give you the numbers to properly evaluate the potential value of equity, then you properly value it at zero and ask that salary be bumped up. And, yes, that works and much better than asking for numbers you'll never get.
The problem with a public cap table is that it amounts to a public salary database. Usually companies (and employees) don't want everyone to publicly know everyone else's salary. When people do jobs you don't understand (like marketing, for the tech crowd here), or are perceived as underperforming, removing all doubt about their compensation breeds contempt.
Anyway, even buffer doesn't publish enough information as they don't publish the "preference stack". Whether by design or an oversight is hard to say. And you can't really publish it as it will lead to difficulty recruiting as candidates get soured by the prospect that investor's real equity is better than their sweat equity.
Sure, VCs talk but (speaking as a not-VC) I doubt they are going to share cap tables and such. They are busy people. If you, as a VC, care, talk to the company yourself. Even if they would share peer-to-peer, you are not a VC so you are not going to be privy to this VC-public info.
Actually, employees would love to know everyone else's salaries. This gives them a stronger negotiating position.
"difficulty recruiting as candidates get soured by the prospect that investor's real equity is better than their sweat equity."
So basically looking for useful idiots as they really realize that the startup is definitely not a good deal? They are investors after all, but investors without full disclosures.
Which _can_ be ok... if salary plus bonuses are high enough... then you're not betting on your horse to come in anyways, you're betting on putting your nose down and getting things done.
"We are a private company and don't share this information."
Outside of the room, the Engineering team laughs at your questions, Operations and the CEO give each other quizzical looks before laughing too, and they go on to the next candidate.
You get smug satisfaction for not going with "THAT Company who cant answer simple questions", until a reminder about the rent payment comes in due and all you want is a 30% pay increase over your last/current role.
Anecdata, but I interviewed for a marketing role at a 10-person startup in 2013. I asked questions #1, 2, 4, 5, 6, 7, 8, 9, 12, 13, 15, 16, 17, 18, 19, and 20 - and the company was more than happy to 1) answer immediately, or 2) say "I don't know, but let me find out." I should have asked the other questions (especially the relo package!), but I was young, naive, and not tactful enough to ask tougher questions in a "cooperative" manner.
IMO it's insane to work for a company if they're evasive about the value of your equity (#4-8). That's tantamount to lying about comp. You can usually find out how much they've raised on Crunchbase, and you can napkin-math their burn by eyeballing the team (#9-13; payroll is the dominant expense for most startups). #14 seems like a weird question to ask, but YMMV.
I would take their answer to the product-market fit question with a heaping pinch of salt (what are they going to say, "no"? and PMF means something different to everyone), and listen closely to the "feedback from customers" answer.
This is such a short sighted perspective that it's laughable.
Good management will see that the candidate is thinking about joining the team as a long-term commitment and isn't just making a job change for a pay increase over their last/current role. It shows that candidate is showing up for the same reason the company exists -- to be fairly compensated for services rendered.
A leadership team that laughs at these questions are going to lose long-term, and should be avoided by potential employees and VC alike.
Wow, that's rich! You trust us, but we can't trust you. That dissonance pretty much makes it an auto-fail.
Except you have to be an employee share or options holder already
And you have to sue for it (or launch an administrative proceeding)
I would say though, don’t assume malice! Some people really believe that they’re supposed to keep this secret to protect their investor info or something.
If during the interview and negotiation process, a hiring manager (probably a large equity holder) at a startup company can't give me details regarding their equity, funding, board makeup, business strategy, work environment, competitors, challenges they're facing, and how I fit in to their strategy... why would I bother working with them? There are plenty of startup companies that will give me that information in order to sell me on joining them.
If they aren't serious enough to consider each hire vital enough to put some cards on the table, then I'm not about to waste my time working for them.
Further, there are plenty of non-startup companies I can go make a big paycheck at with 9-5 hours.
I'm on the management side (was CEO CircleCI, now CTO darklang) and we would absolutely answer all these questions. It's a complete red flag for any company that would recruit an employee without telling them what they're actually getting.
It's reasonable to keep the answers to Qs 4, 5, 8, 10, 11, 14 and 15 until later in the hiring process when you're close to an offer, so long as you give directionally-correct answers first.
Personally, I would answer everything except 5 in a first interview (and that's only cause I'd have to look up the exact numbers).
I've worked at two startups in the past. The first startup tanked. When interviewing for the next role, I did ask these questions, but had no luck. Ended up taking an offer with 15% increase over my last role. Two years of work, and I find out that this startup too, is on its way down. Eventually ended up moving to a big company.
Then on, I had only two choices: (1) ignore the problems and not worry about future, or (2) act fast and start interviewing until I have options if something goes wrong. I chose the second option, and hence a lot of interviewing.
I've noticed candidates who have had a bad experience at a previous startup often try to find a circumspect way to ask if we're profitable and if we're going to run out of money. Those are good and fair questions that I'm happy to answer.
I'm sure some companies would demure on some of these if the answers are uncomfortable. I hope not many would laugh!
For an engineering position I suggest candidates also ask if they can review some of the code they'd be working on like a recent pull request.
Getting this information is done in the form of an application
Good senior people are selective and want to know a lot about the companies they might be joining. If they didn't ask perceptive questions I'd think it was a red flag.
I mean seriously, a startup is trying to hire a senior engineer, is offering less base salary than Google, stock with an average value of nothing and they don't even want to answer the hard questions? How would they ever hire anyone good?
The only people I'd give a pass on not knowing asking good questions in an interview are interns or new grads.
If you are worried about making rent, then perhaps your evaluation criteria would be different, such as "will this pay the bills, and will I be okay working here for the next 2 years."
There are tons of resources online for questions to ask, and I think the company/viability questions from the post are good, but I would add to them some of these types of questions:
How you will be managed/evaluated and the mission of the company: https://www.themuse.com/advice/8-questions-most-people-dont-...
How your founder/manager will navigate conflict, which is inevitable: https://www.thebalancecareers.com/interview-questions-to-ass...
You are a founder.
They are working with a technology or in an industry that you specifically want to work with and it is very hard to work on it professionally, and doing side projects are infeasible.
You need experience and you have no other option to get experience.
You are getting a significant title bump that moves your career forwards.
Invalid reasons for working at a startup:
Equity (getting rich off stock options) - this is very likely to be worthless unless you are a co-founder.
Salary - you would make (much) more at a big company.
Work life balance - you will work harder than you ever have.
Stability - does not exist.
Benefits - very bad.
Learning - they will not have any formal training nor time to train you, so be prepared to self-learn.
All that said, I enjoyed my time as an employee at multiple startups. Just go in for the right reasons and your eyes wide open.
I think this is the crux of his argument. Of course there are outliers, but 90% of the time (I don't know the actual percentage, but I'd venture it's around there - if we're only talking about money I'd say 99.9%) someone will be happier if they go to a more established company.
And people are often disillusioned when their equity becomes worthless, because for years they were told that would be worth millions and they accepted low salaries because of it.
Of course sometimes it does work out great, and I'm happy that it did for you! But statistically, you are incredibly lucky.
Of the high-growth tech startups we're looking at, here's an analysis pointing towards 92% failure rate - https://s3.amazonaws.com/startupcompass-public/StartupGenome... - I suspect the real number is actually much higher if we're including seed stage companies.
Beyond that though, it's mostly me piecing together anecdotal evidence of disgruntled startup employees who left for larger companies and regret not joining immediately after college. There are of course plenty of people who join for the experience, for the smaller team sizes, the autonomy, etcetera. But I think my argument is largely driven by equity. Unless you'd happily except the job offer without the equity it's pretty hard to refute that people join startups because they want equity. And that equity is almost never worth it. If you aren't a single digit employee number at a company with a 10 digit exit, and this is still assuming you didn't get fucked by dilution because of asshole investors, the math just doesn't add up.
The odds of being in that cohort is much less than 1/1000, probably closer to 1/10000. It would take me a bit of effort to find a hard number on it (looking at total number of employees at large exits, find large companies that failed, approximate number of employees at various other startups) - but I actually know people that were employee #X at a company with a 10 digit exit who didn't get screwed by investors and they still would've been better off going to Google in terms of financial compensation.
Also I think a lot of it is ignorance. Many people at startups don't realize how much better it could be at a FAANG company because they've never worked there.
What's the amount of your salary? What's the value of your equity compensation? How much time do you get off?
(your benefits may not be as good as you think)
The concept here is closer to "firing your investors" or "buying back your equity", but they haven't necessarily done that yet.
HN threads are conversation. Anecdotes are the life blood of conversation. This is an internet forum, not a peer-reviewed journal.
valid: you want a sense of ownership and responsibility. if you don’t perform, there is a noticeable effect on the company.
valid: you want to be in an environment where others are just as committed as you to the success of the company. you want to treat your work as an endeavor, not as a means to a paycheck.
i don't mean it in a legal/financial sense, and i am not referring to any extrinsic reward, eg financial upside.
Five-year-old well-funded-and-profitable companies with 50 employees, where you as employee #50 are just there to toil away writing some dumb CRUD backoffice code—are still referred to as "start-ups."
And, in fact, since the other kind of startup dies more often than it succeeds and grows into this kind, most startups that are hiring at any given moment are this kind of startup.
Are there big investors? Welcome to big company politics.
> valid: you want a sense of ownership and responsibility. if you don’t perform, there is a noticeable effect on the company.
Responsibility? Sure. Ownership? Unless you're a founder or a big investor, haha, no. Unless you mean the corpo-speak "ownership," which is just another word for responsibility.
Responsibility might make the work more emotionally rewarding, but it also makes the work more stressful, so I won't sell it for free.
> valid: you want to be in an environment where others are just as committed as you to the success of the company.
They may measure the "success" in terms wildly different from you, the employee, though.
> you want to treat your work as an endeavor, not as a means to a paycheck.
Actually while I might want something more, endeavour doesn't pay rent.
I don't know how else to get the kind of experience you get at a startup. A big company will give you depth, but a startup will give you breadth.
Also, if you ever plan to be a founder yourself, working at a big company might not give you any useful experience at all.
Alternatively, from experience, while big company might not give you valuable experience it can give you some good people to have in your network. Even if its to ask your former company accountant for advice choosing a billing partner.
To add to this. The title of "early member of <insert famous startup company>" holds a lot of weight in SV circles. Whether or not you legitimately helped those companies in the early days, it's a strong signal that you are valuable. And those <insert famous startup company> doesn't have to be a company that necessarily had a huge exit or has a strong economic reputation. For example - early engineer of Yahoo? Ya, people probably think you're worth one's salt.
IMHO - I think this is the main driver people join startups. It's taboo, but vanity feels much more tangible than equity.
Both of these are valid reasons to work at a startup, if you have a family to feed and care for.
Sometimes any job is a good job, even if it's only temporary while you try to find the perfect gig.
Edit to add:
I've been in exactly this position. I took a dev job with a startup I knew was a complete loser, run by scam artists. But I had to put food on the table. Fortunately, I was only there about eight months before I landed a real job with a real company.
The dodgy company imploded, exactly as I expected it to.
The title bump rarely moves your career forwards.
These questions have always guided me well.
You see guys working late at their little startup and maybe thing you should tell them it’s not going to happen. Because honestly for most of them it’s not.
But... I want to make the case that it's OK.
Even if it’s never happening they may be happy. If one stops viewing startups as $$$ opportunities and starts viewing them as rehab from the soulless corporate jobs full of soul-wilting mediocrity, politics, legacy, same old shit over and over, and backstabbing, then it might make a kind of sense to work at a startup instead. Take a pay cut and "try some different shit out" with a tightly-knit team.
It’s a chance to work with things that are greenfield and/or new/different/experiment. Maybe it works. It’s a chance to not be bored. You aren’t wedded to it and don’t need to do it forever. Stay up late and code for awhile. Have pizza. Debug. Try. Care.
The gotcha is if people focus on the IMGONNARICH including the management (where it translates to UNDERMARKETYOURCOMP, though maybe one doesn’t care). That’s poisonous but I think there are lots of options where this isn’t true.
The more people I talk to outside the Bay Area, the more I encounter who I think are doing it right. A lot of them are not crazy, they don’t really think IMGONNARICH. They don’t end up in the FEELINGSWILLBECRUSHED state after it doesn't work (because, honestly, it doesn't).
I like people and being around them. I love the feeling of a team pulling together and exploring the dark corners of a problem. So when a break is in order, the answer might be startup rehab. It's cheaper and better for your career than a full-on year off.
1. I never graduated from university (life came up, and I couldn't afford to keep going); but, also,
2. I don't live in the US (I'm Canadian.)
Any of the US bigcorps that want to hire programmers, expect them to get a visa and move to the US.
You know what you need, to get a work visa as a programmer coming to the US?
A college degree!
So, my employer pool was instantly limited to non-US companies. Mostly local Canadian companies. Most of those are very conservative and also expect a college degree. The only ones that aren't, are startups. So that's what I had to do.
The really annoying thing is, I ended up doing work for these Canadian startups that would netted me a $300k USD salary if I had been doing it for a US bigcorp. But, because Canadian salaries are lower, and startup salaries are lower, I was only getting ~$60k.
After years of doing that, I'm a Canadian startup founder... and still only making (i.e. paying myself) $60k.
I guess I'm an object lesson in the value of a college degree!
As well as the really innefective way we judge talent in the US
Disagree with this one - yes you will need to self-learn, but learning to self-learn is an invaluable tool in itself. You will learn to be extremely non-reliant on other people, and you will probably need to learn about parts of the stack you did not know about before, and fast. You might learn about project management or giving sales pitches. If you are thinking about starting your own company, you will learn a huge amount about how this happens, and what that means (I learned that I didn't want to do it for example!)
I have learned a huge deal from my startup experience, probably double the rate I was learning at the bigger company I was working at before.
Because I would add "chaos" to the list of negatives. The odds are likely you're going to get a C-suite or board that has ADHD-like tendencies, especially when chasing large customers and/or funding rounds.
You will continually be dropping or delaying long-term work for short-term projects to help the company achieve other goals.
At that point, it's just another job. Unless the company is clearly headed for a unicorn IPO, your tiny slice of the company is unlikely to be worth much.
This was me and I paid for it. Right now I'm on week 8 of 30 hour weeks. It sucks.