3 ms·

I'd argue against your statement that the company doesn't: > take risks and work together When I was there, I was _constantly_ being told (as a manager in Dev

I'd argue against your statement that the company doesn't: > take risks and work together When I was there, I was _constantly_ being told (as a manager in DevDiv) that our next release had to work together with each and every new technology that might almost be ready near our ship time (Windows, SQL, Office, etc.). This added not only a huge amount of schedule risk, but dramatically slowed everything down. When your development team has to wipe their machine and install a new build of Windows every week (literally true during one ~9 month cycle of a product I was on), you lose a lot of time. Especially when those builds each pass basic smoke tests, so they're sufficient for running tests, but do not pass basic usage tests, so you can't, say, install Visual Studio successfully on some of them. Microsoft is well-practiced at the strategy of lashing together all of the boats before they head off to a battle at sea... And unfortunately I have little sympathy for people who complain about the ranking system. The numbers of "poor" ratings required were so low even back in more-aggressive days that they served more to prevent managers from copping out on delivering hard messages than unjustly delivering bad review scores. Though, certainly, many leads delivered the, "oh, so sorry, couldn't get you a better score" message. But, that's often part of why they're still leads and not managers.

Jare 14y ago
I believe the point is that while the software HAS to work together, the people (product owners and stakeholders) often don't. The result is that features cost a lot, and innovation costs even more; overall quality is driven by the lowest common denominator, and most products stagnate naturally because of that.
- larsberg 14y ago
  I certainly agree with your point about the goal and the issue in some companies. However, having seen Microsoft in action from the inside, any collaborations - most of which are _required_ at gunpoint from top-down - result in a horde of program managers shuttling themselves from building to building "owning" the X->Y relationship, one each per group-pair and arrow direction. It's a win-win for them, as those are a quicker path to promotion than trying to build up internal scope or working with the external market (godforbid <grin>). Frankly, it's really, really expensive and painful for ~2000 developers on three different teams to each be adding a slew of features with one of those teams building on top of and coordinating the other two. Even with huge amounts of communication, tracking, and the best of intents, until the products at the bottom of the chain settle down, you can't make any progress at the top. And when the top is finally making progress, you actually can put developers in front of APIs (in our case) and then you find out that the stuff at the bottom is totally unusable, but it's too late, because they finally stopped churning and want to ship soon. I don't claim there's an easy answer, but throwing more people or tools at the coordination problem doesn't (I've seen it tried).
  - Jare 14y ago
    Hehe you just described my past 9 months to the T. :) (Unrelated to Microsoft, anyway)

Jare 14y ago

I believe the point is that while the software HAS to work together, the people (product owners and stakeholders) often don't. The result is that features cost a lot, and innovation costs even more; overall quality is driven by the lowest common denominator, and most products stagnate naturally because of that.

larsberg 14y ago
I certainly agree with your point about the goal and the issue in some companies. However, having seen Microsoft in action from the inside, any collaborations - most of which are _required_ at gunpoint from top-down - result in a horde of program managers shuttling themselves from building to building "owning" the X->Y relationship, one each per group-pair and arrow direction. It's a win-win for them, as those are a quicker path to promotion than trying to build up internal scope or working with the external market (godforbid <grin>). Frankly, it's really, really expensive and painful for ~2000 developers on three different teams to each be adding a slew of features with one of those teams building on top of and coordinating the other two. Even with huge amounts of communication, tracking, and the best of intents, until the products at the bottom of the chain settle down, you can't make any progress at the top. And when the top is finally making progress, you actually can put developers in front of APIs (in our case) and then you find out that the stuff at the bottom is totally unusable, but it's too late, because they finally stopped churning and want to ship soon. I don't claim there's an easy answer, but throwing more people or tools at the coordination problem doesn't (I've seen it tried).
- Jare 14y ago
  Hehe you just described my past 9 months to the T. :) (Unrelated to Microsoft, anyway)