The Inner Osborne Effect (2021) | Hacker News Reader

The Inner Osborne Effect (2021)

raganwald.com

145 pointsluu42 comments

This reminds me of an experience with a former employer. Company A, heavy users of Salesforce, was acquired by company B, which was married to M$ Dynamics. On the day of the announcement, one of the bullet points was something like, "the new division will transition from Salesforce to Dynamics over the next three years."

I think it took three weeks for all of the Salesforce admins and most of the devs to quit. They had to hire a small army of contractors just to keep things running, and last I heard, the parent company ended up switching to Salesforce anyway. All they had to do was say, "We don't know what we're going to do yet," which besides saving them tons of money would've been literally true as well.

I've seen that sort of strategic ambiguity used to try to have your people and your decision too.

It may work for a little while, but generally you're going to be left with the people who are young, naive or trapped. One of the problems with hiring smart people is that they don't stop being smart when you're trying to manipulate them.

This is a super important point that almost no executive management ever internalizes; The people doing the work are smarter than you and trying to manipulate them is alienate them.

It is perhaps an ego thing but still. Pretty sad.

The solution I was suggesting was not to play dumb, but to notice the looming problem and try to address it. I don't know what the right plan would've been, but I suspect it would've ended with, "...generous severance package for those that stay and help us through the transition."

> M$

What?

Microsoft

It's a 90s thing.

Yep, force of habit.

A 90s thing? More like 10s? If anything it's 13 year olds I see doing that. Well, mentally at least.

Well, I was 13 in the 90s, so that part also applies. :-)

Microsoft had a stranglehold on the computing industry in the 1990s due to its near-monopoly on PC operating systems. Their software was also much lower quality, which led to widespread hatred of the company among computer geeks. Hence the derisive dollar sign.

2010s Microsoft was a shadow of its former self, so I think any usage of the dollar sign then is more of a holdover from the 90s than anything else.

A string variable named M in QBasic, I imagine.

No one in their right mind would move from Salesforce to Dynamics. Both the UI and APIs pale in comparison to Salesforce.

...and then the current team is told they will focus on maintaining the "Legacy Platform" meanwhile the new team who has done jack shit gets 3 years to underdeliver, all the while being the golden children at the front of every line. The Legacy Team gets undermined and disrespected at every executive review, despite the fact that the entire company or program depends on them, either as infrastructure or to generate actual, you know, revenue.

Oh, and after 3 years, the V2 Team will fail but simply move on to another project or company, with no accountability.

Yeah, this sounds familiar :-)

Replace "Legacy Team" with "BAU Support" and new team with "Projects" and this mirrors what I see.

The people who keep the lights on aren't doing anything exciting to write down in a report. Or if they are, then that is bad news. The best you can be is a butler - invisible but effectively keeping things running smoothly.

But your pay/wage/salary won't be invisible to the accountants who see you as a cost centre.

> Apple III and Lisa failed. Macintosh was underpowered and overpriced on launch. But Apple continued to invest in Apple II, which financed investing in Macintosh

Apple barely scraped through the Apple III + Lisa debacle. The Apple III was itself supposed to be the conservative product line that would fund the Lisa and other advanced development. They even added hardware to prevent accessing its extended memory and etc. from Apple II emulation mode; they didn't want developers targeting both platforms. The Apple II was put on the back burner. It wasn't going to get the new OS for the Apple III, for example, even though it could support it. (It did eventually get it, as ProDOS.)

Development of the Apple III started in '78 around the time the Apple II+ came out. The Apple III came out in 1980 as a massive flop. The Apple III+ came out late the next year as another flop. Around then, the Apple //e was started in late 1981 as a rather rushed effort to expand the Apple II line, which by then had been completely stagnant since the release of the Disk II drive more than 3 years before, during a rapidly evolving time in the microcomputer market (the IBM PC had just been released). If they had just released a straightforward upgrade to the Apple II+ around ~1980, instead of the overengineered Apple III, they might have been the IBM of the industry.

The IIgs was also a different platform from either the II, the III, or the Macintosh. It wasn't released until two years after the Mac. It outsold the Mac for a while, but the high price put it well above the price of an Amiga before it was retired.

I wanted a IIgs for a while, but a BBSer convinced me the Amiga was a much better machine (also wayyyy cheaper.) The difference in price between an Amiga 500 and an Apple IIgs was insane. And the Amiga 500 could emulate a Mac!

I think the price difference led a lot of people toward the Amiga and probably some toward the ST or PC. I might pick one up for my collection one of these days, but there's no way I'd have had one new.

Author here. I remember the Apple III well, we nearly bought one for my mother's Real Estate brokerage. Ended up with a fairly vanilla Intel-based PC.

Whew!

But thank you for the correction on "Apple continued to invest..."

I love Apple history and Apple, mostly because buying serial number 79 Apple II and then years later buying a Mac when they first became available were career changers for me, but for a weird reason: both had, given the hardware limitations, good Lisp programming environments and it was a game changer to hack Lisp at home until I got more professional Common Lisp work.

Yeah this happened at Atlassian, beat for beat. Textbook incompetence.

HipChat was a declining dumpster fire with endless outages, so they thought they’d make a new chat platform from scratch (Stride)

So all the development effort was on Stride from that point. It was released, no one used it, and then under a year later it was shitcanned and “sold” to Slack. The dev team was RIF’d. Good shit!

Did a similar thing happen (minus the new product going away) in the Stash to Bitbucket transition? I also wonder how many people are not moving to Bitbucket Cloud when Server and Data Center are discontinued. Gitlab is still available to be self-hosted with full support.

Stash and Bitbucket “cloud” were completely different codebases. It was kind of a unique case.

The HipChat “server” was just a weird fork of the “cloud” version. JIRA and Confluent cloud started off as containerized versions of their on-prem versions. Then they did a big rewrite to make them actually multi-tenant.

I haven’t been keeping up but Stash was definitely not the priority at the time.

Bitbucket Cloud wasn't the immediate successor to Stash, though. There have been Bitbucker Server and Bitbucket DC or whatever they're called for years between the retiring of Stash and the retiring of the on-prem solutions. Where I am we already made the transition from Stash to Bitbucket on-prem (not too long after leaving Gitorious for Stash). When our executives heard "cloud VCS", we bought Gitlab licenses and are moving to that.

We also left HipChat for Slack shortly after leaving our own OpenFire server for HipChat. We recently left JSM for Zendesk because it apparently is way easier to get quality statistics out of it.

We have shadow IT programs all over the company using something other than Jira even though that's the standard the company provides.

We're moving from on-prem Confluence to cloud, but there are still many grumbles about it vs something as simple as FOSWiki or MediaWiki.

Bitbucket lost me when they dropped Mercurial support. If I've got to move to Git, anyway, why should I stick with them?

RIF’d?

"Reduction in force", similar to a layoff. A layoff happens when the company can no longer afford an employee they'd otherwise like to keep, a RIF happens when the role no longer makes sense and is closed permanently.

A related rule I've learned: when someone says that they're going to introduce a new design system (which will fix all of the problems caused by the legacy one), run.

Ask them to define the problems.

A manager start to tell everybody that we will get rip off our "old obsolete" report tool without any project, budget or research to find a replacement. We convince him to keep the tool, but the damage was done. Project, training of user, development.. everything start to stall because nobody want to work with something that will be replace. 4 years later we still have to tell people that this is still the tool to use, but everybody just think it obsolete.

The unspoken highlight of this is "don't piss off your team".

Are people unhappy? Don't work against them with another 'hidden' team. Fix the problem they keep complaining about.

If a big challenge is coming up, don't alienate the people who will be getting you through that challenge.

If you are taking over a company it may be too late! The takeover is probably done for strategic reasons benefitting shareholders only. Staff normally get fired or quit due to fit in or F off policies.

A most interesting read. Never heard of this effect. It makes sense. Maybe caught a whiff of it in some organisations. In highly compartmentalised setups you sometimes feel that another team is working directly against you. There's also the kind of anti-engineering, where one team builds a product while another within the same organisation try to break it. For example: one team is trying to make a great UI while the ad-revenue or DRM crew are screwing up the user experience sticking their oar in. These are the sort of things that lead to a feeling of betrayal, or that your team is second best. Making grand announcements that "soon everything will change" or that some hitherto secret product will upstage everything else is bound to be unsettling. If it's a secret, keep your mouth shut and quit posturing to your own congregation.

Ah yes... I have seen something like that in a previous place I worked.

One team was building a gizmo that could detect the difference between the exhaust of a fighter jet engine and the deployed countermeasures (for a missile, say).

Another team was working on countermeasures that could fool the first team's gizmo.

Fun times...

> countermeasures that could fool the first team's gizmo

And on paper, what an economy! Where else would you find engineers with the expert knowledge better placed to defeat your own toys :) fubar, what a show :)

Related evergreen post from Joel Spolksy: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

> only once—to my knowledge—made the grevious mistake of inflicting the Inner Osborne Effect on itself.

They gimped the IIgs with a lower clock rate than possible to avoid cannibalizing Macintosh. It outclassed the contemporary Mac in a number of ways.

(For people who read the comments first) the Osbourne Effect is when “a company pre-announces a future product that will obsolete the product line it’s selling today” (thereby killing current sales and revenue), and the Inner OE is when it’s the employees that are demotivated by a similar announcement (which devalues their skillset and obseletes their current project, possibly leading to mass resignations).

On the flip side, there are companies unwilling to cannibalize themselves ended up having their market share gobble up by competitors. It is a fine line to navigate

Thanks for posting this, great stuff. I haven’t seen anything from “raganwald” for a while, probably since I last bought one of his books.

I have been fairly lucky in working for mostly well run companies. It is a bad dynamic when critical parts of a company are cannibalized to help other less important teams, when legacy teams don’t get credit for keeping the lights on, etc.

The company is Netscape, right?

Doubt it .. I've seen this pattern play out with about 50% of the companies I've worked at. Looks closely enough and you'll find it everywhere. It's specifically bad with internal tools because there are no market forces at play, just CEO/CTO whim. A single person can remain irrational longer than you can likely tolerate having an unpleasant job.

If Apple did this to say their iOS team and stopped shipping OS updates for 3 years, people would switch to Android in droves.

If your companies CRM / accounting tool / PNL dashboard / etc type tool stopped getting new features for 3 years .. what happens?

Internal teams become upset, complain to the CTO who is the one who made the call.. CTO promises them the new thing is coming and will be 100x better. This can go on for a while until CTO is proven correct, starts firing sacrificial lambs on new team, or slowly backtracks and lets old team start delivering again.

In the meantime other departments jobs get slower/harder/more annoying and theres indirect, hard to measure impact on sales/revenue/profit/etc.

Reply on news.ycombinator.com