4 ms·
This also directly contradicts one Steve Jobs' management principles: > "Somewhere between the janitor and the CEO, reasons stop mattering," says Jobs, adding,
by electrum 9y ago
This also directly contradicts one Steve Jobs' management principles:
> "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-between-a-vice-president-and-a-janitor-2011-5 http://www.businessinsider.com/steve-jobs-on-the-difference-...
- rxhernandez 9y agoConversely you get handed a pile of steaming hot shit they call legacy code(and it lacks documentation and the variables lack names that hint at any meaning) and they're telling you it's completely your fault that you couldn't get something to work properly. Getting handed a huge amount of technical debt is a very real problem.
- vincnetas 9y agoI think "reasons stop mattering" line is higher up.
- wmeredith 9y agoUnless your VP title is window dressing, in that situation you call it like it is (garbage) and get started working on something that has a future.
- xiaq 9y agoThe industry does not lack programmers who can clean up technical debt or outright rewrite a legacy system. At least, I’m pretty sure that Apple doesn’t lack such programmers. 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.
- xiaq 9y agoA hopefull adequate comparison would be this: you are a technical lead of at a company, you get really really high pay and you have a lot of fellow engineers under your command. You get handed a legacy system, and there are all all kinds of problems with it: 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.
- knightofmars 9y agoI agree with this, the one thing I'll add is that you may also have to contend with the competing priorities of every other VP. Specifically in that Business Development VP may be saying, "We don't have time to do any of those things! We need X done now otherwise we won't get our customer!" And the technical VP response might be, "If we don't fix this now then we won't have _any_ customers." But in the end the financial state of the company will make the decision for you. If you're on the edge and you immediately need more customers to survive then you're going to forgo doing 1 & 2 and instead implement X that BD was requesting. Hoping that you can get enough breathing room in the near future to actually do 1 & 2.
- rxhernandez 9y agoDoes Apple have the resources for this project in particular? I really don't know. However in the general context, I think you lack understanding of two things: 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.