The article mentions needing to sign some paperwork about equity in passing, but I think being asked to sign new paperwork (a new IP agreement, etc.) is a sign all on its own. Like the focus on security, it is suspicious if it happens without any other motivating reason.
One should be careful not to confuse an unknown reason with the non-existence of a reason. One of my prior companies suddenly became a target for digital espionage and I only knew about it happening at all because I worked closely with our security team. Others in the company had no idea except that security policies were suddenly changing.
If the other employees had no idea then upper management did a terrible job. It's their role to communicate such events and strategies to face them so as to get the loyalty and the trust of everyone.
These all seem accurate and I'd add even moreso than security (which can be prioritized for other reasons) a focus on buttoning up open source licensing / IP ownership is a dead giveaway that a sale is close. Also the hiring and retention thing is probably less about distraction and more about not taking on additional expenses in the middle of due diligence - generally the acquirer will want to have more of a say in staffing strategy.
I don't actually know what "buttoning up open source licensing / IP ownership" means. Is that making sure you have a license for all software you're using?
You make sure that employees don't own what they write, but sign it over to the company (usually language to that effect in the employment contract, if there is none).
Also running tools like Black Duck over your source code tree to check open source license types or use of unlicensed code snippets from the Web.
NDAs can be given to people who know how something is done, knowledge that they could use to re-create the product or service elsewhere, which the acquired does not want. In some cases (that I have not personally seen) making people sign non-compete agreements, meaning if they quit they cannot work on the same thing for some time (not legal everywhere).
If "BigCorp" buys "CoolIdea" for their nifty piece of software "SecretSauce" they do not want to find out later that "BigCorp"/"CoolIdea" is required to publish source code for "SecretSauce" because it's based on "GNUOpenSauce" or that "CoolIdea" was selling something based on "FSFSauce."
Big companies are very allergic to GPL-like copyleft licenses. You generally have to go over the entire dependency tree with a fine tooth comb and make sure that nothing is going to get you sued to released the source code (inside a big company there are processes to ensure this on an ongoing basis)
They're still accessible by inspect and hash (maybe start with "docker history".) You may find it easier to use that to get enough info to build your own images from scratch, so you have control of what's going in (since you already have responsibility.) "mmdebstrap | docker import" gets you surprisingly far.
It’s not a problem per-se. You just have to document them and their license. Whether you actually have to do that is another question since most believe that that would fall on the base image publisher, not the final image. Further, a proper base image will already include licenses in the base image because most OSS licenses require distributing the software with the license available.
The only thing you would have to document are the things you specifically added.
Debian based distros (and all the others) have a command to run and get the sources for ALL open source packages installed on the system. So, there is nothing to do there. apt get source package.
If someone asks for source code for a library, simple point them to the GitHub repository. This isn’t rocket science and it isn’t worth automating because practically nobody asks for it.
For packages being installed from distributions like Debian, you are correct that doing "apt-get source $pkg=$version" will download the source, so you can do it for every package in the image that you are distributing. On the other hand, if you are using Alpine as a base, things are not so easy..
For GPL-licensed code, you should provide the sources yourself. "Point them to a GitHub repository" is not acceptable, since the repo might disappear or change contents without you noticing.
And it is definitely worth automating, if you are releasing at scale (either many products or many versions). Otherwise you will be left having to handle requests like "does anyone remember the exact contents of our product X, of version of 2023-03-03?"
That is specific to the language, but neither Python nor JavaScript is a compiled language, so for the most part, those sources are already distributed. Some of those packages also contain binaries, so it can get dicey. Some may even have an incompatible license, so you have to be careful.
At a big company, we (as in the team) had to review any and every library and its dependencies before we could use it, then the security team had to review it. The amount of shit code out there is outstanding; many times we would just reimplement it ourselves, unless the library did something substantial that we didn’t want to maintain. (This is also why zero-dependency libraries are a thing)
> Otherwise you will be left having to handle requests like "does anyone remember the exact contents of our product X, of version of 2023-03-03?"
Generally, this can be solved by simply vendoring your dependencies (aka, commit them to the repository instead of fetching them for every build).
> For GPL-licensed code, you should provide the sources yourself.
Version 3 of the GPL simply states that "clear directions" on how to find the source code may be given. There's no requirement for you to distribute those sources yourself unless you make modifications and make the software available for sale or download. Internal use/private modifications do not need to be given away.
> it is definitely worth automating
I worked at a company that dealt in nothing but commercially licensed open source code. That meant we were much more likely to get requests for our source code because it was obvious we were running heavily modified open source software. That being said, despite having millions of users, we only got a few requests a month and we still didn't bother automating it.
So, I'm not convinced it is worth automating unless you are in the hundreds of millions of users range.
this is how I guessed we were being acquired - a request to compile a list of the licenses of the dependencies of our mobile app, out of the blue and without further explanation
One sign that wasn't mentioned is the sudden exodus of higher team/product managers. I've seen this happen twice in my career. Suddenly, the individuals who were once fully committed to the company are leaving to "look for greener pastures." Sometimes, they hold meetings with everyone and their behavior is odd – often, these meetings are pointless and a huge waste of everyone's time, much like meeting with an ex.
Depending on the acquisition, I think. When my former US company was acquired by a huge Chinese company, it was not clear if my service would be part of the deal too. A lot of higher managers escaped the ship just weeks before they announced that it would be sold to another huge Indian company.
I still don't quite get the downside of staying around and seeing what happens. Were they so sure their role would be impacted for the worse? Were they already having conflicts with their management over the sale's consequences?
- everyone gets rich (including employees with equity)
- founders and investors get rich, nobody else gets shit
- investors get good return, founders get a bit, nobody else gets shit
- investors make mediocre return based on liquidation pref, nobody else gets shit
- nobody gets shit (but people keep their jobs in the acquirer)
In all but the first situation, you as an employee (even a high-up one) are basically being sold to another company without any upside, and whether or not you want to stay will depend 100% what you think about the acquirer.
> So the acquirer will offer some golden handcuffs, usually some stock options with delayed vesting to motivate the acquired to stay.
Sometimes. Sometimes they're weirdly incompetent, treat everyone like shit, and then act surprised when half of the company leaves. Sometimes after that they'll offer a promise of a pittance bonus, and act surprised once again when yet another half of the company leaves after the meager bonus comes through.
There are always signs, and they are easy to rationalise in hind-sight.
The danger is that there are signs for lots of things, so jumping to conclusions regarding the reason can be dangerous.
For example, we recently got a contract with a company fanatical about security. They wanted additional special insurances, which in turn wanted additional company-wide security policies.
This affected everyone, even though the potential contract only affected 3 employees. (And there was an NDA regarding the possibility of a deal.) The policy changes (despite being good policy anyway) likely caused some anguish.
So by all means speculate away, staff love a good rumor, and in the absence of information will speculate anything and everything. But I caution against making big life choices based on that speculation.
That security point stood out to me as well. First of all, who intentionally writes code to contain SQL injection vulnerabilities anno 2024? Or knows about it and doesn't fix it? Is it really that weird that someone fixes it?
The SQL example relates to an acquisition that happened in 2013, and states that the vulnerabilities have been around for some time. The early 2010s have really been a different time in that regard.
Our product undergoes CVE scans before every release, and we ensure that all relevant CVEs are handled before we release; if a CVE is low-severity and isn't relevant to our use of the component (e.g. an information disclosure vulnerability in SASL authentication, but we don't use the library for authentication) then we make a note of that for our customers so they know that, while this CVE does exist and may show up in their own scans, it's not relevant to their use of our product.
That said, we now have some customers who have extremely stringent security requirements, and for understandable reasons. They want every CVE resolved for every release; this is going to cause a notable amount of work to 'resolve' issues which aren't issues by taking developer time to update and test third-party libraries, or even patch the libraries ourselves if the upstream CVE hasn't been resolved yet.
It's unquestionably worth doing if this is a dealbreaker for our customers, but could definitely impact things in the short term by requiring fixes which are technically unnecessary.
> First of all, who intentionally writes code to contain SQL injection vulnerabilities anno 2024?
here's some ways it could happen:
- startup doesn't have ability to hire competent, experienced developers. they end up with rookies with potential but not enough experience to avoid security foot-guns, and/or experienced expert-beginner developers who have a low level of ability
- leadership doesn't value quality or security, so the company culture reflects this and focuses on what leadership values
- startup outsources development work and has no in-house technical capability to check quality or security of deliverables
- startup is pre product-market fit in a domain where security is less relevant, and security issues are less of a risk to the business than the more existential concern around identifying and de-risking a scalable, profitable business model. then suddenly the throwaway proof of concept codebase for the 7th pivot starts getting traction, and by shovelling features on top it is possible to win more customers
It seems unwise to make life choices based on even the sure fact that your employer is in acquisition talks? Probably even if you are a founder personally carrying out acquisition talks?
I guess the exception might be the decision to wait a couple of months before making some other decision!
Some of this could be from a funding round too. I had to actually sign my NDA when people were crossing Is and dotting Ts before closing a round. I had had some printer issues around hiring and hadn't signed it, and nobody followed up until someone wanted to be sure everyone was under NDA.
Also, the morning of a big announcement, my boss asked me "can the blog handle heavy load?" and I was like "yeah sure, but nobody reads the blog", "they will, can we make it like a static page or something?" ... So, like ok, whatever, stupid thing to ask for, but it's easy. Got that going, and also we had a meeting added, no agenda. And one of my coworkers was convinced something was going on, he said people had been in the office all weekend.
That’s what I felt, and the points about extremely preoccupied execs and sudden interest in buttoning down security were big components of our lead-up to series A.
I had a nearly same experience with you when my company was acquired by Tencent. Most of employees don't know what's going on, but there are some strangers around in the office, actually another separate office. Only HR and finance people deal with those people from acquirer, they reviewed company contracts and some other legal paperworks. I saw there are lots of paper in their dedicated office. We engineers are the last one knows.
My supervisor called me to a meeting room, he let me first sign a non-disclosure agreement, or he can't tell me nothing. I had to sign that paper. Then he told me that the company was acquired, and you have choice to either leave or work for Tencent. If you want work for Tencent, you had to go over their interview and only talented people will get offer.
But actually 95% of my colleagues get offer, including me.
I think in a situation like this the outcome is pretty obvious. There's always people let go in an acquisition and if you don't sign the paperwork it just puts you closer to that group than to the other.
Have been acquired/acquihired a few times. Universal. Some holding company you've never heard of but probably have spent quality alone time on their primary website. Activision. General Electric. Accenture.
The distractedness of the executives is spot on. But it always seems to be in hindsight that we look back and go "huh, funny..." I am sure we could write an inference bot that monitors the calendars of people in the organization and estimates that an acquisition is imminent.
And the security/bug fixing. "Yeah, that bug has been there for three years, nobody has time to fix it." Well, all of a sudden, we are fixing it. And more besides. And the licensing of software and source code. Getting a full run down of every open source license, and I mean _every_ license, and then going back and checking them again. A sudden drive to document everything.
I've also seen the ugly side of acquisition too. An equity claw back that happened to me many years ago that I am still sore about. Sudden acceleration of equity grants and a "re-interpretation of what 'it' means" or extreme scrutiny of whether you actually qualify for the equity in your contract. I've seen a few good people suddenly not get anything because there was a missing signature on a document even though the person had been at the company three years.
Large amounts of acquisition money does strange things to people.
The author mentions a bunch of signs, but he misses the most important one in my opinion. There is really one sign that is the telltale sign of all signs with a much higher degree of accuracy than any of the author's mentioned signs. One person is the indicator. It's not the CEO. It is the CFO. Why? When an acquisition is about the happen, the CFO is sent scrambling to ask the founders, accounting, lawyers, and all others involved for many pieces of information about the company's financials. The acquiring company is doing due diligence during this period and needs this information from the company being acquired. The CFO gets put into a mad scurry and a fire is lit under his ass to get everything done on time, accurately. If you see your CFO is more anxious and much busier than usual, asking everyone who has information for information, there is usually something going on.
In a very small company, they will just frame it as a "collaboration". You will have a meeting with an external party to showcase your projects. But not the other way around.
General cost cutting without any other visible reasons. Cut backs on travel, social budgets, contractors, any other expenses that can be trimmed to make the financials look sexier.
Departments like Finance, Legal, Risk/Compliance and HR are overworked and distracted. These people, at least some of them, get involved after the execs but before everyone else. As someone else said this can start with the CFO but it'll spread to whole teams of paralegals and accountants before you are told about it.
Speaking of HR, do they suddenly want everyone to sign contract addendums or "compliance papers" or whatever? Asking you to fill out a "skills inventory"? Everyone got to get background checks?
Sales teams rushing to finish deals (to sexy up financials) and clear their comp (before the new boss brings new rules). I guess this isn't really that different from BAU.
As has been pointed out these things can all have other causes. But all together, all at the same time, without any stated reason....
Unfortunately ICs are often the least plugged in politically and end up the last to know. The compensation is being retained, unlike everyone else above who heard it through the grapevine before you.
I've experienced startup acquisition as an executive and as an employee. Unusual travel is spot on. Our CEO was a frequent traveler, but the rest of the exec team rarely traveled. When 5 of us were all traveling to the Bay Area at the same time, the cat was pretty much out of the bag.
You should do the same thing you should always be doing as long as you’re struggling with your addiction to food and shelter and you need to work to support your addiction - be prepared to look for another job.
Facts on the ground are always subject to change and you should be prepared:
1. Keep an up to date career document where you list all of your accomplishments in STAR format
2. Keep an up to date resume
3. Keep your skill set aligned with the market
4. Keep a strong and active network and guard your reputation
5. Don’t be a “ticket taker”. Be able to talk about initiatives you have led
6. Live below your means and have a 3-6 months emergency fund
7. Even though I haven’t and haven’t found a need to. “Grind leetcode” (tm r/cscareerquestions).
There has never been a day that I haven’t been ready to change jobs at a moments notice since 2008 (I’ve worked longer). This is true whether I was working for a startup or working at $BigTech and everything in between.
> A few days before the Twitter deal was announced, the CEO of MoPub summoned a bunch of us to the office on a Sunday. Nothing like that had ever happened before. At the meeting, he told us about the acquisition (this was when I learned!) and explained that he needed us to sign some paperwork about our equity before the agreement could be finalized.
This sounds dodgy as fuck! If this ever happens to you, please don't sign the paperwork without running it past a lawyer. It's definitely not there to grant you more rights.
If you own equity hopefully they'd have told you about the acquisition beforehand as a shareholder! But that said it's not unusual to have to do paperwork, for example you can have "offer of first refusal" on the sale of shares which gives you the right to buy the shares being offered for sale, over the person making the current offer, so companies will get people to sign a contract waiving that right as part of the sale process. Sometimes you'll be transferring shares from the old company to shares in the acquiring company and so on. Those latter things you should run past a lawyer anyway!
Right, and if they call you in on a Sunday completely blindsided "just to sign some papers" you may regret waiving your right to buy the shares - a right that the acquirer, at least, seems to value. You shouldn't be signing it without an attempt to figure out what that right is worth.
> Moreover, it’s a little awkward to be selling candidates on your cool, fast-moving startup when you know that you’re about to gobbled up by a larger company.
Anecdotally, plenty of companies are still running their hiring pipeline even when someone - including HR - knows that they're about to be acquired, and nearly everyone who doesn't have a signed offer in hand (and sometimes, not even them) is going to be either completely ghosted, or get apologetic letters from a different company's HR department.
I've seen this as an exec and an employee. In addition to things others have noted, I've seen:
- Unusual visitors to the office (or even having visitors at all!)
- Sudden shifts in roadmap priorities
- Sudden changes in interest or emphasis on reliability
> Be on the lookout for the signs discussed above, as well as other, unusual activity, which could mean something big is about to happen!
While it can be fun to fantasize about what every little oddity means, I’d recommend against making this a priority in your daily life. If you find yourself that distracted from your work, it’s a good time to dust off your resume anyway, regardless of if M&A forces you to.
At a company I worked at the CEO out of the blue called for an all hands, all offices meeting with a few days notice. Everybody who wasn't in the main office had to connect via video link. This had as far as anyone could remember never happened before. There was no agenda and no hints as to what the meeting was about. Even senior managers knew nothing. So obviously rumours started flying, people get nervous, and everybody started looking over their CVs and contingency plans.
Meeting day comes and the CEO proudly announces that the company is getting a brand new logo...
Do you really need a sign? If you are working for a non public company or even if you are working for a public tech company that is not one of the top 10 tech companies, you are always an acquisition target.
And even if you are at a company that realistically won’t be acquired, you should always be prepared to look for a job at a moment’s notice.
84 comments
[ 1.9 ms ] story [ 158 ms ] thread(I was a CISO. I absolutely would have told the company afterward so that they knew what happened and what to watch out for next time.)
Always, always. If it’s legit, the CEO will ask you to do that and then get back ASAP. Anyone who objects to you doing this is trying to screw you.
Also running tools like Black Duck over your source code tree to check open source license types or use of unlicensed code snippets from the Web.
NDAs can be given to people who know how something is done, knowledge that they could use to re-create the product or service elsewhere, which the acquired does not want. In some cases (that I have not personally seen) making people sign non-compete agreements, meaning if they quit they cannot work on the same thing for some time (not legal everywhere).
The only thing you would have to document are the things you specifically added.
At least, that’s been my experience.
If someone asks for source code for a library, simple point them to the GitHub repository. This isn’t rocket science and it isn’t worth automating because practically nobody asks for it.
For GPL-licensed code, you should provide the sources yourself. "Point them to a GitHub repository" is not acceptable, since the repo might disappear or change contents without you noticing.
And it is definitely worth automating, if you are releasing at scale (either many products or many versions). Otherwise you will be left having to handle requests like "does anyone remember the exact contents of our product X, of version of 2023-03-03?"
At a big company, we (as in the team) had to review any and every library and its dependencies before we could use it, then the security team had to review it. The amount of shit code out there is outstanding; many times we would just reimplement it ourselves, unless the library did something substantial that we didn’t want to maintain. (This is also why zero-dependency libraries are a thing)
Generally, this can be solved by simply vendoring your dependencies (aka, commit them to the repository instead of fetching them for every build).
> For GPL-licensed code, you should provide the sources yourself.
Version 3 of the GPL simply states that "clear directions" on how to find the source code may be given. There's no requirement for you to distribute those sources yourself unless you make modifications and make the software available for sale or download. Internal use/private modifications do not need to be given away.
> it is definitely worth automating
I worked at a company that dealt in nothing but commercially licensed open source code. That meant we were much more likely to get requests for our source code because it was obvious we were running heavily modified open source software. That being said, despite having millions of users, we only got a few requests a month and we still didn't bother automating it.
So, I'm not convinced it is worth automating unless you are in the hundreds of millions of users range.
- everyone gets rich (including employees with equity)
- founders and investors get rich, nobody else gets shit
- investors get good return, founders get a bit, nobody else gets shit
- investors make mediocre return based on liquidation pref, nobody else gets shit
- nobody gets shit (but people keep their jobs in the acquirer)
In all but the first situation, you as an employee (even a high-up one) are basically being sold to another company without any upside, and whether or not you want to stay will depend 100% what you think about the acquirer.
So the acquirer will offer some golden handcuffs, usually some stock options with delayed vesting to motivate the acquired to stay.
Sometimes. Sometimes they're weirdly incompetent, treat everyone like shit, and then act surprised when half of the company leaves. Sometimes after that they'll offer a promise of a pittance bonus, and act surprised once again when yet another half of the company leaves after the meager bonus comes through.
Honestly that seems to be the norm in my, admittedly limited, experience.
The danger is that there are signs for lots of things, so jumping to conclusions regarding the reason can be dangerous.
For example, we recently got a contract with a company fanatical about security. They wanted additional special insurances, which in turn wanted additional company-wide security policies.
This affected everyone, even though the potential contract only affected 3 employees. (And there was an NDA regarding the possibility of a deal.) The policy changes (despite being good policy anyway) likely caused some anguish.
So by all means speculate away, staff love a good rumor, and in the absence of information will speculate anything and everything. But I caution against making big life choices based on that speculation.
That said, we now have some customers who have extremely stringent security requirements, and for understandable reasons. They want every CVE resolved for every release; this is going to cause a notable amount of work to 'resolve' issues which aren't issues by taking developer time to update and test third-party libraries, or even patch the libraries ourselves if the upstream CVE hasn't been resolved yet.
It's unquestionably worth doing if this is a dealbreaker for our customers, but could definitely impact things in the short term by requiring fixes which are technically unnecessary.
here's some ways it could happen:
- startup doesn't have ability to hire competent, experienced developers. they end up with rookies with potential but not enough experience to avoid security foot-guns, and/or experienced expert-beginner developers who have a low level of ability
- leadership doesn't value quality or security, so the company culture reflects this and focuses on what leadership values
- startup outsources development work and has no in-house technical capability to check quality or security of deliverables
- startup is pre product-market fit in a domain where security is less relevant, and security issues are less of a risk to the business than the more existential concern around identifying and de-risking a scalable, profitable business model. then suddenly the throwaway proof of concept codebase for the 7th pivot starts getting traction, and by shovelling features on top it is possible to win more customers
I guess the exception might be the decision to wait a couple of months before making some other decision!
Also, the morning of a big announcement, my boss asked me "can the blog handle heavy load?" and I was like "yeah sure, but nobody reads the blog", "they will, can we make it like a static page or something?" ... So, like ok, whatever, stupid thing to ask for, but it's easy. Got that going, and also we had a meeting added, no agenda. And one of my coworkers was convinced something was going on, he said people had been in the office all weekend.
My supervisor called me to a meeting room, he let me first sign a non-disclosure agreement, or he can't tell me nothing. I had to sign that paper. Then he told me that the company was acquired, and you have choice to either leave or work for Tencent. If you want work for Tencent, you had to go over their interview and only talented people will get offer.
But actually 95% of my colleagues get offer, including me.
The distractedness of the executives is spot on. But it always seems to be in hindsight that we look back and go "huh, funny..." I am sure we could write an inference bot that monitors the calendars of people in the organization and estimates that an acquisition is imminent.
And the security/bug fixing. "Yeah, that bug has been there for three years, nobody has time to fix it." Well, all of a sudden, we are fixing it. And more besides. And the licensing of software and source code. Getting a full run down of every open source license, and I mean _every_ license, and then going back and checking them again. A sudden drive to document everything.
I've also seen the ugly side of acquisition too. An equity claw back that happened to me many years ago that I am still sore about. Sudden acceleration of equity grants and a "re-interpretation of what 'it' means" or extreme scrutiny of whether you actually qualify for the equity in your contract. I've seen a few good people suddenly not get anything because there was a missing signature on a document even though the person had been at the company three years.
Large amounts of acquisition money does strange things to people.
General cost cutting without any other visible reasons. Cut backs on travel, social budgets, contractors, any other expenses that can be trimmed to make the financials look sexier.
Departments like Finance, Legal, Risk/Compliance and HR are overworked and distracted. These people, at least some of them, get involved after the execs but before everyone else. As someone else said this can start with the CFO but it'll spread to whole teams of paralegals and accountants before you are told about it.
Speaking of HR, do they suddenly want everyone to sign contract addendums or "compliance papers" or whatever? Asking you to fill out a "skills inventory"? Everyone got to get background checks?
Sales teams rushing to finish deals (to sexy up financials) and clear their comp (before the new boss brings new rules). I guess this isn't really that different from BAU.
As has been pointed out these things can all have other causes. But all together, all at the same time, without any stated reason....
Unfortunately ICs are often the least plugged in politically and end up the last to know. The compensation is being retained, unlike everyone else above who heard it through the grapevine before you.
Insider trading. It happens.
Unusual executive travel. The CEO, CFO and VP of Legal spending a week of "workshops with a customer" in Hong Kong?
Facts on the ground are always subject to change and you should be prepared:
1. Keep an up to date career document where you list all of your accomplishments in STAR format
2. Keep an up to date resume
3. Keep your skill set aligned with the market
4. Keep a strong and active network and guard your reputation
5. Don’t be a “ticket taker”. Be able to talk about initiatives you have led
6. Live below your means and have a 3-6 months emergency fund
7. Even though I haven’t and haven’t found a need to. “Grind leetcode” (tm r/cscareerquestions).
There has never been a day that I haven’t been ready to change jobs at a moments notice since 2008 (I’ve worked longer). This is true whether I was working for a startup or working at $BigTech and everything in between.
This sounds dodgy as fuck! If this ever happens to you, please don't sign the paperwork without running it past a lawyer. It's definitely not there to grant you more rights.
Don't let false urgency ever pressure you to do otherwise.
If they need your signature, they can wait to get it. If they don't need your signature then they shouldn't have a problem anyway.
Anecdotally, plenty of companies are still running their hiring pipeline even when someone - including HR - knows that they're about to be acquired, and nearly everyone who doesn't have a signed offer in hand (and sometimes, not even them) is going to be either completely ghosted, or get apologetic letters from a different company's HR department.
While it can be fun to fantasize about what every little oddity means, I’d recommend against making this a priority in your daily life. If you find yourself that distracted from your work, it’s a good time to dust off your resume anyway, regardless of if M&A forces you to.
And changes in the work hours of execs
Meeting day comes and the CEO proudly announces that the company is getting a brand new logo...
Relevant: https://reclaim.ai/blog/this-meeting-could-have-been-an-emai...
And even if you are at a company that realistically won’t be acquired, you should always be prepared to look for a job at a moment’s notice.