Watching an acquirer ruin your company
startupwin.kelsus.com
startupwin.kelsus.com
This exact pattern has preceded every mismanagement disaster I've ever seen:
1) Management gives an unreasonable deadline to developers before defining the deliverables. Clock starts ticking.
2) Management then fails to settle on the requirements for months and/or continuously moves the goalposts while people are trying to work, turning an unreasonable deadline into an impossible deadline
3) Developers start realizing that they're going to receive the blame when impossible deadline isn't achieved, despite not having any control in the matter. They start leaving for new jobs, and the death spiral begins.
It's the universal pattern of a management team that doesn't know how to do anything other than make demands and then apply pressure. Unless you can get someone in charge who has real leadership and planning skills, it's not recoverable.
The death spiral becomes visible, really. The gun had already been fired, the body just hadn’t hit the ground yet.
I must say these failure modes are much worse than the ones I’ve experienced, which maybe I should be grateful for, I’d have to think about this. Generally I’ve seen a slower burn, where the remaining fiscal year plays out with soothing tones and promises of not changing things, and if money doesn’t magically appear in their accounts, which why would it? Then they don’t give you money for some of the things you usually do and while they technically didn’t tell you not to do them, if there’s no money you don’t get to do them.
I don’t know which business school teaches people to say “ah can you smell that fresh mountain air” while they have their hands wrapped tightly around your neck but that’s some gaslighting BS that I hope nobody experiences, but I know people have. Best I can do is tell them to watch out for it. Some places you’re safe until FY+1, and things don’t go fully absurd until FY+2.
It’s all of them and the higher you get into management the more apparent it is. They sell a system of meritocracy where those who work the hardest get the rewards. Then you get into management and working side by side with people whose first job out of college was as a VP, who explain to you how they are forcing the newly hired manager to fire someone at random to “make sure they have a backbone”
Software engineers have been tricked into thinking they are part of the in club because they are paid well enough to have the lifestyle that the middle class had between ww2 and the 80s, but we are being systematically stripped of the value we bring.
If this wasn’t true then we wouldn’t be able to point towards recent events like jobs setting up a hiring cartel to depress our wages
This, and additionally we've been tricked into feeling guilty about it as well.
Maybe in the future we will have to unionize. Definitely not now and not in Europe. And this is not a matter of pay, e.g. airline pilots are paid more than programmers here yet they are heavily unionized.
Right now management will be off-guard, not expecting any unionisation push and will be a little bit unprepared as to how to counter it (that is, if they even try). Employees will likely feel comfortable openly discussing unions knowing that they probably won't feel any reprisals (and if they do, well the job market is still pretty good for the moment). The tough part would be convincing someone on $1x0,000/year that they might benefit from a union.
Education still doesn't prevent us from falling in particular traps.
Spend your money/energy on lobbying.
This is naive. Any ticket tracking system can be used to track productivity. And if you don’t have a ticket tracking system to organize work, that’s a miserable environment to work in.
I have had numerous jobs in IT, and software development is by far the worst. Ticket grinding bullshit.
The sad part is that developers think this is how software development is so they can't even demand better. Clueless.
I can't work out what "this" is that does not happen to unionised workers? Unionised workers can switch jobs to get more pay too.
Is it not stressful when switching jobs? - from paperwork, interviews, new colleagues, friendships, on-boarding, new place politics - especially for brain.
If I got fired tomorrow it would result in a vacation, probably followed by a raise. When you get to that place it isn't scary at all.
I hate it with all my heart but if I have to, I'll do it 50 times more. I am never allowing myself be held hostage.
So, you navigate this quagmire begrudgingly, yet don't favour unionisation?
But software development can be stressful on its own: you have endless pointless meetings which serve no purpose but you have to attend them, you have mandatory corporate team-building shite which you must attend or you lose the "software engineer SENIOR" job title and you have to show leadership skills to HR people and your managers during pointless "funny" "games" during the team-buildings, you can't be involved in illegal activities (e.g. rage-type murder of your manager is a major no-no which can ruin your career for good). You also have to learn new things constantly in your free time because your employer is reluctant to pay for courses. The list goes on. My previous job was applied research and especially the university professors who did the actual research treated us like a piece of shite. I can't even count the number of times I heard something like "you can't understand anything because you have only Master's".
The stress-level of switching to a new job is generally comparable to normal activities. You need to grow some thick skin.
As a counter-example to this specific point, the Screen Actors Guild does a tremendous amount of work to raise the pay and conditions of the median earning actors, without preventing the highest performing members from negotiating compensation in line with their ability to contribute to the success of a project. We can have our cake (collective negotiation) and eat it too (million dollar+/yr IC roles).
Other notable examples; State bar associations (lawyers) and the American Medical Association (doctors).
Also professional sports unions.
The Bar Associations and the AMA are not quite unions though they certainly advocate and lobby strongly on behalf of their professions.
For the Bar there may be confusion because of the names of licensing agencies. In California, the state agency is the State Bar of California, but that has nothing to do with various bar associations.
The last 15 years have also been a relentless boom market, longer than most.
It won't always be that way!
The best time to prep for bad times is when the going is still good.
[Citation needed]
* https://centreforaviation.com/news/pilot-union-accepts-emplo...
* https://www.flightglobal.com/strategy/klm-clears-path-to-bai...
VNV is the pilots union of KLM, the Dutch national airline. IIRC they were the very last of the unions to sign up to the 'commitment clause' the Dutch gov required as part of their bail-out during Covid. Not a union without teeth.
I was contesting that pilots are paid more than developers. If you have data that supports that, please share. It seems like an absurd claim.
https://fr.glassdoor.be/Salaries/airfrance-pilot-salary-SRCH...
https://www.payscale.com/research/FR/Job=Software_Engineer_%...
The answer is obviously not - do you have any salary data?
also, for every engineer, there is one who will claim to be able to do the job cheaper. that is why we need unions. that, and to get rid of leetcode. people already went to college and that should be enough.
I don't like or do LC interviews, but even if (a big IF) college prepared you for programming, a LOT of professionals don't study development or even attend college. How would they get into the industry? Take 2 years off later in life and attend college?
any good college will require significant programming work, so by the time you graduate 4 years later you not only have CS theory subjects down but are able to write software and can pick up any language in a few days.
Would the stability and general level of working conditions have anything to do with the fact that most are unionized, and have been over a long time so they can do their job responsibly, perchance?
Maybe the parent wants the union to fight for the same conditions as Europeans now have? I wouldn't know. My experience from a Nordic union certainly wouldn't be a good take of what an union membership in Brazil, US or Japan would be like.
I think of this when managers come up with different requirements during the project. If the requirements seem to make the product better, I'm all for it. I like to work this way and they pat me on the head for being "agile". But I always end up kicking myself when they ask why the project is taking longer. I fall for it almost every time because I like to tinker.
I missed this, any details?
"former Apple CEO Steve Jobs, former Google CEO Eric Schmidt and top executives from [Intuit, Pixar and Lucasfilm] had reached "no-poaching" pacts prohibiting each other from trying to lure away each other's top workers with offers of higher-paying jobs."
These were the ones for whom DoJ had enough "smoking gun" proof, but Jobs and Schmidt had a lot of friends elsewhere (Larry Ellison...), so the cartel was likely much bigger.
What? How?
Company A buys company B for a product it believes in. Company A knows that company B was incapable of getting product to finish line, which is why they sold out. No problem though, company A has done this before…
The managers at company A are assigned to ship product, just like they have before. Managers can’t say “its all good, we’ll give them a couple more devs and leave them to it.” they were told to manage, changes will be expected, planning must happen.
The C level of company A just spent a bunch of money on company B. The product needs to hit positive revenue in 9 months, without positive revenue in 12 months the company will be out of cash. So management are told in no uncertain terms that they have to ship in 6 months.
The contracted developers sign on to a 6 month fixed timeframe and know there will be design tweaks by the new management.
At every stage everyone is doing their job. Everyone is trying to do the right thing for success and to not get fired. Everyone has a problem that can only be fixed by someone at a different level compromising on their quality of work or their personal happiness.
I’m not excusing bad management or execs who looking for a rapid cash-out. Trying to illustrate how a good company can hit the same pattern.
I think this hits the nail on the head.
A bunch of reasonably competent people went in with the best intentions, all in good faith and over time it became clear certain assumptions were either too optimistic or simply wrong.
While there is definitely blame to be apportioned, the frustration felt by all involved leads to a very human reaction of calling it malevolence or incompetence.
Then everyone pays for their mistakes, and the whole thing is a waste .
Optimism is essential in any endeavor, but it is no substitute for starting with accurate -in detail- assessments & provisioning of resources.
They (the Corp-A C-Levels) had one job here...
Companies make these decisions all the time, particularly in industries whose products are hit driven and then tail off.
Management panics when they realize they won't make the self imposed deadline and start throwing bodies at the problem.
In our case, we went from 2 teams to 8 over night. The very few engineers who actually were capable of shipping features became swamped dealing with the fallout.
To make things worse, they keep scheduling multi-day, 8hr "planning" sessions that all key devs must attend so they can better "understand the remaining work"
The better way is to have a smaller number of people work on requirements and figuring stuff out before a whole team lets rip. Some tasks just don’t parallelise well so a 9 person team isn’t good for everything.
I wonder where this comes from. Is it just hubris mixed with incompetence?
But, it take hubris and incompetence to get there.
Once they've shown they can do it once it's perfectly reasonable to bet the entire business on them doing it the next month.
Oh, and also, the diversity team have noticed we have hired a lot of young people so we're only hiring over-50s this year.
That's true. A team of 20 women can easily produce one baby a month.
Nine women can't, but the people who like to say "nine women can't produce a baby in a month" are almost never trying to tell you that you can fix your problem by expanding your team to the appropriate size.
The other day I had PM complaining how they were going to keep their team (which has somehow grown to 10 devs!) busy after the highly sequential work was blocked by a dependency on another team...
That would have allowed modules/components to operate independently ,reved on different schedules, and more, but evidently too much thought at the outset ,so they just didn't even bring it up ,or passed on the opportunity if it was brought up.
They think they can't spend the resources to get it right, but they'll magically have more resources to fix the problems.
Now everyone pays.
It was to partition the app into at least the primary segments that did different functions and had different behaviors, system resource load profiles, etc., and then mandate that those all run on separate machines (this was before everything was cloud-based), and that the relationship to entities was not 1:1. Defined clean interfaces up front. The primary goal was to be able to scale very rapidly for any big customer and/or upon discovering a scalability issue by temporarily throwing hardware at the problem, and secondarily to allow teams to rev different portions of the system on different schedules.
Both worked great, and it wasn't long before we were taking major customers away from competitors because they had scalability issues and we didn't. I'm in R&D and manufacturing now, but see no reason that this approach of fundamental modularity should not be relevant. Heck, I find high modularity to be a good approach relevant to designing industrial processes, or just setting up a shop... just keep everybody's fingers in their own pies, make the organization implement the best architecture, not make your architecture implement your org chart.
(see point about about the not understanding what is being built and constantly changing the scope)
and to save money they hire some newbies instead of experienced people. I have had it multiple times where the project got looded with people who had no experience or they were in India 12 hours away so onboarding was really hard. the result was always that the added people slowed the project down.
One place I was at had quarterly 3 day planning sessions. That was something else.
Team1: "Hey, we've launched a new initiative a few weeks back. Important for us to be able to add one field to the response of your internal billing API. Can we discuss what that would take?"
Team2: "Hey, probably a few hours of work. But, we just had our quarterly planning last week. In 12 weeks you can submit for Q2, and _maybe_ we will plan it somewhere in May or June."
Plus a planning every sprint and daily stand ups.
sigh
For the people doing planning, they were always busy playing ticket shuffle, asking random devs random questions all the time. But those two weeks was cray and anything not done by the end of the sprint had to be done by the end of the planning period, and you better have a good reason.
The place where I worked: the owner of the company was Bipolar (in the literal sense), and depending on what phase he was, he wanted different features, so every time he "switched", he changed all features, often going back and forth between two feature sets, after a while he got mad the apps were all late and not finished and fired everything and focused on his other business that was more successful.
Place I had a friend that worked there: Experienced (but small) movie studio decided to make games... My friend after a while started to complain of features changing non-stop, I made aquantance to a lot of other employees for various reasons and gathering up all their stories one thing was very clear: the owner new wife often hanged around in the office, and went around demanding new features, whenever employees resisted, she called her husband (the real owner), that then proceeded to agree to whatever she asked... Until they married the project was going well, as soon they married it tanked.
Second thing: you can change jobs as often as you want. I am for loyalty but you can’t know what a job will be like until you work it.
If you've had projects like this in the past you'll recognise the early warning signs (eg. hard deadline before (even rough draft) requirements are available).
You'll know it's time to start the job hunt early because there's no way it can work unless you work yourself 24/7 into the ground.
It's not about accepting defeat, it's about accepting you are worthy of something better.
Note that in this case there’s no way it can work period. The product is useless and worthless. The ring that beeps differently depending on the color of objects it hits? How much would you pay for it?
I personally know better not to judge people who are not.
A job doesn't deserve more from you than it gives you.
Today it's so incredibly common (and hiring processes are extremely strict compared to before), that most companies see having started multiple jobs as "validation" from other companies.
"Hey we don't really need to make any decision ever or even know what we are doing. That's the great thing about agile!"
This might be a controversial take but if you have an actual deadline -- "product must cross the threshold of not shippable to shippable" as opposed to a cutoff date "product is at all times shippable but we need a date to say we're done refining" then agile is probably not the way to go.
I've always structured projects like this as waterfall to your MVP then switch to agile. You have to get your PMs to agree to an (externally) unchanging design and feature set until you have something working to talk about and then you can ask what they want next.
Even without a deadline I still try to follow this model but define the "MVP" as a "hello world" app but with functioning prod-ready infrastructure and ci/cd. So then I can go to the design meeting and say, "I have a blank canvas, what do you want on it?"
The management in the company didn't plan anything and the meandering development process showed it.
Please don't underplan. It's awful for morale to throw away work because of bad planning.
If your morale is harmed by throwing away work, that's something you should work on.
If that doesn't kill your morale, I don't know what to say.
Meanwhile, by all means discover that no one likes typing numbers on a phone so you have to refocus on taking pictures of receipts and wage stubs and text recognizing them.
Then all the unknown unknowns become known unknowns and you can actually create good solutions to it.
All planning is a waste if you don't even know where the speed humps will lie.
[1] https://en.wikipedia.org/wiki/Chesterton%27s_fence#Chesterto...
If that's the place where someone is, they should be conferring with someone else who knows something instead of trying to fly solo
Blindly going through problem spaces is how you waste your life taking wrong approaches
The promotion process explains way more of what I think you are getting at.
1) losing a critical mass of developers is the beginning of a death spiral
2) the critical mass is smaller than you think
3) you lose the developer months before you know you’ve lost the developer
----------------
The Advanced Automation System began, in concept, in 1981 and ended in 1994, “terminated for convenience” by the government. Billions of dollars were spent on it. It is hard to describe. You can’t learn anything from the name. You know it’s about air traffic control because I told you, or because you read about it in the papers. Maybe part of the problem was the name. It sounds like the system to end all systems.
...At $3.7 billion, the Advanced Automation System was one of the largest civilian computer contracts ever; maybe the largest. It was the largest single contract in IBM’s history. From the moment it was awarded, until near the project’s demise, IBM patted itself on the back. There was something for everyone, beginning with a great ball in Union Station, featuring Chubby Checker and “The Twist”.
...What I saw on the FAA’s Advanced Automation System would have made Sisyphus weep… Whatever commitment and discipline there was… was worn down by a battery of watchfulness that I can only ascribe to fear of failure. In spite of tens of millions of dollars spent on new computers for AAS, the most important piece of equipment on the project was the overhead projector. There were endless meetings attended by dozens of people – as if we were never quite sure about the whole thing. The people in charge simply lacked the confidence and the finesse of the space team: NASA, contractors, and astronaughts.
It has been noted by everyone from the New York Times to the Vice-President of the United States that the main problem on the Advanced Automation System was “changing requirements”. For those involved in large-scale computer systems, that is nothing new. No one can perfectly surmise the shape and feel of a system years in advance. Even replacing some aspect of a system you know by heart is not immune from thinking twice about it. … [But] the requirements churn (it was called) on the Advanced Automation System was not normal. It was the result of our enchantment with the computer-human interface, the CHI. The new controller workstation, fronted by a 20″ by 20″ color display, because it was capable of seemingly endles variety of presentations, mesmerized the population of AAS like the O.J. Simpson trial mesmerized the nation…
The project was handed over to human factor pundits, who then drove the design. Requirements became synonymous with preferences. Thousands of labor-months were spent designing, discussing, and demonstrating the possibilities: colors, fonts, overlays, reversals, serpentine lists, toggling, zooming, opaque windows, the list is huge. It was something to see. (Virtually all of the marketing brochures – produced prematurely and in large numbers – sparkled with some rendition or other of the new controller console.) It just wasn’t usable…
The cost of what turned out to be a 14-year human factors study did not pay off. Shortly before the project was terminated a controller on the CBS evening news said: “It takes me 12 commands to do what I used to do with one.” I believe he spoke for everyone with common sense.
Rummaging through one of the closets at the far end of the hall on the fifth floor one day, looking for some standards document, I found an envelope left by someone who left the company – as many did after so many years advancing against stone, while the wheels of commerce were accelerating on what everyone referred to as “the outside”. It contained “A Brief History Of The Advanced Automation System”. It was printed by hand and left, perhaps inadvertantly, or perhaps with the hope that some anthropologist might some day discover it and make a pronouncement. In every important way, it is the truth:
“A young man, recently hired, devotes years to a specification written to the bit level for programs that will never be coded. Another, to a specification that will be replaced. Programmers marry one another, then divorce and marry someone in another subsystem. Program designs are written to severe formats, then forgotten. The formats endure. A man decides to become a woman and succeeds before system testing starts. As testing approaches, she begins a second career on local television, hosting a show on witchcraft. An architect chases a new technology, then another, then changes his mind and goes into management. A veteran programmer writes the same program a dozen times, then transfers. The price of money increases eight times. Programmers sleep in the halls. Committees convene for years to discuss keystroking. An ambitious training manager builds an encyclopedia of manuals no one will ever use. Decisions are scheduled weeks in advance. Workers sit in the hallways. Notions of computing begin in the epoch of A, edge toward B, then come down hard on A + B. Human factors experts achieve Olympian status. The Berlin Wall collapses. The map of Europe is redrawn. Everything is counted. Quality becomes mixed with quantity. Morale is reduced to a quotient, then counted. Dozens of men and women argue for thousands of hours: What is a requirement? A generation of workers retire. The very mission changes and only a few notice. Programming theories come and go. Managers cling to expectations, like a child to a blanket. Presentations are polished to create an impression, then curbed to cut costs. Then they are studied. The work spikes and spikes again. Offices are changed a dozen times. Management retires and returns. The contractor is sold. Software is blamed. Executives are promoted. The years rip by with no end in sight. A company president gets an idea: make large small. Turn methods over to each programmer. Dress down. Count on the inscrutability of programming. Promote good news. Turn a leaf away from the sun. Maybe start over.”
http://www.smashcompany.com/business/the-worst-software-proj...
It's an immutable fact of life.
I see this on a smaller scale where ICs leave a company and take a copy of "their" code (ask Sergey Aleynikov [1] if that's a good idea). It's not yours. If you ever use it you could face legal consequences. And there's no code I've ever written that I wasn't convinced I could write better from scratch the next time if it ever came up. Side note: it never has.
Don't be that guy who takes the check and then expects control. Don't be that guy who is convinced the new owners are messing it up and then goes out and does the exact same thing..
Move on.
I agree with your point though, which is to just walk away with the check unless you're willing to take a significant risks with either of those two other outcomes.
https://news.crunchbase.com/ma/earnout-plan-startup-sale-how...
Yes, you technically no longer own it once sold, but there's a huge amount of blood, sweat and tears that goes into building something from nothing - not to mention a sense of loyalty to your staff - and you genuinely do want to see it go into good hands and become managed well.
I guess a somewhat leaky analogy would be like giving away a dog you raised to another family and finding out later that they're abusing it. Yes, it's no longer your dog, but you're still going to care deeply about its wellbeing.
Selling something is letting it go.
(b) as you might see, your analogy is not very good.
(c) if you find you care about the money, sell it to the highest bidder. be happy with the money.
(d) if you find you care about the fate of the company, perhaps not sell it? or if you do, sell it to someone who also does? or if you don't, at least realise it was your failure to find such a buyer.
(e) if you expect an acquirer to care about what they acquired beyond how to make money from it, you are a romantic, a fool, or both... and I want to buy your company for cheap.
That's easy to say
But it partly requires reading someone else's mind
Your analogy could be apt: don't sell your company if you can't see it suffer in other people's hand.
Obviously companies try to tie past owners hands to avoid future competition, but it still happens sometimes.
Second time. A $10B company acquired a $4B company. The parent demanded high margins from the company that had been running on low margins and legacy, near end of life applications. Layoffs ensued and the parent was choking on the acquisition. They’d been sold on a bogus modernization effort that ended as soon as the acquisition closed. That acquisition is a drag on their earnings today, six years later.
Getting to see these type of disasters first hand is pretty cool imo.
1) Start with a $55 billion dollar company... 2) Hire a new CEO and cronies that are going to make miracles happen with with a very expensive acquisition of another company. 3) 18 months later the miracles have not happened. CEO and cronies are invited to leave with very generous golden parachutes. 4) Start with a $50 billion dollar company...
I've literally just got to watch a company get ran into the ground by the new owners. Learnt a bunch and once the legal stuff is over I'll have an amazing blog post to write.
In a few sentences.
Tech Side: A company decides to rewrite an application in 3-months, it takes 18-months and couldn't even invoice all the customers upon release. Biz Side: The company has a "better" strategy created for it by people who don't understand the industry after all the original business people fleed and then starts having to do all the stuff the original people were doing.
how does a changed sales team cause features to dwindle and bugs?
it's more likely that management attitudes changed when acquisitions happen - and that new attitude doesn't foster an environment in which good code gets written. It wouldn't have mattered if the sales team changed or not imho.
I can think of at least two ways:
1. In many companies, sales is an important part of the window to the customer. Sales interprets customer desires and forwards them to product management.
2. If revenue drops, the company may need to cut costs too, and one stupid way to do this is to reduce development spending.
A bit more than 10 years later, a wise decision to piss on their customers wiped 8 billion from the brand. Now Gillette is just a ghost of what it used to be.
in both cases, the company doing the acquisition was making dumb decisions.
There used to be a category of software called "electronic design automation". It presented an interactive editor where you could enter the schematic diagram of an integrated circuit, and also enter a chip layout, and it would ensure that they matched. It was big business. But "silicon compilers" that needed only the schematic, and generated the chip layout, threatened that business.
So, in the mid-to-late '80s the biggest EDA company set about buying up early-stage silicon compiler companies and shutting them down. That was doomed, but bought them several years during which silicon compilers were (therefore) not available for people to use. The company is still in business today, but sells very different things.
General Motors bought up more carmakers to, effectively, shut down than probably any other.
Sometimes a company can be bought for less than it would cost to hire as many staff as they have. So, they are bought and shut down, and the employees are put to work on various other projects. Google's hiring system is so Byzantine that buying companies, bypassing it, might be their main recruiting method.
One might even buy a company because its product has a name they want to use for their own product. The momentary importance of domain names in the late '90s caused a fair bit of that.
None of these contradict one another. A company might be bought for any or all reasons at the same time.
So when your company is bought, expecting its product to come out the other side is naïve.
They probably frequently lead to competitive benefits (and increased market share / revenue) for the acquirer, but the discontinuation of products presumably leads to lost time, effort, and potentially money as the former customers of the product look for alternatives (in a diminished market).
I'll beat my usual drum and mention that free and open source software can mitigate some of the risks (but not, for example, support availability) for a software-based product, similar to having an agreed source-code escrow provision with a vendor.
Have you seen this work in practice, do you have any examples to share?
It’s hard to take seriously at face value for two reasons: 1- generally speaking it might undermine the acquisition in the first place since acquirers and investors and boards tend to like private potentially patentable IP, or at the very least proprietary code. 2- More importantly using your software after an acquisition-as-shutdown to compete with the acquirer is almost certainly a recipe for legal trouble. This seems unlikely to get that far since the acquiring co probably would have vetted the software and also had the acquiree sign a non-compete. Either way, if the intent was to shutdown the software, and if the acquiree was paid for their business, there isn’t a good way to “mitigate the risks”, the deed is already done. If you want to avoid the risk of shutdown, don’t take the deal. When you do see open source software as having any ability to change that equation?
Those acquirer-side incentives do seem rational (and to some extent traditional) in a business sense.
The risk-mitigation I mentioned was from the perspective of users, not so much of the acquisition target (although it could reassure their employees to know that the time and effort they invested continues to provide value).
> Have you seen this work in practice, do you have any examples to share?
I design semiconductors and I use EDA software everyday.
I know Cadence was formed from a merger in 1988 and they have since bought around 30 other EDA companies.
Back then, chips were still laid out by pasting up prepared logic blocks, gates, and occasional custom transistors, and routing metal traces between them, all on what we would today call a low-resolution workstation monitor. A million transistors was a lot. These would be output via a plotter to make photomasks for the various doping, glass, and and metal layers.
The EDA software of the time, besides supporting manual editing editing of layouts and schematics, would simulate whole chips taking into account capacitance of wires and transistor inputs, propagation delay, and drive capability of output transistors. It would also apply geometric checks to make sure the layout conformed to rules of the target process. Where violated, somebody would need to redraw that bit, which might mean moving stuff out of the way.
Somebody would have to make up sequences of values to feed to inputs, and others to check outputs against.
So the period when MG was buying and shuttering silicon compiler startups was '85 to '89.
I think after Cadence won, Mentor Graphics got more involved in supporting embedded system design and firmware integration, leaving chips to others. Daisy merged with Cadnetix and went bust in 1990, and after twists and turns what was left became part of Mentor Graphics in 1999. Valid was folded into Cadence in 1991.
Cadence tried and failed to buy MG in 2008. MG was finally bought by Siemens AG in 2016.
I had never heard the term "silicon compiler" before so I looked it up.
https://en.wikipedia.org/wiki/Silicon_compiler
Silicon compilation takes place in three major steps:
Convert a hardware-description language such as Verilog or VHDL into logic (typically in the form of a "netlist").
Place equivalent logic gates on the IC. Silicon compilers typically use standard-cell libraries so that they do not have to worry about the actual integrated-circuit layout and can focus on the placement.
Routing the standard cells together to form the desired logic.
So this is basically what I do everyday but we just call it logic synthesis (Synopsys Design Compiler / Cadence Genus) and Place and Route in Cadence Innovus or Synopsys IC Compiler. We use Mentor Calibre for LVS/DRC.
I've worked in serdes teams where there is a lot of custom analog design with manually sized transistors and custom layout in Virtuoso. I'm working on chips in 5nm that are over 20x20mm so it would be impossible to do those without all the automation and it is still tons of manual work.
Some of my older coworkers told me about doing layout on transparencies and colored pencils in the early 1980's.
Some of us remember Rubylith with conflicted fondness.
Wrong. Google actually fires all former employees of acquired companies once a certain protection period in the acquisition agreement is over, unless they individually pass the tests applied to new employees.
Here's better advice – the moment you sign the contract start counting the days left in your retention agreement and quit right after.
Agree. It's impossible to really know your acquirer unless they are a bigger publicly traded company. Every acquirer puts their best foot forward, talks about how awesome their culture is, and how they are going to do all the things to help you grow faster. IME, it never works that way.
> the moment you sign the contract start counting the days left in your retention agreement and quit right after.
That's a bit too cynical for me. But, you do need to answer some questions, do you want to be an employee? Are you ok not being the one in charge? If you got a decent payout in the acquisition, you have a lot of freedom in the new job if you want to try to keep things going.
One other thing to note, is that many times companies can be spun back out. I know multiple founders who have had this happen.
Compare - I sold my bootstrapped company in 2018 after 16 years. It had been my entire career, and had hit a wall basically because of me & my big head not being able to work with my co-founder (and old friend & brother-in-law). Even then I understood the lie you have to tell everyone for the cash - we're very excited, nothing will change, etc. etc. The awful blog post is still up :-O
The acquirers insisted on an earn-out based on profit over the next 12 months. And 2 weeks after the acquisition I realised. I called them on Friday and said "so I had started a lot of projects with a payoff in much longer than this time. Nobody at the parent company seems interested in them, I've contacted (long list of people) and had nothing back. Since you were explicit about short-term profit being the goal, I'm intending to start firing 40-60% of staff related on Monday, which should lift profit considerably in the remaining quarters on my contract - there's no risk to operations."
I had a pearl-clutching call back from the CFO who was shocked SHOCKED at how I would treat my former company. That's not how they do things at (parent company). He would put his foot down and use his statutory right as a company director to stop me. Then he offered me & my co-founder about 20% of the earn-out cap to leave immediately, and we took it.
Of course they fired everyone anyway 3 months later. Maybe I'm just older than the OP was, I was 38 and tired of the whole thing, but (after travelling up a few times to the parent company's offices) I assumed the acquirers would do the worst, most short-term thing possible and I was not disappointed.
(A small consolation was seeing the CFO purchasing gobs of his company's own shares at the near-peak share price following the acquisition - it's declined steadily, and now suddenly, and is stands at 40% that peak).
It would be interesting to see how noisy that signal is. I wonder if there is a subset of people that would give a better signal? Maybe an external party that hasn’t drink the kool-aid and has enough inside information - board member? VC?
Requiring theory and practice to use an instrument isn't bad design. Compromising creative potential for potential market size just turns it into a toy, not something with staying power.
Killing the android version would have been fine. Music apps and tools have been great on iOS since well before Oboe dropped on Android to fix the latency issues. The poster seems to be as wrong a fit for this product as it was for the market.
All that said if you make a music tool and find an acquirer for any dollar amount you've succeeded. The market is teeny and people don't want to pay for new things.
i also think it’s lame the article does not mention the marketing cost to reach the 188k funding.
also, building realtime synth / audio apps especially for professional use is a highly specialized job you should not outsource to generic mobile devs. you need to hire people who have been doing that for many years.
android has many audio stack related problems and those still haven’t been solved. someone who specializes in audio apps already knows that.
i get that the author is frustrated but the real reason people probably didn’t buy the product is that it was not good enough and not a “need”. to really want something it has to be crazy good. i’m surprised they got a deal from apple to distribute a poorly executed product.
it sounds like sphero and other parties were wowed by the idea and acquired or partnered with a startup with a prototype that was still far from a real product. i don’t think it’s fair to blame sphero in this case…
It’s way more than this. The acquirer also has to share your vision, be willing to let you execute on it without interference, be willing to commit funding for sufficient time for it to grow legs, have deep enough pockets to sustain the investment, and be honest about all of the above. Quite often the acquirer is just as caught up in the heat of acquiring as the acquired is.
In my experience, if you are trying to execute on a vision, acquisitions are supremely dangerous.
Exactly! I recently saw someone blame Nissan's failure on how Renault ran the company into the ground. Only problem is that Nissan was on their way to bankruptcy when they were acquired. "Beggars can't be choosers". To be fair, Renault has done Nissan dirty, taking out money instead of re-investing
YouTube, Instagram, Github, Android, Slack, Heroku (until recently), etc. And those are just the ones that were left to their own devices.
There's also a ton that have lost their brand, but melted into the parent company. It's not obvious from the outside, but the tech (and team behind it) goes on to become a vital feature. Like, look at any acquisition by Stripe.
Lastly, companies sell because things are going really well or they're going really badly. This company was closer to the latter, and that has a much smaller success rate – but teams often get continued employment, some get promotions, people make money, etc.
Then, four months post-acquisition, Anduril’s influence earned them a $100M contract to build prototype submarines for the Royal Australian Navy. Dive benefitted from Anduril’s political savvy and connectedness in a new part of the world; Anduril benefitted from Dive’s tech of course.
Title should be: “ Watching an acquirer ruining their investment”
Because it’s no long “your company” the moment you sell it. It’s now their company.
Not a startup, but we'd grown to be a public billion dollar revenue organization when we were acquired by a much larger company (not using names here, as I'm sure there are folks on HN who were also there and would remember this and I don't want to doxx myself).
We were very profitable and had an excellent company culture, with almost everyone pulling in the same direction. It was one of the best jobs I've ever had. Until the acquisition.
After acquisition, as significant portion of our services were essentially given away to customers buying hardware from the acquirer, and our revenue plummeted.
New top management then proceeded to destroy the company culture in an attempt (a guess) to bring it more in line with the acquiring company's culture.
It was a disaster, and after a half dozen rounds of layoffs and 3-5 years, the division (that was the original company) was sold off for ~5% of the original purchase price.
I'm sure there are situations that make an acquired company better, but that wasn't the case here. And more's the pity.
No on both counts, but not bad guesses. :)
And lets not get started on the 1-2 year slowdown that an acquisition can put into a team.
I built a satisfying career on a couple of those.
Good ideas are for squishing obsessively into the fuzzy pumper until you get an iteration worth sticking in the oven.
My thought on trying it again though is that IP rights could be tied up in the old entity.
Edit: see the sibling comment, they gave a link. Brother need a little off the top.... and I never even had this or most of the crap whose jingles are still in my head.
if they aren’t making the leader of the acquired company into VP or higher, it is unlikely that the product will succeed.
before acquisition you are an important innovator that has much to teach. after acquisition you are a crazy person who only wants to spend money.
Do they have a drug to treat this condition yet? Maybe that’s what has been missing from my life.
Basically there is a very negative view of finance, that they want to cut costs to the bone, optimize everything, dont care about anything else then the numbers etc.
In some ways it is a wrong view, but there are tons of people who see most things in a company as "cost centers".
So maybe get someone to do cost planning for you and then compare actuals to your budget - often even setting up a budget allows you to understand where the money should go. Other thing is where it actually goes.
If you are talking about personal finance then the time cost of properly analyzing where your money goes is high, but even with crude registering you probably can get an overview where most of it goes. Then you can work on biggest positions to try to minimize them. Those personal finance subreddits probably can help you with such analyses. There are also those "frugal" communities.
But for most people: the more they earn, the more they spend. Also some of those frugal types are just weird (e.g. run around with a broken phone while you use it every day).
If the money isn’t enough to make me walk away from a project, then the money isn’t enough for you to bug the project.
If my goal is to build something useful for my customers, is there any harm in converting the company into a co-op or something when I get bored? I have a lot of money (not bragging, because it’s not like millions and millions, but I’m fine) so I’m not motivated by that. Rather I want to solve problems and create an environment where my team can prosper professionally and we are all on the same mission. I’ve worked at companies before where the culture was amazing and it was actually a joy to work. And it’s not like we were some hippie company - I’m talking unicorn status and later an IPO. I want to emulate that sort of environment where people were legitimately happy to be there.
Instead of selling to some PE firm to come ruin things, has anyone converted their company into a co-op or is there something better where the remaining employees can be empowered to keep the engine running and steer the ship to new shores?
And I work 60h/week already, cannot join two coops to learn more :-(
I suppose one problem could be that they'd try to make decisions via consensus or votes -- but there might be one person who is brighter and/or knows more than the others, and leaving most decisions to that one can be an improvement?
Imagine the Linux kernel starting to make decisions via consensus or votes, rather than a BDFL?
(I'm sbd else)
Look at the most recent company you worked for, and from your colleagues think of: one idiot engineer, one idiot manager, and one idiot admin. Now imagine that they each feel they have equal rights as anyone to share their “input” into that business, and imagine trying to find consensus with you. Now multiply that problem by 10, because it isn’t just idiots that want to have their say, and most people have valid input that needs to be ignored because most businesses need a leader to provide focused power on a few plays.
I know of successful co-ops, but those seem to usually have a corporate structure and members have limited power, and I don’t know their internals.
Do you feel you have the skills to manage a co-op? Superficially you appear to be somewhat idealistic and innocent of the difficulty: although I think most traditional startup founders have and need those traits! Advice is cheap and experience is expensive: go with whatever works for you.
The engineer, admin and manager example sounds frustrating!
I can run a company (it seems) but a co-op, then I'm afraid one would need much greater charisma and persuasion skills, and also enjoy that?
Otherwise the co-op would be unstable? With equal voting power, then any member with bad ideas and persuasion skills would be an existential threat? But in a company, s/he could just be fired? (Or contract not renewed)
For example, Ghost? Does Mozilla count? (A non profit)
> We set Ghost up as non-profit foundation so that it would always be true to its users, rather than shareholders or investors. Our legal constitution ensures that the company can never be bought or sold, and one hundred percent of our revenue is reinvested into the product and the community.
If you own the company and you decide to close a product line, you're pivoting and being a good owner.
If you sell your company to someone and the acquirer closes a product line, they're ruining your company.
I've got a new dream now, and if the boss sells it, pfft, I'll just keep dreaming.
If you look at the film industry, they are masters of this. Buying scripts and sitting on them etc. A company could buy your widget startup and say they are still selling it, but mail order telephone sales only.
For some of my trades I use capital to purchase shares on the stock market
For some of my trades I have a 100% premine of shares and sell them at a higher price until I’m down to 20% left but only because I minted 500% more shares to sell to the PE guys
Its no different to me, a trade is a trade
I didn't understand your example at all. Care to explain?
From then on, the goal is to sell shares at > $0.00
But instead of selling any of those shares, when an investor comes you create a bunch more shares at $0.00 and sell them, dropping your percent of ownership to < 100% while not incurring a capital gains tax event.
Initial capital is a thing, and most jurisdictions have strict requirements on the minimum and maximum size of initial shares.
type TransferOwnership interface { exchange(money float64) someAsset }
the most disastrous decision of humans. Life is not that simple.