Wow. It those were his original words, I don't doubt a bit that this guy should be responsible for Siri being left behind.
> "Somewhere between the janitor and the CEO, reasons stop mattering," says Jobs, adding, that Rubicon is "crossed when you become a VP."
> In other words, you have no excuse for failure. You are now responsible for any mistakes that happen, and it doesn't matter what you say.
http://www.businessinsider.com/steve-jobs-on-the-difference-...
A VP’s job is to find those people and give them the correct incentives. The VP has the rights to hire new people and restructure teams. The VP should use those leverages.
At the VP level, how a particular codebase or team is doing simply doesn’t matter, as the VP has all the leverages for organizational shifts. Blaming a codebase or team only makes sense if the whole company cannot produce quality code, and it’s impossible to hire new employees that can. I am pretty sure that this is not the case for Apple.
1. The system uses a database that is not duplicated.
2. The system has no monitoring.
3. The web frontend is written in PHP.
What do you do?
To fix 1, duplicate the freaking database.
To fix 2, add some freaking monitoring.
3 is presumably the hardest to fix. But remember that you get really high pay and you have a lot of engineers. What did the engineers at Facebook do? They fixed PHP.
Do you blame the previous team that made this horrible system? No. No. No. You own the system now. There are valid engineering approaches to fix. So fix it. It can take a while, but eventually you can fix it. In the worst case, you will have to rewrite. But that's still a feasible thing to do.
Now substitute technical lead with VP.
1. You cannot simply put your standard programmer(or any number of them) with undergrad (even with superb knowledge) of combinatorial algoritms in the former position of someone with a graduate degree that focused on algorithms engineering who didn't give a damn about even the smallest aspects of software engineering like version control or documentation. You have even less ability to do this on an embedded device for numerically sensitive algorithms. I've been in this position (except with a far broader background in mathematics and algorithms engineering) at least a couple times with other engineers with graduate degrees in the requisite areas and (I'm not exaggerating) it is truly a fucking nightmare.
2. Just because you are a VP doesn't mean your managers are willing to approve the amount money that goes into a number of algorithms engineers fixing or rewriting a product that just barely functions well enough. I am incredibly close to a couple people that are VPs at companies with ~10,000 people and you would be surprised with how little power they can have on hiring sometimes. Companies are not bottomless pits of money and the people at the top usually treat it as such.
Honestly, I don’t know the full details, but I still hold that Forstall took the fall for the poor execution of Williamson in the Maps debacle.
Well that's not true because Eddy Cue fired Williamson [1]. Maps might have been the straw that broke the camel's back, but Forstall was fired also because he couldn't work well with Bob Mansfield (who came back out of retirement after he was gone [2]) and Jony Ive.
[1] https://www.cultofmac.com/203032/apple-svp-eddy-cue-fires-ri...
[2] http://allthingsd.com/20121101/behind-silicon-valleys-un-ret...
Surprising that a person at his level wouldn't be mature enough and self-aware enough to realize that.
"@Jessicalessin This statement, wholly false, was made by the architect and head of the biggest launch disaster in Apple history, Apple Maps. In reality Siri worked great at launch but, like any new platform under unexpectedly massive load, required scaling adjustments and 24 hour workdays."
Apple Maps is remarkably good today, doing nearly all of the important things well. Here in Australia, it's on par with Google Maps for driving (slightly worse for novel route planning, slightly better for guidance) and when travelling to major world cities I've found Apple Maps is frequently better than Google Maps for navigating on foot and public transport.
Google Maps now provides wholly personalized points of interest and attention affordances in its UI. It's also well on its way to 3D scanning and annotating POIs in every structure in the world, including very large pedestrian-only interiors. It also has realtime transit and traffic feeds, and more pedestrian trails and venue detail than anyone else. All of these are areas where its competition is not just behind, but falling further behind. But the personalization combined with superior POI search really illustrates how Google's competitors don't even have the platform to properly conceptualize the type of product Google is building, much less build it.
TomTom just don't have this issue, I've been using it for 5 years now and it's never done anything like that. Also TomTom Traffic is vastly better than Google Traffic, consistently beating it for time and route prediction(I've been driving with Android Auto and TomTom 5000 set up side by side for a while, and if TomTom suggests a detour it's usually a good one - take the one google suggests and you're getting stuck on some small street that google thinks you can drive through but you actually can't).
Also anecdotally I’m not sure if I can agree that Google’s POIs are vastly better, mostly just different but of a similar low quality (which is to say neither pleases me).
Both maps have similarly good cartography where it matters. In most countries, both maps are similarly accurate.
I find it interesting that Google doesn't care enough to add the most recent several metro lines in (for example) Beijing or Shanghai, considering that many people try to use Google Maps in China when visiting and usually seem to end up switching to Apple Maps as a result of the complete trash the Google Maps experience is there. I wonder if they switch back when they go home.
It's good enough that I use it primarily on my phone over Google Maps, in the UK
When you set hard deadlines for software release dates because you want to have tentpole features for IOS releases, and you mostly refuse to do widespread beta tests because then it won't be surprising, you're creating the maps debacle. Now I'm sure maps was harder than it looked, but I'd also bet lots of people on the inside knew that. They should have let the date slip.
They couldn't let the date slip, because the deal with Google was set to expire and not having a built-in maps application at all was not an option.
The question you need to ask is, did a pushy management style make Apple Maps better than it would have been otherwise or worse. I think it's hard to argue that pushing the team hard didn't produce a better product than they would have had otherwise.
We are hitting territory where there are now problems so hard that it will now take time to create the software. He never got that.