My First Week on a Microsoft Product Team: Wallowing

Last week was my first week on my new team. A lot of interesting things happened, some of which Don has already mentioned. For me, two especially interesting things happened. One, I found out why I was hired, in spite of my preference to work from kitchen most of the time, even though I’m working on a product group (which typically avoids my kind unless they’ve already worked for the team for a long time) and even though I’m working for a manager that’s never had a remote employee (he doesn’t even run IM!). Don’t get me wrong; it’s not like a skated through the interview process w/o “passing.” But “passing” isn’t enough when you work in a “shower optional” environment (my house, not Microsoft : ). My team needs people with a skill that I’ve never seen applied to product development. Most of the people that have this skill are either a) already busy shipping Indigo or b) marked as a target (some of you should feel the laser sights on your forehead : ). The skill is the thing that allows me to write books and articles in my own special way. My team has a name for this skill; it’s called “wallowing.”

For my team, the ability to “wallow” means the ability to dig into a discipline, any discipline, and “wallow like a pig in the mud” in that new discipline, forming questions, getting to the root of things, gathering fragmented truths together into wholes, communicating the truths to each other, gaining intuition, and generally spending time understanding the space without first coming to firm conclusions about what it is that we’re actually going to build. This skill is by far the most important thing I learned at DevelopMentor. The “popping” sound I got in my head when I finally figured out COM is something that I’ll never forget (mostly because my head stopped hurting after 6 weeks of hurting very much) and it’s served me well over the years. For example, I wrote my WinForms book not because I had a ton of “real-world experience” as my Amazon reviews claim, but because I knew very little about WinForms and was interested in learning. I wallowed in WinForms for 9 months, writing articles and an instructor-led short-course before ever writing a single word in my book. Once I’d wallowed, however, I was able to write the book itself in 5 months.

So, while I’ve used to wallowing as a way to produce talks and prose, it’s not a technique I’ve ever applied to product selection. In the past, I’ve come to a team where the goal was very clearly known, although the details were still up in the air (often ’til they were discovered as coding problems). I’ve even started my own software organization from scratch, but only after the core vision of what needed building came to me whole and I’d already built the prototype. However, with my new team, we’ve got a group of folks actively wallowing in a space, figuring out the right thing to build. This led to some initial frustration on my part.

Actually, frustration is too weak; for the 3 days of my employment, I was a drooling idiot with no hope of recovery. I’m used to not knowing stuff (that’s when the wallowing behavior is triggered), but I’m not used to not knowing what I don’t know. The reason that I was so frustrated was that I didn’t know my team was wallowing. My team has already been working together in this problem space for months. They’ve already put together a prototype and showed it to BillG. This evidence made think that the team already had a firm vision of what they were building, so I was in coming-to-a-team-to-help-build-a-known-product-mode as with every single product team I’d ever been on or heard of.

Firmly in this mode, I spent my first 3 days in architecture meetings, brainstorming our way through the main issues of our “product.” At each meeting, it seemed like people had a firm idea of what they were building, because the items on the brainstorm list flowed like water from everyone but me. To give myself some ground on which to stand, I kept asking whether we were going to cover this customer scenario or that one and the answer would always be “yes.”

This went on for three days and each day I felt like I knew less about what we were doing. Instead of drawing up a plan to build a v1 settlement on the moon, I felt like we were listing the issues associated with covering the entire surface with a 10-story city. My head was swimming. How could a brand new team be targeting that kind of scope? What the hell had I gotten myself into?!?

I’m not the kind of person that keeps frustration to myself. I spent a good deal of time trying to express my despair to my boss and my new team mates, but it took me 3 days to be able to wind back my assumptions enough to be able to ask, “Do we even know what we’re building?” The answer that shined light into my gloom was “no, we’re wallowing.”

And suddenly, all the conversations made sense. When they kept saying “yes,” they meant “yes, we’re still considering that possibility.” We were discussing enough issues to cover the surface of the moon not because we were going to do that in v1, but because we were still figuring out the right place and kind of settlement to build. We’d picked the moon and we’d put up a tiny shed to see what it was like to live there, but we hadn’t yet figured out what the next wave of settlers would need. And because we didn’t want to die in the process or kill that next wave, we were going to spend some real time exploring to make sure we were proud of our first city.

This process was a revelation to me. In the small to medium-sized software engineering projects in which I’d been involved to date, this kind of product planning was outside of my experience. I mean, even when I plan to wallow in the implementation details, I’ve never once wallowed in the issue of what to build. When I picked my WinForms book, I didn’t survey the .NET developer landscape for their needs; I just picked something I was interested in. I got lucky, but in the case of other projects, I have been less so (and sometimes expensively, spectacularly less lucky).

I told my sister-in-law this story and she was all ready to be upset for me. “You mean, they never told you? You signed up to do product development and they don’t even know what they’re building?” she asked. I told her that I wasn’t upset at all. In retrospect, I was told that my team was wallowing, it’s just that my preconceptions about what a product team does at Microsoft blocked it out.

Further, this way of figuring out what to build is one I’m looking forward to. I’ve never been any good at this part of the product construction process. In fact, I once drove 2 hours north and cajoled Eric Sink into driving 2 hours south so that I could ask him how to answer this very question (micro-ISVs sound cool, don’t they?). His advice was “fail fast.” That’s good advice and, having talked to my new boss, it’s something we’ll be doing, but we hope to do it while exercising wallowing as a product selection technique.

The second thing I learned this week is that, while I didn’t know this ’til after my 3rd day, my team is still wallowing. I told my sister-in-law that I wasn’t upset at all. I love wallowing. : )