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:
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):
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.