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?
You usually don’t get that type of appointment unless leadership is confident you’re the right person to be successful at it anyway.
While teams may vary, in my experience postmortems seek to understand where in the process a breakdown occurred, rather than fault individuals.
An SRE may be blameless for a bug but they may also be the DRI for getting an incident resolved.
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.
https://about.gitlab.com/handbook/people-group/directly-resp...
Just compare the quality of products and failure rate of the competition...
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.
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
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.
They also are very hesitant to allow researchers to publish their breakthroughs which makes recruitment very hard. Although this is changing
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.
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.
Wow. Every company in SF Bay area I worked at stressed that they don't look for who's to blame, but on how to solve the issue.
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.
It doesn't have to have anything to do with blame.
That said, from what I've heard, culture at Apple varies heavily by group and manager. There are plenty of horror stories!
- 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.