Live data from Hacker News

Apple’s Organizational Crossroads

stratechery.com

1–10 of 39 posts

Re: Apple’s Organizational Crossroads

#2
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.

Re: Apple’s Organizational Crossroads

#4
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.

Re: Apple’s Organizational Crossroads

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

Re: Apple’s Organizational Crossroads

#9
post #8

Well argued rebuttal and counter by John Kirk at Techpinions https://techpinions.com/apple-shouldnt-cross-that-road-till-...

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.

Re: Apple’s Organizational Crossroads

#10
post #9
post #8

Well argued rebuttal and counter by John Kirk at Techpinions https://techpinions.com/apple-shouldnt-cross-that-road-till-...

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.

Post reply on HN