support serf to writer: part IV

this is part III of a story about software support and how I moved through various jobs...
part I - support serf to writer: a how-to
part II - support serf to writer: part II
part III - support serf to writer: part III

after the MCMS pre-sales program in Redmond was a success, I started working on the sample site for MCMS 2002. the new .Net platform was all the rage amongst developers so the MCMS management decided that .Net would be the main focus of the MCMS 2002 product cycle. this meant that I had the opportunity to develop the Woodgrove.Net sample site. I was thrilled to be working with the new C# language. even though it was primarily a porting exercise, I greatly enjoyed the project.

based more on my commitment to the job than my development skills, I was offered a position as a web developer on the MCMS product team. since the .com bubble burst, most companies have reduced the size of their web teams. Microsoft is no exception. consequently, the title of "web developer" is rarely used. in addition, unlike most Microsoft jobs, there is no defined career path for web developers. in other words, if I ever wanted to change jobs, I would have a tough time.

when my new manager suggested that I should move to the role of Program Manager, I jumped at the chance. instead of writing the code for the sample sites, I was now responsible for the specifications. I found this to be interesting work but frustrating at the same time. when you create specs, you have the ability to bring forth your idea of what a feature should look like. however, it's very rare that anything that a PM does will actually get to the customer. PMs at Microsoft love to say "we don't ship the specs".

the problem with the Microsoft system is that if a dev feels that a PM is making a mistake, she can change the dev estimates in favour of the way that she believes the feature should be designed. this sort of maneuvering ability requires that all the groups within the product team to be on good terms and working towards the same goal. in Barbarians led by Bill Gates, Marlin Eller argues that developers don't need PMs at all. I personally feel that this is a ridiculous assertion. having specifications is crucial to the software development process. the number of potential bugs that are avoided in the spec phase is substantial.

after being with the product group for awhile, I thought that it would be a good idea to write a book about the new MCMS .Net Application Programming Interface (API). we happened to be talking to MSPress about porting their site to MCMS so it was easy for me to get the right contact information. I sent a proposal to an internal publishing agent and she told me that there was already an MCMS book underway. she contacted the group and they asked me if I wanted to join their writing team. the result was Microsoft Content Management Server 2002: A Complete Guide for Addison-Wesley.

I do regret the fact that the first MCMS book wasn't done with the guys who started the project at NCompass. however, I was excited to have the opportunity to do some writing. it was clear to me that my goal of getting more technical was outdated. I wasn't going to be a hardcore developer so I figured that getting back to my passion for writing was the obvious choice. even though my US work permit prevented me from accepting any compensation for the book, I gladly accepted the invitation to join the project.

the team leader for the MCMS book was Bill English, a veteran writer who had already written a couple of books about SharePoint. the other writers were Olga Londer, Todd Bleeker and Shawn Shell; the Addison-Wesley editor was Sondra Scott. I hadn't met any of the other writers before the project began. however, Shawn was one of the most experience MCMS consultants in the world. over the years, I had exchanged e-mails with him about various projects.

since I was late joining the project, I was given fewer chapters than most of the other writers. however, I was pleased with the ones that I was assigned. for example, I was given the architecture chapter - one that I was hoping to write.

another side effect of joining late, was that I found the schedule to be aggressive. like the other authors, I had a full-time job so I could only write during evenings and weekends. however, now that I've worked on other projects, I realize how naive I was about the schedule. even with a job to consider, the schedule was less aggressive than most.

<how-to section>
as soon as I was given my chapter assignments, I started working on the architecture chapter. I talked to the devs and put together my first rough draft. in an effort to gather some feedback, I sent the early draft to some of my friends. one of the MCMS devs responded to my request with the criticism that my chapter "didn't look like it was written by a 'writer'". it was the most honest feedback I had received and I felt that I was truly fortunate to have friends who would be so frank. if you aren't getting honest feedback, you aren't getting feedback.
</how-to section>

having realized that I was far from my goal of becoming a writer, I began an ongoing effort to improve my skills. although I haven't pursued any formal training, I am still considering the idea.

the MCMS book made it to a second printing so it was considered a success. I enjoyed the experience so much that I decided that I wanted to write full-time. fortunately, I figured this out at the end of my days with Microsoft. after marrying my Canadian girlfriend, I knew that it was time to move back to Canada.

I sent out some quick e-mails letting my friends in the publishing business know that I was interested in more writing projects. although working hard will create opportunity, I feel that there have been a few times when I have simply been lucky. this was one of these times. without my knowledge, one of the writers, contacted an agent and told him that I was interested in a writing career. the agent called me up and we started talking.

after a short time, it was clear to me that the StudioB agent was more than qualified to help me map out my career. we started exchanging ideas about books that I could write. I expected to be writing about things such as ASP.Net or content management. however, when I mentioned that I had been a Beta tester for Halo 2, everything changed. I wrote up a proposal for a book about Halo 2 combat techniques and the agent sent it to some publishers. the first day he sent it out, three or four publishers expressed interest.

<how-to section>
finding an agent was essential to my ability to write full-time. I would strongly recommend that all new writers seek out a skilled agent.
</how-to section>

I moved back to Canada and I started work on The Unauthorized Halo 2 Battle Guide: Advanced Combat Techniques for Premier Press Game Development (Thompson Course Technology). the project went extremely well and it led to other book deals. I am currently working on Halo books for O'Reilly and Sams.

in the end, I feel that it was working on project-based hobbies that reduced the friction of moving from one position to another -- a little luck didn't hurt either.