15 Rules
It has been a few years since I published my last article on LinkedIn. Then, as now, I was inspired by reaching a career goal. This year I achieved the title of Partner at Microsoft. "Partner" is an overloaded term at Microsoft. We also use it to refer to ISVs and, as it happens, a big part of my job is working with ISVs. So I am a Partner that works with partners now? Anyway, I have been telling people that this promotion has been the most anticlimactic achievement of my life. Indeed, I worked crazy hard for it and things just don't feel much different now that the moment has arrived. But I said I was inspired. How so? Well a few people I work with reminded me that the title is a good indication that I probably have some smart things to say, so I thought maybe I'll use the event as a forcing function to write a bit. But okay. I'll keep the remaining preamble short; I promise. ??
Back in grad school, I wrote a paper on Godaddy.com and its founder Bob Parsons. Mr. Parsons had a list he called his 16 Rules for Success. There were a few in there that have stuck with me today. I especially love: "Pay attention to your competitors, but pay more attention to what you’re doing." I often draw from this rule, especially when competitive pressure from the other clouds makes it hard to focus. It's obviously good to understand what competitors are doing, but it's actually more important to have your own plan, be convicted about it and execute against it with excellence. There are a few other good ones in Bob's list and, given that it has stuck with me for so long, I thought I'd build a list of my own. 15 things that I have learned myself, and from mentors, over 15 years at Microsoft. Of course, they're not proper rules – they're guidelines, tips, etc. And now I will avoid further bloviation and jump right to the list. Enjoy! ??
1. Your challenge is not to run away from the hard conversations, but to run towards them.
I learned this one at a Microsoft boot camp held for new leaders with the moniker "executive" in their title. It has been at the top of my list for about a decade now since I heard it. The more responsibility one takes on, the more pressure increases. And some of the toughest problems must be overcome via some of the toughest conversations. When that feeling creeps up trying to convince me to run - it's a good prompt to indeed run towards, rather than away. (hat tip, Alistair Lowe-Norris)
2. Do not act based on what you want to be true, but always based on what you know to be true.
This was a great piece of advice that I received when I was trying to have someone on the team fill a role we desperately needed filled. I hoped the person would be a good fit, but my manager pointed out that I was acting based on what I wanted to be true; not based on what I knew to be true. It was a flaw in my management instincts that needed to be improved. The advice rang so true in that moment, it has been stuck in my head since. When a decision makes me uncomfortable, I often wonder if it is because I am acting based on something I wish to be true, but upon greater introspection realize I actually know a different reality. Hope is fine for inspiration, but not for business decisions. (h/t Matt Kerner)
3. When in doubt, do what's right for the customer
I learned this one when I was doing Office 365 deployments. At the time, Microsoft's cloud was still new. Office 365 was a v1 product we were deploying to early adopters. We navigated tense relationships with customers every day. In a perfect world the company and its customers' motivations are always aligned. The reality is – that relationship at times exists in a state of tension. Features are expensive. Timelines are hard. When a decision has you on the fence, do what's right for the customer. It's a defensible position every time. (h/t Marty Schuchman)
4. Always be shipping
My first training at Microsoft, they showed a video called "23 and a Half Rules of Thumb for Software Development". It was eye opening in that it was my first insight into what made Microsoft the most successful software company in history. The main takeaway I carried with me from that series was to always practice shipping. Whether it's software, a document, or a presentation – every day is a countdown to a ship date. Act like it. It's easy to spend time contemplating, forming/storming/norming, etc., but the best and fastest progress is often generated by pretending every day that go time is tomorrow. (h/t Jim McCarthy)
5. When growing into a new space, establish a beach head.
When people join Microsoft for the first time, or join our team from a significantly different role, this is the advice I lead with. I just used it again today with someone on their first day at Microsoft. The expression "drink from the firehose" is apt; everything comes at you so fast that you can get an overwhelming feeling of being unable to absorb anything. The way forward is to find one thing to get great at. Learn enough about it that people start to see you as the expert in that area. From that beach head of expertise, it's much easier to expand your influence.
6. Tables Rule
Tables, as a graphical organization tool, totally rule. They're awesome for simplifying a nebulous problem space. The test of moving from pure ideation to action is converting thought to tables. You're brainstorming a list of customers – put them in a table and figure out what columns matter. You're brainstorming a set of priorities – convert to table. Feature list – table. You get the idea. It may seem obvious, but it was something I had to learn.
7. The Rule of Thirds.
I use this one when team members are frustrated by low priority activities competing with high impact work. On one hand, we push the team to spend the majority of their time doing high value work. On the other hand, everyone has overhead of what feels like low value activities. So how do we reconcile? Enter the Rule of Thirds. I tell new PMs to expect to spend about a third of their time doing high value work; a third of their time doing what feels like low value activity; and a third of our time convincing our leadership that we're doing the first two-thirds exceptionally well.?? Knowing that all of us spend a good chunk of our time doing overhead or work that doesn't feel high value helps us endure the reality of our days. You can think of low value activities as defense and high value work as offense. Both are needed. This is also related to Rule 8.
领英推荐
8. Live the pain
This may be most applicable to the PM discipline but there's an adage: if you want someone to automate a task, the best incentive is to have them do the task manually. Live the pain and you'll be motivated to fix it. Sometimes these tasks fall into the low impact third from Rule 7. Bringing these together, you can assume if you're living pain a third of your day, fixing pain a third of your day, and communicating your progress against the first two thirds for the rest of your day – you're living your best PM life.
9. When in doubt, be of service to others
My very first work assignment at Microsoft was at a customer site, where I was supposed to be a consultant on a new technology I was still ramping up on. The delivery lead called my new manager and said, "Get him out of here." The clock was ticking for me to be thrown off the first job site on the first morning of my first day at Microsoft. So I just started listening to everything the delivery lead said to everyone else. Now that he stopped talking to me, it was all I could do anyway. Although I didn't understand much (he was right to want to toss me out apparently), I did understand that he had no one to write documentation. So I just started a draft on what I was learning in real time from listening to him. Before long, I had a draft written. It was hardly a masterpiece, but it was a start. By the afternoon, he updated my manager, "Alan can stay." And this approach has carried me all the way through today. Help yourself by helping others. It just seems to work consistently. (h/t Steve Tiano)
10. Never assume incompetence until you have validated.
This one builds on the classic "Never attribute to malice that which is adequately explained by incompetence." I add a) never attribute to incompetence that which is adequately explained by context, b) never attribute until you validate, and c) the best way to validate is to ask someone. Before I joined the company, I made all sorts of assumptions about why certain Microsoft products struggled. Surely, I thought, the people in charge of that product must be incompetent. As I got in and learned the history of the products from the people that made them, I realized that product owners generally make smart decisions based on business constraints and what they know at the time. Context matters. My current manager is extremely consistent in never assuming malice or incompetence, until he has personally validated it. Something could seem blatantly obvious to me, but he withholds judgement until validation is complete. And the best way to validate something is to...
11. Pick up the phone.
Email has limits. IM has limits. Nothing beats in person, video, or voice. Any time I catch myself spending too much time trying to craft the perfect email, it's a good sign that I should try to talk to the person. This is the exception to the list in that it was drilled into me before Microsoft, but I did learn how true it is at Microsoft. I'll never forget being barked at, as I worked for an hour on what I knew would end up being the perfect email, "Alan. Pick. Up. The. Phone!" (h/t Eric Lamar)
12. Own tough messages
So much of my personal growth as a leader has been about getting over fear. One bad habit I have worked hard to improve on is channeling someone else when delivering bad news. The fear-driven way to land a tough message was, "Well I'm being told...". I learned the hard way that this is no way to lead. One painful hit the team took is when someone left the team and told me, "I can't have you as my manager when I'm being managed by someone else." That one stung, but I did learn from it. Now whenever I feel myself trying to pin a tough message on someone else – I go back to internalizing and deliver it as mine. (h/t Val Jeffers)
13. Try to do your manager's job
This assumes you want to move up and that you have a good manager. If both are true, practice doing your manager's job. This is an extension of Always Be Shipping. Want to ship perfect software? Practice shipping perfect software every day. Want your manager's job? Practice being your manager every day. If your manager is good, they will occasionally coach and nudge you in the right direction. Every time that happens, learn from it. That problem you want to ask your manager for help on – have you tried to figure out what they would say? Have you really thought about it and taken your absolute best guess? Until you do that, you're not actually practicing being your manager. Any time I feel the need to ask my manager something, leading up to the conversation I do my best to figure out what I think they would say. If I'm right 5 out of 10 times this year, maybe next year I'll be right 7 out of 10 times. Heck, if I can reach 10 out of 10 times, it seems I'm ready to move up, wouldn't you say?
14. Override in private
This is a management best practice I still need to get better at. For individual contributors, this is one worth coaching your manager on if you have that type of relationship with them. When a manager wants to override a direct report's position on something, they should do that offline and empower the direct report to issue that as a final decision. An example of this is when a manager has been cc'd and determines a bad call was made by their direct report. Instinct is to come on top and override their opinion. But the better practice is to message the person individually and explain why you disagree, with the goal of having them pivot to the change in direction. This is important, as it builds a team up instead of tearing them down. It helps them learn why the decision makes sense and it helps you both reconcile your positions. Maybe, by taking it offline, one of you will actually change your mind. Most importantly though, this practice ensures that a manager is not reinforcing the behavior of escalating to them. If they override the team's decisions publicly, then it's signaling to others that they need to come to the manager if they're not getting the answer they want. The hard part about this is that it's easy to come over top of a thread and look important or smart. It's much harder to drive consensus. But this is why MSF uses the language "Team of Peers," to include the manager. The manager doesn't oversee the team. They're a team member. (h/t Robert Dring)
15. Fortune Favors the Bold
If you're working at an established company instead of a startup, you have taken a relatively safe path. Within that safety net, take risks. Chase that dream role you have your eye on, take a bet on a product or leader you believe in. You have one life and one career. Seek out risks worth taking and go for it. (h/t Graham Mosley)
_____________________________________________________
Encouragement and editing h/t to Philippe Brissaud, Lu Azhari, and Tanner Briggs. ??
Thank you for your appreciation. For reference: https://www.youtube.com/watch?v=5Nc6yuwvUAw&list=PL9B1543FBFFB18EDD
Principal Data Architect Manager - Data Architect Lead - GDC at Microsoft, Inc.
2 年I worked under Marty Schuchman and can corroborate his tutelage. I learned a lot from my time with him. As an adjunct to #14 I always mentor other managers (and parents) - 'praise in public, chastise in private'. It's vital that your team and children know that you're on their side.
Global Accts Strategic CTO at Microsoft
2 年Thank you for sharing, very inspiring, congratulations you are so deserving
Chief of Staff | Microsoft Cloud for Industry
2 年Nice article Alan. It’s super fun learning alongside you!! Thanks for the reflection and for always being open to listening and growing - it’s fun working with a great leader!! ????