[fastball]

Right, but engineers probably are going to have some level of conviction and judgement when it comes to something they helped build. They're personally invested in a feature they've worked on.

If I was an engineer at Apple who worked on iMessage, and I heard acquaintances talk about the bugginess about iMessage, I would probably start out being defensive but then I would regret that we didn't ship a better product.

I think an EPM is less likely to feel like that, as they are not so closely tied to the actual product, which is what the Reddit poster was saying.

[vlovich123]

It's easy to blame "the other". Having worked at Apple I never felt like it was the EPM causing quality issues for us. It was us setting an aggressive schedule ourselves and, more importantly, having poor testing. The EPM was mainly just making sure tasks didn't get missed, reprioritizing them as the schedule moved based on discussions with managers & other engineers etc. Sure at some point in the schedule the central EPM committee for a release would start locking things down & punting less critical issues, but that's something that's done for every single release even for engineer-driven companies because you have to ship at some point.

Keep in mind also that these EPMs themselves tend to be fairly competent engineers in their own right so these aren't MBAs making decisions, they've just moved on as their career evolved. They care about quality just as much as anyone. The difficult part is making the call of cutting a feature especially if it's a keynote feature because there's just not enough time to actually ship it because that's predicting the future. Another difficult call is what bug constitutes a delay of an OS release, especially when the bug report may not have the necessary details to indicate it might be more critical than it seems.

TLDR: It's not as easy as saying it's all the EPMs fault. There's plenty of blame to go around because nobody is perfect & predicting the future (which is what scheduling is) is very hard.