It's very slow and difficult to change something that is working. It is even more difficult to change something that is both working and growing like gangbusters. And the larger something grows, the harder it is to change.
(Ironically, things with no customers are easy to change. And things that are obviously broken are also easy to change: It's broken, the worst that can happen is that it becomes twice as broken, so just go for it.)
There's a famous aphorism attributed to Napoleon: "Never interrupt your enemy while he is making a mistake." Rule zero of systems engineering is the inverse of this: Never interrupt yourself while you're succeeding. Do not kill the golden goose.
So, the first thing that has to happen for Apple to make significant changes in their process is that they have to stop succeeding so darn much. While the App Store is working they're unlikely to change the process. And, indeed, it doesn't seem like much has changed: They've fixed obviously broken things like months-long review wait times (as I said above, fixing obviously-broken things is relatively easy) but they haven't really changed the fundamental game plan. Why should they? It's raining money.
There are several reasons why it takes so long to improve working things:
Entire companies are built on the existing Apple model, broken as it may be. Break their revenue stream and these companies will scream and yell.
It's easier to swim with the tide of institutional inertia than against it. If you have to hire one hundred new App Store reviewers per month, those people need to be trained. There is (at least at first) no textbook for that job, or perhaps the manual is two years out of date. And nobody reads manuals anyway. And some important parts of any job are not written down anywhere. So the new folks will learn by watching over the shoulders of existing App Store reviewers. And so it goes: As things scale up, it becomes easier and easier to let the existing culture maintain itself, bolting on new parts as necessary, rather than try to change that culture.
When you want to change a working thing, it's not enough to show that your new version works. You must also demonstrate that it's a significant improvement over what you're doing now. This can take a lot of time. Science is patient work. If you're lucky you can run continuous A/B tests of small changes, and thereby gradually inch your way forward to a brighter future, but how do you A/B test App Store features when the developer community has a clue and a forum? Offer a feature to one developer on Monday, and by Tuesday night all the others will be at your metaphorical gate with metaphorical torches and pitchforks, demanding the feature for themselves. You have to go very slowly. It pays to do so below the radar.
(Ironically, things with no customers are easy to change. And things that are obviously broken are also easy to change: It's broken, the worst that can happen is that it becomes twice as broken, so just go for it.)
There's a famous aphorism attributed to Napoleon: "Never interrupt your enemy while he is making a mistake." Rule zero of systems engineering is the inverse of this: Never interrupt yourself while you're succeeding. Do not kill the golden goose.
So, the first thing that has to happen for Apple to make significant changes in their process is that they have to stop succeeding so darn much. While the App Store is working they're unlikely to change the process. And, indeed, it doesn't seem like much has changed: They've fixed obviously broken things like months-long review wait times (as I said above, fixing obviously-broken things is relatively easy) but they haven't really changed the fundamental game plan. Why should they? It's raining money.
There are several reasons why it takes so long to improve working things:
Entire companies are built on the existing Apple model, broken as it may be. Break their revenue stream and these companies will scream and yell.
It's easier to swim with the tide of institutional inertia than against it. If you have to hire one hundred new App Store reviewers per month, those people need to be trained. There is (at least at first) no textbook for that job, or perhaps the manual is two years out of date. And nobody reads manuals anyway. And some important parts of any job are not written down anywhere. So the new folks will learn by watching over the shoulders of existing App Store reviewers. And so it goes: As things scale up, it becomes easier and easier to let the existing culture maintain itself, bolting on new parts as necessary, rather than try to change that culture.
When you want to change a working thing, it's not enough to show that your new version works. You must also demonstrate that it's a significant improvement over what you're doing now. This can take a lot of time. Science is patient work. If you're lucky you can run continuous A/B tests of small changes, and thereby gradually inch your way forward to a brighter future, but how do you A/B test App Store features when the developer community has a clue and a forum? Offer a feature to one developer on Monday, and by Tuesday night all the others will be at your metaphorical gate with metaphorical torches and pitchforks, demanding the feature for themselves. You have to go very slowly. It pays to do so below the radar.