Hacker News Reader

> 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?

[1] https://sre.google/sre-book/postmortem-culture/

> This seems to be in contrast to the tenet of blameless postmortems [1] adopted at Google et al.

While teams may vary, in my experience postmortems seek to understand where in the process a breakdown occurred, rather than fault individuals.

Blame and responsibility can be orthogonal concepts.

An SRE may be blameless for a bug but they may also be the DRI for getting an incident resolved.

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.

https://about.gitlab.com/handbook/people-group/directly-resp...

Is he the one directly responsible for the Silicon Valley "It's Apple Maps Bad" scene?

https://www.youtube.com/watch?v=tVq1wgIN62E

My employer stopped promoting QA and the best ones all went to Apple.

Makes you wonder if modern product practices and buzzwords (agile, ux, mvp, etc) is all nonsense

Just compare the quality of products and failure rate of the competition...

Ex: https://news.ycombinator.com/item?id=31069434

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.

Could you please give an example what could be better holistically / what other company does it well?

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.

Siri is not where it needs to be because Apple refuses to mine user data to enrich it.

They also are very hesitant to allow researchers to publish their breakthroughs which makes recruitment very hard. Although this is changing

https://machinelearning.apple.com/

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.

Sounds like a genuinely very impressive setup.

> When something isn't working out, the first question is "who's the DRI on this?"

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.

In many cases, the first step in "how to solve the issue" is "who is responsible for this?"

It doesn't have to have anything to do with blame.

Yes, as in who knows this component more in-depth than anyone else in the company and is best able to solve any problem with it?

The intent is not (or shouldn't be) to find a scapegoat—it's so others know WHO exactly is going to help resolve the issue.

That said, from what I've heard, culture at Apple varies heavily by group and manager. There are plenty of horror stories!

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

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.

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