Hacker News new | past | comments | ask | show | jobs | submit login
Apple’s Organizational Crossroads (stratechery.com)
176 points by hullo on April 24, 2016 | hide | past | favorite | 36 comments



Nah. DuPont was selling gunpowder and paint to completely different customers. Apple sells devices and services to the same customers. Furthermore what they are selling needs to be tightly integrated.


Apple Services could be sold to very different customers - those on Android and Windows devices.


This assumes Apple can get their iCloud working properly. I've avoided pings from them in the past because their is no leadership in this area. ICloud has been a failure for multiple years.

I'm not comparing management, but iCloud reminds me of the non-dropcam part of Nest - basically unable to deliver.

I've been contacted by both for roles and just think why would one want to be part of a dysfunctional after thought?


I agree that the iCloud brand has generally been a failure. Does anyone ever proudly use their @icloud.com address anywhere? MobileMe is considered an embarrassing failure by many, but I still see @me.com email addresses from time to time.

But technically, iCloud is not really one "thing". iCal, Reminders, Notes and Photos work pretty well, whereas iCloud Core Data is an unsalvageable afterthought. Working on some parts might still be fun.


Great Point.


Well argued rebuttal and counter by John Kirk at Techpinions

https://techpinions.com/apple-shouldnt-cross-that-road-till-...


Thanks, I hadn't seen that. For what it's worth, I think the rebuttal misses that Thompson wasn't actually arguing for a Services division - he was arguing that if Apple is serious about creating better services, as they are currently claiming to be, then that's what they should do. But that doesn't mean that they should be serious about services! That's basically the same conclusion that is drawn by the article you linked. (Thompson goes into this a bit more on last week's Exponent podcast, if you're into this sort of thing.)


I'm a fan of Thompson, but he's all over the map on this one. The podcast made almost zero sense.

Apple operates one of the biggest consumer services portfolios out there. Little things like iTunes, AppStore, iMessage, photos, find my iPhone, iCloud backup.

I think it makes sense that Apple would align its normal vertically integrated model.


For what it's worth, the author of the rebuttal does address your point (from "Conclusion"):

> But I don’t think Ben Thompson is actually arguing that it would be great if Apple created a new services division. I think he’s arguing that Apple should create a new services division if they want Services to be great. Ben Thompson is doing what good analysts do. He’s not giving us the right answer. He’s asking us the right question.

The rebuttal does a nice job of expanding the discussion around that question.


I think Thompson is walking back from his blog. His blog and podcast do not align. I would expect him to use the givens (Apple product culture) and come up with a strong theory around why Apple should not venture into Services.


Thanks for sharing - I wouldn't have found this otherwise.

Is anyone aggregating discussions like this today?

NYT has some opinion pieces and shares rebuttals, but I haven't seen long-form opinion aggregators around.


> Is anyone aggregating discussions like this today?

That's something I'd like to see as an official feature on HN or reddit. In addition of normal comments on the article you can also add "additional information from a qualified source" (which can be either a qualified user or another article from another reputable journalist).

But I am not sure if that would work. Perhaps it would be fine on HN, but it would be difficult to enforce and moderate on reddit.


Michael Tsai often does so on his apple-focused blog (e.g. Paid App Store Search[1]) but he hasn't gotten around to this discussion yet.

[1]http://mjtsai.com/blog/2016/04/15/paid-app-store-search/


I'd love for a TechMeme style site that sorts and organizes the articles more intelligently ( sort out the articles that just say the same thing without adding anything new, mark and organize responses and followup third party articles as 'informative', 'rebuttal', or 'support', etc.


His opinion is interesting, and leads to the question: Why shouldn't apple start a services division, with it's own process, managers and internal profit and loss, but that would have somewhat limited independence, by definition - in major decisions they would have to consult the CEO and the other divisions to make sure this doesn't interfere with the hardware products.


The idea behind Divisional Organization is that you'd motivate Services by holding them responsible and measuring success and failure via quantifiable things like turning a profit.

But a lot of what would make Services profitable isn't necessarily good for the rest of Apple: squeezing people harder to upgrade storage space for pay, paywalling popular features like Find My Phone, or selling iCloud for Android might all make Services look better on paper but hurt Apple as a whole.

Your proposed compromise, if anything, might make Services worse -- take it from someone who's been there, there's nothing more demotivating and worse for productivity than being held responsible for the bottom line while not having any authority to do anything that would improve it.

And if you're not going to hold the Division responsible for its financials, there's no benefit to moving it out of Engineering.


Great read. The big risk that Kirk doesn't mention is that Apple's hardware offerings could start to falter if they don't at least keep up with the service offerings of their competitors. Apple has been famous for creating the whole widget, the software and hardware. These days that software is services.


The question is can they compete with Amazon Prime and Microsoft OneDrive and Google Photos, etc or should they instead focus on building a great electric car to compete with Tesla.


The reason why services and devices can't be totally separated as gunpowders and paint is software. Apple's recent software qualities have been facing many challenges and varied user feedbacks, Apple Map, Siri, FinalCut update, New Photos, iCloud hack issues. I doubt their organization structure is the magic fix to their software issues, in fact, a complete separation between devices + services might make some of their software challenges even harder.


Is Amazon a good comparison? Amazon Web Services is a separate organization from the consumer side (amazon.com, zappos, etc).

As I understand it, the "jewels" (retail/consumer) do depend on AWS...they supposedly are strong on "eating your own dog food". But, they have roughly equal footing and representation. There is the difference that Amazon's services can be sold standalone, rather than just bundled, I suppose.


Amazon and AWS have different markets (consumers vs business), similar to DuPont's paint and gunpowder (consumers vs military). Generally speaking, the markets don't overlap.

As noted in other comments here, Apple's products and services are both consumer-focussed; ideally, you're trying to sell the consumer both of them, so the outcomes for the two are co-dependent. Amazon doesn't really care about how many instance-hours AWS sells; the iCloud team cares a lot about how many devices Apple sells.


Services are hardly a unique Apple specific problem though. For a few that get services right you'll find many that suck. It takes a very different collective mindset, culture, processes and iterative improvements - those are a no brainer. Beyond those it also takes unconventional innovation at multiple different levels - look at how HTTP2 happened for example and look at how everything underneath GMail must have improved to make it what it is. Also think of AWS and how many first-have problems they must have needed to solve.

It's hard to get services right and even harder to keep them right. I am of course not saying Apple can't get there but merely separating the hardware and software/services isn't a meaningful first step.


I don't know about processes or mindset; I think it's mostly a matter of hiring real Engineers and letting them do real Engineering on your backend. That's a cultural problem, though, on an organizational level: if you run everything in the "20-somethings burning midnight oil to ship" mode, the experienced Engineers don't want to join you. You'd have to shift your culture into one that has room for them (like e.g. Facebook is continuing to attempt to do with the Engineers from Whatsapp.)


This article makes the case Apple should have a dedicated Services division.

Pretty sure Eddy Cue runs a division called "Internet Software and Services" which is iCloud/Maps/Siri etc: http://www.apple.com/pr/bios/eddy-cue.html

Article: 0 Fact: 1


Yes, but what Ben is proposing is that instead of being a functional division, it would be it's own business unit reporting it's own profit-and-loss. That might even mean having it's own engineering team, it's own design team, it's own sales, etc, etc. Maybe not all of those, but certainly some of them.


This is the road that IBM and HP went down, isn't it?

Stop making things and start providing services around the things you used to make.


This is dated 4/19, but I would swear I've read this (and seen the same organizational graphics) before. Was this already posted somewhere else? Is this a summary of a bigger work that is getting the summary treatment on multiple sites?

Weird.


Ah. Realized it was probably the discussion of Microsoft in 2013 on the same site.

https://stratechery.com/2013/why-microsofts-reorganization-i...


His stuff always has that style of graphics, and I believe that graphic was used in a different post a year or so that went into more detail about horizontal/vertical organizations.

Edit: I see you found it


The scary example against the "separation" the author suggests is Sony, having the structure where the different profits and loses produced the results where one Sony makes another Sony worse and vice versa.


fascinating thought is what a well-run services Org looks like?

and how that can layer onto a hardware / device Org.. they never seem compatible


This post makes the case that Apple is not organized in a way to allow it to effectively run services like iCloud, iTunes, Apple Pay, etc. I haven't worked there in ten years, but back then at least, I'd agree with that. Teams and orgs were heavily siloed and vertical.

However, then it goes on to say a few things that I think are harder to defend. The author talks about how it's hard for Apple to build good services since they're so focused on achieving perfection with a tightly integrated device that has a new release once or twice a year. Basically, the thesis is that since the market penalty for releasing a bad device is so high, Apple has thrown a lot of resources into getting the device right the first time, which makes it very hard for them to think or operate at the tempo you need when operating services:

"You only get one shot to get a device right, so all of Apple’s internal rhythms and processes are organized around delivering as perfect a product as possible at a specific moment in time."

This isn't right in a couple ways. First, Apple has released all kinds of sub-par hardware in the past. And will likely do so in the future. Apple says they are looking to achieve perfection, and it sounds noble, but it's more of an iterative process than this article makes it sound like.

Second, many of a device's features, especially the integration that the author lauds, are actually in software. Particularly the integration pieces that make the device seem like magic. And those are updated often as one can see with the release tempo of iOS updates. The pattern has been the same for a long time--release a bunch of new features in iOS X.0, then do point releases to fix bugs, plug security holes, and make minor tweaks to fix annoying things and make the user experience feel more smooth.

The other conclusion I don't agree with is that the author says that in order for them to build better services, they need more accountability, which would be achieved by tracking profit and loss for each service and making the leaders financially accountable. I agree that accountability is something that's required to create strong services, but it's not the primary lever I would use. And I certainly wouldn't bring P&L into the accountability equation since that incentivizes the different service orgs to grow adversarial relationships. It's old company thinking IMO.

Instead, I feel you need to build better services by building a better infrastructure culture. A lot of people look at situations like this and look for punitive or regressive measures to fix the problem, i.e. using the stick instead of the carrot. I think however they would build better services by focusing on other levers like open communication (the heavy siloing meant a lot of duplicated work), being open to criticism (lots of politics and defensiveness meant fiefdoms and grudges were created), a focus on instrumenting and measuring performance of services to have the right picture for how everything is working together (instrumentation and visualization of performance was terrible), a culture of learning from mistakes instead of assigning blame, having embedded SRE-like engineers who focus on production quality and availability instead of having separate second-class ops teams, etc. I could go on, but I have a really strong objection to boiling all their problems down to not making each service unit financially accountable. That won't fix things, it will instead make the internal culture on the infrastructure side much worse.


The comment was marked as "dupe" but I don't see why so I vouch it. Is it a bug ?


Check the guys comments to see the dupe. He posted the same comment to a separate submission of this article.

https://news.ycombinator.com/item?id=11559781


Yeah, I didn't realize you couldn't do that. Next time I'll just put a link to the comment versus pasting it verbatim.


this article is all fluff.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: