What I learned in Microsoft

Having worked for five years in various teams at Microsoft, I made a few things that I didn’t even suspect when I graduated from college. The core values, what I learned, the lessons learned, the reason for my shouting at friends, whatever you call them, they served me well.

Some of these things are specific to Microsoft, but most will find use in any command / corporate environment. Some of them are difficult - because of them you can be fired (and maybe worse) if you do not know what you are doing.

Ask for forgiveness, not permission

Any large enough institution has something to lose. Credibility, money, power, whatever. Therefore, any request for something new and risky is met 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 crash.
')
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 ban. An interesting idea for a side project? Go encode it. If you ask someone first, you may be told “Consult with team X, Y and vice president Z,” and then you will run into an endless spiral. Want to write a 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. Committing code without warning anyone? Very bad idea. Are you writing an angry letter to the vice president? Perhaps (but usually not such a bad idea). As with any risks, there is a downside.

It does not work all the time. You will fail, sometimes shamefully. But this is normal (see the next heading for why). In fact, if you do not mess up from time to time, probably something you do wrong.

Conclusion: If your failure can affect others, it is better to warn them in advance.

(Usually) Weeds is normal

So you broke off and made a fool of yourself. Perhaps the executive director yelled at you. Your demonstration has failed dramatically in front of thousands of people. After you edit the code went to the site.

It turns out that this is normal. Although at that moment may not seem, but in fact, it is expected. If you do not break off, you do not try enough. It really annoys me when someone only works on trifles. What are the chances that it will be useful in five years? Usually none.

An even greater danger of working with small shoals? It makes people cautious. If your employees are afraid to break something, they will be stuck in place and will not learn anything new. No one 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 errors. Try to talk to me, if my performance has gone bad - I usually want to fall underground. But after a while you learn to distinguish between things that should not worry you and things that you really should worry about.

Conclusion number 1: If you have to work in an environment / team where everyone is afraid to make the slightest mistake and tiptoe around - better get out! The same should be done if your manager puts your minor offenses into a personal characteristic.

Conclusion number 2: If you have committed a misdemeanor, admit it openly. They sent a letter "I'm here nakosyachil." Accept the charges 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. A simple way to measure this is to look at people who are looking for you. If people don’t look for you all the time, be it a problem, an idea, or something that they need from you, then something is wrong.

The flip side - you have to be involved constantly. Whether you are a developer or not, you must be on all commit and mailing lists on the team. You should try all the freshest daily builds. You should be involved.

If you do not turn on or turn your back on the people who are looking for you, do not expect to be invited when key decisions are made.

Code led

If you have a technical job, you must look into the code. You should not be able to write or debug it, but you should have basic programming skills. Synchronize the source and start the compilation. If you can’t understand how, ask around (and in the process learn about the development team). Check out daily commits. In good times, commits will go all the time. In hard times, commits will be rare and skinny.

I watched a myriad of talks and meetings that could have been avoided by glancing at the code for 30 seconds. There is absolutely no substitute for knowing how the product works (and architecture diagrams will not help here). If you know how the debugger works, put a couple of breakpoints and understand how the various parts fit together.

If there are no other problems, your developers will treat you much more seriously.

Lone wolf syndrome

Every time I hear the term "team player", I remember this post. The expression “team play” is often misunderstood 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 and code something and then show the finished product. Ignore the letters, letters and red tape of the usual boring work.

Do not do that. Perhaps don't do it all the time.

Hacking is a creative process. There will definitely be weekends spent behind the code. Although, if this is your usual mode of operation, you will cause a lot of suffering to your team. If they do not know how far you are from “done,” they will not be able to figure out how much they should worry or how much time they need to leave in contingency plans.

Take some time to walk through the offices. Come in 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 endlessly reading Habrahabr (in the original Hacker News). After a while (acceptable time), you will gain enough confidence 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 it 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 is thoroughly changed every few years. The worst thing you can do is not being aware and letting yourself fade.

This does not mean that you must be present in each new social network and have dozens of established programs for the iPhone. But you have to "play" with what is popular. Put a new popular programming language, web framework, browser plugin, whatever.

“No time” is no excuse. What has always impressed me in Bill Gates and Ray Ozzie is how much they play with the technique of their own company as well as others. If they can find time, you can all the more.

In addition to simple fun with technology, watch how others use it. You can learn a lot just hanging out in the notebook department in Eldorado Ray Ozzie says that every time you get to a new city or country, you drive through public transport to watch how people use things. Try to understand what normal people are trying to get from technology.

The teams that are bent at Microsoft are those that are not trying to be in the know. Signal of this - 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 and not products

Every time I decide to switch to something else, I first look for people I would like to work with (this is how I typed my current team). This is very different from how I started, having the habit of taking the command of the coolest product I could think of.

Quickly you learn that in the long run, how you get along with people in your team has a greater effect on how happy you are. Cool technologies fade away, change and become old. At the same time, the relationship that you managed to build with excellent team members lasts for many long years.

What type of people to recruit? I tend to take in teams of the following types of people - disrespectful, insurgents who create problems. What suits you, decide for yourself.

Leave the comfort zone

I strongly believe that the only way to grow is to do things outside of your comfort zone. Be it people, places, programming languages ​​or your work - try and do something you haven't done before.

For example, I always felt uncomfortable in bars and clubs. I looked for all sorts of excuses just to avoid a sortie with my colleagues. Finally, I decided that the only way to feel comfortable in this situation is to take it and go. I forced myself to go out for a few 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 briefly to do another job. At Microsoft, simply becoming a part-time program manager or part-time developer - people love the help you can give them. Benefit from it.

Ask uncomfortable questions

Each of us has been to 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 avoids a sensitive topic.

This is due to the desire to be suitable, not to look stupid in front of their colleagues and bosses. You know? Most often they are in the same boat as you. The principle of the thumb, which seems reliable to me in this situation, is that the smartest in the room will be the first to say “I don't know.”

Inconvenient questions tricky. Some questions are taboo for a reason (a good example is legal issues). Recognize them and move on. Most often, you will achieve more productive negotiations by asking the usual question that everyone avoids.

Go say hello!

Every large organization has a lot of interesting people. This is statistically obvious. People who have created 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 meet 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 refuses to meet over lunch or a cup of coffee. They may resist, but most will succumb. If this does not help, look at their office and say "Hi." If you work at Microsoft or Google, meet superstars - meet Dave Cutler, Patrick Dassadah, Dave Campbell, Robi Pike, Ken Thompson.

Praise in public, punish behind closed doors

Criticizing 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's approach or performance? Hold a conversation behind closed doors. This is especially important if the person is below you on the corporate ladder. Benefits in power will not allow them to answer you.

On the other hand, praise is always something that should be done in public. Unfortunately, people often underestimate the effect of recognizing a person for what he did. 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 reasonable and rational.

In teams / companies this is very often not the case. What little feature will you add to the next release? You have to go and tell everyone how cool she is. Want to thank you for your work on a massive increase in product performance? Make it so that the right people know what you did.

This surprises many hackers. Shouldn't a “system” automatically take care of such mundane things as a declaration of thanks or an assessment of how good something is? The problem is that the “system”, as a rule, is a bunch of smart, well-intentioned, overworked people who usually have not enough information about everything happening in a team. If you don’t make efforts to get the necessary input data (and it can be as easy as knocking on their door and saying “Look what I did”), don’t be surprised if things go wrong for you.

Don't be an asshole

The most important lesson of all of them - do not be an asshole. Many smart people tend to develop a rude, antagonistic pattern of behavior. Sometimes they are assholes by nature. And sometimes they see this behavior manifested in people with whom they work and 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. One person who demonstrates bad behavior is enough to spread.

Be tactful.

Conclusion: Do not confuse "being tactful" and "being politically correct" or "being passive-aggressive." Being passive-aggressive and over-politically correct is equally bad. The main thing is to criticize someone's work or ideas without criticizing a person personally.

This, however, is hard enough to do.

UPD: Corrected some stylistic and grammatical errors in the text.