What I learned at Microsoft Part III: Understand the rules

This is a sparring program, similar to the programmed reality of the Matrix. It has the some basic rules, rules like gravity. What you must learn is that these rules are no different that the rules of a computer system. Some of them can be bent. Others can be broken. Understand?
The matrix

The Construct

The transition from developer to program manager was scary.  How would people know that I was doing a good job if I wasn’t writing code or helping customers?!?! The deliverables were changing – they became less tangible and measurable.  The rules were changing – they moved out of the concrete social structure of developers and into the touchy-feely realm of PEOPLE.

Though I do not desire to perpetuate the myth, I have to admit that I was (and perhaps still am) inept at social  interactions… (remember that the why is important).  To complicate matters, I believed that the social part was unimportant because I believed that we were working in a technocracy chartered with using software to improve the condition of the human species (and making money).   So as far as I could tell, selection was driven by the merits of the ideas.  If you consistently came up with good ideas, you were also selected.

In Microsoft Premier Developer Support, customers used a character mode DOS application name “Microsoft Online” or phoned to ask  questions like

  • How do I zoom in or out on a Windows display
    context (DC) that I am rendering within?
  • How do I create an owner draw ok button?
  • How do I kern text in the DC that I am writing
  • How do I do create an owner draw menu?

It was fun.  Initially, I didn’t know the answers to many of these questions.  However, in answering each question, I built up a corpus on knowledge and a catalog of samples that demonstrated each how to use each of the common APIs or how to perform common programming patterns.  For the most part, everyone else in the developer support cube farm had done the same.

My next door work neighbor, Dave had been in the group for a couple of years and he had written Tetris in the original Windows Game Pack.   Dave hated the phone – it slowed him down.  Typically, he would look at the queue of questions that came in from Microsoft Online for topics areas that he was familiar with.  The typical exchange with Dave and customers went something like this

Dave: Hello you’ve reached Microsoft
Customer: How do you select a font for use in drawing to a DC?
Dave: Have you Read The Fine Manual?
Customer: Huh? Yea, but I do not understand how to pick the font I want. It doesn’t seem to return the font that I asked for.
Dave: Ah, well you need read my fine sample.  I’m sending it to you right now.  Thank you and good luck.
Dave (Sotto Voice): On to the next caller.

Dave would send the customer the sample.  Dave explained to the rest of us that customers didn’t want to look stupid to us, they would try to figure out on their own from the sample.  At the same
time, he was able to answer lots of questions everyday by using this approach.  He had more experience and understood the system.  He was answering more than most of the rest of us.  Since our
review system was measuring us on the sheer number of questions answered, he was consistently recognized and rewarded.  The recognition seemed way more important to Dave than the reward (remember why is important).

Shortly after the fall review in September, the way support engineers review metrics were amended.  Customer satisfaction was now a key component in the overall review assessment.  My calls went something like this

Cyra: Hello, welcome to Microsoft
Developer Support, how can I help you?
Customer: I need some help with getting zooming working on a drawing
Cyra: Sure! I can help.  I’m sending you a sample right now.  Let me know when you
have loaded into your editor
(chit chat while downling a small text file at 300 baud)
Customer: Got it.
Cyra: Great.  Open up main.c and scroll
down to the message pump.
Customer: I see it.
Cyra: See how I set the mapping mode to MM_ANISOTROPIC. That allows you to
change the units in the DC that’s rendered.
Customer: Oh, I get it now.
Cyra: What kind of application are you making?
Customer: A Computer Aided Drafting Application – it’s called AutoCad
Cyra: I’ve head of that! That is really cool.  Here’s my phone number <>, give me a call if you have any more
questions.  I’d love to see the application once you’re done.
Customer: Really? That’s great, thanks so much for your help.  I’ll let you know how we do.

During the spring review cycle, I had the highest satisfaction scores.  Dave dismissed my recognition as “customer ass kissing” instead of “technical skill”.  Irrespective of Dave’s assessment, Microsoft
rewarded me with a trip to COMDEX in Las Vegas.  To me this was a big deal.  I grew up in North Philadelphia; I’d visited New York twice, briefly lived in New Jersey and stayed summers in North Carolina a hand full of times.  This was the first time I was making a company trip – so it was a huge reward to me.  The opportunity to go to an event that was the showcase of technical innovation for the industry was a huge treat.

The desert of the real

During the interview process and even into my first few years at Microsoft, I mostly ignored the review process.  Consequently, I ignored the social transactions and rules in play that are part ofthe review process.  I was there to move technology forward for human kind.

Youth, Narcissism and perhaps a little mental illness prevented me from seeing that my manager, Ridge, his manager, Jacim and everyone all the way up to Bill Gates were being reviewed.  Even Bill was essentially reviewed by the board of directors and the stock owners.   Mr. Gates may or may not have cared what the stockholders and board  said, but everyone between us did care and that shaped our behavior accordingly.

Initially my manager was being reviewed on support capacity; the number of questions the team could answer.  As the capacity target was filled, Product Support started to focus on  quality.  As the organization adjusted targets, the managers favored people that helped them to achieve the organization’s goals (an implicitly their goals).  Though this explanation is simplistic and ignores a good deal of social dynamics, it outlines the basic idea that the people around us have professional and personal needs.   It is our ability to help fulfill those needs that grants us value to them and is in fact our social currency.

Over time, recruiting people that help the leadership team fulfill their goals implicitly (whether they know it or not) creates a culture.  My touchy feely behavior to see the Autocad developer successful was playing to my innate curiosity and desire to help/teach people.  In the wake of the quality focus, Ridge hired more people with the desire to help or teach customers.  Fundamentally there was a shift in organization toward more soft skills. I had no real insight into the organizational changes – but I was evolutionarily selected because I was in the right place at the right time.  Not because I had insight and took action or because I was the smartest/most technical.

The modern corporate citizen has to specifically understand what the organization’s goals are – and more importantly what your manager’s  goals are.  After understanding the player’s goals, you then need to understand the rules that they operate by.


Some rules can be bent…

As I’ve said before, the “Why” is important.  The rules matter even if your only hope is not to loose – and naturally rules are extremely important if you hope to win.  Like any system, some rules can be bent, others can be broken – the important skills are to know what you can do with which rules.

Folks that hack know that computers are unforgiving of the errors, they also follow the instructions they are given without variation.  Understanding how the computer executes those instructions may allow one to creatively redirect the behavior of the program or system.  For many developers this is an exciting task – and as long as you are not engaging in a fraudulent activity the risk is low.  Taking that curious ethos into organizations seems like it would be natural for those inclined to hacking – but that has not been my experience.

Microsoft, like any large organization is composed of groups of people.  Those groups of people based on the business goals, the leadership and the recruiting targets forms an ecosystem.  Understanding how that ecosystem works, understand how people are rewarded and promoted are an important part of being successful in it.


Rarely, will a self aware manager be candid with someone they do not know or trust.  These managers have managers and peers that contribute to the annual assessment of that manager.  Typically managers have project, people and personal goals.  Project goals have to do with project delivery. People goals refer to recruiting, growing or managing out of people.  Personal goals are not traditionally written down, but they exist and may or may not be discussed with their manager.  Personal goals might be to get a promotion, to take over a new project area or to save enough money to retire.  So when you work with a manager, you have to recognize that they are balancing (like many of us) a variety of needs (see How We Decide by Jonah Lehrer).

Punching through a wall is not an important super power for managers (although I’ve seen one do it).. reasoning and influence (sometimes called Woo for oldschool softies) are important.  Managers and ICs that are able to reason on their feet, to create a framework that leads a group of people to the decision that is recognized as benefiting the team is highly valued.  Remember that they do not need to come up with the idea – they need to orchestrate the group into coming up with the idea.  Some folks are so good at this, that they can manipulate the group into the outcome they desire by customizing the framework.  One of the best books that describe how to hone these skills is Getting To Yes by Roger Fisher.  Like any good chess player, this requires practice, the ability to read the the other players – but most importantly it requires the ability to think several moves ahead.

The blog Mini-Microsoft provides more details about the review process than I can provide while honoring my MS NDA.  However, there are several diffuse insights that I can offer.

  • There are two review periods during most years.  The annual review happens in September.  Your management team usually reviews the entire team by July so that their results can be rolled up to their management team in August.
  • In each of these meetings, the management team is being accountable to meet their review targets.  Irrespective of how well each individual intrinsically performed, they must be fit to the teams budget performance slots.  Their are a specific number of A’s, B’s, C’s.. and F’s that the managers must assign based on the number of people in their organization.
  • Your managers (and their managers, and their managers…) must eventually sit in a room with their peers to agree where EVERYONE in the organization fits.  Naturally the people at the top and the people at the bottom are the subject of the most conversation.
  • The managers that have the easiest time, have the trust of their peers or have direct reports that have visible results that have value to a large number of people in the room.
  • Because our memories our short, I have advised my directs to meet with my peers.  To understand how we can create deliverables that benefit the broadest base.  I also advise them to ensure that their deliverables arrive immediately prior to the management review meetings.  This means that individual contributors should be have big deliverables well executed in Oct-Nov and June-July so that they have the most significant impact in the review process.

Certainly you could argue, that with enough information about how a game works, one could be inclined to cheat.  In Microsoft especially, there are a lot of smart people.  Most of the time, they will see through people trying to play the system.  Most managers find this practice unsavory.  However, understanding the system and delivering quality results can be amazingly accelerative.

We are the matrix


In most work places, we ignore much of the intangible elements that make someone successful; appearance, vocal tone and speech patterns to name a few.  Frequently we rely on intuition to identify these traits when interacting with our co-workers.  However, there are a set of physical traits that affect how people interact with us.  People can make a trust or competence decisions in 33ms based on the shape of our faces (see the videos from Princeton’s Neuroscience Lab for an exploration of this).  For the most part, there is not a lot that you can do about the way your physical traits influence people.  However you should be aware of default impression that people have of you based on appearance.  In my case, people by default find me intimidating.  I’m tall and stand confidently.  This can distance people – so I have to go to great effort to present a more friendly demeanor when I’m conscious of it.


Distilled down to its essence, trust is the ability to predict the outcome of a person or situation based on historic behavior.   Certainly there is a ton of research that indicates that there are complex biochemistry involved in interpersonal trust.  Spindle Neurons, Pheromones and Oxytocin are some of the players in a more complex dance between experience memory (which is corruptible), emotions and needs which leave you to compute whether or not the coefficient of risk is within your range of comfort.

In your personal life, the possible risks may be so low that you have a higher tolerance (e.g. action -> I can date this dumb but attractive guy for a while, risk->because no one will find out).  In your professional life, these risks can affect your future employment and earning potential (e.g. action-> I rely on Frank to delivery his portion of the project, risk -> he won’t deliver and I won’t be promoted).  Unless one is independently wealthy or feels confident that they could get another job, they may be much more conservative at work than they would be in their personal lives.

In your actions at work, we establish a pattern of behavior.  Over time that pattern of behavior weighs heavily in the minds of peers making trust decisions.  These trust decisions are made when you are hired into a company.  Initially trust is assigned based on your resume and how well your interview answers correlate to your stated experience.  After you work with a team, your managers and your peers consciously and unconsciously review your promises and how many of them you were able to keep.  Over time you establish a brand of trust.

Management Connection

Whether your kiss up to your manager, blow sunshine up her skirt or consistently praise her, smart managers keep tract of your actual delivery and what the people around you say about your delivery.  Especially at Microsoft.  For better or worse, there is organization memory around your trustability.   When you’ve consistently delivered and your management team understands how you make decisions, there is organizational memory of the established pattern of  your behavior (my definition of trust).  Having your management team understand how you make decisions is important.  You help them to understand your process by demonstrating value alignment and by talking out loud with them about your decision making process (this could be its own blog post).

Honestly, this is not very different from how we should understand our personal relationships.  People trust you based on how well you perform in your relationship with them.  Believe it or not, managers are people too.




Leave a Reply

Your email address will not be published. Required fields are marked *