Ineffective Middle-Management Suckups

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 for An Ode to Managers.


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 .