gavinshearer.com

« Escaping From Alcatraz: June 8, 2008 | Main | Marianne Stanley To Coach The Storm? »

December 19, 2007

Scale

It's the holiday time of year, which means that Elaine and I have been catching up with old friends at parties and family gatherings. Time and again, I keep getting asked about my "new" (four months in, and it's still "new") job at MacBU - what it's like, what a "program manager" actually does, and so on.

Generally, I get asked what I like about the new gig, or what's surprised me the most. The answer is the same: scale.

I've spent my entire career in tech, doing services (Internet access/Web hosting), custom software (Web application development), and consulting. In each of these areas, I've always seen through the lens of a small business - my partners and I had companies that offered something to a defined population, and we customized, where possible, for specific audiences and needs. In many ways, this was the geek equivalent of running a Saturday-afternoon lemonade stand - you brew your lemonade, hang out a shingle, and look for thirsty customers. Since you're the one selling the lemonade, you have a personal encounter with most everyone you do business with. Your transactions are in your native language, and likely all in cash. The product you're selling is the product you've got - there's no customization or after-market. It's a simple business, and a satisfying one.

Making software that's used by millions of people, by contrast, is not a simple business.

Let's take the product I deal with - Office for Macintosh - as an example.

First, Mac Office isn't just used by one type of person - it's used by millions of different people. We use research to develop customer segmentations and personas that we can rely on to help guide our product investments. However, the devil is in the details - if you're trying to cater the product to a user that is less technical, say, then you need to do a good job of remembering what problem you're actually helping them solve (as the old saying goes, "Nobody buys a drill; rather, people buy a 2" hole in their wall").

Your feature needs to be built in such a way that it's also attractive, as much as possible, to other customer segments, who will have different assumptions about what your feature should or should not allow them to do. You're forever trading off complexity for simplicity - what's "flexible" to one person is "confusing as hell" to another. Product designs have to be tested, tested, and tested again - you can't just put a crazy idea in the box and ship it.

Second, Mac Office comes in a number of languages (English, Japanese, French, German, Spanish, and so on). Consequently, the product is sold in a number of different countries, each with their own specific market requirements and government regulations. As a practical matter, this means we have to have people who are doing translation and localization work, but it also means that, as product designers, we have to worry about specific aspects of the product that you might not think about.

Small things - an icon, say - might be just fine in the United States, but be really offensive to members of a certain group in another country. "Smiley faces", for instance, can imply one thing in one culture (e.g., happiness), and something else again somewhere else. We have teams of people who are responsible for ensuring that our products have been checked for just this sort of thing, and are acceptable to a global audience.

Third, Mac Office isn't just used by the people who buy the product at the Apple Store. There are lots of people who are responsible for installing, updating, and supporting our software (e.g., IT administrators at universities or corporations; parents on computers at home), many of whom have concerns about keeping their systems stable, secure, and available. We have people who work on things like the Installer - something that many people don't think about (most end users only fire up the installer once, when they first get the product), but that are critically important to this community. We have people who worry about security, people who worry about "sustained engineering" (those are the friendly folks who bring you the .1, .2, and .3 updates), and people who do nothing but bang on our products all day long and try to break them before customers get their hands on them. Each of these teams has its own set of requirements and concerns, and many of these teams can prevent the product from shipping if they feel that their concerns are not being addressed.

Fourth, Mac Office has a partner community - people who have extended our products with their own code or intellectual property. Much of our product can be accessed programmatically, using macro languages in the products themselves, or external languages like AppleScript. When you design a feature, you need to think about how someone might want to access it programmatically - how they might want to build on top of your stuff. You also need to make sure that this has been well-tested by your colleagues in quality control.

I could go on, but I think I've made my point - at scale, software is much, much more than it appears to be, and has some incredibly important aspects (e.g., security, quality testing) that users never see.

(Since arriving, I've felt a bit like Charlie, getting a tour of the Wonka factory.)

I mean, I knew this stuff existed - I saw it, at lemonade-stand scale, when I was working for myself - but to actually step on to the factory floor and see the blue ball machine running full-tilt ... it's a bit dizzying.

One intriguing aspect to all this is that no change is simple. God knows I've sat in front of software on more than one occasion and proclaimed, "Augh! If only this product did [blank] - I mean, how hard can it be?"

Answer: damn hard. There's no such thing as a "simple" change, because even "simple" changes need to be run through the necessary machinery to ensure they're not introducing more problems than they're solving. You think that menu item should use slightly-different wording? Great, let's change it ... but we need to make sure that it doesn't break a partner solution, or cause a localization issue, or make the product harder to understand by novice users.

Learning what it's like to work at scale has been the most eye-opening thing about my new job. And, in truth, it was a big part of what drew me to the position. My contributions to our 2008 release notwithstanding, I've never shipped a shrink-wrapped product before, and I figured it was a skill well worth learning. (And not "learn" in the sense of "I understand, conceptually, how this process is accomplished", but rather "learn" in the sense of "I've got mud on my face and shredded clothes after crawling through the rainstorms and razor wire of getting the thing out the door.")

Hence: Gavin Shearer, Program Manager, MacBU.

I expect the next few years to be incredibly fascinating.

Posted by Gavin Shearer at December 19, 2007 8:47 PM. Posted to MSFT.

Trackback Pings

TrackBack URL for this entry:
http://www.gavinshearer.com/weblog/mt-tb.cgi/135

Comments

Posted by: E.Chen at December 20, 2007 9:45 PM

Post a comment

« Escaping From Alcatraz: June 8, 2008 | Main | Marianne Stanley To Coach The Storm? »