Hacker News new | comments | show | ask | jobs | submit login

Perfect time for the ol' throwaway...

I'm a former iOS EPM (not speaking for Apple, obviously, since I don't work there anymore), and although the Reddit commenter got the atmosphere of constant crisis right, he/she is misplacing the blame and misunderstanding the power dynamic. EPMs at Apple essentially have zero power over engineers' workload. They take the list of stuff the engineering managers said they want to get done this year and say "You guys are crazy, you'll never be able to do this without 3x the hours/manpower." Then they proceed to drive the team as hard as necessary to make sure that they actually deliver what they said they were going to deliver. That's it. The idea that there is this cabal of mighty EPMs twirling their mustaches and loading developers down with work is pretty far from reality.

It's true that you shouldn't be working on anything not in Radar (the bug tracker) but this is true anywhere you'll work. Project managers however do not sign developers up for all those radars--on the contrary--we're usually trying desperately to help you get rid of scope and get the task list down to what's actually do-able!

One of the great things that IMHO sets Apple apart is how engineering-driven they are. I've never worked anywhere else where engineers had so much freedom to decide what they're working on. The fact that they always decide to work on 3x what they can actually achieve is kind of on them. But that drive to try to do so much is part of what keeps innovation strong at Apple.




The comment was half-right in describing the situation radar-obsessed culture (Radar-Driven Development?)

It places the blame on EPMs because EPMs are just the bearer of bad news, middlemen who carry out the whims of the UI Gods and VPs. The original commenter couldn't see those above the EPMs, the ones overseeing the BRBs and other inquisitions.


We use the bug tracker for coordination and collaboration. If you have a customer-affecting bug or a stakeholder-facing feature you’ll use the relevant task to discuss it, but we certainly don’t let the bug tracker dictate how engineers spend their time. That sounds like hell.


That's the norm in any medium to large sized engineering organization. PMs set out what needs to be worked on and want to know the progress on these tickets. How is that unreasonable? Maybe it would help if you referred to it as a sprint board rather than a bug tracker?


Within the project I was assigned this quarter, I decide what needs to be worked on. Most of the tasks on my screen were created by me and represent details that my product manager neither understands nor cares about. They're involved in master tasks for deliverable units of functionality and inbound bugs/feature requests. My PM and EM like to hear progress and like to have some idea of what I'll be doing in the coming week, but I'll pretty often have and scratch an itch in the same day, without necessarily going through the motions of writing up a task. (We do have code review, and I'll probably mention it at standup). The existence and level of detail in a task really depends on the number of people who need to be involved and how much we need async communication.

If this is atypical, I'm terrified to ever leave my large engineering organization - it's a pretty great model for the work we do.


> Then they proceed to drive the team as hard as necessary to make sure that they actually deliver what they said they were going to deliver.

Sounds like really healthy practice


I think the craziest thing about this comment is how juxtaposed it is to the original one. How you could have such divergent opinions on org structure or team dynamic is mind blowing.


The fundamental unit of team dynamics is what, maybe 8 engineers? Companies like Apple have thousands.

Even working somewhere, sure, you'll know what the adjacent teams in your org are like, and maybe you'll meet some internal transfers, but the truth is you have no idea what life is like for the thousands you'll never meet. There might be broad strokes that differentiate the company from its peers, but only the vaguest outline is going to be universally or even mostly true.


Well this just further convinces me that Apple’s problem is lack of man hours. If the problems are due to trying/wanting 3x what your capable of... you’ve got two options. A: reduce your expectations. B: increase your capacity so you can achieve it.

Given Apple has a pile of cash so large it could do pretty much anything it wants... and have had for several years now... I’ve begun viewing their continued unwillingness to aggressively pursue opinion B as a failure of “upper middle management” who are clearly either suppressing the needs coming up from below, or in the very least, not pushing hard enough to their bosses that their teams are under resourced for achieving the companies goals.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: