Brad Abrams : Program Manager

PM Tip #10: Interview Tips for Landing a Great Program Management Job

BradA — Thu, 25 Jun 2009 00:33:33 GMT

Recently a friend of mine at Microsoft asked about tips for how to land a great Program Management job at Microsoft. It has been a while since I did a “PM Tips” post, so I thought I’d use the opportunity to share my thoughts and get your feedback.

I have done lots of PM interviews over the years and through the process I have developed a few things I look for to spot great program managers. In fact I have often mentioned to co-workers in Dev or test and even people I meet at social events that they would be great PMs… most of the time they look at me like I am crazy… but sometimes, they turn out to be, in fact, really great PMs.

Getting the Interview

Know what you are looking for – Given this economy, I know many folks just want *a* job. But I’d encourage you to think more deeply about it. You are more likely to land a job that allows you to use your discretionary effort – that is, something you will LOVE doing.   Another way to look at this is for every job you apply for, know why *that* job is great for you. So while you could apply for many jobs, you want to figure what makes you interested in each one. Is it the people you’d work with, the technology, the role?

Understand why you are looking – There are lots of good and bad reasons to look for a new job. Be sure the check your motives. Hiring managers don’t want to get a “problem” employee that runs away from hard problems or can’t get along with co-workers, etc. Good hiring managers will want to really find out what is motivating you to look now. Even if it is something like a “unfair” review or a disconnect with your manager that is making your want to look, I’d encourage you to think hard about the root cause – for example maybe your review isn’t great, in part because you have lost passion for the an area you have worked in for long time.

Network – Chances are very good that someone you know knows your future boss. Put the word out that you are looking. If anyone on my team recommends someone for a position, I always do at least an informational with them… the same is certainly not true for the cold calls I get.    Be sure you have talked to your management chain about this first as news travels fast. You don’t want to surprise anyone. It is always best if you can tell your management chain that your first option is to stay with the larger team… that motives them to find a role for you and helps you not look like you are running away.

The Cold Call – Sometimes you will have to do a cold call – just reply to an open position even when you have no personal connection.   Don’t let this stop you from your dream job. But do do your research. In your first mail to the hiring manger mention why you are interested. is it the technology, the people, or some aspect of the role? Specifically ask for sometime with them or someone on their team to talk more about the job.

Do your homework – In the days of Bing, Google, Blogs, Twitter and Facebook it is very easy to find information on people and projects. Who are you going to interview with? Find out what their last talk at a conference was, what was their last blog on, have they done a blog post on interview tips ;-) etc. For the project, what is the core message, what are customers saying? what are the big problems? Is there a beta or CTP of the product you can play with a bit? Can you get some first hand experience with the product.

The Interview Process

The overall interview process can be time consuming and take a lot of elapsed time. And while you can try to put a schedule on it, the truth is it will take as long as it takes. This is a big decision for both you and the hiring manager. Here are a few things to expect in roughly this order:

1. Initial Informational – this is usually with the hiring manager or someone she respects. The goal here is mostly a “get to know you”.

2. Follow up informationals\informal interviews. Committing to an interview day is big for both of you. You have to tell your current manager (if you are already an employee at MS) and the hiring manager has to invest several hours in an interview loop and discussions. Often you both want to raise confidence before doing a loop. I am a big fan of these as they give you a very good idea of what the loop will be be like. It is very much a trial run.

3. The Loop – If all goes well, eventually you will do a full day interview loop. You are likely to talk to 3-6 of your co-workers, your boss peers, etc. Be sure to ask each of them what their relationship is to the hiring manager. Begin to form of map of the organization.

4. The hire\no-hire decision – often this is very quick.. a matter of a couple of days for the hiring manager to compare notes with the interviewers and make a decision.

5. Accepting the offer – You need to formally accept the offer. My suggestion is that you loop back one more time with your current team before formally accept… again you want to leave on the best terms as possible.

In the Interview

Good answers to stock questions – I always ask a few stock questions:
Why is now a good time to look?   Good reasons would be product shipping, significant change in directions, etc. Bad reasons would be you got a bad review, a reorg didn’t go your way, etc.
Why this role? Good reasons would be following your passions for technology X or part of a progression (from low-level to high-level platform for example, or it could be the people, etc. Bad reasons would be you want to be the boss, you want an easier\less stressful job, etc.
Why PM?    Good reasons would be around wanting breadth of scope, impact the product, customer connections, etc. Bad reasons would be to make decisions or be in charge.

Tell me about a time… - I love to hear about the personal experiences of interview candidates. What have they really been through and what have they learned? To get at this I often ask Tell me about a time you made an unpopular decision, made a big mistake, managed someone out of the company, etc.   Have a few stories ready for this sort of thing. Think of a few “big” issues you have dealt with recently and what you have learned – likely this event can cover no mater what the “tell me about…” opener is. Just be sure you know what the point is you are making. That you learned quickly, that you stand your ground under pressure, that you know how to work cross group into a win-win situation.

Industry Questions – I often ask candidates about the software industry to see how much they are keeping up. Sometimes I ask candidates about the industry around their current role. Here I am looking to understand how deeply they seem to understand the industry. For example, if they are coming from SQL Server, do they talk about the industry around one version of SQL to the next or do they talk about it in terms of Oracle and MySql or do they talk about it in terms of unstructured data storage and how we can mine that in different ways. I also ask candidates about my area.. how much do they understand about the real business they are interviewing for. Clearly they are not experts, but I like to know they have done some level of research and thinking. I also like to push different ideas and see how they react, distill and question.

Technical Questions – I almost always ask technical questions. Say a coding question done on the whiteboard or a how technology X works. My goal here is to see if the candidate can hold their own in a technical conversations. The main thing to do here is to set exceptions well. For example, if honestly you are not a world's best coder, be sure to tell the interview, but go for it done the less. Remember this is more about how you think than what you know. Candidates often freeze up on these sorts of questions. The best thing you can do is relax and think out loud. Even ask the interviewer if you are on the right track or not.. Often they want to help you.

Design a Bahh Questions – Design a ATM for a child or a blender for the blind, etc. These questions are really about trying to see how creatively you can think and, more importantly, how well you can sift through and winnow down your ideas. My advice here is to start with questions – ask a bunch of questions to scope out the space and give you time to get inspired. Get excited about your solution – even as you (and the interviewer) finds holes. This is a great time to show your passionate about your job.

Riddles and Trick Questions – It is true – Microsoft does often ask “why are manhole covers round” sort of questions. I have found the main value here to be on the candidates attitudes. Don’t belittle or doge the question.. again, show you are game and go for it. It is very unlikely that this is a simple pass\fail test, so worry less about the getting the right answer at the end and more about the process of getting there.

Your Questions – I typically end the interview by asking if the candidate has any final questions. This is your last chance to make a good impression. Ask good questions that shows you have done your homework. Does the interviewer see the industry trends the same way you do (or you have read about)? what are they doing about top issues in their product that you know about (or have read about)? How is their cross group interactions? The best questions are the ones that you sincerely have… after all, it is a big bet for you as well.

After the interview

Just like your mom probably taught you it is a good idea to follow up with your interviewer the next day mostly just to say thanks for the interview. The truth is very likely their hire-no hire decision has been made already, so you are not going to change that. But it is a small world, so a good last impression is important. One thing I appreciate is when I am able to get a candidate sufficiently interested in a question that they think about it later. So in the follow up interview you might mention you thought about it more and you have X to add or you solved the coding question and here is the answer. Again, you are very, very unlikely to change the outcome of the interview from this, but it is a nice touch.

What do you think? If you often hire PMs at Microsoft, what would you add? If you have recently been through a loop, would any of this have helped?

Presentation tip: They Remember the Mistakes more than the Polish

BradA — Fri, 27 Mar 2009 19:39:00 GMT

One of the reasons I love going to Mix is getting a chance to watch really world-class technical speakers. As I watched the keynote and a few sessions this year one theme really stood out to me: The audience seems to remember how the speaker handles their mistakes\crashes more than the content of their presentations! Obviously it this is a pretty hard thing for a speaker to prepare for. If you can prepaid for it, then I’d suggest avoiding it all together ;-). So how do you prepare for the unprepareable? It seems to me it is all about attitude.

For me, my learning on this started when I arrived a day early for Mix. I had a chance to talk to one of my favorite speaking coach Richard Klees. If you have not had this guy rip you to shreds, you need to! I had the good fortunate to have an error pop up during my talk with Richard – FireFox popped up and wanted to update the browser in the middle of my presentation. I was clearly annoyed and frustrated by this interruption in my carefully planned flow. Richard called me on it and strongly suggested I work on my attitude.

I partially understood his advice, but I didn’t really internalize it until the keynote when Bill Buxton could not get his HP Touch Smart to respond.

Notice how he handled this – so much grace.. I had the good fortunate of seeing this demo during a dry run the night before, so I can say with some confidence Bill got more applause with his quick wit and good humor than if he had actually been able to do the demo.

So that got me really thinking.. I immediately went back to Richard's advice and it started to make more sense. Later in the keynote I was very attentively watching ScottGu’s coding demo.. My team had worked with him a lot of getting this demo just right and crisp.. and being pre-release software I was a little nervous of what bugs we might see so I was a little on the edge of my seat during this demo. And Of course he did hit an issue, but notice how gracefully he handled it?

Scott had been through this demo 100s of times in the previous 24-48 hours and trust me, he never saw this issue.. yet he handled it perfectly! He came across as more real and human. Again, I thought back to Richard's advice, I was really starting to understand…

Just a few hours later, I would get a chance to put into practice my new found wisdom. I was doing 75 mins worth of demo on preview software on to of a random daily build of Win7. Let’s see how I handled it..

So maybe not as good as the masters, but way better than I would have done without the active learning going on. It is all about the presenters attitude and state of mind.

Have you seen some great presentation failures? How about great recoveries?

Book Review: Made to Stick

BradA — Mon, 28 Jan 2008 03:08:11 GMT

I just finished reading (ok... listening) to Made to Stick: Why Some Ideas Survive and Others Die.

The authors do a great job at expanding on some ideas on how to make ideas resonate and, well, stick with your audience... This is a key skill for any Program Manager needing to lead without authority. While many of the ideas where common sense, the detailed explanation and colorful stories help to bring light to the kernel of truth. The authors use a mix of scientific data, careful analysis of urban legends, proverbs from all over the world and advertising data to bring color to their points.

A few of the ideas that stuck with me from the book are the curse of knowledge, surprise, stories, focusing on the personal rather than the corporate, burring the lead, concreteness, less options are better, analytical vs dialog\problem solving frame of reference.

I know that doesn't do justice to the topic... but read the book and you will get it!

PM Tip #14: Great teams have members that defy roles

BradA — Wed, 24 Oct 2007 18:55:02 GMT

I was asked recently to define the roles for PMs on my team. Specifically what they should do as compared with the dev and test teams. I flatly refused. The best teams I have worked in and with are those that defy the traditional roles and responsibilities. Putting up artificial walls between extremely closely related disciplines can only be detrimental to getting great team work. Any given set of devs, testers and PMs working on a feature have a different set of skills and experience they bring to the team. Putting in place a structured set of expectations denies this fact. If the developer is more senior and experienced in an area, then you may want them leading more of the design of the feature, not just the implementation. Likewise if the PM is very senior and an experienced software architect, you may want them to have more of an input in the actual implementation decisions.

My thoughts on the ideal process is that the feature team (dev, test and PM) get together regularly to discuss what needs to be done and, together, they decide who is best equipped to do those tasks. In many cases the more customer facing and partner interaction tasks will fall to PM and more implementation tasks will fall to dev, and more quality assessment tasks will naturally fall to the test folks.. But this model allows for individual situations to vary. More importantly, it puts the overall responsibility of successful delivery of the feature on the crew as a whole - working as a team. While I am a huge fan of personal, individual responsibility, this should not take away from the team as a whole feeling accountable for the feature as the customers will experience it.

But, given this is a PM tip post, a few pragmatic thoughts for PMs in this sort of situation..

1. Your feature team relationships are the most important you have. When issues like this one come up it is often a symptom of a disconnect or mistrust across the feature team. It should be a single to you to invest more in these relationships. What is really going on?

2. Keep the conversation focused on what needs to be done. Don't fall into the trap of each person on the team just defining some "traditional" work. Help guide the team to the point that everything that being done actually needs to be done by this team at this time. For example, do you need exhaustive test cases while you are still incubating? Do you need an API level spec while basic design tenants are still being established?

3. Be the most flexible member of the team. When you do get into dividing up what needs to be done, be the most open minded and flexible person. For example, if dev wants to own defining the APIs for the feature, fine, you pick another area to add value on and figure out a way to influence the design though customer feedback, app building, etc.

That is a full day's work!

BradA — Sun, 29 Jul 2007 03:34:48 GMT

I am starting to work on writing some annual employee performance reviews and I was thinking about one of the first bits of advice my manager gave me when I joined Microsoft "Don't confuse activity with results".

As we reflect over the year, it is easy, and natural to think about all the activities we did... the specs we wrote, presentations we gave, partners we managed, etc. But what is more important is the results we archived, a well received feature, a community excited about our product, partners that are wildly successful, etc. Of course these results are a bit harder to pin directly to our actions, but it is worth a try as this keeps us focused on the change we are contributing to rather than just spending time and effort.

As I think about this challenge, I am reminded of a story my wife's grandfather (who recently celebrated his 93rd birthday) tells of how he learned to focus on results instead of activities in his youth on a small farm in the rural North Carolina… On a muggy summer day, he and his brother had plans to meet some friends to go skinny-dipping. Their father, on his way out the door for work that morning, asked his sons to pick up the flat white rocks that littered their field and stack them up. Thinking their day’s plans might still be salvaged through an ill-defined success metric, his son’s very respectfully asked him: “Is there anything else we should do when we finish that?”. But their father was one step ahead of them, he told them “Son, that is a full day’s work. If you finish that, spread the rocks out on the field and pick them up again.” While this foiled the skinny-dipping plan for the day, it helped to instill a strong work ethic that still runs deeply in his family today.

FxCop Honored with Chairman's Award for Engineering Excellence

BradA — Fri, 06 Jul 2007 04:39:00 GMT

Every year, Microsoft honors a few innovations that have furthered the state of engineering excellence at Microsoft... Some years, Bill Gates selects one of the winners to honor with the special distinction of the chairman's award. I am told that Bill does this for truly noteworthy achievements that have tangible impacted software development in every division at Microsoft. In fact, until this year, the only other winner of the Chairman's award was Watson.

This year, FxCop (along with some two other static code analysts tools) were selected for this award. This achievement is a testament to the importance of catching errors at the developers desktop before they even get into the source tree. We know it becomes orders of magnitude more expensive to catch errors once checked in, and even harder still once they have shipped. FxCop (and similar tools) enable developers to quickly and reliably scan their code against all known issues. This type of checks is a scalable and reliable way to catch whole classes of issues. As new classes of issues are found, a new "rule" can be written and codebases across Microsoft (and the industry) can be quickly checked for that class of issue. If you are not using a tool such as FxCop today, you should!

FxCop is available standalone for anyone inside or outside of Microsoft to get as well as an integral part of Visual Studio 2005 and beyond.

While Krzysztof Cwalina, Michael Fanning and I were honored to accept the award and get a nice hand shake and photo will BillG, there are tons of people that made FxCop successful. While I can't claim this is a complete list of those that played key roles, it is a good start. Thanks for all of you that helped!

Chris Anderson
Dave Bartolomeo
Marcelo Birnbach
Andrew Brown
Kathleen Carey
Erik Christensen
Brian Crawford
Rob DeLine
Mark Dredze
Joe Duffy
Manuel Fahndrich
Stephen Fisher
Brahmnes Fung
Kit George
Natalia Glagoleva
Bret Grinslade
Brian Grunkemeyer
Nick Guerrera
Sheridan Harrison
Anders Hejlsberg
Anson Horton
Hunter Hudson
Kamran Iqbal
Duane Kanz
Ravs Kaur
David Kean
Todd King
Dave Lubash
Matt Lyons
John Mackenzie
Tom Marsh
Ivan Medvedev
Syne Mitchell
Anthony Moore
Mike Murray
Joe Rohde
Sean Sandys
Roberto Santos
Jesus Ruiz-Scougall
Amanda Silver
Anshuman Srivastava
Roman Snytsar
Lisa Supinski
Ryley Taketa
Valtcho Valtchev
Paul Vick
Jeff Van Gogh
Herman Venter
Nate Walker
Brett Wortzman
Eric Zinda

plus: Every engineer and customer who contributed thinking and feedback to the Framework Design Guidelines, provided useful feedback and bug reports to the FxCop team, or simply objected to the sanctioned casing of the term ‘Id’. Your numbers are legion.

Thank you!

Are you ready to make a change?

BradA — Sun, 03 Jun 2007 00:40:49 GMT

The ASP.NET team is looking to fill some senior Program Manager positions and you might be just the right person. I would love to have someone who is passionate about the web’s potential, who is an expert in common web technologies such as Php, Rails, JSP, Ajax (and of course .NET), who wants to build amazingly great products for customers, who knows how to drive, lead and inspire teammates, who knows how to listen (and talk) to customers and partners. There is a change going on here and you can be a part of it… With products such as ASP.NET AJAX, Mix, Silverlight, dynamic languages and Astoria Microsoft is in the process of changing the way we work with “the web”. Come be a part of taking that to the next level…

If you have never considered working for Microsoft before, but you are intrigued by the chance to change Microsoft – come!
If you have long dreamed of a chance to make a big impact on the development platform that millions of people use everyday – come!
If you have a vision for the web that Microsoft and ASP.NET can be part of – come!

For the moment, we are only looking for senior program managers, that means 5-10 years experience in the industry, lots of experience leading teams, lots of experience building solutions (large and small).

If you are that person, check out these job descriptions and then contact me or brada AT Microsoft DOT com!

http://members.microsoft.com/careers/search/details.aspx?JobID=6792ECAB-89B3-4BBA-95DA-5507A95A325E&start=1&interval=50&SortCol=DatePosted

http://members.microsoft.com/careers/search/details.aspx?JobID=6D82A604-BE50-446F-A7C3-E58FF912BE55&start=1&interval=50&SortCol=DatePosted

The Wisdom of Crowds: Rethinking consensus

BradA — Sat, 19 May 2007 07:02:45 GMT

I am a HUGE believer in building consensus, but The Wisdom of Crowds is starting to make be rethink the approach a bit. I just finished reading, ok listening to the audio version on my bike ride into work, James Surowiecki's latest book.

His point is that groups of people make good decisions on matters of general knowledge when all of the following conditions are meet:

1. There is a diversity of opinion
2. People are not overtly influenced by others in the group
3. Some "fair" aggregation system is at work

Surowiecki argues that these elements allow you to tap into the collect smarts of the group while canceling out their errors.. Doing things like spending tons of time consensus building often has the result of creating less diversity in opinion and thereby misses out on the collective wisdom on the group. While I don't think this applies universally, it is some thing that is making me stop and think more before doing the 100 items consensus building check list.

Rather than consensus, Surowiecki suggests using a mechanism such as Prediction Markets to make decisions. Markets like the Hollywood Stock Exchange. I'd love to participate in a market around predicting the raise of a given programming language (Java, C#, Ruby, Python,??) or programing methodology (Object Orientation, Rails, Linq, ??) or say the ship date of Orcas... It would be really interesting to see what the "wisdom on the crowd" is here.

PM Tip #12: Don't waist keystrokes

BradA — Mon, 07 May 2007 05:54:00 GMT

At Mix I ran into Jeff Atwood who reminded me about a my post on the "Be More Visible" Sham. He also told me I should take a look at Jon Udell's post Too busy to blog? Count your keystrokes [via Jeff's blog]

While I don't think every PM has to be a noteworthy blogger to have a successful career, I do think Jon's principle of conservation of keystrokes is an important one. By far the biggest problem I see on teams of > 1 is communication. Different people know different information, this leads to disconnects and often to product design, quality and schedule issues.

Teams need better communication and PMs are primarily responsible for this. So think about the email you are getting ready to write... Should you add a tester or dev to that email? better yet, should you use a team alias? What info should flow up to your management chain or across to your peers? can you forward that mail? And to Jon's point, can you just blog it and share it with the world?

As Jon mentions, there is a time and a place for private communications, but generally we tend to overuse them.

Good luck and happy communicating!

Building Consensus

BradA — Sun, 24 Dec 2006 06:05:00 GMT

One of the core skills of a Program Manager is to build consensus. Microsoft (like many knowledge-worker driven IT companies) is not a top-down organization. For the most part, projects, ideas, directions are taken on through a consensus building exercise at one level or another. While this can be frustrating and slow at times, it does a very effective job at weeding out bad ideas and honing good ones.

So how do you go about getting an idea to stick? Because Microsoft is an organization of people, it is more than push-a-button-get-an-answer. You have to work with and through people with all their wonderful idiosyncrasies, creativity, passions, hopes and fears. As a PM, you are often asked to build consensus with folks that are much more senior, more technically deep, and even more bull-headed that you. What should you do in those cases? Recently I got a few folks on my team together to trade stories on how to build consensus.. here are just a few of the ideas we came up with. Notice not all of them work in every case, pick the ones that feel best for you and for the situation.

Ask for help. Rather than come in with a ready-made solution you just want them to buy-into, come in with a well thought out problem statement and get them to brainstorm with you on possible solutions. Hopefully the one you had in mind will come out or better yet, maybe you will get a better one.
Write it down. One of my favorite VPs is fond of saying "Writing is thinking". Write down your idea in a complete, well thought out way. This gives something concrete for folks to comment on and buy into.
Get the data. In many cases there is hard data that can substantively inform a decision. Using 3^rd party data in this way enables the discussion to be less about opinion than interpretation of data. For example if you are trying to diced if you are going to target an OS platform like Win9x, get data like the number of Win9x users hitting microsoft.com or projection data from marketing.
Customer anecdotes. Even in cases where hard data is difficult to come by, a quote from a customer or story about a customer deployment can be very valuable. For example, it is way more powerful to say: "Yesterday I was talking to the folks from ESPN, and they thought feature blahh was a must have" rather than "I think feature blahh is a must have".
Build a prototype or demo. If a picture says 1,000 words, a demo says 100,000! There is nothing like seeing an idea to life, even in a limited way.
Define the middle ground. Outline the extremes of the possible solutions, painting your proposal in the center. This encourages the other person to agree with you or be closer to one of the extremes. For example, "We can completely break compatibility or freeze-dry the product and not evolve… OR we selectively take changes we need to"
Actively take feedback. People love to make their mark, give them plenty of room to do that. As long as it doesn't substantively change the plan, be very open to change. For example, when I am doing a dry run for an exec review, I make a point of taking appropriate changes from every stake-holder, especially those that are not 100% in agreement with the plan. The extreme of this the admiral's pipe.
Change your mind. Never forget that you may be wrong. The goal here is not for your idea to win and everyone else to lose, it is for the best ideas to come to the top. If someone else has a better idea, drop yours and take it and start building consensus around it!
Appeal to respected other. Let's face it, the person you are trying to convince may not respect you and therefore will never buy into your idea. If so, find out who they do respect and talk to them.
Identify the blocker. Often times there are is just one thing about the plan that is a blocker but lots of other issues come up. Try to weed through the issues until you find the one that is truly a blocker and deal with it. You are just wasting time dealing with the easier issues that are not blockers.
Let history be your guide. The IT world is a great big cycle, anyone that has been watching the industry for more than 2 years knows that the same ideas come back around with the same set of issues. Appeal to historical examples, how is your solution going to be better or different? For example: "Unlike clippy, we are going to provide help in the context of where it is needed"
Find the agreements. In most cases you agree on way more than you disagree on. Defining the agreement makes it clear how close you are to consensus and you may find that you have enough consensus to move on.. that what is left as disagreements don't substantively mater in the short-medium run.
Define the disagreements. Spell out clearly what the blocking issues are. Be sure you deeply understand the other persons' position. Getting the disagreement written down clear can help you both see what additional data would help resolve the issue and will help others to chime in.
Find out who matters. It is impossible to have 100% agreement with absolutely everyone involved. Very rarely are IT organizations a democracy with everyone getting an equal vote. Let's face it, some people mater more than others. Find out who the key players are. Who needs to take action on the plan, who controls the resources, who can veto? If this person doesn't matter, maybe you don't have to get them to buy-in.
Deal with the fear. Sometimes there is an underlying issue that has nothing to do with the matter at hand. Does this person feel you did them wrong last time? Is there a territorial issue at play, is there some other reason for a lack of trust? You have to deal with this first.
Why more than what. Deeply understand why the person is taking the position they are. Directly ask why, make suppositions and test them. But focus on the why way more the what of the disagreement. The why might have to do with history, politics, personalities, etc. Address the why directly.
Be differentiated. Not everyone is equally invested in every issue. Find out who the key stake holders are that are deeply invested in the issue and give them higher touch, earlier feedback opportunities. For example, sending a spec out to a wide alias might seem like a way to build broad based consensus but it could backfire if those directly involved feel short-circuited.
Be broad. Especially later in the lifecycle of an idea, the more people you get to buy in the better. There is a wisdom of the masses element that can help a lot. For example reviewing possible product names with key marketing and sales people are key, but it can be helpful to get broad range of opinions as segments of the population may have an adverse reaction to the name. In this phase, 1 or 2 negative reactions is to be expected, what you are looking out for is trends and repeated reactions.
Simple wins. Spend some time thinking about how to simplify your idea.. what is the essence of it? How can you represent it in a simple-yet-meaningful way? Ideas that are more simple are easier to understand, easier to implement and harder to find nits to disagree with.
Check your emotions. Is your anger, passion, or frustration getting in the way of your consensus building? It is amazingly hard to deal with one person that is reacting poorly to a new idea, it is completely impossible if both you are reacting poorly. Building consensus is NOT about proving you are right, smarter, better than the other person. Relinquish all desires along these lines and focus on the objective. Go home and play your Xbox to prove your worth ;-)
Avoid getting entrenched. Once people take firm sides on an issue you have already lost in many ways. The best consensus building is done as ideas are being formed (yours and others). After someone has already taken a side they are more apt to defend that side out of pride. Presenting ideas as a black and white choose fuels the "taking sides" fire. Don't force an answer until you'll get the right answer.
Let time pass. New ideas may take a while to sink in. Many folks are uncomfortable making snap decisions, give them time to think through all the implications. Check-in regularly to show you care and to keep on track but don't force a decision unless you really, really have to (that is quite rare).
Let them save face. If someone has been entrenched in a position for a while, their lack of love for the new idea might have more to do with making them look like a "loser" than the merit of the idea. Are their concessions you can make? Are some timeframes better than others? Are there other areas you can offer your support in?
Create a path. If you can't get consensus on an issue, try getting consensus on the path or steps toward an agreement. What data do you need? What 3^rd party could you appeal to? What prototypes must be done? Stepping back from the issue in this way allows room for agreement and trust to form before confronting the issue again.
Have Principled Flexibility. By definition, there must be a single, coherent idea around which consensus is built. If you change the idea substantively every day you will never build consensus. Figure out what the core idea is and stick to it, but be open to changing the non-core elements as much as is needed.

In the process of creating this list, a few anit-patterns emerged. Certainly you can NOT any one of the above to find out how to botch a consensus building activity. In addition, here are a few common ways I see people screw up in consensus building.

Blessed Ignorance. Many failures can be attributes to folks not realizing they are in a consensus building activity. They miss-judge it as a competition or information dissemination and thereby forgetting to listen and take feedback. It is very helpful to identify the situation clearly, calling it by name, and maybe references in this post ;-).
Escalate. When faced with a difficult consensus building activity, the knee jerk reaction in the corporate world to talk to the "stubborn" co-workers boss. Presumably the goal is to get the manager to get the problem-child in line. A few questions to ask before you escalate. Will the damage to your long term relationship with the stubborn coworker be worth even the best outcome from escalating? Will your coworkers boss buy the idea themselves? Will you come across as incompetent at a core PM skill (building consensus)?
A mission from God. Occasionally a PM is asked by a senior exec to drive some initiative. A common mistake in this case is to assume that this makes you infallible and obligates everyone to buy-in immediately. The truth is that even in this case you need to build consensus. At best the exec air-coverage gives you the foot-in-the-door and hopefully defines the core principles.

So, what do you think? Other patterns or anit-patterns for consensus building you have used? I'd particularly love to hear stories about using any of these.

The What and the How

BradA — Sun, 08 Oct 2006 01:39:00 GMT

I was talking recently with a coworker of mine about the “what” and the “how” of software projects.

The “What” is the definition of the thing you are building. What customers should we go after? What markets should we serve? What competitors do we care about? What scenarios matter most? What feature should we have?

The “How” is the definition of the way you build it. How should we org the team? How should we ensure quality? How do we do SCRUM, Agile development, TDD, etc? How should we ensure customer feedback gets reflected? How should track progress?

Between these two areas, the what and the how, is the essence of software projects. When a project fails it is often due to one, or both of these having insufficient IQ on them. A project without a good “what” can flounder from exec review beatings to analyst lashing to customer ambivalence no matter how good the “how” is. A project without a good “how” can suffer delay, after delay, quality issues and poor team morale no matter how good the “what” is.

Think about the software project you are currently on… is it missing more of the “what” or the “how”? Do you have a clear idea of the product you are building and the customer you are targeting? If not, your team is missing the “what”. Do you have a good idea of how quality is ensured, how the schedule is created and managed? If not, your team is missing the “what”. Understanding the world in these terms can help you spot the issues, communicate them clearly to others and (hopefully) fix them!

Another interesting angle on this is that people tend to have inherent talents in one or the other of these dimensions. There are “what” people and “how” people and a software project needs them BOTH to be successful. If you are strong in one of these, it is certainly possible to be great at the other, but you will likely have to work at a lot harder at it. Once you have reached the competence in your weaker area, consider if you would be more successful overall (and happier) investing the time and energy into making your strength area even stronger. A “How” person that everyday has to come in to do “what” work will likely soon burn out… and vice-a-versa.

As any student of the Mars vs. Venus conflict can guess “what” and “how” people often deeply irritate each other. Have you ever been in a conversation about which feature would delight customers more only to be randomized by a rant about the schedule and the amount of time it would take to get those feature done? Likely you are a “what” person being irritated by a “how” person. On the other hand, have you ever had your orderly schedule review wrecked by pie-in-the-sky thinking on features 2-3 releases out? Likely you are a “how” person being irritated by a “what” person. Appreciating that there are “what” and “how” people and that they are both super valuable to a software project can help you bridge the divided.

What are your thoughts? Do you think most projects fail with the “what” or the “how”? Any thoughts on what has worked for getting “what” and “how” people to just get along?

Thoughts on writing reviews...

BradA — Sat, 09 Sep 2006 23:39:00 GMT

Well, it is that time of year again here Microsoft – time for managers to write employee reviews (they are due 9/15 folks ;-)). While this is the subject of much Dilbert-style joking, I thought it would be useful for me to write down a few of my opinions, habits, and observations about actually writing a performance review… Other Softies have thoughts? Does any of this resonate with folks outside of Microsoft? Any horror stories from your past reviews?

· Writing is thinking – Don’t just barrel through the writing of the review, as you write, spend some time thinking about the employee, what is the overall message they need to hear? “Kicking butt”, “fix this one thing”, “Get in shape”, etc. Be sure the review overall carries home that point. I spend about an hour per review actually writing.

· Use the 3^rd person – I chose to use the 3^rd person when writing reviews. For example “Bob is kicking some butt…” rather 2^nd person, “you are kicking some butt”. It helps me as the author think about a future manager reading the review so I include the right detail for her. It also helps me be a little more clear in giving constructive feedback and for some employees the detachment helps it sync in better.

· Feedback locality – There are three location in the template where I give feedback and for three very different reasons.

o In line with the employees assessment of their performance – Here I highlight what I think the important things were, agreeing or clarifying what the employee said and filling in context or important details left out. I think of this as fairly conversational.

o In the commitment rating section – I do the 2-3 strengths and the same number of growth areas each punctuated by feedback quotes

o In the contribution section – I make brief comments about the employees relative rating on the curve and what their long term prospects look like.

I do all of these with tract changes on and prefix my comments with “[BradA]” so any reader can easily see my comments.

· Let it settle – I always like to write the review at least a week before the review 1-1 so I can have a chance to re-read it and\or let my manager read it to ensure the message I am trying to convey pops out. Written communication can be very one-dimensional and the added stress of having it part of their “permanent record” can exacerbate even minor issues.

· Pick your battles – It is NOT necessary to include every bad (or good) thing the employee did this period. Focus on the blocking ones, the items that are keeping them from being really effective. Focus on actionable, attainable feedback.

· Everyone has room to grow – Even your star employee who just got a promo and Exceeded\Outstanding could be doing something better. It is very likely that their positives far outweigh their growth areas, but you still owe it to them to point them out. One way I have found to think about it (and communicate it) is to consider how the expectations for the next level are going up. For example: “As Bob continues up in level, he will need to think more strategically about how the team overall uses resources”.

· Beware of the strength overdone is a weakness – I have seen a pattern where an employee’s biggest strength can be a weakness when it is overdone. For example an employee with an amazing drive to get things done, can sometimes be seen a railroading issues or not listening to feedback. Help the employee think through where the line is, but you don’t want them lose the strength while they work on the weakness.

· Avoid absolutes - I generally avoid absolutes when given constructive feedback such as “Bob never finishes his specs on time” or “Beth always interups her co-workers”. It is likely the employee can find a counter example which will rob your feedback of some of its power. Keep the focus on the behavior that needs to be addressed.

· Balance the feedback - While it is certainly not true that all employees have an equal weight of good and bad things to give feedback on, I do try to give the same number of good and bad feedback points, even while clearly highlighting the most important issue. This helps to show the employee that you are trying to be balanced and you are seeing the good work they are doing.

· Enhance their strengths and minimize the impact of their weaknesses – The goal is not to “fix” employees weakness. I have found it far more effective to identify the employees strengths and put them in a place where those strengths can be even more impactful rather than continuing to focus on the same weakness over and over again. Figure out how to put them in the place where their known weakness are not a huge blocker for them.

· 360 degree feedback – I put a very high priority on getting feedback from an employee’s peers… as a PM, their opinions taken in aggregate are a pretty good barometer of their overall effectiveness. However, you never get 100% good data, every person is different and no feedback can be taken as gospel. As such, I only include feedback that resonate with me… that is that I have seen similar behavior or experiences. I also try to work the feedback into the major points I am trying to make. As a manager, I prefer the coaching type of role where I can say “here is the feedback we are seeing let’s have a discussion about how we can effectively address it”. Rather than the not-so-helpful “I think you have this problem, here is how you should fix it”. It is often interesting to note that 360 feedback often misses important areas you should fill in… things like coaching of employees or the task that was never done because no one know they had it!

PM tip# 11: Information is the Currency of Program Management

BradA — Mon, 10 Apr 2006 17:27:00 GMT

A huge differentiator between mediocre PMs and excellent PMs is how they deal with information. Anyone that has been a PM for more than a few days inherently knows that information – getting, distilling, combining and distributing of ideas – is a key part of just about every PM job. PMs that know how to get, process and share information in a timely way are a huge asset to their teams.

Here a few ideas around information sharing...

Noise is not information

There is a big difference between getting distilled, relevant and timely information to the right people and spamming the masses with trivialities. This falls into the “don’t confuse activity with results” bucket. It is not the activity of send status reports or forwarding information or having a meeting that is the goal, it is the results of feeding an informed, collaborative work environment that is the goal. There is certainly a time and place for team wide emails and all-hands meetings, but think carefully about the goals.. would a 1-1 or small forum meeting be better or at least a better start? Think about how folks like to consume the information. You might consider splitting out detailed notes "for the record" from the few key action items.

If a tree falls in the woods...

I will not repeat the whole Be More Visible Sham post, but suffice to say if no one knows you did X, did you really get all the benefits for doing X?

Know who knows

Obviously you can’t know everything but possibly by the Six Degrees Rule you could know who knows any given bit of information. Clearly the admonishment to “build your network” is nothing new, but it is none the less true. Pay attention to who seems to know a given area by who address issues in public forums (blogs, newsgroups, internal email lists, meetings). Leverage others networks by paying attention to who others ask. Be a good member of the network by helping to direct queries even if you can only get them a little bit closure.

Hoarding information

You can take this information is currency thing too far. I don’t know about you, but I want to hold onto as much US currency as I can.. I am not likely to share it with you unless I get something in return. On the other hand, information is a much more fluid market than capital.. So fluid in fact that it almost always behooves you to share the information you have even if you are not directly getting a quid pro quo return.

A classic example of information hording is the annual review system. The mechanics of how review scores (and by extension monetary compensation) are dolled out is often a carefully guarded secrete. The argument is that individual contributors don’t “need to know” this information so it is horded between the managers and HR. This causes no end of rumors and speculations on how the system really works many of which are hopelessly wrong and lead employees to the wrong behaviors. I have always advocated (and practiced on my team) full disclosure of how the process runs, I found that sharing that information actually takes away some doubt and worry and helps focus employees on the right things.

Lose lips sink ships

As a general rule PMs should work hard facilitate the transfer of information freely, however there are times when you should keep your mouth shut about something such that the right channels for communication can be used. This problem sometimes manifests itself in forwarding an email that contains sensitive information or in simply trying to “show-off” that you know more than someone else.

Early in my career I was involved in a project that was taking a major change in direction. I owned the partner relationships for this team and I happened to see a key partner after hearing about our change in direction. I told the partner and even provided my own analysis (“that means we’ll have to can your project”, I said). Needless to say this concerned the partner I was talking to, he talked to his manager, who talked to mine who called me at home to stop the leak. Not only did this mistake cause some personal distress for some folks as I did not get the story exactly right, it also caused my own manager to be slower about including me in sensitive discussions.

While I am still a huge fan of free information flow, the rule of thumb I use is if-in-doubt-ask...

The Echo Chamber

You get an echo chamber effect when information is simply repeated (and often exaggerated) without a firm grounding in fact. I have seen speculations, turn into rumors, then into facts through the course of a few days based on nothing more than hearing other people say something. Maybe it is a competitor is doing xyz or a given technology is not good for a scenario, etc. These get really hard to manage as very senior folks in the organization start accepting them as fact.

To battle the echo chamber effect insist on understanding the information, don’t just pass it on as if it must be true. Get a reputation for cutting through the bull to the real-deal rather than just someone who knows what the latest echo is. Be sure to listen outside the walls of the echo camber. That might mean outside your group, your company or even your industry..

What do you think? Agree/disagree? What else have you noticed about dealing with information?

The Beta vs. CTP Dilemma

BradA — Mon, 03 Apr 2006 18:11:00 GMT

Over the last couple of years, the CTP or Community Technology Preview has been one of the bigger changes in the way Microsoft release software. Microsoft introduced the concept of CTPs with the “Whidbey” .NET Framework and Visual Studio release but I was happy to see the concept spread to SqlServer, Expression, WinFX and even Windows!

CTPs have been very valuable to us as we have been able to get some great feedback in near real time from customers rather than waiting for a long Beta cycle or worse until after the product has been released to hear the feedback.

But, of course, CTPs have not been without their paint points... Frequent releases come with variable quality and are often incompatible with other pre-release software putting developers in a state of “CTP Madness” where it is often difficult to figure out what two builds work together. JasonSu and I did create a cure – or at least a treatment – that I have heard helps a lot. But the pain certainly does not go to zero.

So, as we begin planning the interim release schedule for Orcas I find myself torn between the traditional value (and costs) of betas and the new value (and risk) of CTPs. The downside of betas is that in order to drive up the quality we need pretty much all hands on deck working on the beta... if there are a few features that are not quite done, it is hard to keep those features moving forward during the beta lock down. This effectively means we extend the release schedule by the Beta lockdown time. We also attempt to “line-up” Betas of related products so that customers can use them together. The plus side of betas is that because we drive the quality up and make them work together, conventionally wisdom is that more customers are able to try it out and get us feedback.

But I wonder if we did a good job with quality throughout the cycle making the builds fairly usable as they come out, could we replace the two or even three beta cycle with less betas and more regular CTPs? This of course only works if we get customers to give us the good quality, real-world feedback on CTPs.... if we don’t get the good feedback until very late in the cycle then the plan didn’t really save us anything.

So what do you think? Do “betas” offer you\your customers something specific that CTPs don’t? Are you able to pick up the CTPs and try real deployments on them or is that something you can only do with Betas?

PM Tip #72 Instant feedback...

BradA — Thu, 30 Mar 2006 21:44:00 GMT

One thing I love about blogs is the instant feedback aspects. While certainly comments on a blog are far from scientific you can get some great anecdotal responses that can help you see problems in a new way or provide some real-world data to backup one position or another. So my tip to PMs out there is to think carefully about what question you want to know the answer to and blog it! I have really benefited from the feedback I have gotten on my blog and I know several specific instances where the feedback changed my mind and\or helped me impact the product in tangible way.

Of course, you should still use the official channels such as SDRs, usability studies, market opportunity analysis, etc... but many of those are quite general and long lead. Involve the community in the heat of the moment... I would not use blog feedback as the only data point, but it is certainly a data point you should use. You do not have because you do not ask...

This topic pops to mind as I watch a couple of masters use this technique to great effect... how can any PM read these comments and not have it effect their view of the solution space!

Chris Sells on Tell me about your troubles and woes configuring, deploying and maintaining distributed .NET apps

Don Box on HTTP, XML, REST, and $100

Oh, and as users, I encourage you to respond and be heard!