Few phrases would strike fear into the hearts of my co-workers in Austin faster than “when I worked at Microsoft”. I’ve since learned to keep my stories to myself a bit more. But recently I’ve been contemplating not what I learned at Microsoft, but instead what I’ve learned since.

At Microsoft, I was a horrible writer. I’ll be honest. I hated writing specs. Considering I was a Program Manager (PM), I think that was a bad thing (in hindsight). But I’ve realized since then that it wasn’t the writing that I hated, it was the process. I lucked out and worked with several devs for most of my career in Windows that were willing to work “on the fly” on features as we isolated the customer need. In particular, one dev and I did an immense amount of work on a key deployment feature primarily using his whiteboard and my whiteboard.

In particular, I hated the idea of creating a monolithic document that was often referred to as an “artifact”. Artifacts aren’t things that people use. Artifacts are something that archaeologists discover after great societies fail.

In 2005, while I worked at Winternals, I was offered an opportunity to write an article for TechNet Magazine. One article became 3, 3 articles became a year-long contract, and that was renewed. For many of these pieces, I largely just regurgitated knowledge about how deployment features worked based upon my deep knowledge of them. I built a quickie outline, filled it in with knowledge, made a few edit passes, and handed it off. For better or worse, most of my pieces went to publish with only a quick edit after that.

A few years later, as TechNet changed forms, my contract wasn’t renewed. For a while I wasn’t writing. In 2010 I joined Directions on Microsoft, who I had met in 2001 when describing a feature that I owned to my now colleague Michael.

Directions has a guiding tenet – the idea of uncovering the fundamental news for whatever topic you’re writing about. You have the obligation, as a writer, to describe to your reader what the feature or technology is, how it works, and how it could prove valuable to the reader (or what gotchas it brings). Many of us are ex-Microsoft, and understand the importance of approaching the idea of describing the technology not necessarily in terms of the marketing message, but instead in terms of the actual value customers can expect to find in the technology, or the complications that they may find as well.

The hardest part of becoming an effective analyst at Directions in fact has less to do with understanding how the technology you are covering works, and more with how to adequately, and accurately describe it to the reader, without overwhelming them. In short, like many kinds of sauces or foods, it’s not throwing things together quickly and eating. It’s a matter of finding the important elements, making an outline, reducing it to the important key components, and writing an effective piece. Sometimes this process takes days. sometimes it takes weeks. Sometimes you have to go through the process of letting go after you realize that there is no story there. Then several comprehensive edits later, ideally, you have a piece you can be proud of.

In this video, one of my favorites on YouTube, Apple designer Jony Ive discusses Apple’s approach to design, and in many ways, towards manufacturing. I’ve watched this many times, and what I take away from it is that good technology is complicated, and good designers do their best to buffer the end user from that complexity. Either a good designer absorbs the complexity of the technology and makes the experience approachable for the user, or a bad designer fails, and passes along the complexity of the underlying technology to the user – producing technology that is unpleasant to use, and often largely unusable.

As I read a lot of content on the Web, sometimes it drives me a bit crazy. So many articles – like my old ones at TechNet were at times – aren’t planned well, aren’t edited, ramble on, leave key points unclosed while  wasting time on chaff. All too often I click through to an article – or often a blog post – and abandon it at the 1,000 word mark, when it appears sufficiently clear that the writer lost their way in the woods, and at some point simply said, “screw it, I’m done”, and pushed publish, when they should have either saved it as a draft or just closed their browser.

Earlier tonight, I stated on Twitter that I think many of the things I’ve learned that have made me a better writer today would helped me a better PM at Microsoft. In addition to writing and editing skills, part of this is likely my own maturity, and another part is surely me having the patience to do the best job possible and taking my time to do it – even if it means cutting key work I’ve done (“murder your darlings“), or discarding an idea that is important to me personally.

Finally, another part I’ve learned is that it’s okay to write with brevity – as I always wanted to do at Microsoft – as long as you manage to clearly and accurately get the primary points across to the reader – at Microsoft, the developers, testers, user assistance writers, among others. Whether you’re a PM at Microsoft, a writer, or a blogger, I think it’s important to understand who your consumer is, what you’re trying to tell them, and if you’ve successfully transmitted your message, or whether you’ve gotten lost in the wilderness along the way.