Steven Sinofsky's Microsoft TechTalk : Software Development

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

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

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.

More about learning from the past -- Office Assistant

steven_sinofsky — Mon, 12 Sep 2005 23:42:00 GMT

The past couple of weeks have been busy as all the interns moved on (yippie we have more parking) and we’re gearing up for the Fall when we visit lots of college campuses around the US, Canada, Mexico (Europe is later). I’m planning on visiting a few schools in October so I hope to see those of you thinking about a career at Microsoft.

And what is keeping us really busy is working on Office “12” of course. This week is very busy as we are going to show the new product for the first time in public. There’s a lot of excitement brewing on blogs around the PDC (Professional Developers Conference) where Bill Gates keynote will show a lot of new things. Of course for the interns that worked on the new user experience in Office this is definitely a big deal, and we have a number of developers, testers, and program managers for whom this is the first time their work will be shown in public and by Bill as this is their first product cycle. Congratulations!!!

In thinking about the role of user interface in Office, one can only be humbled. As an engineer on the product you are responsible for how millions of people around the world produce documents, read email, do business analysis and in general enhance their productivity with the PC. It is really incredible to get to work on something like that, but it is also quite a responsibility. It is also a responsibility you can have as your first engineering job.

When you’re young and in your first job you are not as concerned about change and are generally more aggressive (something that happens as you get much older as well I think). Office has been the mark of stability in our user interface since Office 4.0 (16-bit version) when we basically had menus, toolbars, status bar, and multiple-document interface windows. Over the years we’ve added some elements but few things have been removed and not much has really changed. This was the conservative era for the product as we were getting established and frankly that is what customers asked for. Customers are now asking for a lot more—they want to tap the power of the software they know is available but “hidden”, they want to use the software for new scenarios (like business analysis, collaboration, etc.), and they want to produce much better looking documents (rather than the circa 1990 charts we produce today).

One of the things that has made us very comfortable thinking about change has been the role of new hires and interns in our group. They have seen the work we are doing and take to it right away. In fact they don’t see it as nearly the huge change that folks who have grown up with the products see it. The generation of people that move between TiVo, iPods, and IM have not been indoctrinated by “consistency is all that matters” or the goal of having “one single user experience”. Rather they experience life, and productivity, through a series of programmed experiences each tuned to the task at hand remarkably well. Our job in Office is to build those tuned experiences while integrating the work products seamlessly across the entire range of programs in Office.

The last major change we created in Office user experience was the Office Assistant, also a technology done by many folks fresh from college with many experienced folks leading the team as well. I hesitate to bring up the new user experience in the same blog as the Assistant—as you have no doubt figured I am a big fan of leaning from past mistakes and so I am certain the new user experience benefitted from any mistakes you might think we made with the Assistant. I should say that despite the fact that in the press and reviews the assistant was nearly universally panned (perhaps because of the implicit relationship to Microsoft Bob), even to this day we get letters from people saying how much they love “the little guy”. It is most certainly one of those puzzles we will never understand. Perhaps it is best to say “love it or hate it”.

The development of the assistant, even if you didn’t like the outcome, was a great example of experience, new hires, and a synthesis of ideas. The idea of a social interface was championed quite a bit by the team building “consumer” software as a way of making things easier to use. We started to pick up on this idea as a way to enhance the access to help within Office. One of the elements that became very important was “how do you make the assistant real to customers.” We spent a lot of time on animations and trying to make them feel like real personalities (we in fact met with the famous Disney animators Frank and Ollie responsible for many of the 20^th century’s best animated characters). But what was missing was the way that you interact with people—how do you ask it a fuzzy question and get a specific answer or how do you ask it for help while it is “looking over your shoulder”. This is where the synthesis came together and it was a couple of new hires on our team who really championed these ideas.

The two were very mathematically inclined and quite familiar with the work going on in Microsoft Research over “probabilistic reasoning”. They figured out how to connect this type of thinking to two elements of the lovable “clown”. First, they figured out that you should be able to click on the clown at any given time and it should have some sense of what past actions you were doing and be able to suggest help right then. So for example of you clicked on Print, then cancel, then Print again, we should have the clown suggest help with printing. This was a cool technology that required a statistical modeling of the commands used.

Second, we had to figure out how you could ask questions of the assistant. This took a lot of effort to develop a language model. In 1996 when we were developing this, “search” at best was always an exact word match and maybe a keyword index. We wanted people to type questions in their own language—after all the language of the user interface in Office is a bit jargon-oriented (is “mail merge” really a word, what is a “PivotTable”?). The work that got done here by the new hire was to develop a technology working with MSR to allow fuzzy matching of help questions (queries) to the possible answers. He developed an authoring tool that allowed the people writing help information to identify fuzzy terms that might describe a topic. The whole process of asking the clown for help became one of building a set of possible matches. This was super high tech at the time. It got to the point where you could ask “how do I sent Christmas cards to all my contacts” and we would point you to mailmerge—I remember actually helping someone at a taping of a tv interview once with that exact query. It blew the person away (she was a user of the Kitten!).

These contributions represent the huge responsibility you can have as a new hire--blazing new trails and developing new technologies and bringing them to market in a pretty big product…even if it doesn’t please 100% of the audience.

At the time we came out with the assistant, we got a little bit defensive and started to do some research about new ideas that people came out with and what the reception was. The classic of course is the Sony Walkman which was universally panned because it did not record, but only played tapes. The rest is history. But here are a couple of quotes that are hard to believe these days:

In reference to the Apple Macintosh, Windows, and GUI

"The Mac simply doesn't have the look or feel of a business computer." (InfoWorld, March 26, 1984)
"A few traditional computer users see the mouse, the windows, and the desktop metaphor as silly, useless frills." (Byte, May 1984)
"'Icons represent an attempt to restrict what people do with computers, in the guise of user-friendliness.' According to Currie, icon-based systems are appropriate for novice computer users, but will hinder the work of knowledgeable users." (Computerworld, August 20, 1984, interview with Edward H. Currie, president of Lifeboat Associates, a New York-based software publishing firm)
"Because <Name of Program> works the way you do, you don't waste time with a mouse or learning a Macintosh-like graphics environment. <Name of Program> works the way PC software is supposed to work." (Ashton-Tate brochure for Byline Desktop Publishing, 1988)

In reference to the mouse peripheral device

[headline] "Mice are nice ideas, but of dubious value for business users" (George Vinall, PC Week, April 24, 1984)
"I was having lots of fun, but in the back of my corporate mind, I couldn't help but think about productivity." (George Vinall, PC Week, April 24, 1984)
"Does the mouse make the computer more accessible, more friendly, to certain target audiences such as executives? The answer is no." (Computerworld, October 31, 1983)
"There is no possibility that this device will feel more comfortable to the executive than the keyboard. Because of its "rollability," the mouse has the aura of a gimmick...." (Computerworld, October 31, 1983)
"The mouse and its friends are merely diversions in this process. What sounds revolutionary does not necessarily help anyone with anything, and therein lies the true test of commercial longevity." (David A. Kay, Datamation, October 1983)

Sometimes people are funny when it comes to change. In hindsight, you can see the conservative nature of these comments.

We learned a lot. The assistant never became a GUI or mouse in the level of success it achieved. We learned a bit of humility. We learned a lot about how customers do not like to necessarily be clowned around with. We learned about how to synthesize disparate ideas into a technology. And we learned how to learn from our mistakes.

The folks that worked on the Assistant have all gone on to do amazing work for Microsoft and elsewhere. So that great attribute of Microsoft that says you can make “mistakes” (even if some people still say they love the Assistant) and not only recover, but grow your career is really a truism. This is just another example of a place we learned.

--Steven

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.

Chrysler has interns redesign the Jeep

steven_sinofsky — Mon, 29 Aug 2005 05:23:00 GMT

I was just reading a WSJ article (WSJ subscription required) on Chrysler asking interns to design the Jeep of the future. This is most certainly a cool intern project in that you get to be as creative as you can be and one that has clearly not been a challenge met by the full time designers at Jeep.

These interns are all Art and Design interns for the most part and so concept projects like this are the norm for most internships. We have interns with these backgrounds (as well as full timers of course) though we tend to focus on a different set of projects.

We try very hard to make our intern projects significant contributions to shipping products. It makes for a challenging experience and one that reflects the “real world” a bit more. There is probably room for both ends of the spectrum at Microsoft.

I just thought the article was interesting so I’d pass it along.

An excerpt follows:

EYES ON THE ROAD

By JOSEPH B. WHITE

Rethinking the Jeep

Chrysler Interns Take on a Challenge:
Design Next-Decade Jeeps for Six Cities
August 29, 2005

If a reality-TV promoter wants to set a new series in Detroit, here's a scenario: "Motor City Designers," in which a group of eager young contestants competes to design a Jeep that will go on sale in 2015.

In fact, that's the assignment Chrysler gave to a group of six college-age design interns and three engineering interns this past summer. The company recently offered a peek at the ideas that resulted.

Give Chrysler's design management credit: They handed the kids a genuine challenge that has bedeviled the company's full-time design staffers for years. Jeep is one of the most-recognizable brands in any business. The word "Jeep" is practically a synonym for four-wheel-drive vehicle, having the relationship with SUVs that "Kleenex" has with facial tissue and "Xerox" has with photocopiers.

That's great, except when it's time to react to shifts in consumer tastes, or move the brand into different markets around the world where consumers may like the idea of owning a Jeep but wouldn't really want to drive a U.S.-spec SUV. Moreover, by 2015 -- which in auto-industry terms is roughly two model changes from today -- will consumers who are today in high school or college want a Jeep that looks just like Mom's Grand Cherokee? It probably wouldn't be wise to bet the franchise that they will.

Chrysler's apprentices were each assigned to design a Jeep for a different major city. The cities were Los Angeles, Detroit, Geneva, Tokyo, Hong Kong and Sydney, all places that Chrysler either sells Jeeps or wants to sell more in the future. Each designer had an engineering intern to work on practical questions, such as "Will there be room for the driver's feet under the dashboard?" The concept designs had to fit more or less on the chassis of real DaimlerChrysler vehicles, such as a compact Mercedes or a long-wheelbase Dodge Caravan minivan.

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.

Thoughts on the first few years of a new hire at Microsoft

steven_sinofsky — Wed, 27 Jul 2005 01:10:00 GMT

I wanted to write some thoughts on career progression for new hires at Microsoft. Up front I should probably say that I am not trying to sell folks on Microsoft, but trying to tell it like it is. Folks who know me often accuse me of being too honest. What I would say to people looking to enter the job market for the first time is that you are being marketed to—that means that you have to learn to separate the claims from the realities. I think that is something I hope to do over the coming months.

It is performance review season at Microsoft so everyone is busy with that process. It is also a time of year when people take a step back and think about where they are heading in their careers and what they should think about in terms of career goals over the next year or three. A member of our team that is going through her first review stopped me in the hallway today and wanted to chat for a minute. A question on her mind is “what should I expect out of my career in the next five years”. In other words, what is the typical first 5 years like at Microsoft.

Of course my first response as a manager is to say “no career is typical”. I think that is a normal manager reaction to trying to avoid making specific commitments in the hallway :-) It is also a truism at Microsoft--no career path is typical and certainly nothing comes without hard work and solid execution.

We hire a lot of folks straight from college in the Office team. The first 5 or 6 years can be exciting, but is also challenging, so a new hire needs to be committed to learning and growing with the organization. So the first rule is “be prepared to learn”. As someone wrote me last week, “what if you’re not happy with your first assignment, then what?” This is a common concern since sometimes your first assignment doesn’t sound quite what you thought it would be. This is especially true if you are unfamiliar with the whole area and it doesn’t sound like a familiar college course (databases, languages, etc.) In most software development, when it comes right down to doing the work there are a lot of details that are a lot deeper and perhaps less “science” than college courses.

Once you have that first round product cycle experience (generally in the first couple of years in Office where our full product cycles are 20-30 months—it might sound long but that is a topic for another missive I’d love to fire off, “the myths and realities of internet time”) people tend to follow one of two paths. First you can choose to stick with the same group working on a different area perhaps. This is probably the most common as people develop expertise and interests. Surprisingly, most members of our team self-select to stay working on the same product area the second time around.

The second path is one where you choose to work on another technology, either in Office or somewhere else at Microsoft. Of course at Microsoft you have the opportunities to work on an amazing breadth of software from the living room to the board room. Most people who want something different also look at other parts of Office. At each product cycle we have an open and systematic opportunity for people to move across the team. This process is one where people are encouraged to move and to talk freely about the opportunities. In fact, at the start of a release it is not uncommon for 25-30% of the team to seek out new technologies to work on (and new managers to work for).

During the course of these first two product cycles I believe the most significant core learning takes place in terms of being a contributing engineer to end-user software development. Whether you are program management, software design engineer in testing, or development every day is a learning experience. You learn all the core skills with close mentoring—your manager will work with you on a daily basis on your specs, your code, your test plans. You will have peer review of your work. And at Microsoft you have the opportunity through our open mentoring program to receive a mentor from any part of the company. It is during this time that if you are performing exceptional work you will receive promotions through the career ladder system. This system is described in our intranet with detailed examples of the skills required and the inputs your manager (and his/her manager) have in terms of evaluating your accomplishments. You are eligible for promotion throughout the year (unlike some companies that only allow one time per year). While nothing is typical, as an example, a strongly performing developer hired from college might expect to be promoted in 12-24 months, and then again in about the same time period. A lot of this of course depends on the team and how your performance stands out relative to them—performance is not measured in isolation.

A key thing is about how your own work changes during this time. The first thing that changes is your scope. When you first start you will have something to do that is narrow and you will have your manager helping you every day. Believe me the first time you do a checkin it a super stressful time—after all your work is on the way to being used by 400 million people. Whether it is code or a web service, the thought of a ton of folks using your code can really keep you up at night. Over time as you master the overall system you will learn about how the components interact—how does your work impact macros and solutions, localization, corporate desktop management, and of course there is a ton to learn about security, quality, performance. So your first checkin will be probably localized to one file, but over time you will find yourself checking in code in many places (or writing specs, testing areas, etc.) In fact, if you work on shared code in Office you will own features/code/tests that cover all of the “Office System”.

After you have gained the experience at contributing at the right level you will start to be asked to take on broader responsibilities. One example might be mentoring interns for the summer where you would have an intern that you are required to “manage”. Perhaps one of the most exciting things for me is to see someone I remember as an intern transitioning to the role of an intern mentor for the summer. We had quite a few folks this summer who were interns 2 or 3 summers ago. It is great to see people moving along through their own careers. It also makes me feel old!!

At this point people do start to decide “is management for me or not”? This is a natural question and why our career progression recognizes that not everyone wants to be a manager. In fact, even our managers must contribute to the code/specs/tests of shipping products, so being a manager does not let you off the hook. But should you want to be in management, it will actually become pretty natural and you will see that the opportunities will arise and at the start of a cycle you will soon enough find yourself what we call a “lead” or first line manager. I started managing folks about 4 years into Microsoft. In hindsight I probably wasn’t quite ready and I was definitely shaky. Fortunately my first reports were forgiving. Whether you are a manager or not the progression through the career ladder is possible (in other words promotion is not tied to management, but related to your technical aptitude, ability to work independently, and as always the business need). The key thing of course is that Microsoft is hiring people all the time so the need continues to grow for senior people, whether managers or not, who understand how to build real-world software.

Once you reach this part of your career, perhaps that magic first 5-6 years of experience, you become much more “in charge” of your own career as you have the experience and understanding of what you are looking for. You probably established a network or at least some contacts in other parts of the company and so exploring also begins. It is also the case that for the folks that came up with the best designs or wrote the best code, it is amazing how quickly word spreads and you will definitely be sought out by others.

The short answer to the question this note posed is that the first 5 or so years of a career at Microsoft are a huge learning experience. But not a trial by fire, but a way of “drinking from a fire hose, but with supervision” You’re surrounded by people who have experience and more importantly empathy for you and are super motivated to help you to learn how to contribute to our products. And even more importantly we are super interested in tapping your creativity and energy at solving the challenges our customers face by building great software.

--Steven