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

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.

Comments

• Anonymous
  September 24, 2005
  Dear Mr Sinofsky,
  
  Please run your posts through a spellchecker.
  
  Spellbound is a good one for Firefox. IESpell can be used with Internet Explorer. This will make them more readable and more accessible to automated translation engines.
  
  Liklihood is not a word.

• Anonymous
  September 25, 2005
  I'm terribly sorry. I used Word but just missed the suggestion. Please use a less offensive handle when suggeting comments.

• Anonymous
  September 25, 2005
  tough crowd.
  
  i'm an mba who is interested in working at Microsoft and i found this post extremely informative.
  
  Steven - i imagine that the restructuring won't affect the org. structure you've outlined....?

• Anonymous
  September 25, 2005
  Steven,
  
  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.

• Anonymous
  September 25, 2005
  Anonymous, check out http://blogs.msdn.com/techtalk/archive/2005/09/25/473808.aspx. The answer got too long for a comment.
  
  --Steven

• Anonymous
  September 25, 2005
  Kayvaan,
  
  Thanks for the support! I'm working on a post about MBAs. Stay tuned. Please feel free to post any specifics about what you'd like to hear about. I'll be MBA recruiting on the east coast on 10/5. I'll be doing technical recruiting several times in October as well.

• Anonymous
  September 26, 2005
  The comment has been removed

• Anonymous
  September 26, 2005
  The comment has been removed

• Anonymous
  September 26, 2005
  Dear Mr Sinofsky,
  
  Besides the spell checker, please consider using a grammar checker, too. Though I am not using that particular product, I heard rumors that Microsoft Word has one.
  
  "has been studying organization for a few thousand years and because manpower is everything is very motivated to have the maximal number of troops"
  
  I am not native English but I am almost certain that lacks a bunch of commas, I read it like 5 times to understand what was meant.
  
  Thanks

• Anonymous
  September 27, 2005
  Since you publicly stated that you corrected spelling, and since the only thing worse than spelling errors is spelling errors in a corrected document, I thought I'd point this out. While your statement that "employees compromise 50% of the manager-employee relationship" might be true, I think it's a little unfair to assume they're compromising the relationship right from the get-go. Perhaps we should say that they "comprise" 50% of the relationship at first, and then decide if they're compromising it on a case by case basis. ;)
  
  While you're at it, maybe add editors to the list of under-valued employees - I know a few news organizations that could be reminded of their value, as well.

• Anonymous
  September 27, 2005
  Thoughtful post, thank you.
  
  The issue of team size appears to be the constant throughout companies, including those beyond software. Human attention only stretches so far.

• Anonymous
  September 27, 2005
  Gosh folks, I'm just blogging away here. I didn't realize I needed to hire an editor. I was merely following the blog convention of noting changes visibly rather than just reposting.
  
  Lucy I would point out that there is nothing worse than correcting someone and being smug about it, only to find that you have incorrectly used a hyphen surrounded by space rather than a dash. Please see Strunk & White, rule 8 under elementary usage. Ooops!
  
  --Steven
  

• Anonymous
  September 27, 2005
  Kan da grama 'n speling polis pls bak of.
  
  Fank u i atvans.
  
  

• Anonymous
  September 28, 2005
  thx Dan!

• Anonymous
  September 28, 2005
  All I can say is that second (burdened) manager clearly has a problem. I mean, just look at the employee at the top left of the group. He/she looks ready to cause some real trouble!
  
  Seriously though, an interesting read and insight into the team structure at Microsoft. I had often wondered how very large product teams were organised.

• Anonymous
  September 29, 2005
  Steven,
  
  I just ran across your blog a few minutes ago and it brought a smile to my face. Since leaving Microsoft one of the things I miss most is the rapier-like wit that can be found around nearly every corner. I'm somewhat nervous about posting this since my Strunk and White is not at hand...
  
  Cheers,
  YvonneLo
  
  
  

• Anonymous
  September 29, 2005
  Oh that's ok -- I won't be spell checking any comments. :-)

• Anonymous
  September 30, 2005
  If you help me find the dash key I'll help you find your sense of humor. ;)
  
  Seriously I wasn't meaning to be smug, I was just trying to point out the humor in what you actually said. I apologize if it came across as anything more than a friendly heads-up and a chuckle. The content itself is too intelligent to have the message be ahem compromised by silly things like choosing the wrong word. While it is "just" a blog post, it's definitely one that deserves to be taken seriously.

• Anonymous
  September 30, 2005
  OK Lucy, call me too sensitive!

• Anonymous
  October 29, 2005
  I don't know what you did to attract all the trolls, but it sure works! Sorry you have to deal with all the heckling.
  
  Only 7 steps to SteveB for the average Office new hire? That hierarchy is a lot shallower than Windows'. And over here in Windows I get one more step away from Steve with every re-org. What's Office's secret?
  
  - Drew

• Anonymous
  February 26, 2006
  Steven
  From your post and the structure of the team you describe for the office team, it seems as that to move up the ladder you need to move from dev->lead dev->program manager->general manager. From what it seems is that at some point in the hierarchy, say at program manager level the bulk of your responsibilities would shift from technical(hands on coding) to managerial(people management, liasoning with other groups, etc). Is that correct ?
  Also, is there another parallel technical stream where say the engineer has 25 years of coding experience and is still developing/coding software ? What is he called ? architecht ? chief technologist ? What is the career path on the technical side ?
  ...kabir

• Anonymous
  April 13, 2006
  While at Stanford this week I was asked by a number of PM (program manager) candidates to talk about...

• Anonymous
  July 16, 2006
  I just finished reading Steven Sinofsky’s post about what managers do and team sizes are at Microsoft.

• Anonymous
  December 29, 2007
  PingBack from http://cars.oneadayvitamin.info/?p=982

• Anonymous
  June 05, 2008
  The comment has been removed

• Anonymous
  June 17, 2008
  Republished from Steven Sinofsky's PM at Microsoft , TechTalk, Dec 2005 While at Stanford this week I

• Anonymous
  June 16, 2009
  PingBack from http://lowcostcarinsurances.info/story.php?id=4501

• Anonymous
  November 17, 2010
  mr.etc i think u will do some think special bcz any buddy know about what manager do u write very common think i have no benefit for your comment so please extra think say