I may have hit a chord with the management theme last week, lots of offline feedback on that post. I’ll post on the topic again to see if I can turn a data point into a trend.
At Microsoft we have a competency called “Cross-group Collaboration” which is used to illustrate the degree to which one is successful in employing tactics like “managing without authority,” “holding others accountable,” “creating win-win situations” and all that. Even in writing that sentence I cannot help but surface some of the cynicism I have for those concepts.
The adult definitions are strikingly similar to the concepts we’re taught in pre-school:
Adult Definition
Childhood Definition
Facilitates "win-win" situations; works with others to achieve positive outcomes. Establishes working relationships with others to capitalize on ideas and resources for mutual benefit.
“When someone asks to use your things, you can't simply say, "no." Nor do you have to say, "yes". But if you decline to share, respect the other enough to either give a reason or suggest an alternative, such as "Let's take turns," "You can play with it, but only inside," or "That's my very favorite, but you can play with any of these."”
Read more: http://www.drgreene.com/qa/learning-share#ixzz111ynSn9n
This isn’t to say that I think we manage people like 3-year-olds. What I am saying that many of the competencies used in assessing our performance at work are basic life lessons in a specific context.
These principles are defined in so many places by so many people that their application takes on an artificial quality that separates the behavior from the intent. In the worst examples, these cross-group collaboration competencies are forged into instruments of career torture. Events in one’s day to day life evolve into context-free samples of how one is failing the basic rules of “don’t hit,” “be nice,” and “share your toys.”
Desire for excellent collaboration among individuals at work is not the problem. Defining attributes of successful workgroup collaboration isn’t the problem either; <recruiting commercial> Microsoft does well in defining what this looks like in our company. Microsoft spends a lot of time on Career development for employees. The model we use for career development (and the tools available for employees to use in doing it) is something you have to see to understand. If it is not unique in the industry, I’m certain that few companies can come close to matching what we use here. </recruiting commercial>
The problem arises when the definitions for Cross-group collaboration become untethered from the purpose of doing it well. This post is about the purpose of cross-group collaboration.
What is the root of collaboration in the corporate environment?
(I’m sharing my own thoughts here, but here are some obligatory resources: http://www.creativityatwork.com/CWStore/OCAWe-book.htm, http://www.ami-communities.eu/wiki/Collaboration%40Work, http://tucsoncitizen.com/wise-work/)
My mental model for the problem is as follows:
If Microsoft was a company of one, this would all be so easy. I would go ask a bunch of people what they wanted in a software package, write some code to meet their requirements, test it myself, ask them to help me test it, figure out how to package and price it, spend some time on the road selling it, and eventually get back on the treadmill and do it all over again.
Because I would always have all the data all the time, and my ability to relate business functions is dependent only on my memory, I would have little need for anything beyond a day planner and a notebook to record notes for future reference.
Because I have two young children at home, I am unable to sustain this life. I need help. Much like cell division, I need to produce more people to do the work. For each cell division capacity is increased by 2 and/or workload is halved. The largest tradeoff I consider in adding people is the degree to which work is divided into autonomous functions vs. roles where information must be shared between the parties. Where I now depend on the second person for information, I create a potential communication problem.
Unfortunately humans aren’t perfect communicators, and adding people introduces inefficiency that accumulates with each cell division. Capacity falls somewhat short of doubling with each cell division, and workload absorbs that impact. Each cell division might separate half of the existing work, but the burden that collaboration places on people adds new work. I could introduce some cute mathematics and limit equations here to illustrate the example, but the concept is simple and doesn’t require that.
At some point after a large number of cell divisions, 1,2,4,16,256, the burden of collaboration on each cell’s workload, combined with the cumulative productivity loss across all these functions requires some solution. Welcome our new “management” team; people who are put in place to reduce the efficiency drain and to reduce the net workload effect collaboration places on individual cells. They do by organizing, filtering and sharing the relevant details across different functions in the organization. This solution is a shortcut, because we’re taking a bet that we can’t make people perfect communicators, we have practical needs which force us to do something.
For those who have a pessimistic view of the role of management, take note. I’ve encountered many folks who view the role of managers as reducing vibration within a system. I see it differently. The essential role of management is to reduce the efficiency drag and workload burden inherent in organizations where the role scope is narrow and dependent on the output of others. (The role of ‘leadership’ is different, and perhaps the subject of a future post.)
This is also why “the smartest person in the room” is often the last person you’d want managing a team. People who don’t feel like they should depend on others generally won’t. They make poor facilitators of collaboration. Subject matter expertise can aid one’s ability to communicate and to close gaps, but toy sharing and subject matter expertise are different skill sets. Effective managers are ones who can facilitate productive interactions. Subject matter IQ helps, but if nobody likes working with you it won’t matter. This reminds me of an old saying, “If you want to go fast, go alone. If you want to go far, take a group.” I don’t know who said it, but it makes sense.
We are not a company of one. I believe we have more than 75k employees (estimating conservatively because I’m too lazy to look up the actual number). At a company of this size, there are many, many layers of management. We use complex systems to facilitate information sharing and the collaboration that is required to keep so many cells functioning as a unit. It is imperfect.
For all the models, systems, SharePoint, and other things we use, nothing is more important than the ability of people to connect with each other. This is why we care so much, and this is why it looms large in performance discussions. We value the ability to collaborate and to work well within our organization, regardless of how the imperative is encoded. Whether you learn it in Kindergarten or on the job, cooperation matters because it reduces drag.
Employees and managers are cogs in a functioning system; they are not independent agents acting in each other’s (presumed) best interest. Collaborating well in the corporate environment comes down to your ability to identify mutual goals, move quickly through the ‘who does what’ parts, and to use that framework to measure and communicate progress. And it requires you to be nice to your neighbor. For all the explanation, the strategy is basic and easy to employ.
Sadly, another lesson I had to learn the hard way.
Tossing up a few useful links and a few random comments to go along with it.
Taking a left turn for a moment on the software talk.
I’m at a point where I have to vent on a topic, and no better place to do it than to the anonymous reader. For some reason I’ve been in a lot of these lately (usually the presenter or I am needed for some reason; not as the presentee), and I’m at a point where I just have to empty the chamber on the reviews that are failing for lack of experience / guidance on how to do them well.
With this and so many other things in my management career, I am compelled to teach people to avoid the same mistakes that I make / made. With my enthusiasm for developing people is combined a new perspective of "the other side of the table." I understand now what I could not understand before.
I used to be so bad at this. (Maybe I am still not very good at it.) At some point by design or by intervention, a meeting shows up on the calendar titled "business review" or something similar. These are the dreaded "tell me what you think is important enough for me to know" type meetings, they are common in large companies, where high-level managers don’t have great visibility into the daily lives of people in their organizations. I’m in my 11th year of practice, it took me quite a few to figure this stuff out.
I thought I would share my thoughts on what makes a good review. Having seen enough of them go the wrong way, and being on a streak of reviews that have been moderately successful, I can summarize what I believe the formula to be.
Admit to yourself up front that it matters to your career, because it does matter. There’s no shame in wanting your exec reviews to go well, there is no shame in preparing. For most of us, interactions with your manager's manager and their manager are defining moments that are often repeated in your performance review.
Realize that your (executive) cares most about current/future problems and your role in solving them. One of the most common failures of exec reviews is the glorified "status report" where a person recounts recent history, particularly when it feels like a pose-down.
Demonstrate mastery by understanding the most important challenges in your area as your executive understands them. What makes you interesting to them is how you are helping address the larger challenges they face in running the business. There are many pivots here, many pitfalls. Not everything has a bottom-line impact, it's fine if your problems don’t; try not to force the connection. Most executives see through it and check out of those types of discussions. It is worth recognizing that most executives have span of control over much more than the P&L, including operational issues, budget, headcount, IT, etc. Not everything in a business is about bearing new revenue streams.
Know what you want to get from the meeting. Have a point. Steer the conversation to a specific outcome. If you weren’t given a specific question to answer or topic to discuss, then you have been blessed with the gift of trust in setting the agenda yourself. Even if you’re only seeking a nod of approval for your approach to solving problems relevant to your business, knowing that up front makes a huge difference. Not knowing, or (especially in our culture) pestering everybody with questions/statements in the vein of "you scheduled the meeting, what did you want?" questions only shows that you are not enough in command of your subject area to a) predict what is needed, b) structure a meaningful dialog around it. I have said on many occasions where I am the presenter that "My objective for this meeting is to get (X) to say (Y) so that the entire team can hear it." I have structured some exec reviews around my intent to have everyone in the room hear a VP say a specific thing. It is a good idea to be precise about what you want.
Structure the conversation around your progress on these problems and the things that are preventing you from solving them. In the end the formula is simple. A brief introduction, followed by a sequential discussion of key themes / topics, presented in a simple pattern (and ratio):
Unless you’re building circuits or designing aircraft, you can fit all of that information onto a single slide for each topic.
Recite your recent history of achievements. Companies have performance reviews for a reason. Executive reviews are not performance reviews; it is not a time to recount past events. They don’t matter that much to solving present problems. It may also send a signal to your exec that you don’t view those issues as fully resolved (why else would you continue to talk about the past?)
Obsess over the "who owns what" questions (unless you’re talking about org planning). This is great evidence of the degree to which one has matured in their work approach. There is much written about the difference between managers and leaders. Managers obsess over rule-making and ownership. Leaders champion causes. Managers have subordinates. Leaders have followers. Dwelling on ownership (particularly in matrix-heavy organizations) is a pretty good sign that you’re not driving toward a result.
Overload with details; most of them don’t matter. This is related to a point below about how much information you choose to surface during the conversation. The more detail you add the more vectors you create for the conversation to go sideways. To the best that you can, keep the details constrained to those that are necessary to illustrate progress you’ve made, illustrate your plan to complete the rest of the work or to explain where you are blocked. Nothing else matters.
Speak of principles or topics with arbitrary labels. Ambiguity kills, be clear and precise. I was very bad about this one. I’d have super-detailed plans that I couldn’t easily reflect in a bullet point, so I’d give them a vague, cute label and get killed for it during the review. Admittedly I learned this more through teaching it than through doing it. In preparing my leads for meetings with my bosses I found myself asking them "what is that?" when I saw bullet points were I didn’t recognize the work. I kept pressing until a hyperlink to a plan / spec started appearing in its place. This turns out to be a good rule of thumb; if you can’t link to its description it might not be real enough to surface for a conversation. Having to decode concepts in meetings like this is a poor use of time.
Every bullet point in your deck can absorb the entire meeting. Be careful about what bullet points you put there. You have little control over the direction of the conversation, but you do have the power to influence the direction through the topics you raise. Bullet points are topics. Use them carefully and be prepared to defend each one as if it were the only topic on the agenda. Know your business.
Your executive is probably evaluating your long-term potential as they listen to you. The trick is in understanding how you are being evaluated. Rarely is the evaluation about the subject matter; the evaluation is how you explain the subject matter, how well you understand its relationship to broader business challenges or how well you can influence the thinking of people around the table by what you are discussing.
The advice feels a little basic, but it is wise to share the deck with everyone in the meeting before you get there. Know where you have agreement and where you don’t, and know what conversations will surface disagreement. Personally I don’t think it is necessary to avoid conflict in these conversations, most executives I have seen lament the anxiety over people having arguments in front of them. Executives like to be asked for their opinion on topics and to mediate tough topics from time to time. It’s what they are paid to do. I wouldn’t make a habit of starting fights in a forum like this, but it’s ok if everything isn’t perfectly aligned on your way in the door. Where it becomes a problem is when you don’t anticipate those disconnects.
In the end, knowing your business and knowing what you want the outcome of the meeting to look like will guide you to the right meeting agenda most of the time. You could bury yourself in the good advice of how to run a meeting, smelling good, dressing neatly and all that. But in the end this is all advice on how to get clear on your message, and to seek a specific outcome.
It isn’t that hard, right?
</rant>
Zombies coming up the hill to get me? -- the view from my office (via my (not an i-Phone) mobile phone) this foggy morning:
A while back I posted a scanning tool to detect the presense of Custom XML Markup in Open XML documents.
I wanted to provide an update for this tool to reflect the new Open XML SDK 2.0. The scanning tool has been recompiled against the new version of the SDK and should work a little better. Apart from that, I think the tool is the same. I don't think this one is lighting up the hit / download counts on my blog, but I wanted to post the update just in case. The attachment is a ZIP of an MSI. The tool is provided with no support or warranty, as is.
Resurfacing, It has been several months since I last posted. I have spent that time transitioning to a new role in Office sustaining engineering. I am the proud owner of a new title, I changed my office, my boss, my commitments, bought a mini-van and played 30,000 more songs on my Zune. My new team is responsible for Office updates (in many, many different forms.) Comparing this to my prior role, which was more about developer audience management (or "marketing" if you prefer a poorly descriptive shorthand), there are interesting similarities. As an audience manager we typically address problems at a segment level, enabling communities of people to be successful in more or less a programmatic fashion. We learn a lot about communities by engaging their members; you learn a lot in conversation with customers, as I did in engaging Office developers and by engaging executives in our customer briefing center. In my new role there is little difference; we are engaged frequently by our customers with feedback. Some of those discussions are about bugs, some of those discussions are about product changes, some of them are about support policy needs, etc. In the end, both the marketing discussion and the sustaining engineering discussion serve the same end – ensuring our customers have the best experience possible with our products. And it is for this purpose that I re-direct my comments on this blog. The quality of software should improve over time. This is an interesting aspect of our industry which separates us from manufacturing durable goods or textiles, and makes us more like health care or financial services. We are a service, we take pride in the work, and we’re here to ensure that our customers can utilize the service to their maximum advantage. I’m still me, and I reserve the right to point out things, but I probably won’t dedicate too much time to the file format conversation in the future. I'll also confess to not being in love with the look and feel of the new blog. The platform changed while I was away, and I haven't caught up enough to update the site template. I'll get to that soon enough, I care enough about typeface/color/layout to do it in my spare time between diaper changes. I look forward to sharing some of the more interesting tales about providing service to our customers. I am enjoying my new role, I have a great team and a worthy charter.
Resurfacing,
It has been several months since I last posted. I have spent that time transitioning to a new role in Office sustaining engineering. I am the proud owner of a new title, I changed my office, my boss, my commitments, bought a mini-van and played 30,000 more songs on my Zune.
My new team is responsible for Office updates (in many, many different forms.) Comparing this to my prior role, which was more about developer audience management (or "marketing" if you prefer a poorly descriptive shorthand), there are interesting similarities.
As an audience manager we typically address problems at a segment level, enabling communities of people to be successful in more or less a programmatic fashion. We learn a lot about communities by engaging their members; you learn a lot in conversation with customers, as I did in engaging Office developers and by engaging executives in our customer briefing center.
In my new role there is little difference; we are engaged frequently by our customers with feedback. Some of those discussions are about bugs, some of those discussions are about product changes, some of them are about support policy needs, etc. In the end, both the marketing discussion and the sustaining engineering discussion serve the same end – ensuring our customers have the best experience possible with our products.
And it is for this purpose that I re-direct my comments on this blog. The quality of software should improve over time. This is an interesting aspect of our industry which separates us from manufacturing durable goods or textiles, and makes us more like health care or financial services. We are a service, we take pride in the work, and we’re here to ensure that our customers can utilize the service to their maximum advantage.
I’m still me, and I reserve the right to point out things, but I probably won’t dedicate too much time to the file format conversation in the future. I'll also confess to not being in love with the look and feel of the new blog. The platform changed while I was away, and I haven't caught up enough to update the site template. I'll get to that soon enough, I care enough about typeface/color/layout to do it in my spare time between diaper changes.
I look forward to sharing some of the more interesting tales about providing service to our customers. I am enjoying my new role, I have a great team and a worthy charter.