Steven Sinofsky's Microsoft TechTalk : My Favorites

Interns -- the intern experience in Office

steven_sinofsky — Fri, 24 Feb 2006 01:00:00 GMT

We’re actively hiring interns from the college campuses we visit. I wanted to use this as an opportunity to talk about what it is like to be an intern in Office.

You can read about the specifics of the intern program on the intern web site: http://www.microsoft.com/college/ip_overview.mspx. You can read about the job types available (SDE, SDET, PM) on the product groups as well as the structure of the internship (12 weeks min), and the benefits (endless fun). I’m going to focus on the part I like the most which is the work you get to do on Office.

First and foremost, as an intern you are considered a regular member of the team from the day you start. There is a lot of opportunity to learn and of course we don’t expect you to be proficient in your discipline at a commercial level when you show up. In fact the point of the summer is to offer you the opportunity to rapidly learn the skills necessary to write code, test products, or design features at a commercial scale for 400 million customers around the world. My goal for all the interns is to work on something that customers will see when Office12 ships. So whether you are an SDE, SDET, or PM we structure our projects so you have the opportunity to contribute to something broadly used.

I would emphasize “opportunity” because a big part of the internship is offering you the opportunity. Microsoft has always offered a place where if you have the skills and abilities your work has an opportunity to shine. What we ask for the opportunity is hard work, an open mind, and a commitment to the project. Being an intern in Office is not easy, and it certainly isn’t a summer vacation. In fact, some students are a bit surprised at the challenges at contributing software to such a broadly used product. It is a lot different than working on an assignment at school, that’s for sure. Some of the big differences:

Tools and techniques – building software (whether on a PC or on a server) for a broad set of customers requires a different set of tools and techniques. You are likely to be using tools such as Visual Studio and the .NET framework designed to work with large numbers of developers on big projects. So you will spend some time getting up to speed on C#, C++, etc. if you do not already know them—don’t worry you don’t need to know them. We also of course have a group internally that trains on these tools and offers courses in these and all sorts of other areas which you can tap into.

Security, Privacy, and Quality in general – perhaps the biggest difference between commercial software at scale and other projects is the need for all of the factors that customers expect under the umbrella of quality. This means you will spend a lot of time designing in, coding, or validating these needs of the product. You will spend way more time on this than you have spent previously on non-commercial products.

Performance – performance (speed, memory usage) are key to commercial code. All that stuff you learned in algorithms will matter a ton. You will need to consider your design in the context of a large system so you will not have the freedom to use a ton of resources on just your part of the world.

Iteration – The biggest difference I always think is that you will spend more time on one area than you would in a course. You will spend time iterating on the design, test plan, or code because getting it right is the goal.

Scale – Perhaps the biggest contrast to coursework is going to be the scale of working on software like Office. As described before, while in theory it is cool if you can make a few billion dollars with a group of 20 people, in practice this hasn’t proven to be the case. Microsoft, Yahoo, Google, and others are all very big companies. In fact we are at the point where most of us have a number of developers that pretty much feels the same—once you get past about 1500 or 2000 developers it is tough to tell the difference, which is why Microsoft feels the same to me now as it did when I started (the company was a total of 3,500). By the way, don’t get confused by the numbers you read about the size of a company overall. Microsoft in particular (among those) has a large global sales force which requires a lot of corporate infrastructure outside of “developers”. For what it is worth, the team that creates all of the Microsoft Office Professional code fits in building 36 (and some in Mountain View!) and the number of developers is in the mid 100’s.

Mentorship – and finally an important part of working in a commercial setting, and perhaps the biggest learning opportunity as an intern, is getting to work closely with an experienced member of the team. You will have daily contact with your “mentor” and you will frequently interact with your group manager. I would add that I will definitely be on the lookout for cool projects and might drop by your office for a quick demo when you’re not expecting it :-)

Leaving out all the details of the cool furnished apartments and stuff, your internship will start with an orientation that all interns receive—you learn about all the benefits, meet lots of other interns, and get the scoop on the summer event schedule (activities, parties, outings, etc.). Shortly after that you’ll head over to your office. Interns work in the same offices that full time employees do though generally, just like in college, you’ll share an office with another intern. You’ll get all your hardware and spend some time getting your @microsoft.com email address and the like.

Next up you will start to talk about your project and what the summer holds for you. Things will move pretty quickly since you only have two weeks. Your mentor has written up your project plan—the plan will outline resources, objectives, and explain the overall project to you. Of course this is just the start and your own view of things will contribute greatly to how the project plays out. You will probably spend the next day or two getting oriented around the code, tools, and finding the drinks and cafeteria.

You will work with your mentor pretty consistently. You’ll begin to get a handle on the project, but you’ll have a ton of questions and you will start learning right away. You’ll see the amazing stuff that goes into building a product like Office. You can head over to the labs where we have all the hardware that builds and tests Office if you want to get a real sense of things. If you are in program management you might spend some time in the usability labs or in focus groups/field studies.

Specifically for Office 2007 we are going to be at a super exciting time as a team because we’re heading into the final phases of the project. You will have an opportunity to be on the inside of a super important project. Because we’re winding up, in all likelihood you will be working on forward-looking projects helping us to define the next product. You might work on an area that we are going to release on the web or put in the first post-release service pack. Or you might actually get to work on the final phases of 2007. It all depends on the project and a little bit on your job. If you are an SDE or PM, there is a good chance you will work on future work, which is appropriate since many on the team will be doing the same. If you are an SDET you will want to join up with the full-time SDETs who are focused on the 2007 quality issues—performance, security, etc. In all cases, there is a ton of cool stuff we’ll be working on.

Since you are a full fledged member of the team you will also participate in all the team activities—events outside of work or team meetings and the other things that go on as we build Office. There will be a lot of neat stuff to see in action—how we release the products, how our OfficeOnline web site works, how customers are using the beta release, etc. Team meetings are all about keeping up to date on that sort of information.

Let’s fast forward to the end of the summer—your project is rocking, you did way more than you were supposed to, and in general had a great time. The final thing we ask of all interns is to present their work to the team and to the corporate VP of your group. This is the most fun for me since I try to go to as many of these as I can. You’ll find a very receptive and supportive audience. This is an important part of your experience because in the corporate environment you are often called upon to present your work and undergo a peer review ;-)

The work is challenging—there is no doubt about that. It is not a vacation since you are contributing real code to products customers will pay real money to use. The stakes are high so we will take the work seriously. In exchange you’ll have an experience that is pretty close to real world. We don’t try to dress it up and we don’t hide the hard parts. Sure there is the party at the Chairman’s house and more stuff planned and scheduled than you can imagine, but the work is real!

I should also mention the opportunity you have to learn about the rest of Microsoft and things like Microsoft Research (MSR). Throughout the summer there are open talks by leading researchers and guest speakers of all sorts invited by MSR. These are streamed to your desk or you can head over in person. In addition, each week there is a “tech talk” (where the name of this blog came from) from a product group VP who offers up a view from their product/area (and in my case, a bunch of cool free stuff if you know how to work the system!)

I hope to see you at the tech talk this summer!

--Steven

Dev (or SDE) at Microsoft

steven_sinofsky — Fri, 03 Feb 2006 04:11:00 GMT

As we hit the college campuses for the second half of recruiting, it seemed like a good idea to pick up where we left off.

Development at Microsoft

Let's talk about development at Microsoft and what it is like to be a Software Design Engineer (or SDE as we call them, or just "dev"). My last post described PM at Microsoft (Office in particular) so I thought I would talk about Development today. Development does not have the subtleties that PM does so I don't think it will take as many bytes to describe. From the very beginning Microsoft has been a development driven culture and organization. Of course this starts with Bill Gates and Paul Allen two developers with a very famous story about writing a BASIC interpreter in a weekend.

Obviously the first thing that comes to mind is that at a software company, without developers the company really doesn't exist. And of course Microsoft is no exception. While the company has grown from what I would say was a "developer-driven" company where basically everything was about development, to a more grown-up and well-rounded company with the right focus on customers, business, and the market, we have consistently remained very much a technical and product company. Of course this starts at the top, where our Chairman of the Board is also the company's Chief Software Architect. Also, this post might show a bit more of me and be a bit more personal because development is where I started at Microsoft and because I am one of those folks that has a very romantic view of programming.

At the risk of perhaps ruffling the feathers of some others at Microsoft (myself included), one analogy that was shared with me back when I was a developer is that being a developer at Microsoft is like being a fighter pilot on an aircraft carrier (can you tell about what year this was and what movie was still top of mind?) An aircraft carrier exists to push the airpower and does so on ships that have over 80 aircraft on them, and those aircraft are supported by a crew of nearly 6,000 (on a ship like the Nimitz). So you can imagine while there are a bunch of pilots, the infrastructure of the ship (from mechanics, to naval officers, to doctors, ship's defenses, etc.) are all focused on insuring that the aircraft and resources and doing their duty. So in a sense, if you're a developer at Microsoft then you're on a ship that is all about making sure you can accomplish your mission.

The mission of being a developer is much easier to detail than that of program management--developers write the tightest, most secure, most robust, most performant code possible. At the same time, it is not just any code, but the best code that addresses customer problems in innovative ways for the broadest audience. You can write great code in a lot of places. Being a developer at Microsoft means you're writing code used by hundreds of millions of people who literally bet their livelihood on us.

A year after I joined Microsoft, my recruiter asked me for a quote for our recruiting brochure (I can't find it or I'd scan it in) saying why I wanted to work at Microsoft. For me, the thing about being a developer here is that impact. In graduate school I was working on a class library and working on connecting it up to databases. It was super cool and I had a great time. I came to Microsoft and worked on that same type of project, but instead of sharing the code with my lab mates and a few other interested researchers we were selling the product as a big part of our C++ product line. And before I knew it we had hundreds of thousands of developers using our tools making software for millions. For me that has always been the greatest rush.

As a quick story, I was on one of my reasonably regular recruiting trips to Cornell back around 1995 or so. It was late at night and of course high on my agenda was returning to the Hot Truck on west campus for on of Bob's PMPs ("French bread pizza", an idea copied by Stouffer's mind you). As a quick side note, about 10 years after you graduate your body is not really able to handle these treats, which explains why they only serve PMPs at your 5 year reunion. In any event, it was cold and some others were waiting for food along with me (waiting means standing on a stairway in front of the truck) and I'm sure they were wondering what this grown up was doing there ("loser grad student" comes to mind). They were talking about a cool program they were using in their comp sci class. As the details unfolded it was clear they were talking about Microsoft Visual C++.

I couldn't resist so I jumped in with a "hey I worked on that". Somewhat amazed (perhaps at my rudeness) but nonetheless interested. We ended up having a detailed conversation about the emerging importance of C++ and the implementation issues they faced in class, with particular emphasis on code and technical details (multiple inheritance, virtual function tables, etc.). One student was so excited he said "wait a minute" and ran back to his room to get his box of C++ so that I could autograph it.

Here's the hot truck in action (this is a reunion photo so it is warm and the people waiting are not students):

OK you get it, being a developer is cool. So what does a developer do at Microsoft? Like all the product development jobs, a good way to think about this is to look at the primary phases of a product cycle -- in developer terms you could think of these as evaluate, architecture and scaffolding, construction, and polish. Like all disciplines, development is one equal part of our product development process. In some ways, the other disciplines exist to make sure our developers are 100% focused on building great features, writing great code, and doing a great job. For the record, this most certainly includes me!

As is often the case when I talk with students about the product cycle, the conventional wisdom these days continues to be that it is way cool to work on short projects and that the world has moved on from big long software projects--this is the myth of cool projects can be done in one summer. It is hard to disagree in some sense--if you can have all the benefits of lots of customers, long term success, and profits by doing a small amount of work in a short time, then that is definitely preferable to doing a lot of work over 24 months. Unfortunately, there are very few small programs that are also interesting from a business perspective, especially over any sustained time. And of course today's small program is tomorrow's big program and asset that customers want to bring forward. In several posts I've talked about the product cycle and how we work in Office. I think the rewards that come from building a unique "economic asset" for Microsoft and customers are very great (from a personal accomplishment and a business perspective). I love a cool "project" and we definitely have those for interns, but trying to make a big company out of a lot of projects is exceedingly difficult (a wise leader of Microsoft once said, you can't make a billion dollar company out of one hundred $10 million dollar products). There are some other myths of development that I will follow up on next post.

Evaluate and Estimate

Let’s assume program management has done the groundwork to come up with a good range of feature ideas and you’re now facing a long list of potential features. Many of them are exciting. Many are things you wish you had *today*. Some of them look dorky. Some of them look like implementing them in code involves changing the laws of physics. This is where development brings their point of view to the picture and collaborates with program management (and test) to determine what can possibly be implemented.

At this point a lot of organizations would just pass the baton to development and they would take a “spec” or a “market requirements document” and do the set of things that make sense to them, without much of a feedback loop (until perhaps later when some features that were important to the boss fail to show up). In Office, this feedback loop is a critical one that takes a lot of energy—we call this “adds/cuts” since during this time we are building a list of the features we will implement and deciding which ones go on the list (add) and which ones fall off (cut).

At the same time, particularly for work that is reworking past ideas or improving in-market features, developers have their own ideas about what makes sense. Just as a program manager would do, the role of development is to convince program management to devote the bandwidth to adding those features. It goes without saying, but developers dream up some of the coolest ideas around. One of the coolest that I can think of recently has been the evolution of “Watson” – this is the quality assurance feature in Office that uses the internet to reflect back to Microsoft (anonymously and privately and opt-in) the experience customers are having with the software. This was dreamed up and executed by developers in their spare time.

So development is not there just to “code” the aspirations of program management. Development is also not there to dream up all the features on their own. Remember, there is a lot that went into the program management feature list, vision, and other groundwork. Of course in the end developers “own the code” and they could just go off and do things their own way, but this does not scale very well—you can imagine that as a developer you might know a whole lot about how to use a feature like pivot tables in Excel, but unless you’ve spent the time with bankers looking at how they use them and time talking to VARs who build solutions on pivot tables there is a good chance your views of what to do are based more on the code and the possibilities of the code, rather than the customer’s needs. After all, the most amazing developers are those that make the code do what the customer wants, rather than make the customer like what the code (or developer) wants to do :-)

With this rough list of features in hand, as a developer you are responsible for looking at the challenge and looking at the cost of implementing it. You are responsible for understanding the problem to a level of depth that can allow you to estimate the cost of the feature, including all the edge conditions, error handling, scale and performance, quality, globalization, and more. Of course at this phase you are not expected to get the estimate down to the day (and frankly, it is not likely your program manager counterparts have ironed out the details enough anyway). But what you need to do is to be able to determine the feasibility of the work. This feasibility is super important. If you are off in this area then there is a good chance your work will be very hard to ship. The best part about being a developer, even a new one out of college, is that you own this decision. You can say "no it cannot be done" or "it can be done, but perhaps there is a better way", or "you bet, I'm the one to get this done just like you described". This back-and-forth is critical to being able to successfully determine what is in the product or not.

This brings us to another quick aside, which is the notion that you should just try stuff out and see if it works and if it doesn't, "oh well". I think this is a great notion to strive for and for small products it might be a good idea. But for anything that has any level of complexity, even trying something out is expensive enough that you want to have a high confidence in success before you start. What's the old carpenter saying, measure twice, cut once -- I think that holds just as much for software even though you don't immediately see the downside of a bad estimate. While this looks like some serial “waterfall” process, in fact it is entirely iterative and the goal of this is to allow small groups of people to act as a small team within a big team. But having this information allows us to coordinate and make decisions as a whole. So this way you can have two small teams contribute to a mission, work independently as possible, and have some coordination. It fosters shared code that does not have to get defined at a very rigorous level, but a much more collaborative level, which is often what grinds cooperating teams and code sharing to a halt.

As a developer exits this phase of the product he/she is equipped with a set of features and a rough estimate for the time it will take to get the work done. The developer, working with the dev lead and dev manager, is busy at this point developing a high level task list of what aspects of the work need to get done and an ordering. At this point you will iron out things like scoping the amount of user interface work, the amount of new infrastructure work, the amount of backward compatibility work, the amount of developer/API work, etc. These big buckets look a lot like the specification areas from program management, but of course as a developer you are thinking about the amount of code that needs to get done for each based on those areas. There is also work across the team because there are likely some serializations that will need to take place. Of course the next step is to develop some architectural view of how to really go about implementing this work.

Architect and Scaffold

For many developers the really fun part of a project is determining the architecture. By architecture I mean precisely what you learn about in college courses--what are the systems, sub-systems, data-structures, and algorithms you will use for the major parts of a project. As a developer, you are of course entirely responsible for these decisions. Even if you are new you own these choices. The good news in that case is you will have a dev lead who has experience with the code base and the project who will likely work very closely with you on this phase.

I love walking by developer offices during this phase of the project. Whiteboards are filled with diagrams of pointers, data structures, and lots of "DO NOT ERASE". There are always heated discussions about what choices to make. It is during this phase that I believe developers make the most crucial decisions of a project. As you know the architecture determines not just what can be built well right now, but how responsive to changing requirements the project will be in the future. While it is great for every architecture you design to be able to respond to any change, that is really tough to do in practice. So the best developers are those that work the closest with program management to really understand the direction that things might evolve--to the best of everyone's knowledge. At the same time, it is always worth cautioning that trying to get your PM to say "no I will never ask you for this" might get you into trouble later in the project when things change. That can lead to frustration, but it is of course always the best way to demonstrate the flexibility of your architecture.

During this phase developers make up not just the code architecture, but the assumptions about what the code can handle down the road. The data structures will be chosen to assume certain field lengths, certain limitations, or certain performance traits. All the size v. space tradeoffs you learn about in college come into play here because as you know you can't just use infinite memory or infinite cycles. It turns out that for client based applications the primary gating factor is memory usage, so being very clever about how you use memory and how many pages you touch can make a big difference in how your code performs (for example, in toolbars it is often an elegant design to just have each button be a bitmap, but loading 100 bitmaps off disk can be insanely time consuming at boot time when all you want to do is get work done, so you have to be clever about designing a system that can load one bitmap and create 100 buttons). At the same time, the success of client applications depend immensely on the perceived performance. So these choices early on have a big impact. This is where experience and you mentor really help, because there are many things that come up time and time again. Similarly on server code, the use of CPU and networking have similar issues and an architecture that assumes these are low cost might be very elegant but in practice be problematic. The creativity involved in elegance plus performance plus making something meaningful for customers is very fun!

I have met a lot of developers that say they want to be architects. At Microsoft (and definitely in Office) *all* developers are architects. In some ways I think the job title for everyone on our team should be Software Design Architect. The reason is simple in that we want everyone to be thinking and acting architecturally with their code. Because of that we have not historically needed separate people to be telling people what to do and how to do it without actually doing the work themselves.

With the idea of what the overall architecture will be the next step is to put in place the scaffolding of the project. This is a very personal thing for developers as each have their own way to go about doing this. Some prefer take a depth first approach (I once read that great programmers spend 90% of the time on 10% of the problem, so maybe depth first isn't best, then again I think I spent my life on the CFile class of MFC). Others prefer to take a breadth approach. One of the most architecturally focused developers in Office who designed the line and page layout code in modern Word used a process where before any code at all was written all the header files and structure definitions needed to be complete--and the rule was that once coding started these were not going to change. He wasn't stubborn, but rather just brilliant at doing the complete design ahead of time after appropriately studying the problem.

There are a lot of things to consider at this point as well such as what code can be reused--why implement a new data structure when one exists to do the work. There are items to consider like compatibility. If your work will trample on an existing API that customers used then you will need to figure out how to continue to support that API. You can look at these as a burden or as I prefer you get to look at them as useful engineering constraints. An architect once told me that he loves doing projects where the land the house will be on has a lot of quirks--it makes the project interesting because it introduces constraints that aren't there in a flat quarter acre lot with no trees.

In a three milestone project, this portion usually takes the first milestone. As a developer you exit this milestone with a much clearer idea of the schedule and a much clearer idea of the work ahead of you. Closing out this work and getting all the scaffolding checked in and getting those data structures working is a very significant milestone -- you feel like you wrapped your arms around the problem and can move on.

Construct

Of course what comes next is just solid coding. This too is super fun because this is where you get those feelings of coming into work, writing some code, and showing off a new feature by lunch and maybe another new feature at the end of the day. Like a long car trip from Florida to New England it feels like you made it through Florida and Georgia are hitting the Carolinas and you're knocking off states at a rapid pace (don't forget to stop at South of the Border though).

For the most part during the construction phase you are writing code and making things work. Every day brings new excitement. You know you have really rounded the corner when people start dropping by your office because word traveled around the hallways about a new feature that is running on your machine. Often you'll see a screen shot passed around in email or a URL mailed around that we should all try out. One of the new features in Office "12" that was done was the ability to use InfoPath forms in Groove -- this is a super important scenario for reliably collecting data when you are using a laptop not connected to the internet (such as when Groove is used in disaster relief work, for example). I remember being in the Beverly,MA office where Groove is and seeing a super early demo -- you could literally open up a form in Groove. You couldn't type or anything yet, but it was super exciting because it showed that the scaffolding and architecture were well on their way to being proven.

Of course other folks are hard at work while you are writing code, namely the testers you work with. As you complete features or sub-systems the testers will begin to investigate the work you are doing and they might find some problems :-) Some of these will be because features are not done or the error handling code is not there, but you might also have things that didn't work as planned. In fact the more you make it through this the more testing will likely be able to push your code to the limits. All of this of course helps you to make the code better. As a developer you always strive to make no mistakes, but we know that is not possible, and so your best ally in building a great product in this phase are your coworkers in testing. Similarly during this phase as a developer you will need to be very aware of the real world performance--things that are slow now will only get slower. So you might find yourself revisiting some architectural decisions, since you know that it is much easier to deal with these upstream than hold off.

As you wrap up this phase we are generally in what we call "code complete". This means the feature work is done. It means all the edge cases that were planned on are handled. It means that as far as development is concerned the feature is ready for people to start to use and for the real feedback to begin. There is still a lot of work to do, but your work now looks like a product.

Integrate and Polish

We're now getting ready for the beta test for the product. The product is rough and we can't sell it, but you know what it is going to look like and most of all you are very excited to see what others might think. When you build the product you see the incremental steps so when it all comes together it sometimes isn't as exciting as the first look at the feature. For me, in Office "12" the PDF feature was like this. Alex (and others) worked away on this for quite some time of course, but to us we knew it was a very simple "save as PDF" feature that would be on the "File" menu. It was super cool of course but we'd seen the work evolve. Then we had the chance to demo it to the MVPs when we announced the support and for those that were there we got to hear the memorable quote "if this works, I'll have your baby". We were in the end-phase of the product but it sure reminded us just how cool customers thought the feature was!

One of the most fun parts of this phase is when we invite BillG to the Office hallway and he spends the day going to developer offices and talking about the details of the code and architecture. This is a tradition we do each release and is enormous fun for everyone, especially Bill. We pick devs from each of our teams to demo their features and they prepare and plan on Bill stopping by. You just hang out in your office and then Bill pops his head in. You start your demo and hope that he doesn't stump you out of the gate!

Of course the polish phase is not always just fun reactions from customers. There is a lot of great development that takes place as we really smooth out the product, nail the performance, and nail the quality. The polish phase really is about fixing the bugs. The fun part about being a developer during this phase is that you are working from a list of bugs and fixing them--a lot of people really like this style of work in that you know where you stand every day and nothing is too open ended. Bug fixing for many is a sport. My first manager was just amazing at being able to almost detect the source of the bug by sensing some sort of EMF from the monitor--he was especially adept at using intel hardware breakpoints to track down errant pointers. Some developers will likely become informal tech leads of projects at this phase because they can track down anything. There is also a big aspect of being experienced here that shows and so the more experience you have the easier this phase becomes. Of course from an agility perspective, the buglist represents the backlog of work and one could argue the buglist should always be a “virtual zero”.

Similar to bugs is performance. Even with 3ghz multi-core processors and 1gb of RAM performance is still critical. A lot of people think that perf shouldn't be a problem or if it is it is just because we add too many features. I wish it were that since we could just do less features and not have to work on perf. But the reality is that as fast as we can add features people use more and more of their PCs. So our original benchmarks for Excel were around booting Excel into a Windows runtime used only for Excel--no network, no AV software, and basically nothing but Excel. It is no wonder it could work in 1MB of real mode memory!But today when you boot Excel you are probably running mail, Word, a browser, a media player, a network and firewall, and on and on. So we can’t let our resource utilization grow because there is always contention. All of our work on the server has these same issues relative to scale, pages per second, etc. As a developer on Office you will spend a lot of time looking at how your new work impacts the release-over-release benchmarks. Our goal is that each release should use the same resources and take the same time to do the same tasks. This is a tough goal for software and it is a testament to the team that our applications still perform at these relative levels. And at the same time people can do lots of new stuff.

During this phase some of the classic integration engineering takes place as well. Software represents a complex system and when you bring those systems together the behavior across them and the boundary conditions yields some interesting issues to track down. Microsoft develops a lot of automation testing and a lot of scenario based views of how the products should function that assist the developer during this phase.

Finally for features that interact with users, this is the time we get tons of feedback on the experience and we work hard to incorporate that as appropriate. We learn lots about the features at this point and because the product is working, program management is out there learning. And developers are watching the reviews and feedback and responding as well. I remember when working on the VC++ compiler/IDE and we really wanted to compile the most lines per minute relative to the competition as the spec said we should. The beta feedback I saw said people thought we were slower. Now I was pissed--I had like 3 stop watches and 4 machines in my office and I knew every benchmark for compile speed and tracked these on a daily basis. I knew our speed was faster. Well I talked to some outside developers on the beta and I realized that they thought it was slower and they showed me how the competitor had a very fancy spinning line count telling you how many lines were compiled and we just had a status bar thing. I got so excited because I got to tell them that I used to have that but realized it slowed the compile down by a fixed overhead of about 0.2s and for big files it really slowed things down even more just to TextOut those line numbers. Of course I learned something too that sometimes perceived responsiveness matters just as much as clock time. A good lesson for all.

The best feedback of all though is reading reviews, watching your friends, and maybe signing a few autographs at the Hot Truck!

Attributes

With that we've made it through the product cycle -- we've architected, estimated, scaffolded, constructed, and polished. The product is ready for customers. Whether that was a customer requested DCR that took 2 weeks, an update of OfficeOnline that took 6 months, or a full release of Office, as a developer you will take your code through all of these phases. If you're considering an SDE role at Microsoft (or Office), from my perspective a couple of things you will get:

Part of a small team focused on the customer or technology area
The opportunity to write the very best code for products used by millions of people, not just used but relied on to earn a living, get a degree, or run governments.
Access to the best resources to get your job done -- working with the best in the industry in product groups to being able to tap the resources of Microsoft Research
A very strong mentor who as part of small team will be there for you on a daily basis

Of course it goes without saying that to be a great developer you need to write great code, but the following are a few characteristics that our team finds valuable when finding great developers for our team:

Able to foresee what will need to change in the next round without over-architecting the current round -- many people can write a quick solution to a problem, but quickly program themselves into a corner. That is why you might get asked an interview question and then after you answer it you might get asked "ok, now what if the person's language reads right to left". So great developers know the foresight they are building into the code and understand the limitations that will appear down the road--all code has that of course, but being deliberate and informed about that is a great skill.
Debugs other people's code -- Great developers can jump into other code and make progress in pretty short order. This is super hard. So getting good at building a mental map of a new system and understanding the patterns in foreign code is a great skill.
Makes the code dance for customers -- Many developers are very content to prove their code does cool things. That is definitely good. But to be really great, a developer should be able to show how their code solves a problem that a paying customer would have.
Works well with others -- All great programmers that I've known have told me how much they love The Fountainhead or Atlas Shrugged. Yet at the same time, programming is inherently a collaborative field so all great programmers know when to work well with others and how to use their dev skills to get the most out of the team. This is not just other devs, but test, pm, design, usability, and others.
Knows when to say "no" and when to say "yes" -- Many developers are spectacular at saying "yes" early in their careers which is quickly followed by a tremendous ability to say "no" (after a tough project or two). Great developers know how to make it work and know when something is important that they can find a way to get a quality job done. They can find clever solutions to incredibly hard problems.
Humble -- Everyone probably remembers the scene in Top Gun when Maverick was explaining his MIG encounter--Maverick was calm, cool, collected, and understated. As confident as he was in his flying he told the story with a certain modesty ("[cough] we were inverted" with emphasis added by Goose "no really we were"). Most of all, great programmers are humble about their ability to crank out the best code and make it look easy.

--Steven

PS: A word on comments – I strongly encourage comments. I especially encourage comments from college students and people considering a career at Microsoft. If you already work here, feel free to drop by my office, send me mail, or anything—we can have a great discussion without going through this pipe that is a bit more narrow that my front door!

PM at Microsoft

steven_sinofsky — Sat, 17 Dec 2005 02:16:00 GMT

While at Stanford this week I was asked by a number of PM (program manager) candidates to talk about the PM role at Microsoft. The PM role is unique to Microsoft and was actually created in response to developing software that is more usable and at the same time pushes the state of the art of technology. So when we talk about PM at Microsoft, we're talking from a perspective of creating and evolving the role over the lifetime of the PC industry.

I have been both a PM and an SDE (software design engineer) during my career at Microsoft. When I was recruited I started off as an SDE candidate and then I learned about PM during the course of my interviews and I thought "COOL!" that has to be a job for me--after all it sure sounds like an incredibly cool role, since it has the title "manager" in it and if you read/hear the description it sure sounds like you're running the show. The job title "program manager" is a bit of a misnomer, since program managers do not program nor do they manage--go figure. I went with SDE because I wanted to write code in my job. After being an SDE for 4 years I moved to program management. I think that was a good move for me because while I like to think I was competent at development, I was probably never going to hit it out of the park with my ability to write code, but I think what I wasn’t able to do in writing code I made up for with the skills required of a program manager :-)

What follows is a description of program management from a PM perspective -- that means through the lens of a PM. It is also an analytical description based on my experience. I'm not trying to hype the job or make it seem too over the top. In fact, I've recently talked with an number of candidates who have been told of PM roles at other companies and my feeling is that they are not being told the whole story. So with my blog I try to be a bit more complete and not "sell". This might make it seem like there's no room for change or to impact the definition of the role, but that is not the case. What I'm describing is in constant evolution and it is the members of the team that are constantly evolving the role. PM is a role that has a lot of responsibility but you also define it--working in partnership with expert designers, clever developers, super smart testers, etc. you all work together to define the product AND the responsibilities each of you have. PM is one equal part of a whole system.

Program managers got started at Microsoft while developing Excel for the Macintosh. The challenge the company saw was that we were stretched thin trying to push the state of the art in technology (in this case develop for a brand new OS using brand new Graphical User Interface concepts) and so the developers were very busy just trying to make things like printing, display, graphics, etc. work as well as trying to develop new algorithms for spreadsheets and modeling. That meant that the place where we were not focusing enough attention was on the usability or the scenarios for how people would use the software. In a very classic sense the high order bit of our development was the code--this is pretty classic in most organizations today where you really only see development and test (sometimes called QA) and to the degree that there is input from users/customers this is usually done by the demand generation or marketing team (called product managers in Silicon Valley). So at Microsoft a new role was created in Program Management with the explicit goal of partnering with development and working through the entire product cycle as the advocate for end-users and customers.

The challenge of trying to write code using the latest technologies and bringing ever more complex scenarios to end-users in a simple way continues today as we build web sites (OfficeOnline), server products like SharePoint, and entirely new products like OneNote, as well as build whole new user experiences to replace the aging menus/toolbar paradigm.

Up front I would say that the PM role at Microsoft is both unique and one that has unlimited potential -- it is PMs that can bring together a team and rally them around a new idea and bring it to market (like OneNote, InfoPath). It is PMs that can tackle a business problem and work with marketing and sales to really solve a big customer issue with unique and innovative software (like SharePoint Portal Server). It is PMs that can take a technology like XML or graphics and turn it into an end-user feature benefitting 400 million people (Office Open XML format or the new graphics functionality in Office12). I could go on and paint a very emotional picture, but let's spend some time digging into the more analytical aspects of the job.

Where developers were focused on code, architecture, performance, and engineering, the PM would focus on the big picture of "what are we trying to do" and on the details of the user experience, the feature set, the way the product will get used. In fact the job has matured significantly and it is almost impossible to document a complete list of the responsibilities of program management. One way to do that is to list the sections of a specification for features in Office that a PM would complete before the code gets written which includes nailing the scenario you are solving for, the worldwide implications (will your work make sense to customers in China, India, Estonia), how will developer customers extend the product (object models, programmability), is the product secure and is privacy maintained, what are the other features your work interacts with, will the feature be responsive and performant, and more. These are critical parts of the design of any product, and when you will have 400 million potential customers thinking these through before you start the work is critical.

As an aside a lot has been said lately about "agile development". A key benefit of program management is that we are far more agile because we have program management. That can be counter-intuitive (even for many developers at Microsoft who might be waiting for their PM to iron out the spec). But the idea that you can just start writing code without having a clear view of the details and specification is a recipe for a poorly architected features. A great PM knows when the details are thought through enough to begin and a great developer knows when they can start coding even without the details for sure. But like building a house--you don't start without the plans. While software is "soft" the cost of remodeling or rebuilding is no different than if you decide the walls are in the wrong place or you forgot to leave room for the HVAC system--sometimes because we don't have material costs in software we think that "rewriting" is perfectly ok. That generally works super well in two cases. First, if the program is small then of course you can rewrite it. In the commercial software world most software projects are not the work of one or two people--in fact one way to think of it is that if a project is only the work of one or two people (or is only a 100KLOC) then the economic value (and thus the impact) of that product is probably pretty finite (at the very least a competitor is likely to catch up very quickly). And second, rewriting works well when you are looking backwards and re-doing what has been done (like cloning an existing product, implementing something for the n-th time). When you're doing innovative work, the time spent on design and analysis pays off handsomely in the ability to develop a complete program and to have something of lasting economic value. AND when you have a process that embraces design and up front thinking you also find your development much more agile because when you do get the code in the hands of customers--after 2 months or 2 years--there is time to respond and react with changes because you are not overwhelmed with the basics.

The last point is worth re-emphasizing. There's a school of thought that just getting your software out in beta and then "reacting" to the feedback is the best way to get the product done. Again, this tends to work for products that already have a definition you are chasing of if you're interested in incremental feedback. So if you're building an email experience and release it in beta, your customers/users can help you to prioritize which features in the universe of email to add next assuming you did not have all of them up front. But if you're doing something new and innovative or more importantly if you want more than incremental feedback then you need to have much more sophisticated mechanisms than just beta feedback from power users. Most importantly, the role of PM is to represent all customers, not just the ones who do beta tests or the ones who take the time to send in feedback or use early products. A key skill of program management is to have empathy with a broad range of customers. Often when you are just getting started you will see how easy it is to over-emphasize early power user feedback or anecdotes over broad based feedback. Don't get me wrong, power users are great but they are just one type of user. A great advocate for the "little guy" is Walt Mossberg and he really does point out when you're missing the mark on a product and too focused on "techies" as he calls them. The bottom line is that most people are not techies, but most beta customers and most early adopters are so you as a PM have to do the leg work to validate your work with a broader audience.

Before talking about what PM does specifically it is important to look at PM in the context of the relationships with the others that contribute to building products. A PM serves as the coordinating point where all the disciplines come together--this is why you can think of the PM as being the hub. What is critical about the Microsoft PM role is that all the different people serve as a "virtual team" building the product--the PM does not have to go pull them together but rather has to help get everyone aligned. The resources for a project are dedicated to the project--these resources include development, test, product planning, usability, and product design. Each role brings a unique perspective a unique set of skills to the product development process. While you can often be someone who has an affinity for another discipline, rarely can any one person bring all of these skills and experiences. And I can promise that any project of significance really needs the specialized skills to do a world class job and build a sustainable and uniquely innovative product. I should probably write a blog like this on each role--maybe after the holidays!

Development -- developers write the code. They are in charge of the code's architecture, the performance, the reliability, the security, and getting the functionality into the product. Of course development is at the core of what we do as a software company, but it cannot stand on its own.
Test -- software design engineers in test insure the quality of the product but more importantly that the product ultimately meets the needs of the customer we set out to meet. SDETs will review all specifications as first class members of the team and use their perspective and experience in working with PM and SDEs to insure that the product is not going to be fragile and that it will be possible to insure a successful implementation.
Usability -- usability engineers validate the designs of our software and incorporate the statistical understanding of customers into the process. Microsoft was an early pioneer in integrating usability in the product development process (though some might say how in the world we released the Hot Dog Stand theme if we had usability). Many usability team members have PhDs in HCI or related research areas such as anthropology, and many are undergraduates with a HCI or psychology background. These team members design mechanisms to test and validate designs and design assumptions.
Product Design -- Design work in partnership with PM to develop the interaction model for our products and also own the overall product look and feel. While many companies use design for "graphical design" (which we do) our designers are expert in computer interaction--many have studied at programs like Delft's or CMU. When you look at the new user interface in Office12 what you see is a strong collaboration between the PM experts and the Design and Usability experts.
Product Planning -- our planners are experts in understanding the market place and understanding what our customers need from software. Planners own research and communicating that research to the product team PMs and to the executives deciding the overall goals of a release. Planners are assigned to broad technology and business areas (collaboration, business intelligence) where they become expert in all the products and solutions on the market and how Microsoft can offer customers improvements over what is in the market. Many planners have business background and have worked in marketing before.

Many companies will "sell" you on being able to do many of these different things from one job. This is just not a reality that exists and I always feel a bit bad for folks who believe this. There are two times I hear this a bunch. First is at startups you hear "come join us from college and you can own all of this". Of course at a startup the real experience is that you are the college hire, which means you will do the grunt work while the founders and the venture people do all the strategic work--so you might find yourself setting up the build machines rather than interacting with customers. Second, I hear this a lot when companies are selling against Microsoft and point out that "at our company we do not specialize and everyone does everything". This is another "well in reality..." situation, since of course even when I have seen companies that claim to do the specifications or customer research and up front planning they do that work from Product Management, and those people are just as specialized, they just report to the marketing team. And we know what that means, which is when push comes to shove the marketing team will need to use every hand to get out there and generate the business and sell--so even if there is a single group that does the work, those roles are specialized, and rarely dedicated specifically to the role. These are my experiences and of course your specific situation might be different. I've just seen these patterns repeat themselves over many years of hiring students and having them come back to Microsoft after a short experience with something like that.

It is worth talking about the size of the PM team for a bit. In Office our PM teams are small (our dev teams are usually about 20-30 developers as talked about previously). The entire user interface for Office12 was developed by a team of about 12 program managers--imagine that 12 program managers did all the work to totally define the new interaction model for 400M customers of Office. But along with the fact that the team is small is the fact that a team like this is also one where even the newest members of the team receive significant mentorship and training from a very senior member of Microsoft (you can watch this video to meet the head of the user interface PM team). So you have the biggest impact you could have in designing software while receiving a very high level of management attention. And then of course each PM has developers they are responsible to equip with features and specs -- the whole user interface development team was less than 30 people (so about 2 devs for each PM). A critical part about PM (also one that is unique for Microsoft) is that as a PM you have dedicated developers for your feature area--your job is to get the most out of those developers in terms of bang for the buck by having great feature ideas and great specs to get them done.

So what does a program manager do? Well there are three phases to program management: learn, convince, spec, refine. These roughly mirror the product development timeline written about previously. Do keep in mind that the timeline is not fixed--rather the phases of the timeline are. So if we're doing a 12 month project then the time is divided accordingly, same as if the project is 24 or 30 months.

Learn --> Output of learning is a prototype

During the learn phase, program managers spend their time learning about customer problems and learning about the products and technologies out there that are relevant to these problems. There is a lot of work with planning to understand competitive products or new products in the marketplace. As you can imagine, customers have huge challenges in getting their computing systems to do what they need. So often we will spend days at a customer's place of business learning from them and watching them trying to get their work done. A great example of this is the work we did to understand how customers manage documents in an organization. It is easy to see that organizations like law firms or pharmaceuticals are heavily dependent on the flow of documents in an organization (contracts, drug approval and research) and so the systems are both mission critical and elaborate. Companies really want to automate more and to make things more usable and reliable. The work of program management was to deeply understand how to model the flow of documents in an organization--spending time at big drug companies, small startups, big law firms, local law firms, Public Relations agencies that produce press releases, or government offices that produce legislation to name a few. Out of this work PM and Planning developed a conceptual model called the "document lifecycle" (DLC). This helped us to frame the way that customers would like features to work. So for this work the PM needs to be really good at working directly with customers, learning from them, listening, being open minded to different ways of working, etc. When you're hired from college you will participate in this work for your area.

At the same time there are deep technical problems to solve. We need to solve the control and access to information (drug test results and contracts need a high degree of security, yet they need to be collaboratively authored). PMs spent a lot of time working with the Windows platform team who develop platform technologies like our Rights Management Server or the Windows Workflow Foundation (WinWF). These technologies are critical to enabling a robust and extensible implementation of the DLC. So in this phase of learning, the PM has to become well-versed in new platform technologies or in how to apply existing technologies. Often this is where some people say "it would be easier to roll our own" -- which of course in the immediate term it is (just build your own linked list and event source/sink) but what you miss out on is the expertise and leverage that comes from a deep platform technology. For example, by learning the WinWF and being an ISV of that technology we can take advantage of advances in workflow, integration with Visual Studio, and a very robust and scalable server without us doing any work--just like when developers reuse the process model of Windows, or the client side drawing code of GDI.

With this information at hand the role of the PM is to synthesize this learning into a series of prototypes. These prototypes are of varying fidelity. This is where the analogy to architecture holds--sometimes you do a drawing, sometimes you do a high fidelity diagram, and sometimes you build a model. In software we sometimes build static screen shots, we sometimes prototype in tools like VB.NET, sometimes we prototype in a series of static bitmaps that illustrate a scenario. For our new user experience in Office12 we went through a series of high fidelity prototypes development first in PowerPoint (you'd be amazed at the depth of interaction you can do) and then in more high-end design oriented tools. By the time we were ready to exit the learning phase, we had a full mockup of the user interface (which I have shown at my campus tech talks this year).

The output of this phase is a prototype upon which we will author specifications.

Convince --> Output of convince phase is a plan and goals

Once you've learned a lot you have to go out and convince your peers, your manager, and the dev team that your ideas are worth pursuing. This is where being a solid communicator and someone who is able to bring together customer needs, technologies, and scenarios really comes together.

As an aside, a lot of companies will tell you that you can come and pursue your ideas. That is probably not a good plan -- that is a recipe for chaos. But more importantly, if you can do whatever you want there is a good chance someone else in the company has the right to come in and tell you to change. If there is this level of empowerment it means the management team is empowered as well :-) The ability to just start at a company and pursue your own agenda is much more of a lore than any reality--all companies have a strategy and a business framework that the work needs to fit within. At the very least, eventually shareholders will want a return on your R&D investment.

So at Microsoft the convince phase is really where your entrepreneurial skills come to play. While you will always have work to do, during this phase you are working to expand your vision and get as many lined up behind your area as you can handle. Your ability to convince people of your ideas is a lot like trying to get funding from venture capital folks. That is why if you have a great conviction of your ideas and a lot of energy you probably have the makings of a great PM.

The best part about this is that the teams you work with are all working in unison on the vision and everyone is on board trying to make sure the ideas come together super well. In particular your mentor is there to work with you. But ultimately, the ideas will succeed based on your own initiative and ability to convince the team of the chances for success and the high priority nature of the work.

The output of this phase is the set of objectives for the project area. What follows is developing things at the next level of detail.

Spec --> Output of spec phase are a series of written specifications

The first thing people always think of is "specs are for bureaucrats". That drives me a bit crazy. I know as Americans we have a tendency to use new products without reading the instructions, but it is lunacy to develop a new product without first writing down the goals. The mere process of writing is thinking, and the thinking will always push you to uncover more issues sooner before it is way too expensive to change things. For all the talk about agile development, few ever talk about specifications as being the most important step in agility. It is way easier to change a bitmap or do some editing of English in Word than it is to move around and rearchitect code.

Yet at the same time we do not sell our specifications, we only sell our code. So while we work to be very hardcore about having up front planning we do not develop our specifications to the point that they are the full documentation of the product. It is too much work and not enough of a pay off. So if you make a late breaking design change we might document the change in the change log but we don't go back and redo all the words in the spec. Another fun one for reading specs from a long time ago is that the actual feature name used in the product is never what we named it during development--the Office Assistant was famously named TFC during development. The "C" stood for clown. I will let your active imagination figure out what the TF stood for.

So in writing a specification, the PM that worked on the learn phase now has to turn that learning into an experience that customers will have. This is where the entire series of features, user interactions, boundary conditions, localization, ISV opportunity, and all the details are filled in. A specification is how a developer will estimate the amount of time it will take to write the code. So if your spec omits a lot of details and developers need to guess, then there is a good chance you will end up not being able to realize all of your dreams because too many things needed to get filled in a the last minute, plus your developers will not be very happy working with you. So doing a good job on the spec is important.

A great program manager will take their whole feature area and divide it up into specifications that match the developers or break the feature up into workable "chunks". On average a PM writes about 8-10 specs for their area, and each one can be 30-50 pages depending on how visual (how many pictures). Some specs are significantly longer and some PMs choose to write a larger number of smaller specs.

Specs are not just for developers. But the usability, product designers, and testers are all contributors to and refiners of the specifications. In fact while the output of the Spec phase is the document, the final output is an "inspected specification". If you've ever gone through a code review with a professor or mentor (as an intern) a spec inspection is like a code review. During this time testers might push on you about boundary conditions or compatibility with existing products. Product designers might work with you to improve the way the spec describes the overall interaction. Usability might research the instrumentation from in-market products and use that to refine the priorities for the feature. In fact the role of data is critical to Office PMs--if you run a web site you have click streams and logs, and Office through the Office Customer Experience Program has exactly the same--usage information for millions of volunteers (anonymous and private of course) and that educates us immensely on how to design features (Jensen's blog describes this as well). So the spec, while owned by PM, is a work product of many contributors.

It is worth noting that many times along with a spec is a more detailed prototype. This is particularly true for heavily interactive features. In this case product design and PM work together to develop detailed prototypes of the work (often these will be tested in the labs with customers as well).

When the spec is complete the core part of development begins. PM then transitions to refining the product.

Refine --> Output is the product

During the development of the product, PMs are constantly refining the details, working with development and test to determine what needs more clarity and what is working better than expected (that can happen) and what is going less well (that happens more). PMs are on call to answer questions and "unblock" development.

More importantly as the real code becomes available, PM is anxious to try it out and make sure it is meeting their own design expectations. Once the real code creeps along we will bring that into our usability labs to further understand how the product works. A famous story of this phase of developing the PM role was that the first PMs were trying to improve a feature under development and ran some usability tests. The feature bombed. The PMs tried to explain this to the developers, but the developers insisted that the PM just picked "dumb users" because the feature was great. So after a few rounds of this the PM dragged the Dev to the tests to watch 10 out of 10 users fail to use the feature. The developer finally relented and the feature was fixed. Today, developers can watch tests via streams or go downstairs to our usability labs and watch the tests in person. Almost all developers I know are keenly interested in how their features are doing (and how the PMs are doing designing those features!)

Another aspect of refinement is working with customers who use the early code. While it is cool to throw a product out to beta and get some instrumentation and maybe get some qualitative input via mail, the only true way to understand how the product is doing is by deep engagement with real world users. We do this this through a number of mechanisms that gradually expand the number of customers involved.

Early in the process we meet with a very small number (10-20) customers who spend days with us here on campus and learn about the product. We walk them through all the details and solicit their feedback and input. We did this for Office12 last summer and it was critical to our ability to get to Beta1 with a product that reflects real world usage and learning. As a PM you will be responsible for getting together with these customers and learning from them. We often follow up on site.

Another group we learn from that is a bit larger are our MVPs -- the most valued professionals. These folks are the power users of Office. Our PMs all got involved with the MVP summit on campus and again worked with the MVPs in small groups to get their feedback and expertise into Office12. The MVPs know more about Office than any other customers on earth--they are a wealth of information.

We're currently in the phase of learning from a broad set of beta1 customers. We are doing this through newsgroups and through direct communication.

You might also notice that many of our PMs are blogging (see the links to the right). This is new for us (well for everyone) and also a great source of information and a great way that PMs are connecting with the web community.

Of course our senior program managers are also responsible for working with the press and product management. So a lot of time is spent on communicating Office12. There are a lot of reporters interested in Office and a lot of information to get out there.

All of this Refine work feeds back into the developers where we prioritize and make sure that the very best product is built. Of course that doesn't end with RTM since we're always refining and listening to customers (even though we're not "Web 2.0"). As I mentioned previously, we make over 100 changes every month to Office based on customer input -- so the product is always improving, and we're always learning!

PM Attributes

So those are the phases of program management and what you do as a PM in Office. I would say that there are many unique elements to the role of PM in Office that are not emulated by other companies who have tried to create this role. A good book that describes the uniqueness of PM at Microsoft is Michael Cussumano's book "Microsoft Secrets" or his new book, "The Business of Software". If you're considering a PM role at Microsoft (or Office), from my perspective a couple of things you will get:

A small team dedicated to solving customer problems and bringing the best technologies to the table
Access to dedicated developers who are there to implement your ideas if you can live up to creating a great idea and making sure the details are thought through
A very strong mentor who as part of small team will be there for you on a daily basis

If I had to think of the qualities that make a great PM I might list a few, but your recruiter and the interviews will help out a lot so don't let these discourage you from applying:

Strong interest in what computing can do -- a great interest in technology and how to apply that to problems people have in life and work
Great communication skills -- you do a lot of writing, presenting, and convincing
Strong views on what is right, but very open to new ideas -- the best PMs are not necessarily those with the best ideas, but those that insure the best ideas get done
Selfless -- PM is about making sure the best work gets done by the team, not that your ideas get done.
Empathy -- As a PM you are the voice of the customer so you have to really understand their point of view and context
Entrepreneur -- as a PM you need to get out there and convince others of your ideas, so being able to is a good skill

PM is unique to Microsoft and I think it is fair to say this is a role that is often copied but never duplicated.

--Steven

Seattle: The Emerald City (Really!)

steven_sinofsky — Sat, 19 Nov 2005 16:04:00 GMT

It is not the heat, it is the humidity.
-- David Letterman (ok not really, but it was a catch phrase for a while)

No matter where you live, people can find a reason to complain about the weather (or is it weather forecasting?). Seattle is no different and while we call it the "Emerald City" most probably think that was a marketing ploy not unlike that of the Greenland Chamber of Commerce (ok some people call it the Rainy City--just no one who lives here). A senior group program manager extended an offer to a college graduate last week and she said she has spent a lot of time on the issue of weather. So what is the deal with the weather in Seattle?

I mostly grew up in Orlando, Florida. It is weird growing up in a vacation destination people associate with warm weather and spring break. Until I was 10 we lived in New York and would visit my grandparents in Florida ("del Boca Vista" for sure) and I remember frolicking in the swimming pool in December. Once we lived in Florida I quickly realized just how crazy it is to swim in the winter in Florida--after all it is like 70 degrees outside, brrrr... Climate is a pretty relative thing.

Seattle is a temperate zone. It is really middle of the range. A lot of Seattle's weather is caused by the fact that it is sandwiched between two mountain ranges (the Olympics to the west and the Cascades, foothills of the Rockies, to the east). This sort of has the effect of keeping the hot side hot and the cool side cool, so to speak. While you might think of Seattle as being on the "coast" it is actually a couple of hundred miles to the real Pacific ocean and to get there you have to cross a real live rain forest (one with bugs the size of kittens and leaves the size of small car).

This middle of the road weather is great. You never really need gloves and a fleece pullover is de rigueur for about 9 months of the year. When you're not wearing urban hiking boots (of course you never know when a mountain will spring up) you're wearing sandals (ok not me). There are people who wear shorts literally the entire year (our VP of HR is famous for that). Basically Seattle is a place where it just never gets too cold or too hot. Maybe a few times a year it is what you would think of as winter on the east coast, and rarely does it get to what you might consider hot by southern standards, and it never gets humid and it rarely snows (in Seattle proper). Most developers can wear their favorite thinkgeek t-shirts year round (and by the way, contrary to rumors I do own a "No I won't fix your computer" t-shirt).

Statistics are of course the best way to show this. The following table (from NOAA) shows some weather stats from a number of selected cities around the US (btw, I formatted this with new features of Excel "12" that show off how easy it is to create visualizations of information):

As I mentioned, Seattle is in the middle of two mountain ranges. This makes the climate for Seattle unique relative to traveling 100 miles east or west. If you go west, you hit the rain forest and those mountains. If you go east, you hit the truly alpine region in the Rockies. So that means you can travel and find radically different weather. As I write this there is an expectation of about a foot of snow in the Cascades, which means great skiing!

As you can see, Seattle really is right in the middle based on all the metrics. For temperature you can see how moderate Seattle is right in the middle of the pack, and the standard deviation is quite low relative to most others. This means for the most part the weather folks can get it right in Seattle.

You can see it doesn't really snow in Seattle. In fact I was surprised to see that historical average since it has been years since I recall snow on the ground in Seattle. If you want snow what we like to do is keep it out by the mountains for skiing!

Rain. Now that's an interesting one. Most people are quite surprised to learn that it doesn't rain all that much in Seattle especially compared to the precipitation of nearly every city on the east coast. Seattle rarely gets "rain" but rather we have sort a mist or drizzle. This is actually really great since you never overuse your windshield wipers and you never need an umbrella. In fact when I first moved out here and walked outside in the rain with a coworker from Portland, I popped open an umbrella and got a look of "what the heck is that contraption". That was the last time I carried one of those around. You just don't need it. Plus with all that Polartec and all those REI Gore-Tex anoraks we're well protected. Having gone to college in Ithaca, NY and grad school in the Pioneer Valley in Massachusetts I can safely attest to the fact that having no melting snow and having no driving downpours is definitely a big positive.

Of course what you will see is that Seattle has the most days of "precipitation". These are those misty days. I guess weather people call those precipitation, technically. It is definitely true that the sun does not shine a lot and the sky is not blue during the winter months. But then again if you head to the mountains you will be in blue sky skiing territory in short order (a couple of hours drive). Scientists debate whether this type of weather really has a profound effect on people and whether than is biological or psychological. I certainly don't know. It is the weather and I can say that for me personally the predictability and "middle of the road" of the winter compared to other places is really a benefit. You know what clothes to wear. You know the roads won't get closed. You know you don't have to slog through mud. It is really just fine.

A lot of people do use the winter to take vacations in places like Hawaii (I visit my family in Miami, but believe me I don't go swimming in December anymore). That's why I included Hawaii. That is probably the favorite destination for vacations and lots of direct flights and tour packages make that easy. Of course just as many people head north to the great ski resorts of the world like Whistler and get that same "recharge".

If you keep comparing different cities some things might jump out. Like why don't we move Microsoft to Hawaii? How about Las Vegas (brrr...memories of freezing at COMDEX)? Probably not Chicago. Of course San Francisco is well known for having moderate yet wildly unpredictable weather--"the coldest winter I ever spent was a summer in San Francisco" the saying goes (Mark Twain did not really say that)--and the summers are known to be fog-filled (taking the SFO-SEA shuttle is an adventure for sure!).

Geographically and thus in terms of weather, Seattle is one of the most unique locations in the continental US. Seattle itself is moderate. But the state of Washington has alpine regions, rain forests, plains, and quite a lot of farmland as well (all those apples, Walla Walla onions). Seattle is also located along the same latitude as the wine regions in France and turns out to be a source of some great wines as a result (Columbia Valley wines). Seattle also has a huge glacier lake that is an awesome place for boating activities. If you like fishing, all sorts of salmon and other wild fishing sources are nearby. And for those of you that are ocean going, the Puget Sound is a great boat ride. In terms of outdoor activities, it is fair to say that Seattle is a leader in mountain biking, snow skiing/boarding, hiking, alpine climbing (Mt. Rainer among others), sailing, hydroplane boating (ok, not for everyone), road cycling (there's also a velodrome about 1 mile from Microsoft), camping, rock climbing, and so on. There's a reason REI started in Seattle!

The most amazing thing about Seattle weather is the summer. You have 15 hours of daylight. Clear blue skies. Nights filled with stars. Clear air. You open your windows and sleep comfortably. They are amazing. Every single day. Any intern who spent the summer here will tell you that you just cannot beat the weather in the summer. So even if the mist gets you down a little, the summers more than make up for it.

Of course in those winter months there is plenty to do at night. Seattle is pretty famous for having a pretty cool music scene and there are tons of clubs downtown (where many recent graduates live). Seattle also has world class symphony performances. We have a very active theater community with many Microsoft employees participating in original Seattle-based productions. We have ballet and dance. The Space Needle. Well...come out here and see for yourself.

The weather is something everyone everywhere has an opinion on for sure. I believe if you're thinking of moving to Seattle you should not use the weather as a reason to pass by the opportunity--actually I would say use the weather as reason to take us up on our offer.

--Steven

PS: Here in the USA it is Thanksgiving -- have a happy break from school and I'll be back in December!

The 100 hour work week: believe it or not?

steven_sinofsky — Wed, 16 Nov 2005 23:14:00 GMT

So how much and how hard do you have to work at Microsoft to be successful? I was asked this question by a graduating student who has an offer from Microsoft to be a software design engineer. Actually the question was "do I have to work 100 hours a week to be successful?"

I went back and forth in my head how to answer this one. Well on the one hand, I should probably say that if you come to Microsoft you will have a balanced life where you can work, have hobbies, have friends, and all will be great. On the other hand, I keep reading articles about how at "Web 2.0" companies you get hired from college and live in your office--you don't even need to leave to eat since they bring gourmet food to your office. So I certainly would want everyone to think that Microsoft has a competitive offering and that if you join here you can live in your office and work 16 hours a day (or night). But I would not want folks to think we're inhuman.

I'm not really sure what the best way to answer this is, so let me just tell it like I see it.

The truth is there are two "cycles" of workload that you go through at Microsoft. The first is the cycle that starts as a college new hire and evolves as you gain experience. The second is the project cycle you are on and how that has an ebb and flow.

When you first join Microsoft from college you are very much on a "college clock". That generally means you arrive with that blurred view of "work" and "social life" because in college things are all basically one long experience, punctuated by exams and the summer. You probably want to sleep late and work late. You probably move out here and don't bring a built-in social network like the one you developed at school. And you probably are really anxious to start your job. All of these lead to a pretty intense start to your working life. You are probably going to work as much at Microsoft as you did in the combination of attending classes, studying, and doing project work. At Cornell I took about 18 credits a semester, which translates into roughly 18 class hours per week and generally the guideline was that every hour in the class was 2 hours of preparation or work over the course of the semester. So that means just over 50 hours per week. That pretty much is what I would say is average for a new hire. Is that a lot? Not enough?

Well when you're new at something you always put in that extra effort and pay very close attention to all the details. Some things are way harder when they are new (like how much time it took to write a 5 page paper as a freshman compared to a 20 page paper as a senior). Coding on commercial software is no different. It takes a lot of effort up front to contribute effectively and efficiently. And when you're new you will put in extraordinary efforts to get those first pages of code done well--you will write and rewrite them and test them repeatedly. Believe me it is a big deal writing code and checking it in for a few hundred million people to use! And since at Microsoft you are on real products the day you show up, this will likely be a pretty all-consuming learning process.

In other words, no matter how many hours you are officially supposed to work when you are new you will put in a lot more to get those projects done. That is ok. No, that is expected because you are going through the learning phase. Your learning is not happening on a practice field but is happing in the big show. So the extra hours and effort are worth it to you and the team.

And of course as a college hire you are joining Microsoft with a large number of other college hires (we will hire more people from college this year than any other year, and more than any other computer software company I'm pretty sure). In fact, there is a good chance some of your classmates will also be joining Microsoft. So in many ways your college experience will get translated immediately to Redmond (or Mountain View, or any of the other locations mentioned in other postings). Every "class" of Microsoft has different things that become popular and even within the class you get the same sort of extra-curriculars that you had in college. Some folks go to dinner and movies with their team, others go with their classmates. It is just like in college where some people ended up being friends with their house/roommates and others found people through organizations (at Microsoft we have all the same sorts of clubs you have in college--I spoke at CHIME last week, which is Chinese Employees at Microsoft, for example).

Microsoft will feel a lot like college in terms of the hours you put in and the environment you work in. It will be fun. It will mean late nights. It will mean "hanging out". All of those same things. That was my experience and when I look around I see the same thing happening now.

The only thing I would say is that anyone who tells you how cool it is to pull all-nighters on commercial software or anyone who says "I live at the office" and means it, is really someone I would not want checking code into my project. To be blunt, there is no way you can do quality work if you do not give your brain a break. Since the 1940's people have been studying the quality of work people are capable of without the proper sleep, change in environment, and exercise. There are reasons why even back during Apollo moon missions they forced the astronauts to sleep and not run on adrenaline. So working at Microsoft does not push the limits like this--it is not good for you, not good for business, and not good for the customers paying you for your software. If a company is driving you to work crazy hours like this, either because you want to or they want you to, it is just uncool.

There is an "arc" to this and as you get older two things happen. First, you get better and what you do. So you really can get the same amount of work done in less time, and you do it better. Just like how you got better at problem sets through college. And second, you do start to develop a "work-life" balance. For some people this happens in 3 years and for others it happens in 5 or 10. It all depends on you and your own skill/career arc. You are not slowing down. You are not doing less. You are becoming better at your chosen profession. You are moving from an apprentice to a skilled practitioner. Your individual contribution should be increasing each year as you get promoted and gain deeper and broader knowledge. But you also might be developing a relationship with a significant other. You might want to start a family. You might be contributing significantly to the community. You might actually be taking your vacation and going somewhere other than visiting your parents.

Microsoft is a place where as you increase your skills and advance your career you also simultaneously develop a more balanced approach to life. You have to. Because we want you to have a long and balanced career at Microsoft we do expect your career arc to allow you to attain more balance as you gain experience.

The project cycle represents ebb and flow of work that overlays your own career arc. This workload is well understood and repeats itself each project, but even here we are careful about what is good business and common sense.

The role each of development, testing, and program management plays in the project cycle is matched by level of work "intensity" over the course of the cycle. Early in a project cycle is when program management is writing specifications and planning the release. Testing and development are reviewing specification and planning their next steps. Development is not actively writing code and so their intensity is relatively lower. And testing is likely very focused on planning for the end game. As we progress to the coding portion of a project, development really ramps up their efforts and the intensity increases. Developments intensity also increases as the schedule gets closer and closer to the "end". This is because developers own their own schedules and sign up to get their work done based on their own estimates. So as you can imagine this gets pretty intense. But you are on record to deliver about 35 hours of coding per week (depending on how your group accounts for the schedule) so any "overtime" you put in is really your own. Of course developers also love to go above and beyond the call of duty so it is likely that cool features get done in addition to the committed ones. As development nears the end of coding, testing really ramps up. This is where we are now in Office "12" and in fact this morning we had a test manager meeting going over the work needed to get to our second beta (our first beta is about to hit the streets).

As an aside, it is really the case that you own your own schedule. This does not mean that you work in isolation for as long as you want--your work interacts with other's work and other's depend on you. It does mean that you have to take the desired outcome and scale it appropriately to fit within a normal schedule. Of course you don't really get trained in this in college so that is the role of your lead in terms of mentoring you and helping you to estimate and gauge the work ahead of you. Over time you become expert at this and then soon enough you are managing and mentoring new people yourself.

A lot of companies think that it is cool to buy dinner all the time and do whatever it takes to keep you at your desk to work more during these "crunch times". We actually don't generally do this for Office (though some teams occasionally do). Over the years we've found this is not a good practice for the team overall because it encourages a style of work that does not yield good software. But trying to keep people chained to their offices, in the name of encouraging team work and dedication, does not help. I remember back in 1990 working on the first C++ compiler and we were doing the dinner thing for the team and I remember noticing that a lot of folks would just end up eating dinner at work then going to dinner later in the evening--that does not get better code, though it does yield bigger waistlines. I admit then when people tell me about other companies that buy you dinner and change your oil in an effort to keep you focused on work, I do worry about your health and if you really are able to write quality code. The best example of this is just how you can stare at a bug for 8 hours and make no progress, but if you leave work, clear your brain, and maybe do something nutty (like ride a bike, play racketball, or play poker) you probably will find you can fix that bug with a whole fresh perspective. I think that is an important part of every work day.

Therefore the work week has different levels of intensity as you move through the product cycles. There is a flow to this just like you have a flow to a semester (introduction stuff, problem sets, mid-term, project, final). But for a Microsoft project there are numerous highs and lows that map to both the discipline you work in and the phase of the project.

I think it is super [sic] important that throughout the project cycle you pace yourself--like any endeavor you can only run so hard for so long. What we do is hard, unpredictable, and important for a lot of people. It is also incredibly fun. What you find on our development teams is that most people would be sitting in front of computers, even if they didn't get paid. Computers are also our hobbies. Most of us run elaborate home networks, love to help our friends and family with their machines and networks, and many of us help local community organizations with their PCs. But it is also important to balance this with the need of your brain for down time and the need for you to gain a perspective on your work and what you do.

Finally, the core question is not just do you need to work 100 hours a week, but "do I need to work 100 hours a week to get ahead". The answer to that is definitely no. You need to get a lot done and you need to do it efficiently. We want you to be a heroic developer in the sense that you get more high quality work done in a shorter time than others, but not in the sense that you can work 100 hours straight to produce 50 hours of work without sleeping, eating, or leaving your office. Microsoft went through the phase of growing up where we thought the best programmers were those who survived on Starbucks and gummy bears--we actually studied bugs counts and defect rates and found that the people that wrote the most code, also had the most incomplete code and the most bugs/line. We want you to be great programmers who write high quality code that works right the first time and for a long time. That takes far more skill and talent than you can make up for by sitting at your desk for heroic hours. Developing your skills, making sure your code is complete, bug-free, highly performant, scalable, highly secure is the way to get ahead. Maybe your manager works a lot (I do) or maybe your manager is very efficient, but the hours you work is not a measure of your ability to succeed and certainly not something you get evaluated on. You get promoted because your work excels relative to your peer group--because you get done what you say your going to get done; it works super well; and you got done the right amount of work relative to your peers.

Working at Microsoft is hard. We have a lot of people counting on what we deliver. You will put in a lot of hard hours. But if you are managing your work effectively then you will have a rewarding career and a rewarding balance between life and work.

--Steven

Release timing and Office products -- how fast is fast enough?

steven_sinofsky — Fri, 04 Nov 2005 02:07:00 GMT

I've been asked quite a bit by people interviewing at Microsoft about "software release". This post will talk about our strategy around product releases for Office products, since we have been pretty consistent over the years and this represents a balance between some competing interests.

The topic comes up because there has been a lot of web discussion and press about products at Microsoft that have taken a long time between major releases. This post is about the way we structure releases of Office. In the big picture, one of the things that is a hardcore Microsoft "value" is that we learn from our past experiences and work hard not to repeat things in the future. An article on this can be found in the WSJ which talks about some of the introspection we have done and more importantly some of the mid-course changes we have made within some of the teams at Microsoft.

If you work on Office, you are using software that people use everyday to do work that is really important to them--lots of money, important decisions, and grades rely on Office working well. There is clearly a lot going on in the industry and a lot of "2.0" discussions, and Office plays a big role in bringing those to the broad base of customers in their productivity tools. It is also the case that we have to make sure that Office works extremely well--once a customer makes a bet on Office we owe them a very strong level of commitment and service. That is decidedly different than many of the new products and services that are out there. If you lose work in Office or can't get something done quickly in Office, the cost is much higher and your alternatives at the moment fewer than many of the other types of products out there today. We take this responsibility seriously and it also makes for a unique experience working on our products. If you've been tracking the Office12 blogs (linked to on this site) you can see the comments from folks that do rely on Office and the emotion around the software.

The first thing to realize is that with products like Office there is a whole product lifecycle to consider. Often people think of the big bang release and talk about that, but in reality for Office there are five different releases going on all the time:

Office product wave. Of course the thing that captures the most attention (when done right, the other developments just work and don't cause any stir) is the new release of Office. Since Office 2000 we have focused on delivering most all of the Office products at the same time--so of course Word, Excel, PowerPoint, Outlook, Access, but also Project, FrontPage, and now Visio, OneNote, InfoPath, as well as all of our server products. We have found that releasing the products all at once allows us to develop rich scenarios that cross products (such as Project integration with Excel for analysis and SharePoint for the server). Customers, particularly at the enterprise level, definitely strive for a 1+1=3 solution and see the benefits of a broad set of products designed to work together. Of course we also work to insure that we deliver the best components as well.

Immediate updates to software. These are done on short notice and represent issues with the software that must be addressed "yesterday". These can be quality issues, potential security issues, or exploited security issues. These are very small in number (we have had 3 of these in Office 2003 since it released in November 2003).

Customer driven updates. For corporate customers, developers, or other software vendors we have in-depth support relationships that offer these parties support professionals to help troubleshoot and diagnose issues they might be having with our products. These can result in an "escalation" to the product team if the customer or support professional believe that the product is not meeting the needs, not operating as specifying, or is just broken. We actually see hundreds of escalations in a month. Most of the time these are properly handled by using an alternate way to accomplish the task or by changing some deployment characteristics. Other times a product change is warranted. These changes can be small code changes, significant UI changes, or new features. Any change we make to the product this way will be made available to 100% of customers around the world so we do make sure that these are in the best interests of the broadest set of customers. In a given month we might do 100 fixes along these lines--that's over 100 changes to Office every month.

Broadly available Service Packs. About every 8-12 months we release a "service pack" for a product. Along with all the customer driven updates, we also address the crashes and hangs that we see being reported by our "Watson" tools. We get millions (and millions) of reports of these issues from customers and we constantly look at this data to make sure we understand how Office is functioning in "real world usage". If we see a spike we jump on that right away and perhaps this might call for a critical update (we did this with Office 2003 early in the product cycle). This "instrumentation" (which is anonymous, private, and opt-in) has radically redefined the way we can improve the quality of Office. In the past these issues would linger and we would never know which ones to fix or how to reproduce them. Since Office XP we have been whittling down these errors in the product and have radically improved the overall robustness of Office based on metrics like "mean time to fail" (tracked with this same mechanism). So these service packs offer a big improvement to the overall product quality and allow customers to get all the updates we have done during the previous months. For a given release over the lifetime we will generally do 3 service packs. Generally speaking it is worth noting that we support a release of Office for 10 years from RTM. This is a big commitment we make to customers and it means that at any given time we are fully supporting 3 different versions of Office, because customers expect that from us and it is an important part of why they rely on our products.

Continuously improving OfficeOnline. One element of the Office products is our OfficeOnline web site. This is not just another product information web site, but an integral part of the product's experience. OfficeOnline does contain pre-sales information, but it also contains a vast amount of content designed to help make using the product better, learning the product easier, and maintaining the product as an admin much more efficient. You can access OfficeOnline through a browser, but you can also access it by just using File New and using templates, or Insert ClipArt and using web-based clipart, or just by typing a question into the help "box" at the top right of an Office window. As with other web sites, these queries and usage patterns drive site "programming". One of the biggest things we do is respond in near real time to the questions and problems customers are having use Office. This not only causes us to write new articles, tutorials, online courses, etc. but we also look to see how people rated the articles and then go back and fix those. We are constantly scoring these articles and looking to improve them based on real world feedback and also add new articles based on current problems. Of course just like your favorite shopping sites, we offer timely templates, clipart, and other content -- at Valentines in the US we have lots of hearts, at Tax time we offer tax spreadsheets, etc. And by the way, all of this is done globally and in a locale specific way.

So that is a rough look at the "velocity" of change of the Office products. For the product that is in market you can think of this graphically as the following shows. In this picture I've made the length of this the rough average for time between product waves (more on that below):

Is this fast enough? Or is this too fast? Good question! The answer really depends on the circumstances and how you measure success.

Let's take this question to really be one about the major releases. I've heard a lot of people say that major releases are a thing of the past and that what is "new" today is that software should be released "continuously". Continuously is a lot of software for people to absorb. For some things this works well--I love that shopping web sites have all the newest products all the time for example, and of course I love that we are constantly adding new clipart and templates to OfficeOnline. But for other things even ones that are traditionally continuous, new things all the time can be a chore--for example I love reading The Economist, and it comes with a lot of new stuff all the time and I can't absorb it at the pace they can deliver it. For engineering and manufacturing products, like cars, what seems to have worked for a long time is a big new product followed by subsequent iterative improvements (Toyota famously squeezed that cycle time down to 3+ years rather than the traditional 5-7 years US companies used, but the concept remained). Some would say software is different and some might even say that software on a server is even more different. There is no doubt that technically software is easier to change, but what do customers want, expect, need? It isn't obvious and like so many things we have talked about the answer is "it depends".

Before we look at the choices, here is the history of Office products since Office 97 (taken from microsoft.com):

For Office, some customers are very conservative, or even extremely conservative. They say that Office has no big improvements left or that the cost of deploying and updating is high enough that the product should be updated infrequently, perhaps every 6 or 7 years. I happen to think this is extreme but we do hear this quite a bit (though I would also say these same customers are quick to request their favorite features and say they would like those right away). Other customers, perhaps the trade press or magazines that write about Office, might like this to be more frequent because they can generate more of their business with a big new product to talk about and they might like something very frequently about every 6 months or so. I think that the best place is somewhere in the middle of course. And keep in mind that throughout the talk of the release, we are updating the product as described above--we're not "dark" but always improving things for our customers. What we have found works for Office is about 24-30 months between releases, or so. We've done that pretty much for the history of Windows releases. Sometimes we are a bit shorter, and sometimes a bit longer (the average since Office 97 is 28 months--you can see this on http://support.microsoft.com/gp/lifeselectindex).

Another constituency in this discussion is the marketplace in terms of how and when they can take the time to understand what is in the product, and how they will adapt to using the product. In this case, I would think again about the Economist. But instead of thinking about the new content, think about what it is like when they change the layout of the magazine. This is a major deal (like once every 10 years). But it actually has an impact on you and you need to adjust. Imagine if this happened every 6 months! That would be more than you could absorb and they would spend a lot of pages explaining the change and you'd probably get frustrated. I'm sure you have experienced web sites like this--you feel like your hand knows where to click and then after a few months things move around. So even if you have a web-service based product you need to consider that people need to adjust and learn and once you have a lot of customers/users you can't change things with a very high velocity or you might alienate people. The changes probably are better being bunched up and delivering as a "theme" around a set of changes. This is how the magazine views a new layout and how a car company views a new model. It turns out this is great for the people that market a product as well--having a small, but frequent, set of changes is a rather significant marketing challenge. But having a broad set of changes with a theme allows the marketing people to more effectively communicate the product. Trying to raise awareness of a single new feature can also come across as artificial--if you're trying to read your mail do you really want banner ads for new features to manage your email? While the context is right, it seems a bit distracting. We tried that in Word 6.0 with the "tip of the day" :-)

Office has an extra challenge in that the set of features have to apply to a lot of different types of customers--end users, IT pros, developers, business people, and of course all the industry folks like the press, analysts, etc. (many of whom are also end-users). This means that you have to consider in each release how to offer those customers features they might want. It means for example that each release of Office has features for a broad set of constituencies. There aren't a lot of other types of products that have to meet this test--it comes from the breadth of the customer base of the product I think. It means that it might not be a good plan to offer just a few targeted features for developers, because you won't get any end-user demand. Or even though a few end-user features might make for a good article in a PC magazine, you won't get a lot of support from the IT Pros that have to deploy and support the product.

One of the biggest challenges in product design is what to do when you have a "hit" feature that everyone wants, or a feature you think will be so hot that everyone will want it. Most of the time you figure this out only after you are done developing it and get feedback. I have a first generation Toyota Prius and as soon as I sat in it the first time I knew that the gear shifter was a design mess. When the next model came out they changed that and boy did I wish I could just take that gear shifter and move it to my car--but no such luck I had to get a new car (I didn't. Software is a lot like that -- you see a new release and you just want one thing and wish you could get that on your machine without paying for a new product or "upgrading" (like when PhotoShop finally added RAW support and I didn't need all the other stuff in CS). The challenge we face with Office is that nearly every feature is used by the whole universe of people, and so by definition there exists a set of people who would want that one single new feature and nothing else (see Jensen's blog on the new UI for frequency of command comments). More than anything, I hear this from individuals talking about specific features they would like. Even more interesting is trying to think if we could somehow communicate and market a release based on some of these "nuggets" because more often than not this would be really hard. Sometimes you get amazing nuggets like red squiggles for spelling in Word, or AutoCorrect teh->the. But those are the big home runs of features in their area and don't happen all that much, and of course when we were doing them it was not always universally agreed that they would be such a hit (AutoCorrect in particular). It is important to separate the ability to release things and the market desire for those things. Of course we release hundreds of changes as described above, but trying to communicate these is a huge challenge because they are not part of a larger whole and are about "customer service".

Professor Iansiti at Harvard once told me that he thinks of "innovation" as really an equation: innovation = invention + impact. In other words, it isn't enough to just invent something cool, but you have to have an impact as well. A big part of having an impact is getting the word out on what you do and making sure people ultimately use and benefit from the work. The timing of a release has a lot to do with the impact. Too fast, and you pass people by or frustrate them in their ability to absorb the change. Too slow and you miss the opportunity or circumstances change and your invention is no longer relevant or inventive. It is a fine balance. Often only hindsight is 20/20.

Finally I would also say that as a new member of our team, the ability to participate in all of these offers you a chance to really experience the breadth of software engineering. You definitely hit the ground running and you'll want to contribute soon. But you also have the time to learn and the time to gain experience in our industry--you won't have to release your first code as a critical update (that takes a lot of experience) but at the same time you probably will end up waiting less than a year before your first projects see release, and less if you count pre-releases.

This is where we are today. Things change a lot over time and nothing about what I said above is written in stone. We build our products for customers and we listen carefully. If there is a sea change in how customers want their software delivered or what time frame we should deliver software then we will of course change--without customers liking what we're doing we're definitely way off course.

--Steven

Where should I work? Global development of Microsoft Office.

steven_sinofsky — Sat, 15 Oct 2005 07:05:00 GMT

"Are you able to shed any light on how much software development takes places outside of the US? Or indeed, what happens at which Microsoft sites around the world?

Why would a new grad come to Seattle to work for Microsoft when he can work for Google in Mountain View, New York City or Zurich?"

I would love to talk about our development organization and how it works around the world. For me working at Microsoft has been incredibly rewarding because of the opportunities I have had to work with developers around the world. I first worked with Microsoft developers in Japan as we made the Japanese version of C 7.0 and Visual C++/MFC. Of course not everyone is required to work with folks around the world, but if your job involves that it can be quite rewarding. If you happen to speak another language, then be sure to mention that since that might offer up additional opportunities (PS: don't exaggerate your language skills or you might find the interview with a native speaker a bit awkward!)

First, as some background the Office product is available in over 40 languages around the world and we sell the product in over 70 different countries (at last count). We develop Office to be a single, worldwide binary. This means that all the user interface, help, and local features are separate from the core executable. To switch the user interface language you simply swap out some DLLs using the "Office Language Settings" applet (off the start menu) and bingo! a new language (assuming you have the multi-language pack). The benefit of a worldwide executable is that patches and bug fixes that touch the core code (i.e. a security issue) can be done with a single patch worldwide. This is all pretty neat and it actually took us many releases to get this right and we still continue to refine this so that even at the extremes we can separate out functionality like using calendars (lunar, western, etc.) so that we can maintain a worldwide executable. If you haven't seen your own software running in Hebrew, Chinese, Urdu or another language then you're missing out. In the first floor of our building in Redmond we have the CDs from a bunch of different languages decorating the hallway and it really shows the breadth of work that everyone does indirectly.

The Office products are developed by a number of sites around the world. Most of the C++/C# programming is done in Redmond. This is what you will find with most Microsoft products (with the exception of our Dynamics business software which has most of the development done in Fargo and in Europe). In addition, Office has a number of substantial development sites (all of which are hiring from college and industry):

Mountain View, California – We develop PowerPoint and much of Office's graphics functionality in Mountain View at Microsoft's Silicon Valley Campus. We've maintained this site for almost 18 years (though it has had several locations in the Valley). The Silicon Valley Campus has over 1,000 technical people developing a variety of products and services important to Microsoft’s future.
Beverly, Mass. – We develop Groove and operate the Groove services infrastructure from here.
Dublin, Ireland – Our Dublin location is our globalization hub and from here we localize, test, and release Office in over 30 languages.
Tokyo, Japan – In Tokyo we target our development efforts towards specific needs of the Japanese market, since culturally and linguistically customers require Japanese specific features. We have also learned that many of these needs actually solve problems around the world (like enhanced tables in Word) so this team will routinely ship their work as part of the worldwide product. We also create the Japanese localization of our product here. Through an East Asian effort (Japan, China, Taiwan, Korea) we develop the Input Method Editor (IME) which is a linguistic tool that allows the mapping of keystrokes to Japanese, Chinese, Korean characters. This is some high tech work that has been ongoing for many years and has involved collaboration with linguists and Microsoft Research.
Beijing and Taipei – As with Tokyo, we develop local features for the China market in these two R&D locations. We also create the localized products here for Simplified Chinese and Traditional Chinese (the two scripts). As an example of the work done here, we have developed the ability to send SMS messages from Outlook, which is super important for the China market.
Seoul, Korea – Similarly, we create the local features for the Korea market and also localize the software into Korean. In Korea, workflow and Office automation are very important so for example in Office "12" we have done quite a bit of that type of work here in Korea.
Global Product Planning – in addition to all this we maintain product planners in several other additional locations in Europe and the Middle East. They are responsible for the market-based intelligence and working with customers in their native language to better understand their needs and how Office can help.

For most US and Canadian college graduates looking for a technical career the primary locations to consider are Redmond, Mountain View, and Beverly. This is where you will join the teams that build the worldwide executables. Working in one of the Asian offices would require language skills (Trust me! Last year, I spent 3 months living in Beijing and you definitely want to speak Chinese.)

From the earliest days Microsoft has chosen an R&D model that encouraged all developers to work in one central location. This was not the industry norm as set by IBM where development happened equally all over the world (nor was the fact that most all developers have a private office at Microsoft compared to cubicles). The reason was that there is a strong belief that to build highly complex systems you need to have very high bandwidth communication. The core customer benefit that we drive to is to deliver software that works together and software that has a 1+1=3 cumulative effect. So for example, customers that invest in one technology for working with one product can use that same technology and work with other products. Now this is very hard to deliver and we continue to have ambitious goals to meet customer needs, but this integration is something that Microsoft does work to deliver uniquely. Some like to say that this type of development is slower and that it reduces the pace of innovation. Such statements leave out two important characteristics. First, the integration of products is itself innovation—having two pieces of software work well together in a unique high bandwidth manner is innovative (before Office, word processors and spreadsheets shared information through file import/export of proprietary formats, not just a clipboard). Second, I have never met a customer that does not request even more integration than we currently deliver and the flip side is that I have never met a customer that wants to invest in "point solutions" or a series of unrelated products. But I digress…

So we are focused very much on developing our software from our campus in Redmond. There are a couple of things to really think about when you consider that some companies will essentially let you work from home (wherever that might be) or will let you work in a satellite office:

Critical mass – For any R&D facility you need critical mass to cause the flow of ideas and feedback to really work. You need to interact with people, to bounce ideas around, and to have other people to help solve problems. This number is way bigger than you think if you have just experienced college scale projects. I think the minimum number for this is to have about 50-100 people working on the same set of goals and project.
Visibility of your work – Everyone wants to see their work presented and valued by the leaders of the company and your group. In Office, as we conclude the coding for each project we invite BillG to tour the building and see demos from each team (and during the project we will present to him many times as well). This can only work because we have most developers in Redmond and Bill is in Redmond.
Management input – Along with visibility of the work, the truth is that for your work to be connected and part of the group's mission it really helps for work to be discussed and talked about at regular intervals. While electronic communication is obviously easy and available to all of us, I have found that nothing beats face to face meetings. Often these are informal and happen in hallways and other occasions. I've heard stories about other companies where to get your work "approved" you need to come in Saturday night for a 5 minute meeting with one of the founders. While that sounds exciting and cool, if you want big things to come of your work you are going to want more of an opportunity to share your work or make your case.
Career opportunity – Everyone wants to gain deeper technical knowledge or broaden their management skills. To do so is going to require a critical mass of products or people to work with. Small satellite offices or working from home make this very challenging. If you work in a satellite office then there is a good chance that moving on to a new project will require you to move to a new location. Or if you want to move to management you might not have as many opportunities in a satellite office because the number of jobs and the growth of employees is limited.
Sales and marketing – Even if you are technical employee, there will come a time when you either need to or want to interact with the sales and marketing folks. You might want to get their input on features or you might want them to set up some time with customers. Generally speaking, if you are not in the main part of the company's facilities you are not likely going to be near sales and marketing, as those folks tend to be located pretty close to the executive offices (go figure).

That said, offices that are "remote" can be made to work but it takes an deep commitment from the management team—the people that the most senior members of the team in the remote site report to. For example, the manager of our team in Mountain View spends 2 days every other week down in Mountain View. I manage our Groove team and I travel east every 4-6 weeks to spend a full day meeting with the team and meeting 1:1.

And working remote takes a commitment from the rest of the team to support this type of work. The members of our teams around the world all travel to Redmond. The closer teams (Beverly and Mountain View) travel very frequently sometimes as much as every other week. But it is not enough for them to make it out here. Because we value the integrated approach to development, the members of the team that work here in Redmond are prepared to work closely with these other team members as if they worked here full time. We also have members of our team from overseas spending 2 or 3 weeks at our Redmond campus.

We also work very hard to move people between our sites, in keeping with our general guidelines that working through full product cycles is super important. Also, because we are focused on building out the sites we do choose as extensions to our headquarters R&D and not isolated projects, locations such as SVC are used by all the product lines, which means you have opportunities to move to other projects at the remote facility and still be connected to significant mainstream projects at headquarters.

Also both BillG and SteveB visit our sites outside of Redmond routinely. For example, SteveB was just at our Dublin facility and BillG just visited our Japan facility where he got a demo of the IME and workflow features mentioned above.

This means we have an incredibly high level of commitment to our remote development sites. They are critical to our success and very much "first class citizens". Yet there are challenges in maintaining these sites and it is not as easy at it seems.

It is easy to be seduced by a company saying that you can tele-commute or work at a small satellite office. For a short time that might actually work. In the medium term you have to ask yourself if the tradeoffs are compatible with your own career goals. And over the long term you have to consider that the opportunities that will be open to you will be a different set than if you were part of the bigger corporate structure. And ask your potential employer what is the visibility the remote site has to corporate? Will the manager of the site at corporate be a core R&D person or a "facilities manager"? Will the CEO/founder visit the site? Will the manager from the main R&D facility visit? How often?

Another thing to consider is that when you have a core R&D facility and the company works on the breadth of products that Microsoft does there are two advantages. First, you have access to experts in just about any field—if you are working on SharePoint and want to get the best advice on how to use SQL Server then the team is right there and willing to help. Or if you are pushing the state of the art in development tools and want to work with leading researchers, Microsoft Research is right there. And second, you open up a great deal of career flexibility for yourself—you can find new opportunities on new technologies or you can pursue career growth through management, or both. All of these represent opportunities in the Redmond facility at Microsoft, and when combined with the balanced approach we take with remote development, I think we have a very good set of opportunities.

This topic would not be complete without a few words about "off-shore" development. This year Microsoft will hire a record number of college graduates (and experienced individuals) to our product groups. Our demand for talented employees is still greater. Because of that we will continue to hire record numbers in the US while at the same time continue to grow the facilities we have had overseas. As you can see, developing software from a single location affords us a chance to do great work for customers and this will continue to be our primary mission and our primary engineering structure.

--Steven

Bureaucracy. Threat or menace? Either, both, or neither? Or it depends!

steven_sinofsky — Thu, 06 Oct 2005 07:21:00 GMT

bu·reauc·ra·cy

a. Management or administration marked by hierarchical authority among numerous offices and by fixed procedures
b. The administrative structure of a large or complex organization

I was able to spend the day today with students at Harvard Business School. I was fortunate enough to meet a number of second year students and was invited to participate in a class teaching a case on the development of Office 2000. I spent a semester teaching at HBS and it was great to be back in a classroom where the students bring incredible insight to the problems we face in building Office. This post is about a discussion I had a number of times today—the topic of bureaucracy. The topic applies equally to undergraduate computer science majors and to MBAs, and is certainly one that based on your interest will generate further posts on the topic.

Up front, it is of course impossible to defend bureaucracy. So any attempt to justify rules, process, hierarchy, etc. are met with a groan at best or a complete rejection at worst. In fact it is common to just assume that anyone brave enough to defend such structure is either oblivious or stupid, or both, and in all cases probably a pinhead you would never want to work for. After all, in the world of technology and the internet the one who is out there with no rules, no process, no hierarchy is the one who is going to win big while all those sloths with their spreadsheets and dashboards are all bunched up trying to plan their way out of a paper bag. OK, maybe I went too far. But the basic challenge in talking about this topic is how do you say that Microsoft is not bureaucratic when there are articles out there saying that the company has become too bureaucratic? How do you talk about this topic without at the same time sounding like you like something which everyone obviously loathes?

It is worth noting that I am sure people can share with me stories about how bureaucracy has stifled their progress at Microsoft. We make mistakes and we have dumb things. But I also heard a stories from HBS students today about how difficult the HBS administration is to work with (just ask them about recruiting!). Of course I have friends at all sorts of companies that tell me (in private) stories of how bureaucratic their organizations are as well—some of these companies are even famous for claiming not to have any bureaucracy. Organizations of more than about 100 people are all capable of dumbness—once you grow beyond grabbing money from the petty cash drawer you have process and once you have process it is a matter of time before you don’t understand what is going on. If you don’t believe me then you just haven’t worked with more than a 100 people or you just never happened to stumble across the processes.

In class today we talked about the development of Office 2000. This is a case that “Describes the history of Microsoft's Office product suite. Discusses evolution of the Office 2000 project. Set at the end of the project the team must decide upon the direction for the next version of Office, as well as make changes to the process.” This is a case that goes into detail about how we decide what features to put in the product and the overall engineering process. It was written in 2000 after the release. What is fascinating for me is seeing over time how students in different classes react to the case in the classroom—believe it or not even though the case is unchanged and the facts are the same, students have different views of the important issues of the case based on the perceptions of Microsoft in the market. I didn’t expect that for sure. [Note: business school is often taught by the case method—this is a way of learning through narratives with the goal of discussion the situation faced and the possible alternatives, but not necessarily about finding the right answer since most of the time there is no single answer.]

When the case was first taught, a lot of the focus fell to Microsoft’s plans for being successful in the market and how the product was another release of a successful product. There was always a lot of talk about the big plans Microsoft had for the software and how it would lead to further success of an already wildly successful product. And while the case brings up some issues relative to the challenges the team faced, most of the focus was on the challenges the business faced—was the product late, was it the right set of features, did the company do a good job listening to customers. That was an era where our success probably shaped the perception quite a bit.

Today, the students picked up on issues in the case related to the efficiency of the development team. Now of course that is an issue. In fact the reason this was in the case was because shortly after the project was completed we did our planned (and rigorous) postmortem on the project. From that we identified that we had probably pushed too much on to developers to keep the “daily build” of the whole Office product stable. But in class, there was definitely a feeling of “see this is that Microsoft bureaucracy that we have read about”. But wait a minute this all happened starting in 1998!

What changed? Well very recently a perception has developed that Microsoft has become “slow” or that there is too much “process” around getting things done. Certainly we have talked quite a bit about our efforts on some products and how we probably tried to get too much done and that caused us to take longer than expected and caused us to make changes to products. But that is something that we have been guilty of from the earliest days of Microsoft—we’ve always had a pretty aggressive appetite for signing up for a lot of work (perhaps more than we could get done!). Like nearly every software project, Microsoft has had projects fail to meet their initial ship dates. As we saw in the Office 2000 case we were about 8 months late from our original schedule.

In class a number of students, not computer people, said that it is crazy and we should just pick the features and pick the schedule and just meet it. Interestingly, the discussion was then “how do you do that” and of course the way you do that is planning. And of course the more planning you do the more you probably introduce bureaucracy. Oops.

Here’s a quick quiz. Which project will get done faster and have better quality at the end:

Project A – starts off with some developers that have an idea and they just start coding.
Project B – starts off with some developers that have an idea and they spend 3 months not writing code, but designing the architecture and interface and then they start coding.

Project A might “finish” faster but it will likely not be finished by any stretch, will almost certainly have a set of features that are not coherent, and probably won’t be very easy to sell unless the developers happened to spend a bunch of that time doing some research to understand how to price, position, and promote the product. Now are there examples of Project A being wildly successful—of course there are. Remember, this is a social science we’re talking about so there is a bell curve and anything is possible. The question is how repeatable is it. About the only time this is repeatable is when you’re cloning something that already exists or building an identical second version of an existing system (many open source projects have the advantage of building based on existing, running systems).

Project B on the other hand has a good chance of being coherent. It has a good chance of meeting a customer need. And most importantly has the best chance of not having to go through a major rewrite one or more times during development. If you’ve ever tried to build a house or remodel a kitchen, you know that you don’t just bring in tools and start sawing and hammering away. Software is no different. Now are there examples of Project B being gummed up and a total failure—of course there are. On the other hand, Project B can be a repeatable process and does not depend on super human programming skills combined with psychic market knowledge.

Returning to our case and the recent change in perception that students have had does raise an issue for me. I certainly don’t think we’ve gotten more bureaucratic. In fact if we were to look at the number of new features, the lines of code, and the breadth of products we have offered with each release of Office we are definitely doing more with the same or fewer developers on the project teams. The question students asked to that point was “yes, but don’t developers feel like they have too much to do to ‘check in’ their code?” The answer is of course—because you should just be able to type a line and then boom, everyone should see it.

But that turns out to be rather difficult. The baseline comparison for this, especially for college hires, is the “edit-compile-debug” cycle we’re all familiar with in college. You are the master of the machine. You have no dependencies on anyone else. You know every line of code. This is an awesome way to write code. It is also the best way to write projects that are the work of one person. Anything more than that and you have a dependency. At the same time, if you are working well as a team you can quickly have a 1+1+1 = 4 or better. The challenge is that you have to put in some process to make sure that you get the benefit of using each other’s code and the benefit of working as a team. It does not come for free. Putting in the right process is very hard work. It is super [sorry I used that word] easy to put in process that makes 1+1+1 =2. Process can sap the life out of a team. On the other hand, it seems absurd that you should be able to change “on a whim” the code of a system that is used by hundreds of millions of people—customers expect and demand that you have some process for deciding what to do. Anything of any material complexity must have that rigorous view. If it doesn’t then the system is a toy or the system just isn’t valuable.

Everyone who has built a software project knows that once you have customers you have an installed base and therefore you have to be careful about changing things. But you also have customers that come to expect features in a certain way. You have customers that might want to have say in how things evolve. You can’t just be an “enlightened engineer” and speak for every possible customer, every compatibility issue. It is likely you’ll need some help. Imagine for example, you wrote the code that decides what advertising to show on a web site (like we have on many sites at Microsoft). You have a great idea to make it better and make a change and check that in—but oops, you didn’t know that product management had come up with a clever, revenue positive, pricing scheme based on how different ads appear. You just changed the company revenue with that “flexible” development process. You then find yourself backing the change out in the middle of the night. Perhaps then the team will put some safeguards in place.

Once you put in a process that “slows” down that work there is now an official bureaucracy. So you have to minimize that so that people can spend the time they have doing the things they like—developing, doing marketing campaigns, etc. Pick any profession—writing for a newspaper, selling cars, being a surgeon, airplane pilot, banking, etc.—in every case people do not get to do their profession 100% of the time. In all professions there is some notion of checks and balances or some notion of planning, arguing, agreeing, deciding, revisiting, fighting again, etc. This is all a natural part of groups of people working together—the editor gets to make you go back and rewrite the article, the FAA makes the pilot take certifications, surgeons have to see patients outside the OR, bankers need to report on their returns, etc. And surprisingly every profession when they have complaints they refer to this as the bureaucracy.

As Peter Parker’s father said (sort of), “with power comes responsibility.” So if you have the ability to put something on the front page of the NY Times then your editor is probably going to get in the way. If you want to change the user interface of Office you bet that a lot of people are going to have opinions and you are going to have to spend the time planning and developing an architecture before you just start checking in code.

But you know through all of this discussion I kept thinking about the developments we have done in Office over the years (since the Office 2000 case) and Office12 in particular. We decided to change the file format to XML in Office – actually the team decided to do it and we just did it. We did not have any corporate oversight, no approval process. We just did the work to make it real. The new user interface in Office was decided on 4 levels down from BillG – it was done so without a big approval meeting, without “top down” forcing of a specific design. Perhaps in a future blog, if I don’t get too many flames on this whole topic, I’ll go through the bottom-up process that led to the new UI. Of course there were many big “fights” about *how* the UI should be done, but if it should be done, or who should do the work, or should we change our mind—none of those were mucked with unskilled by middle managers :-)

One thing we did in developing Office 12 was take our organization and break the work down into very small “design/build teams” that go below the feature team organization I talked about earlier. These “feature crews” allow essentially 1 or 2 developers to work side-by-side with test and pm on their feature areas with a private branch of the source code for as long as they need to in order to get the work done. The “isolation” this affords worked very well for many teams. It is a new process and we’re still learning. But if you look at the feedback from the PDC and TechEd (and soon you can hear from our MVPs) we made a lot of progress in this product cycle that really impressed folks (we still have a lot of work to do).

Another thing that came up in the discussions today was the notion of “it sure takes a long time to do one product cycle”. This is definitely a choice we make for Office. Actually, we release over 100 product changes every month for Office XP/2003—these are customer requests, maintenance updates, and robustness fixes based on our instrumentation. We just released a service pack as well, which rolls up ~6 months of these product changes into one installation. We could release these “automatically” but we choose to do this on a more regular interval because that is what most of our customers request of us (obviously if we had a high priority fix we would be more aggressive). For the full product releases, customers tell us different things. Corporate customers sometimes say they would like a new version approximately every…10 years or so J At the other end of the spectrum, popular computer magazines could use a new release twice a year since subscribers like that J We choose about every 24 months or so since that is a good midpoint.

There’s been a lot written about moving very fast and getting new things out there. That is all well and good. For new markets this is definitely something that Microsoft and many companies do—we released big updates for InfoPath and OneNote less than a year after the first release (about the time between releases of things like the search bars that are popular these days). But the truth is that as a developer you know very well that you can only write so much code in say 6 months. And this is even harder if you don’t have any time to plan. And of course if you are an MBA you know that you can only make a big deal in the marketplace about a very significant innovation—and doing that is hard if there is not a lot of engineering to support that. Every once in a while a small amount of engineering can yield a whole marketing campaign (red squiggles or AutoCorrect in Word). But as we all know, most new features are no massive breakthroughs upon which you can build a whole marketing campaign. So you have to build a set of features that solve a customer scenario or theme. This is an area where in hindsight people always find counter examples—but the question is not can you find counter examples in hindsight, but can you define today a feature that will hit it out of the park in six months? If you can, you’re hired—send me your resume!

Despite this defense [I know it comes across like that, but I didn’t mean it to be] of bureaucracy it is obvious that like any organization we’ve done some silly things. We’ve put in processes that make no sense. We’ve decided things as an organization that are plain dumb. How do we excuse these? We don’t. MS people send me mail. I want to know about them.

Microsoft is a learning organization. It is in our DNA. We are hypercritical about our own work. At the end of every milestone and project we look back and then change things going forward. We take out process as much as we can. We change processes. And most of all, if something isn’t working this is a company where you can send an email rant to the very top leader and I guarantee you that you will be heard (heard is different than necessarily agreeing or acting, though). I know when I get mail like that I am in your office right away. I know many companies have a suggestion box. I don't know of many that have one that is near instant.

Building software that 400M end-users depend on and pay you for is a big responsibility. We’re always balancing that responsibility with trying to push the envelope of new technologies.

I personally like definition (b) of bureaucracy and can't stand definition (a).

--Steven

MBA Opportunities at Microsoft

steven_sinofsky — Wed, 28 Sep 2005 22:48:00 GMT

Before I get started I should point out that I am not an MBA and I don’t play one on TV. The closest I ever came to a business class was when I took Accounting I at the nearby community college in 1990 or so. I’m an engineer through and through. That all changed due to a chance encounter in 1998 when I was recruiting at Harvard undergrad for computer science majors and somehow ended up making a guest appearance in a business school class that was discussing the development of Microsoft Word. One thing led to another and I spent the fall of 1998 as a visiting scholar at HBS helping to teach a second year class “Managing Product Development” and I even wrote up a case study. The experience was a real eye opener and it definitely taught me where the MBA mindset and experience can be a great member of our product and business teams. This post is my perspective on where MBA graduates can have a big impact at Microsoft.

As with most of the jobs at Microsoft, there is some slight variation depending on the business group you join. The overall results are the same—bring great products to market and reach customers in a world class manner—but the division of responsibilities across the different jobs is where the variation is usually. I will offer some views that are biased towards the Business Software Division or Platforms Software Division (Office, Windows, Server and Tools).

If you have a background in engineering or technology, or just a strong passion for technology, prior to getting an MBA and enrolled in an MBA program to make a career change that builds on your technical experience/background but takes you in another direction then this post is for you! For those of you that want to pursue finance, corporate controller careers, or development (if you dream job is CFO, for example) then the best place to learn about the possibilities is from your recruiter or http://www.microsoft.com/mba.

The two core jobs that can be quite interesting for you if you have a technical passion (not necessarily a technical education or background) and an MBA or are interested in focusing on products and technologies are:

Product Planner
Product Manager

A product planner is a member of the product team that is out there ahead of the current R&D efforts. Your role is to be defining new product scenarios that we might want to build in the next generation products and understanding the customer and business rationale for going after the market. Success is measured by seeing these ideas implemented in the product or by the research you undertook driving the product to a specific set of scenarios. Like all things at Microsoft, you will have very strong executive support but your data and research and the case you build is what changes things. In the Office team the product planning organization reports directly to the Corporate VP for Program Management.

The role is one of learning, researching, and communicating. The focus is on competitive products, new technologies, new businesses, and above all customers. You will use a variety of techniques from analytical research, qualitative research, analyzing third party research, competitive product analysis, on site customer visits, etc. The job is one that requires creative and out-of-box thinking since the goal is to inform the development team about possibilities that are not necessarily linear extrapolations from the current product line.

A fantastic example of the role of planning for the next wave of products called Office “12” is how we approached the question of “workflow”. This is a technology area that has not made it into mainstream products in any broad way and technically has been a real challenge for our industry—there is a strong customer demand, but the products have not materialized. Partnering deeply with program management, our product planning team led the development of a model known as “document lifecycle” or DLC. The DLC model turned workflow on end and instead of thinking about the steps of the process, looked at how documents move through an organization. So instead of focusing too much on process, the planners looked at how end-users think about their own work products and how those work products move throughout the organization. Through dozens of multi-day in-depth customer engagements the planners developed an extremely detailed model of the flow of documents across a broad set of industries. This had really not been done before and was a great example of pioneering work. And as if that wasn’t enough, in the course of this research the US law Sarbanes-Oxley was passed which changed the landscape of the problem. The planners were able to reach out and develop and adjunct model around “compliance” and from that came a whole additional set of features that are part of Office “12”.

We recently announced the whole area of Enterprise Content Management at the Professional Developers Conference in LA and it was incredibly well received. The work would not have been possible without the contribution from product planning.

As a product planner you will join the Redmond-based team made up of planners in major countries around the world. The planners coordinate their worldwide research because our products need to be great around the world (for example, these document lifecycle features will likely span time zones and languages for a single work product). You will be mentored by a fellow product planner and have frequent access to the senior leaders of the product team who will seek you out for competitive intelligence and views on broad product trends.

A product manager at Microsoft is responsible for defining and executing the business strategy. You can think of this as the “go to market” strategy for our products. With products based on intellectual property this is incredibly complex and why your MBA background will definitely help you hit the ground running and able to make a contribution quickly. The Office business at Microsoft is $10 billion, selling to hundreds of millions of customers, with product offerings in over 40 languages, and dozens of primary SKUs that cover programs, servers, and services. You will be responsible for equipping a worldwide field sales organization of thousands with the tools necessary to be successful at communicating the value of the products to customers and the press. You will do all of this within a team that is about the size of your business school section.

There are many responsibilities that you will potentially have as a new member of the product management team. Over your career at Microsoft, it will be important to gain a well-rounded set of experiences in several of these core competencies. Generally speaking, early in your career you will dedicate yourself to gaining in-depth experience and success in one area. As you progress through your career you will gain experience in other aspects of product management and/or other product lines. As a product manager in Office you would report into the organization run by our Corporate VP for product management who reports to the President of the Business Software Division (my boss too!) Two of our three divisional presidents started as product managers at Microsoft.

As a member of the development team, I am in daily contact with one function of product management which I thought I would talk about which is the role that orchestrates product messaging and the overall value proposition. We work on products that are enormously complex compared to things like consumer goods, cars, snack foods, or advertising supported products like magazines. There exist literally no other products you can buy that do as many things in one “package” in as many different ways as Microsoft Office. Yet just like all products we have a short time to get a message out there and we must do it in a manner that is in touch with customers, scales globally, and drives success for our business. For Office “12” product management has delivered a very compelling messaging framework known as The New World of Work (NWOW). This campaign was kicked off by Bill Gates and represents the cornerstone of our messaging for Office “12”. Of course you can see the connection to the above document lifecycle scenario, as the NWOW is a campaign built around those scenarios that typify the new capabilities we have developed to deliver customer solutions.

If you have a more analytical bent in your background or aspiration, another key aspect of the product management career path is delivering marketing leading and customer satisfactory pricing and packaging. Because we are products based on intellectual property there are seemingly unlimited combinations of features and price points upon which to base your business models. With the expansion of our product line to cover the NWOW we have opportunities to be even more creative with what we offer to customers, balancing our revenue aspirations with customer wishes as you always do with packaging and pricing. The sheer breadth of our product line, worldwide presence, and our industry’s ability to create product categories seemingly overnight, the ability to be a step ahead and have a strong sense of where the market will be is a key strength in this role. A great example of successful product manager work in this area has been the offering of “Student and Teacher Office” which was an end-to-end product management offering consisting of packaging, pricing, distribution, and the campaign partnering with our Academic sales channel and our Retail channel. The product has been responsible for a significant up-tick in incremental revenue for our business and has been featured numerous times in the Wall St. Journal as highly customer satisfying offer. So great product management yielded a great business opportunity and satisfied customers.

Many MBA graduates ask about "owning a business" -- this is always a reasonable career aspiration. The typical decision point for a new MBA is a really about what size organization you want to be part of and what size business you want to work in. Obviously with a business like Office no one person owns the business end-to-end (unless you count our CEO). There are all sorts of real-world complexities such as managing a global sales force (subsidiaries are managed by in-country GMs and the sales people report up through our global COO). Within our organization we have some enormously successful end-to-end businesses including Project, Visio, FrontPage, OneNote, and our server products under the SharePoint brand. In total these represent over $1B in revenue worldwide. We have product managers that own these businesses and equip dedicated field sales and marketing resources around the world to achieve the revenue numbers. A great example of this type of product management experience is working on our SharePoint family. This business is a cornerstone of the "Office System" and is a major corporate-wide strategic initiative. The product management team, in concert with the development team, own the end-to-end business around this effort and have grown the business from a startup of $0 to...well a pretty big number and faster than any other business in Microsoft's history.

As a product manager you will join the Redmond-based team and develop the worldwide strategy for the business. You will have frequent access to executives as you develop your strategic contribution. Of course you will work with many different external parties as well including the press, partners, customers, and developers. Because many of our business offerings cross Microsoft businesses you will partner with product managers in other parts of the company, extending your network as your career advances.

Product management and product planning are “adjacent” careers in that it is not uncommon for people to move between the roles. In fact the leader of product planning for Office was previously a product manager (and an MBA). If you are potentially interested in a career path that leads to general management you might read my post on that topic.

Well that’s all for now. If you have any questions or comments please let me know. If you’re at HBS I’d love to get a chance to meet you on October 5^th. I will also be in a few classes during the day so maybe I’ll see you there as well.

--Steven

Ineffective Middle-Management Suckups

steven_sinofsky — Mon, 26 Sep 2005 03:20:00 GMT

Anonymous said:

Managers love to give more reasons why lots of managers are a good thing. Why lots of managerial levels are a good thing. Your explanation of the file/rank structure and their leads is great. And its right on target. A lead with 5/6 reports (ideally 8 or so) is great - one with 30 is overburdened.

The problem is not here. The problem is at the few levels above this. A dev manager managing 3 leads is underburdened. He's adding process, he needs all this information. Leads are constantly scrambling to feed him information instead of doing what they could do best - developing or directing development in lower tiers.

The problem keeps getting more and more acute between this level (dev mgr) upto some of the senior executives where it straightens out again - executives have a lot of people reporting to them with possibly a seperate team that garners information and feeds it to them. The 3 or 4 levels in between the top two and the bottom two - aka middle management that is the "problem". This is what, for example, mini-microsoft has been ranting about. And this is what startups don't have. Or agile companies for that matter.

My ideal structure for Microsoft is one where we enforce at least 5 upto 10 reports per manager, any less than 5 and management hierarchies need to be collapsed or managers eliminated. Just doing this should eliminate some levels in organizations such as windows (I'm there, so don't really know office).

That was a good post though - and a defense of management is well warranted - there are far too many people who blame management and look to make cuts there when there are just as many as bad dev/test/pm rank and file people adding dead weight to the company.

Hi there Anonymous (btw, if you work at Microsoft and want to discuss this face to face where there is a lot more context, I can promise that the open door policy is fully respected by me).

I don’t want folks to think I am defending management (especially bad management), but then again I did point out that few people will ever rise to defend management which basically leaves that job to me. And of course numerically, if you only have 6 levels of an organization, then management is outnumbered by non-management approximately 3:1. So a tough crowd for sure!

The dynamic you describe is a completely dysfunctional organization. If employees (aka, individual contributors) think that the manager is doing nothing more than creating “homework” for the group/IC then that is systematically and operationally a terrible idea. However, it is not necessarily the case that the “homework” is bad for the organization as a whole. It could possibly be that the manager is doing a terrible job of justifying the work. Even worse, the manager might be saying “I need <x>, but can’t explain it because my boss asked for it”. Wow that is just a mess. If that is happening in the Office team I definitely want to know about it – but actually an even better way to fix that is just to go straight to your manager’s manager and ask “what the frack is going on—it feels like I have a bunch of random homework”. Those on the Office team know that I often ask “does this feel like homework?” and if the answer is yes then I either rescind the request or try to come up with a better reason why the request matters. And we keep iterating. The first rule of thumb is that if the work is not useful for the person doing it then it is not worth doing. And if you think I don’t give that feedback to my manager about things I’m asked to do then you don’t know me very well!

The other dynamic that leads to this is when people feel their manager is spending time managing “up”. This is another example of something that no one will defend but is actually a critical part of management. You can say manage up and it can be totally pejorative and essentially means “I am spinning things and sucking up and basically being dishonest about what is going on”. That is how most individuals view managing up. Believe me, any good upper manager knows when they are being managed up to. What goes around comes around.

BUT, managing up can also mean “I am telling you, my manager, about the work our team is doing and why it is right and why we are on track.” In other words, your manager might just be acting on your behalf and clearing the path for you to get things done. That’s what managers do. If you live in an ideal world where paths do not need to be cleared then that is another topic—in the real world, where you are always competing for limited resources (in software that is usually people, but just try to build the world’s best product without a commitment to actually sell it down the road) you do need management to manage up and clear a path so your great work can be realized and make money. So maybe when you’re being asked for something by your manager it is in fact to help you get your job done, not just to make your manager look good. But if you perceive it that way then either your manager has communication techniques to improve or you might want to ask “why” before jumping to a conclusion.

Effectively managing up is a critical part of a functional organization, whether you are an individual on the team, a lead, a manager of a function, or a general manager. Ineffectively managing up is just as destructive as any other ineffective performance trait on a team, including writing bad code.

I would probably resist any temptation to just define an org structure as having a fixed number of reports. If you try to fix the number at any level you actually drive a “physical” org structure that might not map to the intended logical outcome. One way to think of this is that every software product you ship is a reflection of the organization. While you might want to have architectural layers in the software in one dimension, the physical organization might drive a different split. As a result you have to balance the customer perspective with the organizational needs. So for example, we have a Publisher team that likely has a less “flat” structure than intended, but that is because the team of developers just isn’t big enough to have 8 leads. On the other hand, Publisher is a business that is 10’s of millions of dollars so having the developers focused and part of a Publisher-only structure is probably a good idea. Also, the numbers need to account for some fluidity in the organization—you always have openings to hire people, people are moving around all the time, etc. In other words, a person with 4 reports one day might have 6 in a month. So you would never want to try to create a perfectly shaped organization since it cannot last very long.

For me, I am just not quite a fast to indict managers of managers as useless and ineffective. One of the challenges in taking this position is that it is super easy to complain about managers^2 and frankly those complaints come from people who have never had to do the job. So the idea of “walking in someone else’s shoes” definitely comes to mind. In some ways, I’d love to offer to have someone shadow me for a week and see the “confusion” that heads my way and why everything looks grey and non-obvious, or more clearly “damned if you do, damned if you don't”.

I am, however, the first to admit that it is very easy to act in a dysfunctional way as a manager in the middle (between other managers). You are pulled in a lot of different directions and you have a lot of masters to answer to. The very best managers in the middle are those that do two things: they coordinate with their peer group (and do not focus on managing up) and they seek to clarify the situation and not to muddle it or make it more complex. This is hard. Writing code is a hard skill. Managing is a hard skill. At least you can go take definitive courses in how to write software.

I dismiss the notion that having layers of management is inconsistent with agility. This is no doubt a counter-intuitive, or at least controversial statement. In fact, it is very easy to argue that having a strong role for middle management is actually necessary for agile development because with strong management comes a coordinated effort to develop products. Of course you can also end up with a bunch of turf battles or some sense of paralysis. One over-arching theme is that middle management has the same performance curve that individuals have—it is just that when a middle manager performs poorly he/she drags people down with him/her. That’s why it is so important to pace yourself and why I work hard to emphasize the notion of patience in career progression. It is also why for every ineffective manager at the lead level you create one unhappy manager but 5-8 voices of dissent and unhappiness.

Agility is most certainly in the eye of the beholder or a product of the context or moment, like so many concepts in management. If you have an organization that can develop a brand new product and bring it to market in 2 years without any “approval” then I would say this is an agile organization. On the other hand, if you proposed something that didn’t get built by the organization then I can assure you that you will quickly become a spokesperson for why the organization lacks agility. If 10 people each present an idea to be funded and built by the team, but the team only does one of them then there is a good chance you have 1 spokesperson saying how agile the team is and 9 people talking about how ossified and backward looking the team is, no matter how good a job you do explaining why you decided not to allocate resources to the other 9 proposed features/projects.

There are many examples from within the Office product line that emphasize the agile nature of our organization. We strive for agility within the scope of information worker products, which we define broadly to mean any software you need to be more productive in any context. We’ve built SharePoint from the ground up within our team, and done so without any middle managers coming in and trying to gum things up. We’ve had struggles in coordinating our efforts across the company—are those good or bad? Well I would have rather skipped those meetings, then again if we didn’t have them and reconcile things before we shipped then we would have had to reconcile those with our products in the marketplace and in front of customers. Nothing sends a worse message to customers than a confused product line. Should we have just not thought of doing the product and packed up and added more features to Excel? I had no intention of doing that and in fact moved developers from our “apps” to the server work because it was a higher priority. Not everyone agreed and that itself led to calls for my head.

Another example is the creation of OneNote. Amazingly enough we had no meetings to “approve” this and no meetings to have other meetings. No one had to write a formal proposal. We just decided to build the product. Chris Pratley, the group program manager with responsibility for OneNote program management wrote about the genesis of the product a while back. That was all their was to it. Now the thing about that is you have two middle managers coordinating and agreeing on what to do. Then other middle managers were involved in the staffing of that team with the right people. Were people concerned about how the product would fit with a strategy—you bet and I was among them. Were people concerned that these resources would be better used elsewhere—you bet.

But for every example like that I can cite, someone will point out a decision we made to not fund something or not do something. Is that a lack of agility? I don’t think so since we’ve proven we can go in new directions and also produce in short order. Is that a poor decision? It just might be. But unfortunately engineering is not chemistry so you can’t do controlled experiments on every decision so sometimes you have to pick one path when you have finite resources.

One person’s agility is another person’s screw up. One person’s lack of agility is another person’s strategy.

There are two sides to every point of view in business management. The challenge is not in just being critical of the point of view you don’t agree with, but stepping up and asking questions like ‘how did you arrive at that conclusion <you bozo>?”. If you think a bad decision has been made then you have two options.

First, you can ask why it was decided that way and get clarification and see that indeed there might be another side of the coin and just work your way up the chain (Microsoft has always had an open door policy and any decision can be questioned by challenge/response). If you still don’t agree, then as they say in the military “you can vote with your stripes” because in the end if you don’t respect the management chain then you won’t ever be part of the team. But maybe, just maybe, you will see that the people that were once individual developers (and testers and program managers) on the team are rational and have thought things through. Becoming a manager is (usually) a promotion, but not a lobotomy (usually).

Or second, you can just retreat to your office and complain to your peers (bottoms developing a victim complex) and just gum up the system by passive resistance to the efforts of the team, or worse. When individuals do that it is perfectly rational, but it is not productive. If you develop a victim complex then you are just demonstrating why you are a follower and why your opinion might not be as highly valued as you think it is. Absolutely positively no one has ever been fired for having a dissenting view. Absolutely positively no one has ever received a poor review for merely having a dissenting view. Those things happen when you express a dissenting view by failing to contribute what you’re supposed to contribute in your role. You’re human and you do have to be excited by your work and every employee deserves that. Sometimes groups go in a direction you don’t agree with. It might be when that happens that it is time for you to get a different perspective and try something new. There is no crime in that. I’d encourage you to find a logical break in the action and to do so without going out in a ball of flames.

And I should point out, that this exact dynamic happens to managers all the time. Sometimes managers are asked to do things they are not so wild about and have to go through this same exercise. Being a manager does not make you immune from being asked to help make something happen that does not seem quite right. So all of this applies to managers.

You’ll notice there is a lot of recursion in management. That is a key theme of the tops-middles-bottoms that I wrote about recently.

So the short answer for Anonymous is of course there are always challenges with managers in the middle—just like there are challenges with individual employees who do not write the code as well as they need to, do not do thorough enough designs, or fail to fully test an area. But to indict the whole notion of middle management is probably not a good idea.

Perhaps my favorite and brief description of this subject was written by Michael Kinsley and posted on Slate. It is really worth the quick read. See http://slate.msn.com/id/2064260 for An Ode to Managers.

--Steven

PS: I definitely encourage Microsoft employees to send me mail directly. My door is open and my inbox is open 7x24. I would love to have discussions with more context.

PPS: The title of this was taken from a recurring skit on Seattle KING-5 TV's series Almost Live.

What do managers do and how big should my team be?

steven_sinofsky — Sat, 24 Sep 2005 19:47:00 GMT

The first thing we do, let's kill all the lawyers.
Butcher, in Shakespeare's King Henry VI

The first thing we do, let's fire all the managers.
Just about every employee at one time or another since the 1911 release of Frederick Taylor’s Principles of Scientific Management

Today I thought I would talk a little about a topic related to how we manage feature teams in Office. For those of you considering working at Microsoft this is a pretty important topic because the management environment and the management “system” (to the degree something that involves people can be called a system), the management structure will play a key role in both your success and your happiness with work. For the most part, if you’re in college and going out on your first job you focus on job content (i.e. what you will be doing, what code you will write, what features you will design, etc.) and probably a little bit on the work environment (what your office is like or what the buildings are like). It is more difficult to focus on management, especially since even if you’ve had internships or other part time work, your first full time job will also be your first experience in being managed full time.

The first thing to note about management is that it is not a science. But it is not an art either and it is wrong to just assume that having a good manager is either lucky or rare. Management is like most things in that with practice, coaching, and training, people can acquire the skills to become a good manager. And it is just as important to realize that employees comprise [edited] 50% of the manager-employee relationship, and thus have a significant contribution to make. In other words, being a good employee is a critical component to having a good manager. One way to think of this is that while there might be some classes with great professors where you received bad grades, most of the time there’s a pretty high correlation between classes with good professors and classes in which you earned A’s.

So let’s look a bit into the management structure of an organization like Office at Microsoft (of course all organizations, inside Microsoft and even specific teams in Office have their own variation so what follows is a generalization). It is also worth saying that some readers might be people that have had a less than positive management experience (even within Office), but it would be wrong to indict all managers or management in general because of your experience. After all, managers are people and like all people are not perfect and are trying to improve. Some might not make it, but think of baseball—even the very best of the best might get a hit only one out of three times they go to bat, which seems pretty pathetic when you consider that the whole point of the game is to get a hit and players receive immense compensation just to get hits.

One of the first things that people always do when they think about their place in an organization is count how many edges there are between their place in the org structure and the CEO. When I started at Microsoft in 1989 and the company had 3000 people, I was a new hire from school and there were 5 people “above” me. Today a new hire from college in Office is probably going to have 7 people above them to get to the CEO and the company is a bit bigger :-). This is an interesting number and one that can either impress you if you have experiences with large organizations or maybe cause you to pause if you think that the number of hops to the CEO is a critical number. It turns out that balancing the height and span of an organization has a lot to do with the ability of an organization to be nimble and to also train and grow you in your career.

The typical organization in Office development is one where there is a group of about 5-8 developers (we’ll use developers for this post, but the discussion is just points of the dev/test/pm triad) managed by a lead developer. That is the first level of management called a feature team. There are then 3-5 leads that report to a development manager. That is the second level of management, usually called a group. The development manager reports to a general manager or an executive manager that represents the place that development, testing, and program management come together. This structure is matched by development testing and program management (where there are about equal numbers of testers, and about half that number of program managers). The general manager or executive is where the product or technology comes together (think SharePoint, or Excel, or the new Office “12” user interface). In some groups, if there are a lot of products or a very large team there might be one additional level of management. I manage these general managers. My boss manages the overall Office P&L, so marketing, finance, HR, etc. as well as other products report to him.

To give you an idea, Microsoft Office “12” is built by about 30 product groups, each with about 3-5 feature teams, each with 5-8 developers. The whole point of a feature team is to have your immediate work area be a small, relatively self-contained “unit”. When you consider the size of the business and the amount of revenue generated by Office ($10 billion dollars), it is rather astounding that the entire product line is created by such a relatively small organization. Many of the feature teams work with other feature teams directly, so it is not a series of independent silos. In fact, our customers demand this from us—they want Excel and Word and Outlook and SharePoint to work well together and not just be taped together in a box.

What made us pick these numbers: 5-8 developers reporting to a lead, and 3-5 leads reporting to a dev manager, and the three discipline managers reporting to a GM? That’s a great question and the answer provides the evidence of our very strong commitment to management.

The first line of management is where you have the most interaction with your manager. This manager is someone who has experience in the product cycle and has probably (in Office) gone through shipping at least 2 full product cycles. During their career they have proven a consistent ability to write good code, meet the schedule, and their code withstood the rigors of testing. They have also fostered strong relationships with their counterparts in program management and testing. They have also mentored interns and had that experience managing. Like your professors in college who never really took courses in teaching, managers did not get sent off to “management school” or anything, but are assumed to have mastered the fundamentals as best you can given that the skill depends on first hand experience. This manager has a number of specific responsibilities:

Know the code. First and foremost the lead knows the code for the project. The lead is going to be your source of skill and experience. The lead will be the one to code review your code. The lead has the experience necessary to insure that the work of the team is of the architecture and quality necessary to get the job done for customers.
Help you to know what you need to do. Your lead is like your coach. He or she will be the one to walk through your proposed architecture and implementation and make sure that it fits within the timeframe and that it meets the needs of the project. This is especially important if you are new to the code, team, or Microsoft. For example, conceptually it might seem straight forward to understand a new feature area, but the demands of security, globalization, performance, compatibility, accessibility, programmability, and a host of other issues to consider mean that you are going to need another set of eyes when you are just getting started.
Determine the tasks to be completed by the team and balance the work across the team. The team works with program management to determine the scope of the work to be done. The dev lead works with the team to come up with a schedule and work list for the group. The individuals on the team own their own estimates and they work with their lead to get the estimates as accurate as possible. Under no circumstances will the lead arbitrarily override your estimates. But if you need more time, the discussion that happens is with program management to scale back the feature area. If you and your lead have done lots of projects together the lead might have enough information to help you estimate better :-)
Assist in skills development. You might never have written C++ code or used XML or worked in Word’s table code or something. Your lead is there to help you to learn and to get the tools to learn about the project you are about to embark on. As a company that develops intellectual property, most of our knowledge is actually held in the brains of our employees so this type of knowledge transfer is super important.
Communication to/from the feature team about the feature team. The lead is responsible for making sure the rest of the overall project knows what is going on. This could mean working with the test lead and program manager lead or it could mean working with the lead of another feature team that your team depends on (for example if you are Outlook working with Exchange server).
Performance evaluation. Your lead will ultimately be responsible for evaluating your performance (I am explicitly not getting into this topic here, but might in a future post). The reason I mention this is because you really want your lead to know you well and to know your strengths and weaknesses well and to have spent enough time working with you directly to be well-informed about your work.
Hiring the team. Leads are responsible for getting folks on the team since they don’t just show up J You might think recruiters are the ones hiring you, but the leads are the ones making the decisions and deciding if you might be a good fit for the work and the team. It takes a lot of time and effort to build a team. When I was a lead, I easily spent 4 or 5 hours a week hiring and recruiting. Today that time is spent in different ways, but it is still just as critical a part of my job.

So as you can see, your lead is going to have a lot to do in order to insure success of the feature team. In fact the lead has a lot to do just to insure your success. You might be a programming deity and hit the ground running and never need a single bit of help, but still your lead is going to need to make sure that the work you do is lining up with the broader goals of the product and that you are working on the most critical needs of the feature team. And all the while, since the lead has so much experience and is such a proven developer he or she is also expected to be checking in code, fixing bugs, and making sure the architecture is holding up.

A lot of companies will tell you that the best organizations are “flat” and what they mean is that they want to have the fewest number of managers possible because “managers are evil” or “managers create more work than they get done” or other such comments. You don’t see a lot of people out there defending managers and of course whenever an organization is not doing well the first thing folks want to do is get rid of all the managers who must be gumming things up. I will say that if a team is performing poorly then there is a management problem. But that is quite separate from a problem manager. There might be a performance problem with a specific manager, but there is definitely a problem with the management process (even if that problem is just having the manager continue without improving). Both can be fixed, but this can definitely be a case of tossing out a solid principle just because of one problem area if you indict the idea of having management structure.

To illustrate this just consider this simple picture:

The balanced manager above is a lead with 8 employees. This is the structure described above. You can imagine how straight forward it is for each of the 8 to interact and work together—they can sit at the same table at lunch, they can take two cars to a pizza place, they can bowl on 2 lanes at a bowling alley, and chances are you can easily remember everyone’s name and what they are working on in detail. This is an effective team. If you need an analogy or comparable, the Navy SEALs are organized into 16 person groups with 2 officers (i.e. leads). In the Army, the smallest unit is the squad and it is 9 or 10 soldiers lead by a sergeant. I mention those examples, because the military has been studying organization for a few thousand years and because manpower is everything is very motivated to have the maximal number of troops doing the work they need to do, and not have a lot of bloat.

Some leads might not be as effective as they would like with 8 and can work best with 5, or maybe 3. This is what we call “scale” and it is something that the dev manager needs to evaluate and take into account when building the team. And it is quite possible that some leads are very comfortable with as many as 10 employees, though that is certainly only the case when some of the team members are very experienced or the work does not require a lot of connection to other groups.

Now consider the aptly named burdened manager above. In this picture, this manager has 16 employees. You can imagine that it sounds pretty cool—they are a lean, mean, coding machine. There is no overhead for this team and they are ready to go into action. On the other hand, just imagine how much attention you would get from that manager in the course of the week. In Office, the expectation is that you have a scheduled weekly 1:1 with your manager (to work on the above issues, in addition to significant amounts of interrupt driven help and email). This manager would lose half the week just trying to have scheduled time with those employees and because of all that scheduled time the chances of having a successful interrupt driven event with your manager are near zero. In fact, if you just go through the list above of lead responsibilities you will see that most of them become impossible with such a “flat” organization.

Another issue to consider in the burdened feature team above is how on target the work is going to be. The lead is so burdened that the chances of every one of those 16 people being on the same page are very low. In fact the dynamic you will see in that sort of organization is that the team will naturally "bunch up" or "silo" into two or three groups of manageable size. In other words, the communication and leadership will be partitioned in a path of least resistance, not necessarily in the path that is best for customers. The downstream effect of this is inevitably a project reset or reboot, since eventually "management" will figure out that the team is not doing what needs to be done and corrective action will need to be taken. This is a classic case where the individual employees are not at fault, but the structure is to blame. It is unrealistic to expect the employees to be psychic or all-knowing and so the person who needed to stitch together the work and make sure the right things were getting done the right way at the right time was failing you. And that person was failing you because there simply wasn't enough time in the day to pay attention to everything that was going on and to effectively tap the skills and energies of each of the members of the team.

A lot of times in startups or young companies there is a flat organization and it is touted as a benefit because there are no “layers” and no “bureaucracy”. This does not follow logically from the role of management and is much more testosterone speaking. I’ve seen startups with 100 people that have more management than 100 people on the Office team. I’ve also seen startups with managers that oversee 30 people each. I’ve also seen teams of 10 people come up with so much process and bureaucracy that they could not get anything done. There is no correlation between layers and bureaucracy, though layers might make it easier to gum things up. There is no correlation between being a startup and requiring a flat organization. And finally, there is a high correlation between a flat organization and managers that do not have time to spend managing. For the most part, my experience is that it is easy to rationalize not having managers since showing disdain for management is easy and on the outside and on the face of it few would disagree with you.

If you're a developer you might also be wondering what all the "other" people do--what is it that all those program managers, usability engineers, etc. do during the day since we're all here to write code, right? This is where experience in other disciplines really helps, because until you have actually had to do the job of another discipline you only see the places where they are not doing things to help you :-) Remember that an Army platoon or SEAL unit are about the size of a feature team, but what was not described were things like where all the supplies come from, who gets the tanks from one place to another, who figured out what mission the team should go on, and who trains all the soldiers in the first place. Organizations need all those support functions in order for the primary mission to be as effective as possible. If a developer had to go out and talk to all the end-users requiring accessibility support, or had to talk to all the ISVs who want to use extensibility support, or had to figure out the compatibility testing, or how we would automate the release of service packs through testing, there would be a lot less time to actually work on the mission at hand. That is not a blanket excuse for anyone who does not pull their weight on the project, but just a caution that if all the organization did was write code there is a very high likelihood that the code would not be a great product or business--just like if all the SEAL unit just arrived and starting demo'ing what it thought looked like a good idea to demo.

Your first management experiences are a very important part of your career, much like the first two years of college when you’re mostly taking required classes. We work hard to make this as good an experience as we can within the limits of human beings and the normal distributions of skills and behavior. We’re a learning and introspective culture so we use the feedback from employees about managers to improve things. I would encourage anyone considering their first job out of college or moving to a new job to spend some time asking questions about how the organization works and what the relationship will be to your line manager.

--Steven

PS: updated to fix 3 typos.

Understanding orgs and helping them work better

steven_sinofsky — Tue, 20 Sep 2005 09:06:00 GMT

This is the time of year at Microsoft when individuals and managers decide what HR courses and training to take. I just finished going through the process of nominating members of the team for courses that have enrollment limits—ug! There are a lot of options, but for many this all feels a bit like a word wheel—do I sign up for “Leading a Growth Business” or sign up for “Growth and Business Leadership” or maybe it is “Business Leadership Growth”, or are those the same courses? Who knows?!#@ This is a story of one course, one book, and one set of ideas that had a significant impact on me and I think this can help anyone looking for a quick lesson in organizations.

Of course I need to say up front, that the ideas here apply to every organization I have ever been part of. When I was a resident advisor in college our dorm went through a phase of anarchy adequately described by this. These ideas also apply to small teams within an organization and to large organizations as a whole. In fact, just tonight at our condo association meeting last night here in Seattle, I was observing many of these same dynamics for our small (relatively dysfunctional) association. I happen to think that even in the best functioning organizations, the ideas expressed here can be observed on a routine basis.

Did you ever wonder why middle managers can look so frazzled and feel helpless?
Did you ever wonder why executives can look like they have the weight of the world on their shoulders?
Did you ever wonder why individual contributors can feel oppressed and ignored?

Why is it that when things aren’t working well, the very folks that need to band together and figure things out—the middle mangers—end up creating their own little silos and erecting barriers between teams? Why is it that when things aren’t working well, the folks that need to get heads down and get the job done—the individual contributors—just hang out together and complain about what is going on? Why is it when things aren’t working well, the very folks that need to guide the organization—the executives—are seemingly isolated and out of touch?

Tough questions.

The answers to these and many other questions about how and why organizations of [of any size] can be found in a very provocative book (more like a short paper), called “The Possibilities of Organization” by Barry Oshry. (see http://www.powerandsystems.com/EN/resources/books/the_possibilities_of_organization.html). Those of you who know me know that I do not take lightly the idea that I would refer someone to an organizational behavior book. In fact, I think I might just lose any remaining credibility from those that read this blog (any left after using the word “super” one too many times in my last blog). But the truth is after 15+ years of HR classes, training sessions, and seminars, this remains the most relevant book on organizations I have seen. I should warn you that even though it is very good, reading it might make you feel like you’ve walked into a frame of Dilbert or worse.

But it did not start out that way for me. About 8 or 9 years ago, I was asked to join a number of senior/middle Microsoft managers for a three day offsite. We were not told what it was going to be. We got all sorts of weird instructions like no mobile phones or food, some folks had to arrive (at a small campground-like environment on Cape Cod) a day early. It was all spooky and I was super uncomfortable. Using analogies of today, it was like The Apprentice meets Survivor or something, except there were no lucrative endorsements waiting for us after we finished. What followed was a three day simulation of the ideas in the above book. Without going into too many details, suffice it to say that a group of Microsoft people managed to “break” the simulation. We had the “facilitators” in tears and ended the game two days early. It was torture. I swore off all HR-related activities for about 5 years after that.

NEVERTHELESS, I actually really liked the ideas in the book. I basically felt that you didn’t need to fly 3000 miles, camp out, not shower, and starve to learn them. The 20 minutes with the book was a very significant “duh” moment for me, which has definitely had quite an impact on how I view organizations. I also had a chance to do a 2 hour version of the workshop, which perfectly tolerable.

The basic thesis of the book is that an organization [of any size, we’re talking this can happen in your 20 person team] has the possibility at all times of going to war with itself. There is a ton of complexity and a ton of conflicting goals, data, and issues. In fact that is pretty much how things go for most organizations all the time. The questions at the start of this help you to see that basically all organizations are challenged by these issues at some level all the time, and at some times the issues become pretty intense.

Mr. Oshry talks about the players in the “system” (HR people always have to talk about systems) as tops, middles, bottoms, and customers. As you can imagine the first thing is to figure out who you are and what your position in the org is. For most, it is clear if you are a customer, but then think about how this works for two parts of a team working together (isn’t test a customer of development, development a customer of program management?). The most common mistake is to think that the most senior person is the “top” (like the General Manager), but then again that person has a manager which puts that “top” squarely between you and another “top” which means they are really the middle. And even though you’re a manager, if you get in a room with only other managers, you probably all feel like you’re at the bottom of the totem pole. So the first lesson is to really understand that everyone can be viewed in the middle, often you’re at the bottom, and actually more people are customers than you might think.

When you go through the workshop and simulate an organization, the goal is to see the way people react to being top, middle, bottom, customer outside their normal role in an org. If you’re an individual you end up a manager/middle in the simulation. As the simulation progresses it is rather surprising to see people falling into “stereotype” behaviors pretty quickly. The simulation is designed to provide inadequate information to complete the task thus accelerating the inevitable decline of the org. While you might think this is rigged, consider that any business group has inadequate information and it is only through leadership (or some AI reasoning under uncertainty algorithm) that the org decides to get something done rather than wait for more data.

Some of the behaviors that happen pretty routinely:

The tops become very fixated on the big picture and start feeling the pressure of the goal. They tend to get so focused on getting stuff done that they fail to communicate clearly and start ordering folks to do things and often do not work with the organization structure.
The middles get very confused very quickly. The tops are running around telling people what to do, while the bottoms are asking what to do and complaining about not getting clear direction. The middles just sort of freeze and start acting to just avoid getting grief from the tops or bottoms.
The bottoms feel very victimized and stop working and spend most of their time waiting to be told what to do, not really understanding, and just sort of complaining.
The customers end up with nothing and get very angry very quickly. That makes the job harder for the middles who usually deal with customers, but then they complain to the tops. These actions in turn add more chaos to the middles and more stress for the tops.
This vicious cycle continues until lunchtime. In the real world it takes something to snap the organization out of this pattern, not just a time budget of the workshop.

What comes out of the book and workshop are a few straight forward ideas that you can follow to help either prevent this cycle from happening or break the cycle. Like any management book (ever written) the ideas read like total common sense, and then you are told that they are common sense yet after n years of observing orgs people still do not follow this advice. And as a reader you think this is a bunch of junk. Then one day you look around at your dev team, or dorm, and realize that maybe there is something to this work.

It would be wrong to summarize the book—it is too short and hard to do a fair use excerpt. But let me offer a few suggestions for each of the roles that I have taken from my experience with the workshop (even if these are not exactly what Oshry expected me to put into practice):

Tops – The most important thing is to stop talking and telling so much, and to take a step back and figure out what it is you want the org to do. You need to be clear, consistent, and focused on a goal people understand. And above all, explain why the goal you have chosen makes sense. If the team does not believe you then you’re not done deciding what to do. Iterate.
Middles – The most important thing is to talk to your peer group and agree on how to interpret and execute on the goals of the organization. Silos are not created at the top, but created by middles. After one of the members of our team attended the workshop, he started to have a staff meeting of my direct reports but without me. This meeting has gone on for years and is called the “without Steven” meeting. I am very jealous and have no idea what goes on in the meeting, but I know that the discussions about the project, the org, and issues happen without the pressure of the boss around. Oshry calls this middle integration. It is something we do a lot of on our team and I think it can help a lot.
Bottoms – Individual contributors on a team need to ask questions and more questions, and reach a level of satisfaction with the answer. All too often the bottoms fall into the trap of expecting the middles/tops to be psychics or to have everything perfect before they begin. That isn’t a fair expectation. It is also important for the middles/tops to be clear about what is known and what is not known.
Customers – Well, customers get to keep asking for what they want to ask for and behaving how they want to! They are paying us to be here and so it is our job to do the right thing by them, even in the face of difficult demands. But sharing the customer view with the whole organization (we do this through software tools like SQM and Watson, for example) is incredibly important and goes a long way to helping clear up the challenges the org feels.

I should say that someone is probably reading this thinking, “oh great the answer to our problems is to have a meeting” or something like that. Believe me, I know how stupid it can sound to suggest a meeting to a group that is having trouble. But the truth is that in any size team greater than about 20 you have to figure out what to work on and how to get the work done and the only way to do that is to actually talk about it. This is a really hard thing for most engineers to understand since your engineer DNA just assumes that once the problem is clear everyone sees the most sane, obvious, and rational solution and solution path. But of course as we all know, not everyone on the team is as smart as us so therein resides the problem J Meetings can be a disaster. And on the other hand, psychic powers are not in the DNA of engineers so you have to do something to make sure everyone understands things as well as you do. Meetings can also be a savior. Dismissing the value of a meeting on principle is about as smart as saying you won’t use C# because it does garbage collection or won’t use C because you don’t trust a compiler to generate code. Just like GC (or /O1) meetings have their proper place and when used effectively are an valuable tool.

In reading this I’m sure a lot of folks will be able to apply this to the organizations they are part of. That is usually a good indication of a well-done management framework. Good management books are a bit like horoscopes—they are written so that no matter who reads them they see themselves. It also means that you can read this and try to project it on to an organization that you don’t really work in and know first hand (like when you read a horoscope for a celebrity that happens to coincide with their movie flopping). The downside of citing work like this is that folks can take it too far or too literally.

But the upside for me is that a few simple ideas have made a difference in understanding the dynamics of the team.

--Steven

The path to GM -- some thoughts on becoming a general manager

steven_sinofsky — Mon, 19 Sep 2005 09:52:00 GMT

The recruiting season is getting underway and shortly we’ll be “at a college near you” looking to connect. I will be at Harvard Business School the first week of October, where I’ll visit some classes and also participate in a career fair. I hope to see some readers there!

I met this week with one the managers at Microsoft that I officially mentor. We have a program (literally an ASP.NET program) where you can sign up to mentor or be mentored through a matching process. The discussion we had was about career progression and how does one become CEO. I thought that was a rather ambitious goal—after all asking your mentor for the path to become their manager is interesting ;-). We talked the discussion down from CEO to achieving the career goal of general management (GM). I’ll define general management as managing multiple functions with significant responsibility for a whole customer visible project—this can be a product unit of 50 people (20 devs, 20 test, 10 program managers) or a whole business group of 300 that includes marketing and other disciplines. At Microsoft, as with many companies, reaching this level of management is a significant accomplishment and with it comes significant responsibility. If you aspire to, then how do you get there?

(Now is a good time to say that this is definitely an article that could be used against me since I’m sure there are things in here that I do not practice as well as I should—if you happen to know that, then suffice it to say I’m still learning too and these are lessons I’ve learned! And also I will use a bunch of examples in here, but any of them can have their tables turned and reflect any other job discipline.)

The first words out of my mouth in this case are always patience. It is a cliché, and frankly coming from an executive always seems self-serving. But the truth is I think that pace is the most important element of a career. Once you become a functional manager your career is different and your contribution is different, and not necessarily better. And once you become a general manager, your career again changes and your contribution is way different, and as you’ll experience the job becomes a bit more lonely and often less “fun”. I remember going to my 5 year reunion for college and we’re sitting out on the arts quad eating PMPs (don’t ask!) when I listened to each of my fellow Comp Sci friends bemoan the amount of management they were doing and how they were no longer really doing any “work”. That certainly made me pause and I felt great that I was still writing code and not actually managing anyone! My first lesson in patience.

The second reason to be patient about your career is that you are probably never nearly as ready as you think you are for the next big job. The challenge is that the company has lots to worry about in addition to your career. The company has shareholders, other employees, and customers so balancing all of those needs in addition to your career is tricky. Here is where trusting your manager (and management chain) is super important. In a strong organization, the opportunities for you will come, even if they don’t come as fast as you’d like. We’ve all had people we were impressed by because of their meteoric rise, only to see them perhaps “peak early” or worse. At the same time, I’ve seen organizations rewarded for making the right move at the right time and seeing someone just ready enough to step into a bigger/broader role and make a huge difference with a running start. Mike Maples, certainly one of the most respected Microsoft managers ever, used to remind us all that things work out in the long run. So another reason to be patient.

So assuming you have the patience, then what are the right steps to general management? If you were to ask general managers at Microsoft how they ended up in their job you’d probably get a unique answer for each person. Most at Microsoft that rose up through the ranks probably didn’t expect (or seek) GM roles. Certainly for me, I was generally much more in the moment and excited by the technology, products and customers. I always felt that my managers noticed that and that was a big part of why I was offered management responsibility. The most important thing about moving into general management is that you have to be very good at the function (dev, test, pm, marketing) that you currently work in—no one is going to want you to manage another function, especially one you have never done, if you are not among the best at managing your current discipline.

Generally, you’re going to need to gain some experience in another function before you can really hit the ground running as a general manager. I know that is something I tend to look for in candidates. This is not as dramatic as it often sounds. If you’re a developer, it does not mean you should go become a sales person (most good developers would fail spectacularly at sales, and vice versa). Rather the focus should be on an “adjacent” discipline. You can think of the disciplines as a continuum:

Support <-> Sales <-> Marketing <-> Planning <-> Program Management <-> Development <-> Testing

At any point you can look “left or right” and see the potential for you to broaden your expertise and gain the experience that could serve you well as a multi-disciplinary manager. You probably don’t need to go far for this experience, and in fact staying close by in a familiar organization or product might serve you well and help you keep your feet on the ground. The majority, but by no means all, general managers at Microsoft have experience in the dev/pm space or in the sales/marketing space. I want to be careful about generalizing, because with a relatively small set of folks and a lot of unique stories it is important to understand that many paths can lead to GM. I should also say, that he above spectrum is not complete and not meant to be exhaustive, but just illustrative.

Why is this experience important? The biggest reason is because the day you walk into a room and look around and see 3 or 4 (or more) different disciplines looking at you for leadership and guidance, your credibility hinges on being able to humbly and respectfully talk-the-talk and walk-the-walk of several disciplines that you never did. “BS” detectors will immediately go up—just because you were a whiz at marketing or sales, do not think test or pm will immediately just follow you (insert any other disciplines in there). In fact, one of the biggest early points of failure for a new GM is the inability to see eye to eye or bond with the “other” disciplines. If you were a developer who was always beating up on testing, or a program manager who always said marketing was clueless then imagine how those disciplines will feel if they see you stand up in front of the room and say “Hi, I’m your new manager”. That won’t be a pretty sight. After all, these folks will now be looking to you to expand their career opportunities and you can’t do that if you have not internalized respect for all those that contribute. So if you’re looking to move to general management, showing how you can walk in the other’s shoes is super important. When was the last time you asked testing their views? When was the last time you helped marketing with some technical content and let them get all the glory? When was the last time you didn’t take the “expected” role because you knew the other person was right?

Another point of failure on the path to general management is closely related and that is being too focused on your discipline and not being able to “rise” above your discipline during times when the organization needs it. You can think of this as being too much of a functional silo, or just not “mature” enough to see the big picture. It means for example that as a tester if you know the schedule is tight and that we need time to get the quality to the right levels, but you also know there is a hard constraint due to a “train that is leaving the station then the senior folks are the ones that take a step back and find a solution to the situation and do not dig their heels in just play the expected role (i.e. testers saying we need time, developers saying it can’t be done, program managers saying we need to add features, marketing saying we need it sooner, etc.) The ability to solve problems in a situation that arise from the other perspectives or disciplines is a key trait of a GM who rose up through functional leadership. At Microsoft, good examples of this are program managers who cut features because they know, as much as they want them, that the feature will lower the overall quality, or testers who know how to find a path to insuring the quality of a late braking addition that they know we need but adds measurable risk to the project.

The next area of experience is often the first one thrown at you by managers when you ask about the path to GM, which is to go and get experience on a broad set of product lines. This is easy to say, and actually relatively easy to do. The value though really depends on the situation and the depth of the experience you gain. One way to look at this is if you’re looking at a resume of an external candidate and you see 5 jobs in 10 years, that is usually a little bit of a warning sign. Just because you know all the groups, an internal candidate with that same resume should probably set off the same warning signs. This is only a warning and something to look into, not a disqualification of course. But a key tenet for me is that to become excellent and among the best at a functional role is to work on the “beginning, middle, and end” of a project at least twice. Why is this? Well all the learning comes from deciding what to do, figuring out how to do it, and then doing it. But the real learning comes from watching customers live with all those decisions you made, and then going back to the whiteboard and figuring out how to clean up the mess you made J. In software that could be 5 years on one team, which might seem like an eternity, especially as a person anxious to be a GM, but I believe it makes you a much stronger leader and manger down the road.

At the same time, experience in other product lines is super valuable. It is very similar in benefit to gaining experience in other disciplines. All software products need to work together, certainly that is what our customers say, but if you haven’t been on the other side of that dependency (or interface) then you are only seeing one side of the solution and probably spending way too much time thinking the other folks are coconuts. Again this is one where there is a lot of judgment about how different the experience needs to be, and there are a lot of factors that a company can consider that come into play. Some companies expect you to move very far because the companies are very diverse and the expertise you are gaining is around management and process. Other companies expect you to continue gain technical depth and thus moves that are “far” actually slow down your contribution. And to point out how much judgment there is in this, usually at junior levels it helps to gain the depth experience in relatively adjacent technologies, and then at senior levels because your contribution is much more about process and management you can usually move further away. I strongly recommend having a plan for yourself that balances being excellent at your function over a good period of time, while also gaining that same level of depth experience in another business or product line that builds on those skills you gained.

This leads to the last tip I could offer on the path to general management, which is to develop a mentor or role model within your organization. This needs to be someone you can talk to who can objectively validate and/or criticize your thoughts on career path. A lot of folks will go to the human resources group for this type of advice, and while that can be a good data point, I would suggest that you want to find someone you admire or respect who has come from a similar path you are currently on. So if you are a developer and want to be a general manager, find someone at the company who is a developer who became a general manager. Ask if they will talk to you once or twice a year (usually during performance review or goal setting time) and certainly ask if you can talk to them when you are considering a change in jobs or responsibilities. I know when people ask me about their careers I always ask who they see around the company as a role model, and it surprises me that most of the time folks do not have a clear view. As a hint, it isn’t really the best answer to say you are modeling yourself after Bill Gates or Steve Ballmer – those are a couple of unique individuals and so I’d suggest being a bit more pragmatic in who you’re most likely to want to be like. It is worth noting that mentors are people too and they often don’t have magic answers to questions, but if you bring good questions (such as “how would you handle this situation that I am facing this week?”) then there is a good chance you can have a very beneficial mentoring experience.

Finally, I’d close by saying that if you were reading this thinking “gosh, I don’t really know if I want to be a general manager or not” then that is ok too. Far too many people think being a big time manager is where it’s at. Being a general manager has its moments, but if you rose up through the ranks as a developer and program manager, believe me it is not magical the first time your test manager asks you “do you think we’re investing enough in automated testing for this scenario?” (note, this happened to me!) Managing work that you have never done is very stressful and also a bit lonely. If you have the right mindset and stay focused on excellence, my experience is that the company will recognize this and the right person will connect with the right organization and the right time—and in the end, as Mike Maples said about management, the cream will rise to the top and the right things happen for everyone.

So if I had to summarize a way to think about your career plan to become a general manager:

Be patient. If you take your time and work with your management chain, your chances of success definitely go up.
Be excellent. The first key is to be among the very best performers at your core discipline.
Gain adjacency experience. A good, but not necessarily critical, next step is to gain experience in an adjacent discipline.
Respect and understand all the disciplines. It is not possible for any one person to work in all the disciplines you might manage someday, but you should spend a good deal of effort learning and understanding the other disciplines before you have to manage them.
Work on multiple product lines. Figure out for you and your organization what the right type of experience change you should have and seek that out when you feel like you’ve reached a good level of functional excellence and performance at your current role.
Find a mentor. See if there is someone in the company who followed a path similar to the one you would like to follow and meet with them to discuss your career.

--Steven

BTW, I’ve received some mail about the recent article in Business Week on Microsoft. Right now I will choose not to comment on it until I see if the writers and editors choose to correct or comment on some of the plethora of factual errors.

Registration time -- what courses should I take?

steven_sinofsky — Tue, 30 Aug 2005 21:03:00 GMT

As one of the interns was heading off for his final year, we talked about what courses he is taking. There’s a general question of “what computer science courses best prepare you to be a professional programmer [at a place like Microsoft]”.

I admit to having strong views on this topic because I think that like all departments in universities, computer science has to teach the core of the discipline but is also trying to attract students, look like a hip cool department, differentiate itself from other CS departments, and also has a little bit of indulging in the whims of senior faculty. This means that within the scope of talking to your computer science department advisor and other folks in the department (students and faculty) you are getting a less-than-totally-objective point of view.

That said I think that it is important to understand that university is a time to explore and a time to test your own limits. So there is no right answer about what courses to take. Your future success will not depend on having taken a specific set of courses in those specific four years—after all learning is a lifelong experience, or put another way life is a long learning experience.

I always loved the way the Cornell catalog described a major since it reduced the stress in picking a major (I ended up picking two). Here is what it says now:

Majoring is an opportunity to study what you love most and do well - regardless of what you or others think might be "most practical." Whatever your major, through it you will hone your mind and imagination. You'll learn to think and write critically, skeptically, and imaginatively; you'll learn to recognize and address important questions; you'll learn to create and weigh evidence and make decisions about likely truth in the face of incomplete data; you'll confront basic questions about human life and mind; you'll develop your intellectual and aesthetic sensibilities. These skills will stand you in good stead in any career. You'll acquire them more thoroughly and usefully through studying a subject you care about.

The connection between major and career is mysterious. It is certainly not direct. Your major may have some relation to your first job, but not often to a whole career.

Finally, your major doesn't define your character or your life in any important way. It matters a lot what you stand for, whether you commit to a partner and who that partner is, whether you raise children, whether you work for a non-profit or for-profit organization, whether you live in a city or a rural part of the world, whether you work for a large organization or a small one, what you do with your leisure time. What you major in does not matter in any of those fundamentally defining ways.

So follow your mind and your heart in deciding on your major. It may be your last opportunity to indulge yourself so wonderfully.

The connection to your career is the interesting point. I can’t tell you how many folks I have talked with take one senior level project course and are convinced that they want their career to be based on that class (especially if they got a good grade). Computer software is a *huge* field so don’t get too fixated on your first experience, no matter how positive. As someone who works on Microsoft Office I can say that since I have yet to come across a course in university that is about writing a spreadsheet application or a presentation graphics tool (though I studied compilers and databases as an undergraduate and graduate). You might discover your life’s avocation in that class, but be open minded!

I am a strong believer in using four years to master the fundamentals of computer science (if that is your chosen major). For the most part, in the departments I have visited or looked at (and employees I have spoken with) the first 2 or 3 years of most CS coursework are about the same: basic programming (2 semesters), data structures, algorithmic theory, discrete structures, operating systems, computing theory. Some schools pull a couple of these topics together into a single course and others spread them out.

After that there are varying requirements by department. Usually the requirements for the major include one or more “big project course”. This post is really about some thoughts on choosing those electives because in many ways it is these electives that provide you with a depth of knowledge about a specific topic that can last your career or can just be a fun time your senior year. Computing is really a field that has a lot of change, but that change is based on a few core concepts that have remained pretty unchanged for at least 30 years. I think the courses that show you the depth of material that form the basis of those concepts are best.

Another characteristic to look for in courses is how the professor will spend the time—if you are taking a course that requires you to learn C programming (that you don’t know) and the first 2 weeks are spent with lectures on learning C, then avoid that class! The reason is that your first couple of years should have taught you the fundamentals that should make it easy to learn a new programming metaphor in short order and you should not use up the valuable class time studying syntax. As a first semester student, I remember the professor saying “We will teach you PL/CS, a variant of PL/1, at Cornell—you will never use this language anywhere else but do not worry. As a computer scientist you should not think about ‘programming in a language’ but realize you program into a language”. I really had no idea what that meant, but years later I took it to mean that I was supposed to learn about algorithms and how I express those algorithms is not really the long term knowledge. Sure enough over my time at Cornell I used PL/CS, C, Pascal, Fortran, IBM 360 Assembler, Objective-C, LISP, and then in graduate school I used SmallTalk, Modula, C++, and M – all a veritable graveyard of languages. The concepts I learned are what carried me through and I never spent time in a classroom learning a language (or an operating system). If you think that the course is teaching the language itself then it is likely more of a training class than a computer science course—that’s feedback for the prof!

I’m often asked if you need to know C++ to work at Microsoft, or conversely if you learned Java can you ever get a job at Microsoft. The answer is “if you know the fundamentals then it just doesn’t matter what you learned in college”. Over my time at Microsoft we have mostly used C++ and C# to write our code (with HTML and script of course) but college students interviewing/interning have gone from Pascal to C to C++ to Java (with some Scheme in there as a long running theme) for the intro courses. We don’t mind what you know and expect you to move between tools over many years of your career.

My favorite senior courses [I have a feeling this is a post that I will be adding to as I hear from you!] that prepare you for a career as a professional software developer are below. One thing to keep in mind is that you want to write the code that goes with these courses and not just read about them, so if that “practicum” is an optional part of the class then by all means enroll!

Compilers – any course where you write a compiler that does lexical analysis, parsing, translation, code generation is a great long term bet. Although there are great tools for developing languages and compilers, it seems that nearly every project developers a “little” language and has to deal with user input from a command line or text stream. The advent of XML is only making this all the more important an area. There is often a course of “programming languages” which is interesting, but generally just a survey or compare/contrast of languages like the list above. I do not think this is a very valuable course. Looking at the textbook used, generally the book should be one like Compilers or Crafting a Compiler and of course you should write a lot of the code.

Operating Systems – OS coursework is really fundamental to being able to understand what goes on when you write code. I think for the sake of all your future users you need to understand how virtual memory, disk I/O, process scheduling, and file systems work. These concepts have been very constant over a long period of time. Like programming languages it is not important that you learn a specific OS (like Windows) and this is certainly not a course in learning about the command line tools in an OS, but this is a course in learning about the science behind those core concepts. One of the core reasons an OS course is important is because if you ever want to write performant code you really need to understand how an OS works—a common example of this is that until you understand virtual memory and disks you probably think that more processor speed will help your program run faster! If you have a chance to bootstrap an OS from scratch or to write a big subsystem then go for it. A good textbook in this course is something like Modern Operating System Concepts or Operating System Concepts (two different books with similar names).

Databases – Databases are fundamental to just about any real world application. The specifics of databases that are core to understanding the technology are really about understanding how the relational database model works (aka “SQL”). This is a bit tricky because you can get into a course that is about teaching the ins and outs of the SELECT statement. Don’t worry about that as much as you learn about how the whole model or “algebra” works, about the role of queries and query processing, how performance is impacted by your data structure design, etc. If you have the chance in the course to write a SQL database yourself, not just use one, that is excellent. The book being used widely now is by Ramakrishnan.

Graphics – This is always a super popular course and probably the course most responsible for folks thinking “I want to do this forever”. It is easy to make this course fun and it definitely resonates with those who remain gamers throughout college. The techniques learned are really awesome and the lessons apply to a broad set of problems. Most students are amazed at how much calculus is involved in this class so be careful. This is probably on the fun side since the fundamentals of graphics are pretty unique and are not broadly applicable. But have fun. Computer Graphics is the classic book in like its 100^th printing.

Networking – Of course the world is all about networking. There is a ton to learn around the fundamentals of computer networking starting from hardware through the communication and application layers. These courses are often structured to walk through the networking “stack”. Tannebaum’s book is a classic but there are many books that do this well. Of course this subject will be an in-depth study of TCP/IP and probably not dive into other systems which is ok. Again this is a course that can be theoretical (good) or a bit too practical (if you exam asks you what arp and ping do then it is more like an MCSE certification).

I will stop there and see what folks say. I will offer the following as well. If you have a chance to work in a group project then by all means do. Life is a group programming exercise so you will almost never work by yourself. But when doing so be sure to pull your weight *and* be sure that the group works as a group. It is too easy to divide up the work and then speak at the end of the semester or let one person do all the work (that’s the one we hire for development!) There is often a course in “software engineering” that is specifically about a group project. This can be fun, but I would encourage using the time on one of the above topics first and then take a pure software engineering class.

If you have a chance to participate in undergraduate research that involves writing code then go for it! It is an awesome experience. It is not a substitute for the above fundamentals but it is a great thing to do and unique to university. By the same token, courses that are graduate level or impress you with current papers and knowledge are fun, but be sure to take those *after* you get the fundamentals. You can’t learn about OS fundamentals while at the same time studying advanced parallel programming.

I realize there is some strong opinion here. But keep in mind there is no one path to success and certainly no one course that makes the whole difference. Let me know if this is interesting and what your thoughts are!

--Steven

PS: Again, I used Amazon but use any bookseller of your choice and I have no commercial interest in any of these books.

Learning as an engineer -- rising from the ashes of failed projects

steven_sinofsky — Fri, 19 Aug 2005 08:38:00 GMT

Recently a senior program manager asked me for some reading suggestions and I wanted to share a book that had a big impact on how I view projects that I have worked on. The book is called "To Engineer is Human: The Role of Failure in Successful Design" by Henry Petroski (I have no connection to the author and never met him). This is one of my favorite books to give to engineers for holiday presents and I think I’ve probably given a copy to most of the senior managers on the Office team.

The book is a wonderful history of some engineering projects. The primary thesis that is well supported by the evidence is that for every successful engineering project there is a series of failures that preceded it. Mr. Petroski is a wonderful writer and the book is an easy and fun read. Of course one attraction is that the book talks about the failure of the Tacoma Narrows bridge, which is right by Seattle and an amazing site both in person and when you look at the famous pictures of its collapse. The book details other even more tragic events such as the Kansas City Hyatt walkway collapse. It shows how small design mistakes can be overlooked and also how future designs benefit from the failures. Often people who are not engineers really don’t quite understand how you learn and improve as an engineer by making mistakes, and obviously the challenge is that if your failures cause damage it is really unfortunate.

I think a lot about this relative to the security issues we face in computer software today—we did not design for these and while we are doing everything possible to update old software the real benefit is coming from the new generations of software that were designed from the beginning to work in this environment (for example, in the 2 years that Office 2003 has been out we have only had 2 critical updates). I don’t want to make any excuses at all so don’t misinterpret that, but the learning that has taken place in our industry over the past 5 years has been immense and necessary for us to build products like Office 2003.

When I think about software projects that I have worked on from an OS in CS 415 at Cornell through an object database in graduate school all through Microsoft projects, the notion that failure often precedes success is one that is near and dear to me. Our industry is of course filled with failures that went on to become the basis upon which much learning took place (like the Newton to the Palm Pilot, for example, or the new TabletPC learning from the old PenWindows).

The reason this book resonates with me is because my first project at Microsoft was a pretty colossal failure. I was hired into a very small group (in business school lingo, the group would have been called a “tiger team” – a hand-picked group of experts with a specific short term mission). I don’t know how I ended up in this group since it was filled with incredibly senior developers and I was really intimidated. In any event, the mission we were given just before I started at MS was “build an application framework for Windows”. It sure seemed easy enough—we had a lot of great folks and even little me had just worked on Smalltalk frameworks for 2 years so we collectively thought “no problem”.

We worked for about a year and had a rather complete framework. We were pretty confident in our ability to use it to build robust applications in short order. So we decided to spend a month (a whole month!) building applications. Microsoft Money was under development so I figured I could spend my month building Money, which seemed simple enough. The framework had graphics, persistent objects, a UI model-view-controller framework, etc. ¡No problema!

After a month I had a fantastic application – it was able to successful draw a check on the screen. Needless to say our framework was too big, too slow, too complex for anyone to really use. It was a dismal failure despite all the right ingredients and doing all the “right” things in object oriented design. In fact we had overdosed on objects and had become full-blown oopaholics. Rico has a blog and video on the abuse of object-oriented design worth checking out (Rico was working on the compiler at the time I was working on the class library)

As a result we had a rude awakening. Our manager’s manager’s manager was getting frustrated with progress and we were under the gun. We had a big meeting to review our lack of progress and had to admit that we had not made 12 months of progress over the last year. We had to regroup.

I received my first Microsoft lesson: just because you messed up does not mean your career is over. What matters is how you dust off, what you learn, and if you can put that into practice. Microsoft holds no grudges. The boss said “ok you made a mistake, let’s get moving and don’t make that same mistake.”

We regrouped. We spent a couple of days talking about what we learned and very quickly came up with a number of “rules” about how we would really design a great class library for Windows. I can’t quite remember them all but some of them were:

We’re building a class library, not a compiler test suite, so there is no need to try to use all the features of C++.
Don’t build new abstractions on top of the existing abstractions in Windows. Folks will need to know Windows to use the framework anyway.
Developers will want to call Windows so don’t cache any state in the classes that is duplicating state maintained by Windows (for example, parent child window lists, styles, etc.)
Performance matters from the beginning so don’t go and use fancy stuff that has a fixed overhead that you don’t know if you need (like using virtual functions everywhere for example).

And so on. Once we had these lessons in place we actually developed the whole framework in a few months and were able to ship it with Microsoft C++ 7.0 (our first C++ product). We designed in parallel the next release along with all the graphical tools that became Visual C++, which itself became Visual Studio over time. The class library, Microsoft Foundation Classes or MFC, became a great tool used by tons of Windows developers around the world. I think my proudest moment was walking up to a really tall guy at a DEC booth in a partner section from the University of Ilinois at a tradeshow demonstrating an alpha of a Windows network application called a “browser”, I think his name was Mark, and asked him what tools he used and he said “MFC of course”. Yes!

When I think back about the dismal failure of our first library and how as a team we seemed to have developed a massive case of second-system syndrome for a first system (a mean accomplishment) and how we regrouped, learned lessons, and put those into play, I realized that without that first failure we never would have developed the success criteria that allowed us to build MFC.

The fact that Microsoft offered an environment where we could practice the lessons detailed by Henry Petroski made the whole experience even better.

And most of all I am thankful that I got to be part of an amazing team who mentored and pulled me through these experiences as a new hire. I really want to thank all the people on this project that taught me so much. Thank you for letting me be part of our collective failure and success!

--Steven

PS: I used links to Amazon, but by all means buy your books from your favorite bookseller.