If everything goes perfectly and the company has created a lot of buzz and momentum, there is interest to buy at a price above what has been printed on the S-1. As the pricing approaches, the company responds to this interest by increasing the price. Then the investors respond to the new price. This cycle repeats two to three times as the date approaches.
So, the price was not based on fundamentals of the business, but rather buzz, hype, and tactics like restricting the number of shares. The common stock price has since risen but it's now running a P/E ratio of 135 (1).
Who is getting the short end of the stick when reality kicks in? Mom and pop investors? Mutual funds and pensions?
Also, what's with the "bootstrap" banner at the top of the page? Grubhub took $84 million in funding (2).
Institutions and mutual funds hold about 50% of the stock. Then with employees, any remaining shares held by venture backers, and traditional insiders it's likely the extreme majority of damage at this point would be to non-Mom & Pop investors.
Sounds like they had a pretty long period of bootstrapping compared to most startups that have gone public. Compare to Facebook which says it was founded Feb 2004 and took it's first round in Sept 2004.
Very interesting and educational read. Even if you know a little bit about how IPOs work, reading through the complete timeline helps understand the roles and the steps involved.
One question that came after reading:
The underwriter won’t move forward unless they get a very
high percentage (99-100%) of employees/shareholders to sign
a lock-up.
What are the incentives for employees to sign such an agreement? It sounds like the only point in the process where an (organized) group of employees could have some leverage?
I'll start by saying I'm not surprised employees get the shaft as I've spent countless hours analyzing the IPO process looking for trading advantages and I still don't fully understand it:(
Quite often the choice of a lockup is out of the companies hands, many states require it. The SEC however doesn't require a lock up, they just recommend it.
I'm guessing most companies include language about this when you join and get your first option grant. They usually don't go around to each employee and get them to sign something before an IPO as their initial grant language often covers this. if they do please let me know:), Actually I take that back, that would probably be insider knowledge, please don't tell me:)
I have very limited experience with this, but when I signed our corporate formation documents, the lockout was written in the restricted stock agreement.
It is likely agreed on before employees every start their first day of work.
Practically, it's really less an incentive than a requirement imposed by the shadow of the future/hypothetical IPO and its future/hypothetical underwriter's strong preference (read: requirement) - even at incorporation when founder's purchase stock (perhaps 10 years before the IPO) they are required to agree to a lock-up for the same reasons as a stockholder who purchases stock one-year before an IPO in a growth-round.
In practice, almost all vc-backed companies with decent attorneys will ALWAYS require a lock-up provision in almost every security issuance documents including: 1. founder stock purchase agreements 2. employee stock option agreements and 3. VC preferred stock purchase agreements.
This shows how much influence the underwriter's ultimately have over the entire IPO process, even 10 years prior and with basically less than 1% chance of actually occurring haha.
The reason for the underwriter's ridiculously strong preference (really requirement) is that if insiders of a company (aka. people who work at the company and therefore (supposedly) have inside knowledge that the market does not have) sell 1% of a company quickly after an IPO, it can introduce a significant amount of volatility to the stock price because the market (almost) always reads an insider's sale of stock as a negative signal - this is why there's always buzz about potential price drops before a lock-up (though at this point it's often priced in well before hand).
The IPO is presumably good for the share price (and indeed the ability to sell the shares at all, even after a 3- or 6-month lockup) - it gives employees with shares the chance to cash out just like any other shareholder. And the importance of your signature on the agreement is directly proportional to how many shares you own.
Say that the initial offering is for 10 million shares at $20 a share. Then the price pops to $30. That $30 share price is based on a much smaller net influx of investment. It does not follow that you could have sold 10 million of shares at that price. The $20 price is a discount that is needed to make the market clear a very large number of shares, all at once. Furthermore, the pop to $30 only happened because retail investors know that the institutions buying into the IPO are reputable, long-haul investors like Fidelity, who will not be dumping the stock immediately. So if you don't have Fidelity and other reputable investors putting in money at $20, you will never get the pop to $30. And because of their size and reputation and relationships, institutions like Fidelity will be able to command discounts, like any big buyer can. The IPO-ing company generally needs Fidelity much more Fidelity needs to buy the company's stock. Thus Fidelity can command the discount.
I don't know about GrubHub in particular, but it is normal to see first day IPO returns of 20% or more. The main reason is monopsony- there are a limited number of institutions that can make significant investments in new IPOs, and they demand a discounted price. Another factor is that there are just a few bulge bracket investment banks to facilitate large IPOs. Their loyalties are more with the repeat players that buy IPOs than the smaller players that sell them.
Note that the founders who sell into an IPO tend to hold onto a lot more stock than they sell, so they're not solely concerned with getting the best price at the IPO. Do you think when FB cratered after the IPO Mark Zuckerberg was smiling because he got a great price for the shares he sold?
Even Google wasn't smart or powerful enough to beat the system. They tried to do an auction instead of a regular IPO, but at the last minute large investors threatened to pull out, so Google IPOed at $85 and popped 17%.
I wrote about it towards the end of the article a little bit.
There are a lot of interests in the IPO. perceiving "leaving money on the table" assumes the most important interest is the company's balance sheet.
Institutional investors would shy away from stock that had no potential upside to it, so getting this price right to attract the right kind of buyers (long term buyers decrease volatility ) but still maximize the cash to the company needs a process to find equilibrium rather than a maximizing strategy.
Ultimately the shareholders benefit more from a positive momentum on the stock rather than optimizing the price at the moment of the IPO
I'd be interested in experiences with what IPO means for internal processes, especially in the software engineering parts of the company.
Any more supervision? Did the way development and deployments work change? I can imagine when you're publicly traded the higher ups might suddenly care much more about being on the safe side of things and try to enforce stricter rules.
I'd be interested in experiences with what IPO means for internal processes, especially in the software engineering parts of the company.
Any more supervision? Did the way development and deployments work change? I can imagine when you're publicly traded the higher ups might suddenly care much more about being on the safe side of things and try to enforce stricter rules.
I was at Yelp during the lead up to the IPO and left about 15 months after the IPO. My title was Director of Systems and I managed two teams: the engineering (production website) portion of operations and a team that did internal/office IT. There was another group, that I believe operated under the CFO, that handled the ERP and accounting systems ("Business Solutions"), I often worked directly with the Director of that team (on a number of projects, not just IPO/SOX related stuff). They were intimately involved with a lot of the stuff leading up to the IPO, and I was brought in to answer engineering org specific aspects (other engineering managers were brought in also, if their teams did anything with money or business/metrics reporting). This is a rough description of my perspective (which is going on three years old now), so YMMV. I'm not going to describe anything that shouldn't be part of a standard audit, though.
SOX is about auditing, reporting, and verifiablity around the financial aspects of the company. They don't care, for example, how the search engine on your website works, or if your iPhone app is using obj-c or swift. But anything that is tangentially related to money or feeds into reports about finance is examined in grave detail. That is, they don't care about your web server logs, unless those web server logs are used for billing purposes (or verifying billing). They do care who can access the data, who can change data, what audit logs are available/collected when accessing the data, what the backups look like, how much of the process is automated. Standard due-diligence stuff.
That being said, questions are asked about everything, and anything that isn't documented needs to be. Eventually, the focus gets more specific as they whittle down which areas are finance related and they need to concentrate on. And then someone reviews it and asks more questions. For months. The firm that does the auditing had a team holed up in a conference room for weeks at a time. People who are, for lack of a better term, "document experts" come in, hand-hold you, and ask you to fill in the details on a somewhat "off the shelf" document that describes an extremely generic process that it is assumed everyone and their dog's software company does. You have to document your actual processes, not necessarily implement things exactly as (implicitly) prescribed.
This part was especially arduous, because the finance auditing industry doesn't seem to be fully exposed to/aware of modern tools that we take for granted. Like git (which provides above and beyond the level of auditing and historical change management that SOX seems to require, all searchable and reportable immediately). Or automated deployment (necessary with any group of engineers beyond a handful, as we all know). Or testing. Or SSH key based authentication (I swear, I thought I was going to have to explain the math behind public key cryptography at one point). Or aggregated system logs. Or isolated reporting/auditing/monitoring systems. Or doing multiple code deployments per day. Having this stuff should be bog standard at any software company in the Valley of any decent size. Or maybe it just seems like they aren't aware of it because of the level of detail and repetition of the questions and they're just making sure you know it and have it documented to the nines.
On a number of occasions I was asked to provide a report of all the changes made to a certain part of the code base (they pretty much looked at a directory listing, handpicked anything that indicated finance related code based on file names or what someone said a part of the code did). I said I'd have that within an hour. I spent most of the time reading the git-log(1) man page to figure out how to format what they wanted in a way they could load it into Excel. They didn't believe it could be turned around so fast, I think they were expecting boxes of paperwork would have to be gone through to find who wrote what code when and who approved it for deployment, and who else looked at it to verify it. All this was available via git-log, some deployment system logs, git-tags and the output of the automated testing system. Then they'd interview the members of engineering who appeared in these reports to talk about their aspects of the code.
Once the initial phases where the fresh-out-of-school discovery and paper-collector people have done their job, it was mainly a lot of, what amounted to, casual conversations. Periodically I'd end up talking to someone who had dealt with tech companies before, so automated testing and source control wouldn't need to be explained (again).
There weren't that many changes we had to do, at least engineering-wise, I think because we already had a pretty solid system in place. If Best Practices are your SOP, then I don't think it ends up being that intrusive. One thing that is different is that you gain the ability to say "We do this for SOX compliance".
As for if there was any more supervision, I think it was valuable because it exposed our (engineering) processes to a wider (internal) audience; just meeting with the auditors about your area you get to see the level of detail required for something traditionally considered mundane. You may consider that report you're generating to be a one-off, but it turns out some higher ups look at it and it really needs to be fully productionized and documented. There was an intent to make the IPO and auditing processes not disrupt the engineering org as a whole. We had to be more explicit around who was allowed to change certain parts of the code and who needed to review and approve certain changes going out. I say "be more explicit" because we were already doing like 95% of that ("yes, the project manager and tech manager approves and schedules that set of changes", "yes, only this set of people have access to that sensitive system", "yes, the accounts of all exited employees have been disabled"). I think there were maybe a handful of cases where research need to be done to find out how something happened, and what we were doing was sufficient already and it was just a matter of documenting it and shoring it up. I was sure to include the method (scripts, command lines, ldapsearch strings) I used to generate any reports they asked for (like lists of employees, list of engineers, list of engineering managers, Active Directory accounts, git logs), so during later audits they could just say "run this series of commands you ran last time". This came in handy during the entire process.
There are periodic audits after the fact that verify that you're actually performing the processes as they are documented. This may be the hardest thing to get used to, since it may mean you have to be less agile and can't refactor your processes as easily as you could before. But usually you want to change finance related things slowly, if at all, so this shouldn't be that big of deal. I think a lot of the changes had already occurred on the way to becoming "a big company", in the years leading up to the IPO.
If your company goes public and you have valuable equity but face a lockup of 6 months you can still "lock in" some price...if your company gets publicly traded options that is.
Sell calls at the price you want to sell for the month that the lockup expires. If your shares get called away you got the price you wanted and some premium. However, you miss out on a huge gain if it goes far beyond your call level. Also, if the stock tanks in that time you keep your now less valuable shares but you got some premium.
So, after selling calls you can take that money you made from the premium and buy puts with it at around the same price. You've created a spread here and have locked in a selling price and gave yourself some downside insurance - all for very little cost to you over all since the covered call premium paid for most, if not all of your puts. Your only risk now is that the stock goes through the roof and you miss out on some upside - but that makes sense as you've eliminated risk for very little out of pocket cost. So maybe you do this on 1/2 or 2/3 of your position or whatever you're comfortable with.
Of course the difficulty is if you have a ton of stock and the option market for your company isn't very large and therefore illiquid.
This is typically not the case. The lock-up specifically prohibits trading options, pledging shares as collateral for debt, selling shares, or gifting shares to charities. It also usually a catch all for benefiting directly or indirectly (through a trust or foundation)
Source: I founded GrubHub and wrote the article referenced here.
1) Options don't start trading until well after the stock has gone public, usually atleast 3 months so you can't use this method to hedge out of the IPO gate. This is an exchange issue, not a liquidity issue.
2) So, after selling calls you can take that money you made from the premium and buy puts with it at around the same price.
Put call parity assures you that you won't make enough selling calls to buy puts at around the same price. ie you'll need to put some of your own money into this. I think the author did a good job of indicating this but it should be made clear to people before tyring to do this.
To be clear, following this strategy it helps lock in a price lower than the current market price for your shares, so you know what you'll make if the stock goes down.
However it also means that if the stock takes off you won't get any of the upside. Keep that in mind as it can be very hard psychologically to watch everyone else around you make money while you've capped your upside.
The company and investment banker make you sign a contract saying that you will not buy or sell any derivatives or options or any security based on the stock. Now they probably couldn't catch you, and I'm not exactly sure what happens if you refuse to sign the contract, but it is also not necessarily worth the legal risk to attempt your proposed strategy.
ilamont|11 years ago
So, the price was not based on fundamentals of the business, but rather buzz, hype, and tactics like restricting the number of shares. The common stock price has since risen but it's now running a P/E ratio of 135 (1).
Who is getting the short end of the stick when reality kicks in? Mom and pop investors? Mutual funds and pensions?
Also, what's with the "bootstrap" banner at the top of the page? Grubhub took $84 million in funding (2).
1. http://research.investors.com/quotes/nyse-grubhub-inc-grub.h...
2. https://www.crunchbase.com/organization/grubhub
adventured|11 years ago
gaadd33|11 years ago
Founded: 2004
Series A: Nov 1, 2007
Sounds like they had a pretty long period of bootstrapping compared to most startups that have gone public. Compare to Facebook which says it was founded Feb 2004 and took it's first round in Sept 2004.
psuter|11 years ago
One question that came after reading:
What are the incentives for employees to sign such an agreement? It sounds like the only point in the process where an (organized) group of employees could have some leverage?chollida1|11 years ago
Quite often the choice of a lockup is out of the companies hands, many states require it. The SEC however doesn't require a lock up, they just recommend it.
http://www.sec.gov/answers/lockup.htm
http://www.sec.gov/answers/bluesky.htm
I'm guessing most companies include language about this when you join and get your first option grant. They usually don't go around to each employee and get them to sign something before an IPO as their initial grant language often covers this. if they do please let me know:), Actually I take that back, that would probably be insider knowledge, please don't tell me:)
Rule 7-G http://www.law.cornell.edu/cfr/text/17/230.701 covers this if you feel like reading some really dry material:)
It is possible for the company to file an S-8 registration form to allow some shares to be sold but many companies don't file this form.
Here is a good paper on analyzing the trading of locked up shares.
http://pages.stern.nyu.edu/~eofek/PhD/papers/FH_The_JF.pdf
wtvanhest|11 years ago
It is likely agreed on before employees every start their first day of work.
joshjkim|11 years ago
In practice, almost all vc-backed companies with decent attorneys will ALWAYS require a lock-up provision in almost every security issuance documents including: 1. founder stock purchase agreements 2. employee stock option agreements and 3. VC preferred stock purchase agreements.
This shows how much influence the underwriter's ultimately have over the entire IPO process, even 10 years prior and with basically less than 1% chance of actually occurring haha.
The reason for the underwriter's ridiculously strong preference (really requirement) is that if insiders of a company (aka. people who work at the company and therefore (supposedly) have inside knowledge that the market does not have) sell 1% of a company quickly after an IPO, it can introduce a significant amount of volatility to the stock price because the market (almost) always reads an insider's sale of stock as a negative signal - this is why there's always buzz about potential price drops before a lock-up (though at this point it's often priced in well before hand).
lmm|11 years ago
jackgavigan|11 years ago
bokonist|11 years ago
Say that the initial offering is for 10 million shares at $20 a share. Then the price pops to $30. That $30 share price is based on a much smaller net influx of investment. It does not follow that you could have sold 10 million of shares at that price. The $20 price is a discount that is needed to make the market clear a very large number of shares, all at once. Furthermore, the pop to $30 only happened because retail investors know that the institutions buying into the IPO are reputable, long-haul investors like Fidelity, who will not be dumping the stock immediately. So if you don't have Fidelity and other reputable investors putting in money at $20, you will never get the pop to $30. And because of their size and reputation and relationships, institutions like Fidelity will be able to command discounts, like any big buyer can. The IPO-ing company generally needs Fidelity much more Fidelity needs to buy the company's stock. Thus Fidelity can command the discount.
yellowstuff|11 years ago
Note that the founders who sell into an IPO tend to hold onto a lot more stock than they sell, so they're not solely concerned with getting the best price at the IPO. Do you think when FB cratered after the IPO Mark Zuckerberg was smiling because he got a great price for the shares he sold?
Even Google wasn't smart or powerful enough to beat the system. They tried to do an auction instead of a regular IPO, but at the last minute large investors threatened to pull out, so Google IPOed at $85 and popped 17%.
m_evans|11 years ago
There are a lot of interests in the IPO. perceiving "leaving money on the table" assumes the most important interest is the company's balance sheet.
Institutional investors would shy away from stock that had no potential upside to it, so getting this price right to attract the right kind of buyers (long term buyers decrease volatility ) but still maximize the cash to the company needs a process to find equilibrium rather than a maximizing strategy.
Ultimately the shareholders benefit more from a positive momentum on the stock rather than optimizing the price at the moment of the IPO
ShellfishMeme|11 years ago
Any more supervision? Did the way development and deployments work change? I can imagine when you're publicly traded the higher ups might suddenly care much more about being on the safe side of things and try to enforce stricter rules.
patja|11 years ago
thwarted|11 years ago
Any more supervision? Did the way development and deployments work change? I can imagine when you're publicly traded the higher ups might suddenly care much more about being on the safe side of things and try to enforce stricter rules.
I was at Yelp during the lead up to the IPO and left about 15 months after the IPO. My title was Director of Systems and I managed two teams: the engineering (production website) portion of operations and a team that did internal/office IT. There was another group, that I believe operated under the CFO, that handled the ERP and accounting systems ("Business Solutions"), I often worked directly with the Director of that team (on a number of projects, not just IPO/SOX related stuff). They were intimately involved with a lot of the stuff leading up to the IPO, and I was brought in to answer engineering org specific aspects (other engineering managers were brought in also, if their teams did anything with money or business/metrics reporting). This is a rough description of my perspective (which is going on three years old now), so YMMV. I'm not going to describe anything that shouldn't be part of a standard audit, though.
SOX is about auditing, reporting, and verifiablity around the financial aspects of the company. They don't care, for example, how the search engine on your website works, or if your iPhone app is using obj-c or swift. But anything that is tangentially related to money or feeds into reports about finance is examined in grave detail. That is, they don't care about your web server logs, unless those web server logs are used for billing purposes (or verifying billing). They do care who can access the data, who can change data, what audit logs are available/collected when accessing the data, what the backups look like, how much of the process is automated. Standard due-diligence stuff.
That being said, questions are asked about everything, and anything that isn't documented needs to be. Eventually, the focus gets more specific as they whittle down which areas are finance related and they need to concentrate on. And then someone reviews it and asks more questions. For months. The firm that does the auditing had a team holed up in a conference room for weeks at a time. People who are, for lack of a better term, "document experts" come in, hand-hold you, and ask you to fill in the details on a somewhat "off the shelf" document that describes an extremely generic process that it is assumed everyone and their dog's software company does. You have to document your actual processes, not necessarily implement things exactly as (implicitly) prescribed.
This part was especially arduous, because the finance auditing industry doesn't seem to be fully exposed to/aware of modern tools that we take for granted. Like git (which provides above and beyond the level of auditing and historical change management that SOX seems to require, all searchable and reportable immediately). Or automated deployment (necessary with any group of engineers beyond a handful, as we all know). Or testing. Or SSH key based authentication (I swear, I thought I was going to have to explain the math behind public key cryptography at one point). Or aggregated system logs. Or isolated reporting/auditing/monitoring systems. Or doing multiple code deployments per day. Having this stuff should be bog standard at any software company in the Valley of any decent size. Or maybe it just seems like they aren't aware of it because of the level of detail and repetition of the questions and they're just making sure you know it and have it documented to the nines.
On a number of occasions I was asked to provide a report of all the changes made to a certain part of the code base (they pretty much looked at a directory listing, handpicked anything that indicated finance related code based on file names or what someone said a part of the code did). I said I'd have that within an hour. I spent most of the time reading the git-log(1) man page to figure out how to format what they wanted in a way they could load it into Excel. They didn't believe it could be turned around so fast, I think they were expecting boxes of paperwork would have to be gone through to find who wrote what code when and who approved it for deployment, and who else looked at it to verify it. All this was available via git-log, some deployment system logs, git-tags and the output of the automated testing system. Then they'd interview the members of engineering who appeared in these reports to talk about their aspects of the code.
Once the initial phases where the fresh-out-of-school discovery and paper-collector people have done their job, it was mainly a lot of, what amounted to, casual conversations. Periodically I'd end up talking to someone who had dealt with tech companies before, so automated testing and source control wouldn't need to be explained (again).
There weren't that many changes we had to do, at least engineering-wise, I think because we already had a pretty solid system in place. If Best Practices are your SOP, then I don't think it ends up being that intrusive. One thing that is different is that you gain the ability to say "We do this for SOX compliance".
As for if there was any more supervision, I think it was valuable because it exposed our (engineering) processes to a wider (internal) audience; just meeting with the auditors about your area you get to see the level of detail required for something traditionally considered mundane. You may consider that report you're generating to be a one-off, but it turns out some higher ups look at it and it really needs to be fully productionized and documented. There was an intent to make the IPO and auditing processes not disrupt the engineering org as a whole. We had to be more explicit around who was allowed to change certain parts of the code and who needed to review and approve certain changes going out. I say "be more explicit" because we were already doing like 95% of that ("yes, the project manager and tech manager approves and schedules that set of changes", "yes, only this set of people have access to that sensitive system", "yes, the accounts of all exited employees have been disabled"). I think there were maybe a handful of cases where research need to be done to find out how something happened, and what we were doing was sufficient already and it was just a matter of documenting it and shoring it up. I was sure to include the method (scripts, command lines, ldapsearch strings) I used to generate any reports they asked for (like lists of employees, list of engineers, list of engineering managers, Active Directory accounts, git logs), so during later audits they could just say "run this series of commands you ran last time". This came in handy during the entire process.
There are periodic audits after the fact that verify that you're actually performing the processes as they are documented. This may be the hardest thing to get used to, since it may mean you have to be less agile and can't refactor your processes as easily as you could before. But usually you want to change finance related things slowly, if at all, so this shouldn't be that big of deal. I think a lot of the changes had already occurred on the way to becoming "a big company", in the years leading up to the IPO.
ProAm|11 years ago
nemo44x|11 years ago
Sell calls at the price you want to sell for the month that the lockup expires. If your shares get called away you got the price you wanted and some premium. However, you miss out on a huge gain if it goes far beyond your call level. Also, if the stock tanks in that time you keep your now less valuable shares but you got some premium.
So, after selling calls you can take that money you made from the premium and buy puts with it at around the same price. You've created a spread here and have locked in a selling price and gave yourself some downside insurance - all for very little cost to you over all since the covered call premium paid for most, if not all of your puts. Your only risk now is that the stock goes through the roof and you miss out on some upside - but that makes sense as you've eliminated risk for very little out of pocket cost. So maybe you do this on 1/2 or 2/3 of your position or whatever you're comfortable with.
Of course the difficulty is if you have a ton of stock and the option market for your company isn't very large and therefore illiquid.
m_evans|11 years ago
Source: I founded GrubHub and wrote the article referenced here.
chollida1|11 years ago
1) Options don't start trading until well after the stock has gone public, usually atleast 3 months so you can't use this method to hedge out of the IPO gate. This is an exchange issue, not a liquidity issue.
2) So, after selling calls you can take that money you made from the premium and buy puts with it at around the same price.
Put call parity assures you that you won't make enough selling calls to buy puts at around the same price. ie you'll need to put some of your own money into this. I think the author did a good job of indicating this but it should be made clear to people before tyring to do this.
To be clear, following this strategy it helps lock in a price lower than the current market price for your shares, so you know what you'll make if the stock goes down.
However it also means that if the stock takes off you won't get any of the upside. Keep that in mind as it can be very hard psychologically to watch everyone else around you make money while you've capped your upside.
bokonist|11 years ago
unknown|11 years ago
[deleted]
knivets|11 years ago
Owenzy|11 years ago
mmonihan|11 years ago