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?
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.