Steven Sinofsky's Microsoft TechTalk : Management

Ken Morse on advice for graduates

steven_sinofsky — Mon, 05 Dec 2005 09:27:00 GMT

A few weeks ago I was on a panel discussion at Cyberposium 2005. The panel's moderator was Ken Morse, a lecturer and managing director of the MIT Entrepreneurship Center. Professor Morse has quite a lot of experience with startups in the technology industry (having been involved in launching companies like 3COM, Aspen, and others) and is also a founder of the MIT center.

In the closing of our panel Professor Morse offered some words of advice to the attendees (mostly students graduating from business school at Harvard and Sloan). I think the advice was worth repeating as it is equally appropriate for those pursuing careers on the technical side of product development. He suggested two key things (my paraphrase from memory):

First, get experience at a company that can "teach" and can help you to learn about how to get things done. Building products and businesses is a lot harder than it looks. He mentioned that while many companies have been started by people without much experience, that is not really the method that is repeatable. Most companies that start do not achieve success, and most that achieve success do have a lot of people with experience from established companies.
Second, you really need to love what you're doing and you need to be in it for the right reasons. The right reasons are being passionate about the product or service you are building and not just passionate about making money. When you build a product, business, company it can take many years and you will need more than a desire to make money to keep you motivated and focused during that time.

Just wanted to pass that along. I joined Microsoft because I wanted to learn how to make the things we were talking about in graduate school--make things for millions of people (you can read that in the recruiting brochure from 1990!) The one thing that has changed the most is that we make things for hundreds of millions of people now.

--Steven

Where should I work? Global development of Microsoft Office.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--Steven

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

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

bu·reauc·ra·cy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--Steven

Ineffective Middle-Management Suckups

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

Anonymous said:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--Steven

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

To illustrate this just consider this simple picture:

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

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

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

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

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

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

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

--Steven

PS: updated to fix 3 typos.

Understanding orgs and helping them work better

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

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

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

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

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

Tough questions.

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

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

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

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

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

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

Some of the behaviors that happen pretty routinely:

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

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

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

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

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

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

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

--Steven

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--Steven

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