Ineffective Middle-Management Suckups

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.

A decent defense of middle management. I have corresponded with you directly before and was impressed by your openness.

Is your main point that decisions have to made, and not everyone can be happy about it because there are more workers than chiefs? Let’s explore the area of decisions that go against not just some of the workers, but most of them.

My question is about how to deal with the ‘bad decisions’, the ones which you disagree with but are officially decided. In Microsoft sometimes this comes as "big bets" — let’s say a big bet on a tricky new storage technology as an example [depending on timeframe this could be Office or Windows, it’s a frequent problem area].

OK, so what is the best strategy for those on the bottom? From your blog I get these messages:

– Use the open door to give feedback.

– Don’t do passive resistance like sandbagging.

This has not been a winning strategy for the bottoms [No Ship Its, no respect, bad PR for the groups involved]. The door is open but no change will happen. The sandbaggers come out far ahead in the end and are rewarded for their pessimism and passivity, though what is delivered is below what was promised.

I’ll admit the two times I have seen genuinely "most" bottoms on a team feel this way, either the exec left for ‘personal reasons’ or the project was canned. Neither was a good experience.

I’m not sure you quite addressed the passive resistance approach. Working against the plan and standing up to save the project later can be very rewarding from what I’ve seen. In fact it looks like the only way to speed up advancement. (Whether you regard that as a good thing or not, it is desirable. Even the fastest risers take 5-6 years where someone who started in ’89 could move in 2-3.)

Of course Microsoft is legendary for making big bets that caused amazing developers to leave and not join in. The bet on the GUI was one of those–the lead developer for our spreadsheets quit because of his lack of faith in the big bet. He later returned.

In the end, if you disagree with the big bet and have raised your objections then you really do have to decide if you can change you own point of view and join in the effort. If not, then you really do need to leave the team. It is better for you and better for the team.

As career advice, my suggestion would be not to do this too early in your career–when you are young of course you have much greater certainty in how things should go and are much less open to others. These things soften with age 🙂

And of course, I keep referring to the need to get product cycle experience. If you leave every time you disagree with big decisions you might find yourself without much experience and a lot of jobs.

This is all very challenging because great engineers have strong views on how things should be done. It is no coincidence that "The Fountainhead" is shared as a favorite book by many of us. But for every Roark that gets the project built just the way they want to (and gets acquitted because of strong princples), there are many more disgruntled engineers with long resumes.

Call me an optimist, but I believe that if you stick it out even the most egregiously bad decisions will get fixed soon enough. I do have faith in a system, and I have faith that the right thing happens in the end.

The part that I have the most trouble with is the “most people believe is a bad decision”. “Most” is a lot of people. My experience has been that when someone says this what they really mean is the set of people they talk to but as a manager more often than not, the strong agreement one person senses is not as strong as they think and is usually rooted in reasons beyond those that you might think. In other words, in the heat of a debate it is not unusual for the listening to stop just after someone’s position becomes clear. It might be two people disagree with the direction, but one disagrees because of the architecture and another disagrees because of the customer scenario. A small change in framing the problem might tip the scales. So be careful about generalizing that “everyone thinks…”

With regard to "passive resistance" it looks like you’re speaking about some specific experience. I have a tough time imagining the situation where someone was rewarded for performing in a mediocre manner unless there was no track record to base any performance expectations on.

The opportunities for advancement are greater than they ever were at Microsoft. We have more new projects, more new businesess, more new groups, and are hiring more new people this year than in any year before. As the both the depth and breadth of what Microsoft works on increases the need for leaders in both management and technical depth grows.

We will hire more people from college this year for Office than we have ever hired before!

You bring up intersting points in this rather lengthy post: clear communication of intent, sowing clarity instead of confusion, managers are hard working people too.

This very post is the antithesis all those things in the eyes of an IC. To the peons, the proles, the masses huddled over their keyboards, this post comes out as self-aggrandizing and out of touch.

You want to get our attention? Write a 5 sentence e-mail that isn’t a me-too version of "great job on such-and-such feature". Our time is as valuable too. Don’t patronize us. Don’t dumb things down for us.

We know the dirty secrets of stack ranking. We know we’re not going to be automatic millionaires. We come into work anyways. We do the job day in and day out. We work long hours and forsake our loved ones. Because even if complain, we care about the job we do. Not for our managers’ sake, not for Microsoft, but for ourselves.

Incompetence is there if you care to look. I think part of a manager’s job is to root it out, not wait for someone to point it out for them. But maybe that’s just the the definitive nature of my work.

What about loyalty? What should an IC do when their manager tells them they didn’t get the higher review score because they aren’t loyal to their direct chain of command?

In the world of Office there are better managers and middle managers, because the bar is set high, IMHO. In other organizations across the company is thisn’t the case. What I’ve seen, (of course this would be in limited scope), managers who perform poorly, are just moved from one team to another.

Is the company wanting it’s employees to spend more time on the soft skills rather than the hard core techincal skills?