* Command and Control: Mission Command vs. Detailed Command (link goes to a chart that she showed in a slide). Two extreme leadership styles contrasted. With respect to software development processes, Mission Command is evocative of Agile while Detailed Command seems more like Waterfall.
* "Pull scheduling" or "pull system". This is a concept from Lean Manufacturing (with which I am not very familiar). Mary tells a story about implementing this at a videotape production plant and improving "pack out" (production rates?) from 60% to 95%. The presentation doesn't really explain what this is but has the following(0:49:59): "Having moved from a scheduling system that was push, to a pull system, and seeing the difference, I never believed that if you guys would only try harder to meet your project deadlines, that you know, it all would be perfect. Probably you'll get 60% performance against plan on a week to week basis. Anything that's scheduled at a detailed level, that's pretty much what you get. And if you switch to a pull system instead, you'll probably do a whole lot better." This has sparked my interest to study the difference between push and pull production, for which I think I have to go to lean manufacturing and software development books and articles.
* Developing a process change (when they went to implement the pull system at the videotape production plant) via a simulation: they used styrofoam coffee cups and went through many iterations of the simulation with more and more people and in more and more detail. I have been involved in implementing Scrum from scratch in two different groups at this point, and in general we have just launched, hoped it would go OK, and tried to fix it up as we went along. Practicing the process ahead of time with role playing might be a good way to work out obvious problems and gain confidence and buy-in with the new process before jumping in.
* Mary says that the leadership structure that has worked the best in her experience, in any kind of development business (product or software), has involved two kinds of leaders. One, the "product leader" who owns the vision and architecture of the project, and who combines both marketing and technical expertise to set the direction and ensure product success. (This can be two people, but at Toyota, for example, this role was filled by a technical person, the "Chief Engineer," who had access to marketing expertise to inform decisions.) Two, there were functional leaders, who were responsible for developing people, capturing and maintaining functional knowledge and best practices, etc. The resulting setup was described as a "matrix" organization though I have only ever heard the term "matrix organization" in a negative context. Here it seemed to make sense. I also thought this was interesting because at Microsoft, the program manager seems like a close analog to the "product leader" with its combined marketing and technical expertise. However, what Mary described made me envision more like an architect than a PM.