January 6, 2010 at 19:59What I Learned at Microsoft
- Transfer
After working for five years in various teams at Microsoft, I learned a few things that I didn’t even know when I graduated from college. The core values that I learned, the lessons learned, the reason for my cry for friends, no matter how you call them, they served me well.
Some of these things are specific to Microsoft, but most will find application in any team / corporate environment. Some of them are complicated - because of them they can fire you (or maybe worse) if you don’t know what you are doing.
Any sufficiently large institution has something to lose. Creditworthiness, money, power, whatever. Therefore, any request for something new and risky occurs with caution. Whether it’s a new proposal or a project, it’s safer to say “No”. Corporations are optimized to say no. Maintaining the status quo. There is no risk of failure and spectacular collapse.
For this very reason, it is better to go and do something without asking permission. After all, if you do not ask, no one will forbid. Have an interesting idea for a side project? Go encode her. If you ask someone first, you might be told, “Consult Team X, Y, and Vice President Z,” and then you will come across an endless spiral. Want to blog about what's bothering you? Go write.
However, you must understand what you are doing. Do not do something obviously stupid. Want to write about an unannounced feature X? Bad idea. You commit the code without warning anyone? A very bad idea. Are you writing an angry letter to the wrong vice president? Maybe (but usually not such a bad idea). As with any risks, there is a downside.
This does not work all the time. You will fail, sometimes shamefully. But this is normal (see the following heading for an explanation of why). In fact, if you don’t squint from time to time, you are probably doing something wrong.
Conclusion: If your failure can affect others, it is better to warn them in advance.
So, you broke off and made yourself a fool. Maybe the executive director yelled at you. Your demonstration failed dramatically in front of thousands of people. After you edited the code, the site went down.
It turns out that this is normal. Although at that moment it may not seem, but in fact, this is expected. If you don’t break off, you don’t try enough. It annoys me a lot when someone works only on trifles. What are the chances that it will be useful in five years? Usually none.
An even greater danger of working with small jambs? It makes people cautious. If your employees are afraid to break something, they will get stuck in place and won't learn anything new. Nobody will benefit from this - they will not "grow", and you will not get the maximum from them.
It is difficult to achieve Zen by avoiding public error. Try talking to me if my performance went badly - usually I want to fall underground. But after some time, you learn to distinguish between things that should not worry you and things that you really need to worry about.
Conclusion No. 1: If you have to work in an environment / team where everyone is afraid to make the slightest mistake and tiptoes around - better off! The same is worth doing if your manager puts your petty misconduct in a personal profile.
Conclusion No. 2: If you have committed an offense, admit it openly. They sent the letter "I messed up here." Accept the accusations and move on instead of trying to hide it.
I stole the idea from Jay . When you work in a team, the respect and trust of your subordinates is imperative. An easy way to measure this is to look at the people who are looking for you. If people are not looking for you all the time - be it problems, ideas, or something that they need from you, then something is wrong here.
The downside is that you must be constantly involved. Whether you are a developer or not, you must be on all team alert and mailing lists. You should try all the latest day builds. You must be involved.
If you do not turn on or turn your back on people who are looking for you, do not expect to be invited when key decisions are made.
If you have technical work, you must look into the code. You should not be able to write or debug it, but you should have the basic skills of a programmer. Synchronize the sources and start compilation. If you can’t understand how, ask around (and find out about the development team in the process). See daily commits. In good times, commits will go constantly. In difficult times, commits will be rare and skinny.
I observed a myriad of negotiations and meetings that could have been avoided by looking at the code for 30 seconds. There is absolutely no substitute for knowing how the product works (and architecture diagrams won't help here). If you know how the debugger works, put a couple of breakpoints and understand how the different parts fit together.
If there are no other problems, your developers will take you much more seriously.
Every time I hear the term “team player,” I recall this post. The expression "team play" is often misinterpreted as meaning obedience, predictability and, in general, lack of initiative. In other words, everything that you don’t do if you are a hacker.
It sounds tempting to lock yourself in and code something and then show the finished product. Ignore flies, letters, and the red tape of routine boring work.
Do not do that. Perhaps do not do this all the time.
Hacking is a creative process. There will be a weekend spent on the code. Although, if this is your usual mode of operation, you will cause a lot of suffering to your team. If they don’t know how far you are from “done”, they won’t be able to understand how much they need to worry or how much time they need to leave in contingency plans.
Take some time to walk around the offices. Come and find out what people are talking about. Talk about what you do. In the end, it gives them a comfortable feeling that you are doing something instead of reading Habrahabr endlessly (in the original “Hacker News” - approx. Trans.). After some time (acceptable time), you will get enough trust so that people can rely on what you do on time.
I have often seen stagnation in many good people. You start to notice this when they start saying, “This new thing X is the same as Y twenty years ago, so I won’t even try.” Our industry is such that it changes dramatically every few years. The worst thing to allow is to not be in the know and let yourself fade.
This does not mean that you must be present in every new social network and have dozens of installed programs for the iPhone. But you have to "play" with what is popular. Deliver a new popular programming language, web framework, browser plug-in, whatever.
“No time” is no excuse. What has always impressed me at Bill Gates and Ray Ozzy is how much they play with the technique of both their own company and others. If they can find the time, you can even more so.
In addition to simple fun with the technique, watch how others use it. You can learn a lot by simply hanging out in the laptop department in Eldorado (in the original “Costco” - approx. Per.) Or by watching people chatting in cell phone stores (in the original “AT&T store” - approx. Per.). Ray Ozzy talks about how each time he gets into a new city or country, he travels by public transport to watch how people use things. Try to understand what normal people are trying to get from technology.
The teams that bend into Microsoft are those that don't try to keep up to date. The signal for this is that all team members have been working on one thing for a decade. This is almost always a sure sign that you need new blood to shake your thinking. Of course, as with any rule, there are exceptions.
Each time I decide to switch to something else, first I look for people with whom I would like to work (that's how I typed my current team). This is very different from the way I started, having the habit of taking the team of the coolest product I could think of.
You quickly learn that in the long run, the way you get along with people in your team significantly affects how happy you are. Cool technologies fade away, change and become old. At the same time, the relationships that you managed to build with excellent team members last for many long years.
What type of people to recruit? I tend to take the following types of people into teams: disrespectful, rebel, problem-makers. What suits you, decide for yourself.
I strongly believe that the only way to develop is to do things outside your comfort zone. Whether it’s people, places, programming languages or your job, try and do something that you haven’t done before.
For example, I always felt uncomfortable in bars and clubs. I was looking for all kinds of excuses to avoid sorties with colleagues. Finally, I decided that the only way to feel comfortable in such a situation is to take and go. I forced myself to go out for several years and now I am normal, like everyone else.
The same thing happens with technology. Write the code in a new language, try a new search engine or switch to a new browser. Try to do other work for a short while. At Microsoft, it's simple enough to become a part-time program manager or developer — people love the help you can give them. Benefit from this.
Each of us attended meetings / presentations where you were confused, had questions, or simply did not understand the topic of conversation. Sometimes you see that everyone in the room bypasses a sensitive topic.
This is due to the desire to be suitable, not to look stupid in front of your colleagues and bosses. You know? Most often they are in the same boat as you. The principle of the thumb, which seems reliable in this situation, is that the smartest person in the room will be the first to say “I don’t know.”
Inconvenient questions are tricky. Some issues are not taboo for a reason (legal issues are a good example). Recognize them and move on. Most often, you will achieve more productive negotiations by raising the usual question that everyone avoids.
Every large organization has a lot of interesting people. This is statistically obvious. People who create interesting things, people who have spent enough time here to become wise, people who are interested in their eccentric behavior, the list goes on.
Go and get to know each of them. Find out what they are working on. Ask them to tell you a story about the “good old days.” Let them grumble about the things they now hate. Learn from them.
No one will refuse to meet over dinner or a cup of coffee. They can resist, but most will succumb. If this does not help, drop by their office and say “Hello.” If you work at Microsoft or Google, meet superstars - meet Dave Cutlers, Patrick Dassad, Dave Campbell, Rob Pike, Ken Thompson.
To criticize someone’s idea in public never prevents. This is expected. However, what should not be done is to criticize the person himself in public. Dissatisfied with someone else's approach or performance? Have a conversation behind closed doors. This is especially important if a person stands below you on the corporate ladder. Advantages in power will not allow them to answer you.
On the other hand, praise is always what should be done in public. Unfortunately, people often underestimate the effect of recognizing a person for what he has done. A short letter will go a long way making everyone happy.
A lot of people are waiting for the "system" to take care of them. Especially if you spent your whole life at school and university, where your assessment is justified and rational.
In teams / companies this is often not the case. What little feature will you add in the next release? You have to go and tell everyone how cool she is. Would you like to thank you for your work on massively increasing product productivity? Make sure the right people know what exactly you did.
This surprises many hackers. Shouldn't the “system” automatically take care of such mundane things as announcing thanks or evaluating how good something is? The problem is that the “system”, as a rule, is a bunch of smart, well-intentioned, overworked people who usually do not have enough data about everything that happens in a team. If you don’t make an effort to get the necessary input (and it can be as easy as knocking on their door and say “Take a look what I did”), do not be surprised if things go wrong in your favor.
The most important lesson of all these is not to be an asshole. Many smart people tend to develop a crude, antagonistic behavior pattern. Sometimes they are morons by nature. And sometimes they see this behavior manifesting itself in people with whom they work and who they admire (this often happened at Microsoft 10-15 years ago).
Some hackers interfere with bad manners with directness and rudeness. Do not do this - there is a whole world of differences between these two things. You can be rude, call someone a bitch and not be obscene. In fact, some people whom I admire quite often can call someone without raising their voices or even making another person feel bad.
If you are a jerk, it will not only make people hate you, it will also have a social effect. Just one person showing bad behavior is enough to spread it.
Be considerate.
Conclusion: Do not confuse “being tactful” and “being politically correct” or “being passively aggressive”. Being passively aggressive and overly politically correct is equally bad. The main thing is to criticize someone’s work or ideas without personally criticizing the person.
This, however, is hard enough to do.
UPD: Corrected some stylistic and grammatical errors in the text.
Some of these things are specific to Microsoft, but most will find application in any team / corporate environment. Some of them are complicated - because of them they can fire you (or maybe worse) if you don’t know what you are doing.
Sorry, not permission
Any sufficiently large institution has something to lose. Creditworthiness, money, power, whatever. Therefore, any request for something new and risky occurs with caution. Whether it’s a new proposal or a project, it’s safer to say “No”. Corporations are optimized to say no. Maintaining the status quo. There is no risk of failure and spectacular collapse.
For this very reason, it is better to go and do something without asking permission. After all, if you do not ask, no one will forbid. Have an interesting idea for a side project? Go encode her. If you ask someone first, you might be told, “Consult Team X, Y, and Vice President Z,” and then you will come across an endless spiral. Want to blog about what's bothering you? Go write.
However, you must understand what you are doing. Do not do something obviously stupid. Want to write about an unannounced feature X? Bad idea. You commit the code without warning anyone? A very bad idea. Are you writing an angry letter to the wrong vice president? Maybe (but usually not such a bad idea). As with any risks, there is a downside.
This does not work all the time. You will fail, sometimes shamefully. But this is normal (see the following heading for an explanation of why). In fact, if you don’t squint from time to time, you are probably doing something wrong.
Conclusion: If your failure can affect others, it is better to warn them in advance.
(Usually) Weeds are okay
So, you broke off and made yourself a fool. Maybe the executive director yelled at you. Your demonstration failed dramatically in front of thousands of people. After you edited the code, the site went down.
It turns out that this is normal. Although at that moment it may not seem, but in fact, this is expected. If you don’t break off, you don’t try enough. It annoys me a lot when someone works only on trifles. What are the chances that it will be useful in five years? Usually none.
An even greater danger of working with small jambs? It makes people cautious. If your employees are afraid to break something, they will get stuck in place and won't learn anything new. Nobody will benefit from this - they will not "grow", and you will not get the maximum from them.
It is difficult to achieve Zen by avoiding public error. Try talking to me if my performance went badly - usually I want to fall underground. But after some time, you learn to distinguish between things that should not worry you and things that you really need to worry about.
Conclusion No. 1: If you have to work in an environment / team where everyone is afraid to make the slightest mistake and tiptoes around - better off! The same is worth doing if your manager puts your petty misconduct in a personal profile.
Conclusion No. 2: If you have committed an offense, admit it openly. They sent the letter "I messed up here." Accept the accusations and move on instead of trying to hide it.
Look at the line in front of your door
I stole the idea from Jay . When you work in a team, the respect and trust of your subordinates is imperative. An easy way to measure this is to look at the people who are looking for you. If people are not looking for you all the time - be it problems, ideas, or something that they need from you, then something is wrong here.
The downside is that you must be constantly involved. Whether you are a developer or not, you must be on all team alert and mailing lists. You should try all the latest day builds. You must be involved.
If you do not turn on or turn your back on people who are looking for you, do not expect to be invited when key decisions are made.
Code led
If you have technical work, you must look into the code. You should not be able to write or debug it, but you should have the basic skills of a programmer. Synchronize the sources and start compilation. If you can’t understand how, ask around (and find out about the development team in the process). See daily commits. In good times, commits will go constantly. In difficult times, commits will be rare and skinny.
I observed a myriad of negotiations and meetings that could have been avoided by looking at the code for 30 seconds. There is absolutely no substitute for knowing how the product works (and architecture diagrams won't help here). If you know how the debugger works, put a couple of breakpoints and understand how the different parts fit together.
If there are no other problems, your developers will take you much more seriously.
Lone wolf syndrome
Every time I hear the term “team player,” I recall this post. The expression "team play" is often misinterpreted as meaning obedience, predictability and, in general, lack of initiative. In other words, everything that you don’t do if you are a hacker.
It sounds tempting to lock yourself in and code something and then show the finished product. Ignore flies, letters, and the red tape of routine boring work.
Do not do that. Perhaps do not do this all the time.
Hacking is a creative process. There will be a weekend spent on the code. Although, if this is your usual mode of operation, you will cause a lot of suffering to your team. If they don’t know how far you are from “done”, they won’t be able to understand how much they need to worry or how much time they need to leave in contingency plans.
Take some time to walk around the offices. Come and find out what people are talking about. Talk about what you do. In the end, it gives them a comfortable feeling that you are doing something instead of reading Habrahabr endlessly (in the original “Hacker News” - approx. Trans.). After some time (acceptable time), you will get enough trust so that people can rely on what you do on time.
Try new
I have often seen stagnation in many good people. You start to notice this when they start saying, “This new thing X is the same as Y twenty years ago, so I won’t even try.” Our industry is such that it changes dramatically every few years. The worst thing to allow is to not be in the know and let yourself fade.
This does not mean that you must be present in every new social network and have dozens of installed programs for the iPhone. But you have to "play" with what is popular. Deliver a new popular programming language, web framework, browser plug-in, whatever.
“No time” is no excuse. What has always impressed me at Bill Gates and Ray Ozzy is how much they play with the technique of both their own company and others. If they can find the time, you can even more so.
In addition to simple fun with the technique, watch how others use it. You can learn a lot by simply hanging out in the laptop department in Eldorado (in the original “Costco” - approx. Per.) Or by watching people chatting in cell phone stores (in the original “AT&T store” - approx. Per.). Ray Ozzy talks about how each time he gets into a new city or country, he travels by public transport to watch how people use things. Try to understand what normal people are trying to get from technology.
The teams that bend into Microsoft are those that don't try to keep up to date. The signal for this is that all team members have been working on one thing for a decade. This is almost always a sure sign that you need new blood to shake your thinking. Of course, as with any rule, there are exceptions.
New team? Recruit people, not products
Each time I decide to switch to something else, first I look for people with whom I would like to work (that's how I typed my current team). This is very different from the way I started, having the habit of taking the team of the coolest product I could think of.
You quickly learn that in the long run, the way you get along with people in your team significantly affects how happy you are. Cool technologies fade away, change and become old. At the same time, the relationships that you managed to build with excellent team members last for many long years.
What type of people to recruit? I tend to take the following types of people into teams: disrespectful, rebel, problem-makers. What suits you, decide for yourself.
Leave the comfort zone
I strongly believe that the only way to develop is to do things outside your comfort zone. Whether it’s people, places, programming languages or your job, try and do something that you haven’t done before.
For example, I always felt uncomfortable in bars and clubs. I was looking for all kinds of excuses to avoid sorties with colleagues. Finally, I decided that the only way to feel comfortable in such a situation is to take and go. I forced myself to go out for several years and now I am normal, like everyone else.
The same thing happens with technology. Write the code in a new language, try a new search engine or switch to a new browser. Try to do other work for a short while. At Microsoft, it's simple enough to become a part-time program manager or developer — people love the help you can give them. Benefit from this.
Ask uncomfortable questions
Each of us attended meetings / presentations where you were confused, had questions, or simply did not understand the topic of conversation. Sometimes you see that everyone in the room bypasses a sensitive topic.
This is due to the desire to be suitable, not to look stupid in front of your colleagues and bosses. You know? Most often they are in the same boat as you. The principle of the thumb, which seems reliable in this situation, is that the smartest person in the room will be the first to say “I don’t know.”
Inconvenient questions are tricky. Some issues are not taboo for a reason (legal issues are a good example). Recognize them and move on. Most often, you will achieve more productive negotiations by raising the usual question that everyone avoids.
Go say hi!
Every large organization has a lot of interesting people. This is statistically obvious. People who create interesting things, people who have spent enough time here to become wise, people who are interested in their eccentric behavior, the list goes on.
Go and get to know each of them. Find out what they are working on. Ask them to tell you a story about the “good old days.” Let them grumble about the things they now hate. Learn from them.
No one will refuse to meet over dinner or a cup of coffee. They can resist, but most will succumb. If this does not help, drop by their office and say “Hello.” If you work at Microsoft or Google, meet superstars - meet Dave Cutlers, Patrick Dassad, Dave Campbell, Rob Pike, Ken Thompson.
Praise in public, punish behind closed doors
To criticize someone’s idea in public never prevents. This is expected. However, what should not be done is to criticize the person himself in public. Dissatisfied with someone else's approach or performance? Have a conversation behind closed doors. This is especially important if a person stands below you on the corporate ladder. Advantages in power will not allow them to answer you.
On the other hand, praise is always what should be done in public. Unfortunately, people often underestimate the effect of recognizing a person for what he has done. A short letter will go a long way making everyone happy.
The best things are taken, not given
A lot of people are waiting for the "system" to take care of them. Especially if you spent your whole life at school and university, where your assessment is justified and rational.
In teams / companies this is often not the case. What little feature will you add in the next release? You have to go and tell everyone how cool she is. Would you like to thank you for your work on massively increasing product productivity? Make sure the right people know what exactly you did.
This surprises many hackers. Shouldn't the “system” automatically take care of such mundane things as announcing thanks or evaluating how good something is? The problem is that the “system”, as a rule, is a bunch of smart, well-intentioned, overworked people who usually do not have enough data about everything that happens in a team. If you don’t make an effort to get the necessary input (and it can be as easy as knocking on their door and say “Take a look what I did”), do not be surprised if things go wrong in your favor.
Don't be an asshole
The most important lesson of all these is not to be an asshole. Many smart people tend to develop a crude, antagonistic behavior pattern. Sometimes they are morons by nature. And sometimes they see this behavior manifesting itself in people with whom they work and who they admire (this often happened at Microsoft 10-15 years ago).
Some hackers interfere with bad manners with directness and rudeness. Do not do this - there is a whole world of differences between these two things. You can be rude, call someone a bitch and not be obscene. In fact, some people whom I admire quite often can call someone without raising their voices or even making another person feel bad.
If you are a jerk, it will not only make people hate you, it will also have a social effect. Just one person showing bad behavior is enough to spread it.
Be considerate.
Conclusion: Do not confuse “being tactful” and “being politically correct” or “being passively aggressive”. Being passively aggressive and overly politically correct is equally bad. The main thing is to criticize someone’s work or ideas without personally criticizing the person.
This, however, is hard enough to do.
UPD: Corrected some stylistic and grammatical errors in the text.