I started at Microsoft on June 13, 1994. Until then, I had been living in Japan, working for Seiko Epson Corporation, in their printer and scanner division. Seiko-Epson is located in Nagano prefecture, the same one where the 1998 Winter Olympics were held. That was about 1hr away from where I lived, which was near a town called Matsumoto. It’s a truly beautiful place. I had been at Seiko Epson just over 2.5 years and had helped release their first color inkjet printer and some scanners. I had a kind of neat job, something like software project management and international communications, since I worked with the various subsidiaries and the development lab in California. I worked in Japanese most of the time (90%), except when I was sending faxes (!) to the subsidiaries and talking on the phone.
A high school friend told me about a position at Microsoft, so I figured I would apply. Microsoft whisked me to Redmond over a weekend for an interview and then I flew back right after. Within 3 days I had an offer, which I refused since the pay was low, and they came back with a better one a couple of days later, which I accepted. So I joined the Excel team in Redmond, working on Japanese (and also Korean and Chinese) versions of Excel. My new manager told me that my mission was to “make Japanese Excel the best product for Japan”. What he didn’t tell me was that I was entering a thorny situation where the parties involved were not particularly open to the idea of helping me.
First, there was the core “US” dev team that took pride in thinking only about the English version of Excel, and scorned all non-English folk (they have reformed since then – no worries). There was the “J-team” which had built the Japanese product in Japan for many years, but they were sort of like sharecroppers – they took the US code every couple of months and ported the changes into their branch of the source, changing things as they saw fit. They could never check their changes into the US source tree. This was highly inefficient of course, but the core US team wouldn’t let the “second rate” Japanese guys touch the “real” source, and the J guys valued their freedom with their own source tree, since they didn’t have to argue with the US devs about what approaches to take. On top of that, I had to work with a tester who started two weeks after I did and knew even less, and a developer who was well, let’s just say “introverted”.
No one else in the US gave a poop about the Asian projects, and in fact even laughed at me when I tried to get support for them. The guys in Japan assumed I was the vanguard of a new team to be formed in Redmond that would make them obsolete, so they tried everything they could to undermine me. And here I was, just thinking I could help.
So, things didn’t go so well for the first few months. In retrospect though, it was a great character building experience. I draw on that time a lot now when I talk to new program managers.
Starting out as a program manager is quite a challenge, particularly straight from college (or University, as we called it in Canada where I’m from). You go from an environment where for the past 18 years you have had your life directed, to one where direction is absent. In school, you have assignments, and projects, and exams. There is a lot of structure, and professors follow certain rules where they promise not to test you on things you have not covered in class. Ahh, bliss.
I have written about program management in general before, but I find the first year the most interesting. The usual pattern goes something like this:
- Start off with excitement and enthusiasm for the new job. Your manager tells you something about taking initiative, being “proactive” and “owning” projects. You say “yeah, of course, gotcha!”.
- About 4 weeks into the job, you start to feel strange. People keep asking you to decide things you don’t know anything about, as if you’re some kind of expert. You find yourself going to your peers for help more often than you feel comfortable with. You start to wonder if you can actually do this. You start to tank. Depending on your personality, you withdraw into your office to try to figure everything out by yourself without bothering anyone, or you start asking a broader range of people how to do things as soon as you hit an obstacle, to try to “spread the pain” and get results quickly.
- By month two, you’re convinced you are the dumbest person on the team by far. Everyone seems so capable, and they can do anything. Your manager says something like “remember, you’re 10% of the team that designs an N Billion dollar product – isn’t that exciting? That means you have to step up and really “own things””. But you know that in fact you are an imposter – Microsoft has misjudged badly in hiring you and you are going to fail.
- By month four, you have lived through a torture of feeling incompetent and a dead weight on your team. It’s especially bad because you were #1 in your graduating class, and everyone always looked to you as the smart one.
- By month six, you have a great moment. Once, in a meeting, you actually knew something that no one else on your team knew. This is the first glimmer. You cling to this, and hope there are more.
- By month 12, you have developed your network of contacts that pass information to you, you are a subject matter expert on your area, and people on the team are relying on you because you know lots of things they don’t know. You have made it.
I’ve been coaching new employees for many years now, and I try to help them through this process. I even tell them they will experience these stages. That actually works for some people to help them avoid it, but a large fraction still go through the stages, and then when I say in month four “Remember I told you that you would feel like this?” they say, “Oh, that’s what you meant!”