This is from conversations with friends at Apple over the years. Apple employees: please confirm/complicate!
- Secrecy does actually get in the way. It's not great when you aren't aware of large features or products that will impact your work.
- Apple hires people who have great product design instincts, and even end-users know Apple's foundational design principles. However, lack of feedback from end-users does occasionally bite them (see: aborted Safari redesign)
- Apple takes QA very seriously and invests in high quality QA engineers. QA is not just "a step in the process" or a marginalized outsourced group.
- It's a culture of accountability, not committees. Every product and feature has a DRI (Directly Responsible Individual). When something isn't working out, the first question is "who's the DRI on this?"
- Most of the organization is highly siloed by function. This allows units to focus entirely on their objectives, which can be productive. But it makes cross-functional collaboration rare. In my opinion, this is why certain aspects of Apple's ecosystem feel disjointed, missing, or don't hang together holistically as well as they could.
> It's a culture of accountability, not committees. Every product and feature has a DRI (Directly Responsible Individual). When something isn't working out, the first question is "who's the DRI on this?"
This seems to be in contrast to the tenet of blameless postmortems [1] adopted at Google et al. Does this culture lead to blaming said responsible individual, or is the feedback seen as constructive?
That isn’t quite right. When you are appointed DRI at Apple it means you are responsible for getting that problem solved & you have the authority to move whatever mountains are in your way. I saw more people blamed for not supporting the DRI properly than I ever saw the DRI getting blamed for failing.
You usually don’t get that type of appointment unless leadership is confident you’re the right person to be successful at it anyway.
More about Directly Responsible Individuals (DRI) from gitlab-- It's an interesting organization concept imo. [1]
From the article-- Of course, when things do go wrong, it's also the DRI who (usually) takes the fall as was the case when Scott Forestall, then iOS senior vice president, was forced to resign after he "refused to sign the letter apologizing" for Apple's infamously error-laden Maps app redesign in 2011.
Some of it is just misapplied. Agile is a continuous improvement process, not an innovation process. If Apple had shipped an "MVP" smartphone in 2005, they never would have iterated their way to the iPhone we know.
But some of those buzzwords are perfectly appropriate for companies operating at a smaller scale. Apple has the ability to spend a huge amount of time and effort up-front to get the product right before it's ever announced. They're perfectly happy to spend 3 years on a product no one has seen.
Smaller companies [believe they] have to generate value faster, so they push out MVPs with the hope they can find product-market fit and iterate their way to success. For better or worse (often worse), that kind of post-launch iteration is just not in Apple's DNA. Look how little the Apple Watch software has changed in 8 years.
I don't think everyone should spend as long "perfecting" a product as Apple does, but I do think most companies could save a huge amount of time and money by doing more up-front research and design, to make sure they're building the right thing.
I don't think it is about research, design or experimentation to get product market fit but technical expertise. Just look at how Apple is organized compared to the competition - technical people lead: https://news.ycombinator.com/item?id=31052647
Proof: The majority of today's winning or great products were started by technical people. Yet the industry feels the need to systematically discover "the next Steve Jobs" with MBAs, PMs, methodologies and buzzwords to justify the success of the next innovations...
Not denying its usefulness, some of these might help but seems like too much buzz
> Apple takes QA very seriously and invests in high quality QA engineers
Willing to bet this is worth 80% of the value to the task, especially if your QA testers can write enough code to have good instincts about why something might break & control for a test environment / create novel test situations.
Siri is the biggest example, as a product which crosses SW/HW/services boundaries across nearly every device they make. Apple owns the whole stack down to the silicon, yet Siri is still not where it needs to be. Looking in from the outside, I suspect their organizational structure is standing in the way.
Yeah, I hear that. Apple's privacy position makes Siri a bigger challenge, but I don't think that alone explains why Siri is so far behind. They can do a LOT on-device these days.
I have trouble with Siri setting a timer, telling me the weather, or letting me turn on and off individual lights (it used to do this). Data mining might be some of it but I don't see how that is an issue with a timer.
I have set timers with Siri 100's of times. It's practically the only thing I do with it. Hasn't failed me once.
Just yesterday, though, I said "Hey, Siri, navigate home" and that literally got into a failed state. The first time I did it it told me I didn't have a "Home" contact, so I made it. Didn't work when I was in the car yesterday, but it did just now. So, I agree, there are issues with Siri.
And there's also the issue that it doesn't seem to have any concept of priors. Every now and then I give Siri (and Maps) a try, and it's always something like, I ask it to "navigate to [name of local business]" and it starts navigating to a business with the same name ... but 2000 miles away. Even though it does have that business on the local map...
Context is what’s missing. A dictionary of recently referred to entities. Most recent person, most recent place. Also things like current location. Am I home, am I moving, etc
Siri is great for setting timers, making calls, and changing the volume when my hands are busy.
The biggest “WTF” moment was when I was using Siri in Russian, and told it to “lower the volume” (as I’d done hundreds of times in English). It lowered Siri’s volume, but nothing else (and told me as much).
Never did figure out how to adjust my music volume with Siri in Russian.
Responsible Engineers are a thing in hardware engineering.
It’s less of making scapegoat to blame, and rather a person who has been empowered to call the shots on their product, and entrusted with knowing their product or domain inside -out like the back of their hand. If something goes wrong, you ask for the RE/DRI so you can get the person who is supposed to have all the answers, well, answer.
I think there is a clear difference between being responsible for something, and being blamed for something. There may also be overlap. My experience has been the anti blame culture (which is a good thing) has been twisted into a lack of ownership and responsibility in some orgs (which is a bad thing).
I kinda took it as more of a find the person immediately, understand the situation and why they made those choices, then find a path forward. It probably can be used nefariously, but I'll give them the benefit of the doubt.
If you want to solve an issue, it makes sense to reach out to the person who is responsible for the domain the issue is in. Nothing in the sentence you quoted implied any amount of blame.
- Secrecy does actually get in the way. It's not great when you aren't aware of large features or products that will impact your work.
- Apple hires people who have great product design instincts, and even end-users know Apple's foundational design principles. However, lack of feedback from end-users does occasionally bite them (see: aborted Safari redesign)
- Apple takes QA very seriously and invests in high quality QA engineers. QA is not just "a step in the process" or a marginalized outsourced group.
- It's a culture of accountability, not committees. Every product and feature has a DRI (Directly Responsible Individual). When something isn't working out, the first question is "who's the DRI on this?"
- Most of the organization is highly siloed by function. This allows units to focus entirely on their objectives, which can be productive. But it makes cross-functional collaboration rare. In my opinion, this is why certain aspects of Apple's ecosystem feel disjointed, missing, or don't hang together holistically as well as they could.