Friday marked my 5th anniversary at Microsoft! In those 5 years I've had the opportunity to have three distinct careers. I spent 1.5 years as an individual Developer in Test, 2 years as a Dev in Test Lead, and the last 1.5 years as a Program Manager. All very different jobs working within the same organization.
I'd like to think I've learned a few things in the last five years so I decided to write down five tips to getting things done at Microsoft. These might not be everyone’s top five tips and I can't say I've always lived by them in the past, but hindsight is 20/20 they say. This is simply what came to mind this morning when I was reflecting on the subject preparing to mentor a new hire on our team. Welcome aboard Joe!
1. Remember to ignore your e-mail.
We love e-mail here. If you are successful then you'll get copied on more an more mails over time because you own something important or your opinions are well respected. Its good to be respected, but if you don't watch out you could spend hours each day reading and replying to e-mails. You'll quickly discover that you have turned into a modern day paper pusher without any time to accomplish anything worthwhile.
I've tried several schemes designed to reduce "inbox clutter", but there is one common theme between them all and the theme is that you have to be able to ignore your e-mail from time to time. I personally rely on outlook as my information repository, but I work with it during the day in "offline" mode so I don't get distracted by new mails. I keep e-mail hours from 8-10 and 4-5 every day.
Even when I have outlook "online" I make sure that all its little icons, noises, and toast notifications are switched off. Don't become a slave to outlook. You'll be amazed to find out that several threads resolve themselves without your input just fine and that the "urgent" requests where not really that urgent... if they were then they would have hoofed it to your office.
2. Manage your manager.
In five years I've had three different managers and I've been a manager to boot. Your career is in your own hands and your manager is there to help, but they will be MUCH more effective at helping you if you give them regular feedback.
How do you like to be recognized/rewarded? Maybe free espresso isn't your cup of tea. What do you want to be when you grow up? Good managers will look for opportunities for you to grow the skills necessary to make that happen. What sort of work are you good at and you enjoy doing? Good managers will make sure you spend as much of your time as possible doing the work you enjoy. What changes in process/tools/design do you and your team need to be more successful? Make sure your manager knows this. What do you believe are your key strengths? Do you get to leverage them regularly? Do you know what success in your role/projects looks like? Are you enjoying the work you do?
Good managers will ask these questions often and make sure they get this information from you, but you can't count on every manager to listen as effectivly... so you have to speak up and make sure your manager knows how you'd like to be managed. Part of managing your manager may involve having conversations with your managers manager on a regular basis. Let them know how your manager could be improving if you are uncomfortable bringing up these things with your manager. This isn't being a tattle-tale... this is making sure you are looking out for the best interests of your career if you don't believe your manager is capable of helping you or making sure you are set up to be successful.
3. Ignore artificial boundaries
Discipline boundaries should be mostly ignored. You may be a developer, but do you know what the test team is doing with your code? You may be a tester, but do you know what the product code looks like? If you’re a program manager are you capable of running a product test suite on your machine or writing some of the product code yourself?
How can you effectively work with the rest of your team if you don't know what it takes for your team mates to be successful, what they are goaled on, and what its like to be them? You don't have to be the best tester if you are a developer, but you should be able to get your hands dirty testing other people's code and know how to pitch in when it becomes necessary to help ship the product.
Consider team boundaries irrelevant as well. If you work at Microsoft you likely have some dependencies on other teams. What are you doing to make the other team more successful so your customers can benefit? Read their specs, give them feedback, log bugs against their code, ask for access to the code to their projects, make sure you read their status mails and push back appropriately on decisions they make when it’s important for the success of your customers.
Remember that you are there to make them more successful so that you can be successful. You should have access to the other teams bug database; you should understand their schedule, goals, and priorities. Is the work you need from them correctly prioritized? Does the team have other clients?
You will get pushback when you cross boundaries, but most boundaries are not as important as satisfying your customers with the right product delivered at the right time. There are always shared goals… if nothing else you always have the stock price in common and a goal of moving it in the right direction.
4. Do something great that no one asked you to do
Sometimes you’ll look around and realize that no one is going to step up and deliver the thing you or your team needs to be successful for you. Time to do it yourself. Turn off your e-mail, open up Visual Studio and start building what you, your team, your customers, and your company needs to be successful because you know you’re right. There are a ton of examples of projects that started this way at Microsoft, but those are subjects for separate blog posts. Don’t just get it functional; build yourself a purple cow and get it in front of people.
5. Talk to customers early and often
Your customers are looking out for your bottom line! Help them help you. It sounds strange, but what they need is software that makes them more successful at whatever they are doing. They want you to build better software because it will help them. If you build better software you will sell more of it. It’s a wonderful cycle when it works, but you need to start the conversations and you need to listen.
Its not someone else’s job to have regular conversations with customers, answer their questions about your software, and make sure that the work you are doing will actually make them more successful… its everyone’s job. I don’t care if you are working on some top secret project that is so hush hush you can’t talk to other Microsoft employees about… get yourself some top secret customers. This goes back to point #3. Cross the boundary and start listening to customers before you write your first line of code or your first test case.
Bonus Tip #6: Remember the M&M's
Nothing like junk food as a good "pick me up" for your team. Celebrate your anniversaries at Microsoft by making sure to feed your team with healthy amounts of chocolate, Krispy Creams, and M&Ms. In that spirit... if you are at Microsoft today and near building 41 stop by my office to get your hands on some of the 5+ lbs of oatmeal, peanut butter, and M&M cookies sitting outside. Enjoy!