
Apple's organizational crossroads - wslh
https://stratechery.com/2016/apples-organizational-crossroads/
======
nocarrier
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.

