Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Watching an acquirer ruin your company

startupwin.kelsus.com

Post reply on HN
Print view View original

271–280 of 347 posts

Re: Watching an acquirer ruin your company

#271

Post by jka »

dahart wrote: post #263
jka wrote: post #212

Earlier quoted context omitted.

I wonder whether there has ever been an attempt to calculate the loss-in-value caused by acquisition-as-shutdown-mechanism. 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…

> open source software can mitigate some of the risks 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…

Sure - ZFS[1] is one example that springs to mind.

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).

[1] - https://en.wikipedia.org/wiki/ZFS

Re: Watching an acquirer ruin your company

#272

Post by moomoo11 »

spiffytech wrote: post #267
moomoo11 wrote: post #261

Dum question from someone who has no business experience but trying to start a company. 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 wh…

Ghost CMS set the company up as a nonprofit: > 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. https://ghost.org/about/

Awesome! Thanks

Re: Watching an acquirer ruin your company

#273

Post by jacksnipe »

PragmaticPulp wrote: post #18

> As soon as Sphero completed the acquisition, bringing Kelsus in as an app developer, two things happened: 1) Sphero told us they needed fully revamped iOS and Android apps six months later with no schedule wiggle room. 2) Sphero spent the first two of those six months organizing a team on their side and hashing out requirements for the new apps. This exact pattern has preceded every mismanagement disaster I've ever…

In general it blows my mind that people don’t understand that:

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

Re: Watching an acquirer ruin your company

#274

Post by AdrianB1 »

le-mark wrote: post #10

I’ve seen this twice. First time the PE firm installed their CEO who came in and immediately started talking about cleaning house. A bunch of developers left fearing a layoff. That was bad enough, but what he really meant was sales. He gutted the sales team and brought in his guys. Sales tanked, company growth stopped, hard. Features dwindled and bugs grew. This clown and his cronies were gone after two years and the…

If anyone remembers, Gillette was bought ~ 15 years ago and the decision was to move everyone from Boston to Cincinnati; they lost ~ 80% of the people in Boston with that single requirement.

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.

Re: Watching an acquirer ruin your company

#275

Post by imtringued »

thaumasiotes wrote: post #150
labster wrote: post #123

Earlier quoted context omitted.

So how many women do we need, like 15? Maybe a Scrum master who knows the Lamaze method?

If you hire enough women, one of them will produce a baby within a month.

Acquiring the competitor is a valid strategy but you need both money and a competitor.

Re: Watching an acquirer ruin your company

#276

Post by imtringued »

toss1 wrote: post #218
cjonas wrote: post #55

Earlier quoted context omitted.

I find myself quoting the mythical man month to various poeple at least 2-3 times a week. Unfortunately no one is familiar with it (obviously) or seems to understand the point. 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...

...and who was it that failed at the outset to factor out that dependency into a clean,well-defined interface ? 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 t…

The micro service hype appeals to managers precisely because it is a technical implementation of an organizatoral solution.

Re: Watching an acquirer ruin your company

#277

Post by midnightclubbed »

Kinrany wrote: post #177
midnightclubbed wrote: post #82

Earlier quoted context omitted.

The story fills in all the reasons why ‘management’ start at #1. 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 coupl…

So company A gambled that they can turn around company B in 12 months or go bankrupt? Sounds like whoever decided to buy didn't do their due diligence.

Not necessarily bankrupt but at a point where they’d have to cut their losses by losing staff. But company B was going to be fully bankrupt before 6 months without company A stepping in.

Companies make these decisions all the time, particularly in industries whose products are hit driven and then tail off.

Re: Watching an acquirer ruin your company

#278

Post by toss1 »

imtringued wrote: post #276
toss1 wrote: post #218

Earlier quoted context omitted.

...and who was it that failed at the outset to factor out that dependency into a clean,well-defined interface ? 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 t…

The micro service hype appeals to managers precisely because it is a technical implementation of an organizatoral solution.

I guess I should have been more clear, as I'm not talking about microservices, but an architecture I implemented before that hype.

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.

Post reply on HN