Microsoft and Making things happen
One common criticism, often mild, I hear about my book Making Things happen is it’s a Microsoft flavored book. I plead guilty. But this wasn’t for philosophical reasons, which some people seem to assume. My goal wasn’t to spread to the world how Microsoft makes software (which had already been done by Microsoft Secrets). Instead it was to use what I’d learned shipping IE 1.0 to 5.0 and other products to illustrate concepts, tactics and tricks that can apply to any kind of project whether they use similar processes or not. I needed a spine and that was one I knew well and had the most stories working with. For better or worse, Microsoft is an excellent reference point for how software, or any product is made, for a variety of reasons. But that’s all I meant it for - a system to use as leverage to explore the important stuff, not the other way around.
One of my top gripes at the time was how most project management books seemed written by consultants, people who didn’t write as if they’d actually used what they are teaching themselves (Mythical man month, for all it’s charms, is guilty of this in parts), since they couldn’t point out the common traps of their advice. The best remedy seemed to be specific, be real, tell the truth, and thus, the book came out as it did. I was, and still am, a believer in the idea of program managers, or project managers as true team leaders, and I wanted to tell the story of project management from that point of view.
In fact, if ever I write another project management book I doubt I’d even mention some of the heavier duty process stuff that shows up, however briefly, in the book. MRDs, vision documents, etc. are, as some critics pointed out, artifacts of larger organizations and many wonât have to wrestle with them, which is probably a good thing.
I’m a big believer it’s the soft skills that matter much more, and when I look back at Making things happen I see what could have been two separate books. One about process-y stuff (chapters on vision, specs, etc.) , and another about the human elements of leading projects (leadership, communication, relationships, crisis, risk, politics). I suspect people who like the book have a strong preference for one or the other. In flipping through the book it does seem to hold up the promise in the preface, that you can skip boring chapters and get value from the next - perhaps I suspected there were two books in there when I wrote it.
Anyway, its been years now and I donâ’t think I ever posted about this, despite how often I’ve seen it surface in reviews or had it come up at lectures.
What kind of idiot criticism is that!
You worked at Microsoft. You seem to have done well at Microsoft with a track record of completed projects.
Your know-how is based on what you did at Microsoft.
So why wouldn’t someone expect you to draw from that experience?
People can say what they will about Microsoft, but clearly they did not become the dominant software company they are by being idiots.
There are smart people with smart processes in place and anyone with half a brain would want to learn how things came to be.
Btw, thanks for the book Scott! I bought it when it was still the ‘The Art of Project Management.’
Contra the common criticism, I often found your Microsoft vignettes the strongest part of your writing. I haven’t forgotten the time you told your boss you were stuck despite doing everything you could, and how he gently nudged you to do the next thing and how you did it. Good writing is founded in good stories, and your microsoft stories are pretty juicy.