3 ms·
how often are you correct about your chain of reasonings as such? if it's non-negligible, would you mind sharing where I could read more of your ponderings? tha
by purplecats 6y ago
how often are you correct about your chain of reasonings as such? if it's non-negligible, would you mind sharing where I could read more of your ponderings? thanks.
- Traster 6y agoWell, on this particular topic, I used to work for Intel so a lot of it comes from knowledge of how the company works institutionally. It's difficult to explain to an outsider but Intel has this weird combination of making enormous bets but with an incredibly ossified corporate culture. So some project will get kicked off - they'll buy a company like Nervana or they'll hire in someone like Jim Keller and give them a mandate to go off and do something huge. The problem is how this intersects with the dynamics with the Intel organisation. Firstly, there's already five teams that already do whatever you want to do, so you go up the chain saying "I need 5 engineers to do X" and the answer comes back down the chain "Team Y already has 20 people, they do X, you should get them to do it". But so now rather than doing X, you're paying Team Y to do X, oh and Team Y doesn't give a shit about X, they care about Z, so about half your budget for X is now being subtly shifted to work on Z. So the cost of your project massively inflates. Oh, and because when your project was approved they canned something else, some senior executive is saying that half your headcount should be "internal transfers" so suddenly your project has to find work for 50 software engineers at Folsom who just finished working on Intel's Modem team (before that they worked on Intel's previous GPU team too before that got canned). Now comes the real issues, because you've got all these different teams that you rely on for your project and they don't answer to you, they answer to random different org structures, it's practically impossible to hold them accountable. Which leads to hilarious dynamics where team A will fall behind on their tasks, but they already know team B has fallen behind, so team A will lie about being able to deliver, because they know they'll never have to. So the critical path on your project isn't the team that's fallen behind, it's the team that's fallen behind and all the other teams that have made the calculated judgement your work can be deprioritized because team B will sink your project anyway. Finally comes the release. All of these internal fights don't change the fact that you're responsible for delivering a product to market, and almost certainly if it's an important project it'll be part of some Group's goals (like the Datacentre group or networking group). Now, the General Manager of the group isn't going to miss her/his goals. So you'll "ship" a product, by which we mean you'll send a handful of sample products to a partner. They probably wont work, they'll be a tiny subset of the functionality you originally promised. So anyway, that's the point at which someone realises we've just spent 10,000 years of engineering effort to deliver a discrete Graphics chip that is marginally less powerful than the integrated one. But the product is out there, so you've got sales data now and revenue. So you need to agree your roadmap for the future! But the first product was shit, and getting it into any sort of state to be competitive would be an enormous amount of work because it was compromised at every point, so no one will sign off on throwing good money after bad and so what happens? Nervana? Fuck you! We're betting on Habana Labs now!