Software Engineering, Project Management, and Effectiveness
We have a Downloads Index for Visual Studio Team System Guidance in our patterns & practices Visual Studio Team System Guidance Project. You can now download various types of guidance including our Explained, Guidelines, How Tos, Practices at a Glance, and Questions and Answers guidance modules. While we optimized our guidance for online availability in HTML, we know many readers prefer reading PDFs.
What does it take to be an effective Program Manager at Microsoft? I'm responding to some requests for my take on what it takes to be an effective PM. I figured I could use a familiar 7 habits approach to help frame out a start.
To pick a set of habits, I started with a set of reference examples. I used the most effective and ineffective PMs that I've seen over time. I considered their track record, their ability to influence, and their leadership skills. Most importantly I looked at their ability to ship and make the right impact for customers. Next, I looked for the underlying patterns (I'm a principles, practices and patterns guy). I used the ineffective PMs to think of the anti-patterns and the practices of what not to do. This contrast helped me clarify the distinctions between effective and ineffective.
Here's what I found to be the 7 habits of highly effective program managers:
Habit 1, Frame problems and solutions. Frames are the things mental models, metaphors, and conceptual frameworks are made of. Simply put, they're frames of reference. Effective PMs create useful ways of looking at the problems and solutions. They create shared frames of reference that help narrow and focus, while keeping perspective. Frames help chunk up the problem or the solution. Frames also help share information quickly as well as avoid information overflow. The secret here is that frames provide contextual reference. Without context, it's hard to evaluate problems or solutions.
Habit 2, Sell visions. The most effective PMs dream up great ideas and they sell them. They sell them in the hall, they sell them to co-workers, they sell them up the chain. They have an elevator pitch that resonates. They can paint a vivid picture of how the world will be different. Sometimes a PM has an idea that people aren't ready for. Sometimes a PM has an idea they just aren't selling right. Sometimes a PM has an idea that ... well ... just isn't ready for market or planet Earth. Selling visions involves both thought leadership and people leadership. I think the secret here is effective PMs sell visions by answering "what's in it for you" for stakeholders and customers.
Habit 3, Deliver incremental value. How do effective PMs go from zero to Rome? While the big bang can make a lot of impact, the problem is the longer they delay, the more project risk adds up over time -- visions change, people change, markets change, stakeholders change, perceptions change … etc. Anything that isn't built in a day needs a serious chunking strategy. The sooner they can start delivering value, the sooner they can get feedback and adapt and change. Also, they have better chances of hitting key windows of opportunity.
The most effective PMs can chunk their solutions. This is non-trivial, particularly in software. It means knowing what the minimum shippable chunk is. It means right-sizing their chunks so that each one delivers value for the right customers. It means unbundling dependencies to remove unnecessary project risks.
I think the secret of effective PMs here is thinking in terms of value rather than quantity, as well as knowing dependencies. What can they cut and truly gain time and resources without risking quality? Here's a true test ... if their 12 month project were cut into 6 ... or their 6 month project cut into 3 ... what would they cut and what would they deliver? If the success of their project depends entirely on shipping everything in their plan for the full project cycle, that's a recipe for failure.
Habit 4, Manage communication. This is a crucial skill since this means managing perceptions, managing expectations, brokering knowledge, and making sure the right people are involved. This is why some PMs fail where others succeed. The most effective PMs make sure the right people are involved on the right problems. They also setup forums and channels for communication. I think there are a few secrets here. The first secret is, they tailor the language for their audiences. For example, for stakeholders, they know their relevant currency (time? budget? resources? business value?). For engineers, maybe it's how does it work or why. For customers it might be features, scenarios or value. The second secret is, they use a variety of communication tools. Effective PMs make use of a range of SharePoint portals, Wikis, Mind Maps, whiteboards, blogs, forums, etc. The third secret is, they use the right mediums for the message. Effective PMs consider whether their message is best delivered in slides, mail, meeting, phone, etc. For example, slideware is often more effective than a long email.
Habit 5, Connect with customers. This is where the rubber meets the road. The most effective PMs have strong customer connections. Not only do they work with customer directly, but they have a useful representation across relevant segments. The mistakes I usually see here include the following: no customers, pretend customers, one customer size fits all, or assuming their internal scenario can be generalized to typical customer scenarios. The secret here is that it is not the number of customers, rather it is scenario representation and trusted sounding boards with key customers.
Habit 6, Execute. Execution makes life easier at Microsoft. The most effective PMs have great work breakdown structures and the right resources working on the right jobs. I know this sounds overly simple, but there's a secret here. I've seen work breakdown structures that are focused on activities versus outcomes. If a PM does not have a good work breakdown structure, then that means they don't know the work to be done. If they don't know the work to be done, then their estimates are off. If they don't have a good work breakdown structure, then it's also easy to have the wrong people doing the wrong jobs.
Habit 7, Leverage the system. Effective PMs know the system they are operating in. For example, they know their product cycle, software development life cycle, key milestones, and key events. They also know who or what influences who. Basically, they know how the system works. While they could paddle down the river without a map, this map helps them anticipate the obstacles and opportunities. The secret here is that experience alone doesn't create this map. Anybody can start making their own map by asking questions about the system they're working in.
While this list of habits above is not a comprehensive list, I thought it would be a good start. I'd actually like to hear from you what you think are the habits of the most effective PMs.
"What's their story?" ... With one cutting question, my manager exposed the fact a colleague had only one side of the story -- their own.
We make up stories every day either to explain our own actions or the actions of others. What happens when our stories limit us or hurt our relationships? For example, have you ever jumped to the wrong conclusion about somebody's actions and later regreted it? I know I have.
What the experts do is they swap stories. The trick is seperating fact from fiction. First, they share the facts they know. The more objective or verifiable the facts are, the better. The facts help build common ground. Next, they share their interpretation of those facts. This is their story. Then they ask the other person for their version of the story.
It's a simple technique, but I'm finding swapping stories is very revealing. Sometimes I'm surprised by my own interpretation of the facts. Other times, I'm surprised by another person's interpretation of the facts. Either way, I consistently find that a thoughtful response is better than an emotional reaction.
The next time you find you just don't get somebody's behavior, before jumping to negative conclusions, ask "what's their story?"
As I talk to more feed readers, I find there's patterns that work and patterns that don't. I'm a fan of starting with examples of "what's working" and "what's not" before building a new solution. The most common anti-pattern I found was "too many feeds, not enough time." The most effective pattern I found was a set of tuned and pruned feeds.
To fix my feeds, I used the following approach:
To wipe my slate clean, I archived what I had. I had several hundreds of feed sources. I figured I could compare later, but I wanted to start fresh and lose potential baggage.
To figure out my objectives, I asked a simple question -- "what do I want to accomplish?" I figured listing the questions I need to answer with my feeds would be the most effective:
This created my map of what feeds I needed to add. I ended up surprised by how different my deliberate map was than my typical feed reading habbits. I didn't realize this until I had the map above to check against.
Next, I figured out practical time and quantity constraints. I set a bar of 30 feeds and a max of 20 minutes reading time max for reading time. Talk about a true exercise in prioritization, considering I'm used to hundreds of feeds! I decided I want to trade lightweight and effective over exhaustive and a burden. Put it another way, I want to spend more time with the cream of the crop, and less time filtering the wheat from the chaff.
As I hunted and gathered for feeds, I distinguish sources of news from sources of insight. I want both but I prioritize insight. I also looked for bloggers that take the time to distill information for some key areas, so that I don't have to. In some areas, I do my own distillations, in others, I want to leverage the network effect. As I hunted for feeds, I also kept the following guiding questions in mind:
This gave me a good baseline of feeds. It also put me in great shape to bring over some of my favorite feeds I had archived. It was easier to bring over just a handful of the best vs. sort and filter through everything I had.
While this wasn't my first do-over, it was probably my most useful. I feel closer to the sources of information that I'm actually going to use, and less burdened by the noise. I'm going to test more tools and techniques for feed reading, so if you have any tips or techniques to share, I'd like to hear them.
I made some changes to my tag cloud and learned some lessons along the way:
I removed the following tags:
I changed the following:
I'm not satisfied with my tag set yet, but I did find some of my old favorite posts. There's still a few sets of posts that aren't easy enough to get to, but I'll have to think more about how to surface them.
If you are a hunter and gatherer of guidance, you'll want Guidance Explorer. Watch Video: How To - Personalize Team System Guidance with Guidance Explorer to see how you can use Guidance Explorer to build a custom collection of guidance from our Visual Studio Team System Guidance project. If you haven't used Guidance Explorer before, or it's been a while, you're in for a surprise. Seriously.
Guidance Explorer is a free tool to help you browse, find, organize, or even create your own guidance. When you launch Guidance Explorer, it synchronizes with our online store. For example, today's additions include a number of brand new Team System guidance items:
My favorite Guidance Explorer features include:
Keep in mind that Guidance Explorer is actually a diamond in the rough. It has its flaws, but it also has unique powers. For example, I could use Guidance Explorer to inform you of brand new, emerging security practices. I could also flag the top performance issues using the priority field. Imagine the alternative of hunting through a whitepaper or article, instead of organized collections and lists of actionable, guidance nuggets.
I know consultants that literally save themselves many hours per week by using Guidance Explorer as a personal knowledge base and for tailoring guidance for customers. I also know of customers using Guidance Explorer as a light-weight and effective way to share guidance among their development teams. It's actually the type of tool where customers surprise me what they use it for.
While Guidance Explorer has nearly 1100 guidance nuggets at last count (across security, performance and .NET 1.1. and 2.0), you can quickly shrink the haystacks to find the needle that you need (Ed and I call this our Shrinking Haystack pattern). You can also discover relationships among the guidance, because related items are linked. Don't take my word for it though, test drive it for yourself. Did I mention it's free? Oh yeah, I should also mention it comes with source, so shape it to your heart's content.
Go ahead and watch Video: How To - Personalize Team System Guidance with Guidance Explorer and then download Guidance Explorer. If you do use Guidance Explorer and you have a story you'd like to share, please leave a comment in this post.
We just added Video: What Is - Branching to our Visual Studio Team System Guidance Project. Watch this video to see how branching may impact your strategy when using Team Foundation Server source control.
We added Video: What Is - New in Team Foundation Server Source Control to our Visual Studio Team System Guidance Project. Watch this video if you want a brief highlight of some of the differences between Visual Source Safe and Team Foundation Server: It's one of our first "What Is" type videos as part of our Video-Based Guidance Experiment.
Our patterns and practices team has just released new prescriptive guidance for Visual Studio Team System!
Since my previous post we've made significant updates with the addition of the following content:
This puts us on course to deliver on these main outcomes we have in mind for our Visual Studio Team System Guidance Project
Project OverviewWhile Visual Studio Team System provides powerful new tools, customers are asking "where's the guidance?" ... "where do I start?" ... "how do I make the most of the tools?" In response, our team is building a definitive Body of Guidance (BOG) for Team System. This includes How Tos, Guidelines, Practices, Q&A, video-based guidance, and more.
We’re helping customers walk before they run, so we’re starting with the foundation. On the code side (for developers) – this includes source control, building your dev and test environments and setting up a build process. On the project side (for PMs) – this includes work items and reporting. Once we have the foundation in place, we can move up the stack to making the most out of Team System for the various roles (tester, architect, developer … etc.) We're framing out the tough problems using Scenario Frames (for an example see Source Control Scenario Frame). We then identify where we need guidance and perform solution engineering. This involves building out reproducible customer scenarios, vetting potential solutions, and sharing the ones we can generalize enough to be broadly useful, yet still specific enough to be actionable. We're partnering with customers, product teams, support, field, MVPs, and subject matter experts. We’re working closely with Jeff Beehler to synchronize efforts with the VSTS Rangers, such as the Branching Guidance.
As part of our Video-Based Guidance Experiment, we've released an initial set of VSTS Guidance Videos.
Source Control Videos
Test drive our videos and help shape our experiment by either leaving your comments here or sending your feedback to firstname.lastname@example.org
We're piloting some video-based guidance. Here's what I want to accomplish for the videos:
For the user experience:
I'd like the videos to complement our text-based guidance modules (how tos, guidelines, checklists.) While doing video is nothing new, I think the tough part for my team is figuring out:
I think a lot of our guidance can be more consumable in video form. At the same time, I think some things aren't as useful in video. I see video as a supplement to augment baking knowledge into plaintext (where we can efficiently search it, share it, tag it … etc.).
Why 30 Day Improvement Sprints? I get asked this often enough that I think I should distll the keys:
Because my 30 Day Improvement Sprints are so effective for me, I have to resist the urge to bite off too many areas at once. In general, I try to balance between mind, body, career, financial, and relationships. My scannable outcome lists help me checkpoint. As a pattern, I do tend to focus heavily on career, but now that I see it, I can change it, if it makes sense.
Whether I'm working on a 30 Day Improvement Sprint, or working through a complex problem, I find journaling is key. By journal, I simply mean a personal log in some form that I can easily add to and review. Journaling is key because I get to see at a glance, what I've accomplished. I write down my little achievements each day. When I don't, I tend to focus on everything I didn't do, instead of appreciating what I learned. Those little, incremental distinctions add up fast.
When I write down what I learn as I go, I have a log that I can scan for patterns. For example, do my breakthroughs happen later versus earlier? Do I usually get over a hump by bouncing an idea off somebody? Do I have a pattern for learning that I can optimize?
When I'm doing a 30 day improvement sprint, journaling is a must. Otherwise, I forget when I started. If I forget when I started, I don't know when I finish. If I don't know when I finish, then I'm no longer sprinting towards the finish line.
One of my favorite examples of extreme journaling is John Wooden. Aapparently he kept an indvidual journal for every one of the players he coached. He used journaling to tailor drills and customize training for each member of the team. Whenever I don't feel like *bothering* to journal for myself, I think of the example John Wooden set, and I get back on the saddle again!
How do I efficiently and effectively prioritize my day ... my week ... my life? In an earlier post, I talked about using Scannable Outcome Lists. For a quick reminder, this is simply a flat set of lists. I name each list by project or area I'm working on (e.g. mind, body, career, project X, project Y, projec Z). Inside each list, is my list of key outcomes. Think of these as a list of lists -- a bird's eye view of the big picture, and then a drill-down view in each list.
I use this to quickly scan across my areas to remind me of what's important to work on. This is the lowest overhead approach I've found so far to keep a wide radar scan, yet be able to drill in as needed.
When I first started, it was easy to simply sort my list by area. Now I find it helps me to sort this list by priority 0, 1, 2 and 99. Priority 0 is for my continuous categories: mind, body, career, financial, relationship, personal dev, professional dev, and recurring. I use recurring to remind myself of things like doing backups. Priority 1 is for my most critical projects or most important areas, compared to my priority 2s which might be ideas I'm somewhat working on or starting to build momentum for, but not critical for success. 99 is on deck or backburner. Collectively I think of this as managing action similar to Maslow's Hiearchy of Needs.
To do this in Outlook, I have a single folder called Queue, to hold all my scannable outcome lists. I drag a short-cut to Outlook's "favorite folders" for fast access. I create a single post for each scannable outcome category. I add priorities by assigning "Categories" to each post -- I tag each one with a 0, 1, 2 or 99. I "Arrange" this older by "Categories", and then I custom sort by Subject. This gives me a very fast sequenced view grouped by P0, P1, P2, P99 and then sorted alphabetically within each group.
I start my days by scanning or updating my scannable outcome lists, then carving out the most important actions into my daily dos list. The entire process generally takes me 5 minutes or less each day, except on Mondays where I have to spend a little more time to figure out outcomes for the week.
We did a focused set of security videos with Keith Brown a while back. The problem is they're not very findable (most customers I talk to aren't aware of them). I added them to soapbox and listed them below to see if it helps (note soapbox may prompt you to log in):
Input and Data Validation Videos
They're designed to help you get key concepts behind some of our security guidance. I also wanted to use somebody that was recognized in the field as somebody you could trust. Keith's proven himself for a long time in the security community. He also has the aura of an experienced trainer, which I think comes across in these videos.
After reading Alik Levin's Security Language That Everyone Understands and Michael Howard's Security Analogies are usually Wrong, I reflected on some mantras and metaphors our team found helpful during our various security adventures:
I've found these helpful too:
As with any verbage or mental models, their usefulness varies and really depends on the context. I like keeping my toolbelt full of options so I can choose what's most useful for the job at hand. I do have some more favorites, but I'll save those for another day.
The secret to time management isn't more time management hacks at all. Here's the keys I've found:
I often here the argument, "if I had more time for this or that, I could ..." Well, unfortunately, having more time doesn't always mean getting more done. It doesn't guarantee getting the right things done either. Sometimes I get more done in an hour than I can sometimes get done in a week. Why is that? For me, it's actually about energy. There's only so many hours in a day. While I can't make more hours in a day, I can use my energy better. Sure there's lots of interesting little time savers, but there's plenty of time wasters too. I find the force that makes the most measurable difference is the energy and engagement I bring to the table.
Assuming I have all my energy ready to tackle my day, I need to distinguish between urgent and important. If I'm only reacting to urgent, then I'm missing out on opportunity to deal with important, whether that's job impact or personal growth. The moral of the story is, if I don't make time for the big rocks, the fillers in my day won't leave room. I like Steven Covey's perspective on urgent vs. important in his First Thing's First book. Here's a nice summary of the popular Make Room for the Big Rocks story.
Anticipation is a actually a skill that I haven't worked on as much as I should. I actually plan to do a 30 Day Improvement Sprint, when the time is right. It's funny how many recurring things happen each year, that take me by surprise. Birthdays. Holidays. Reviews. Events. Geeze! You'd think I'd see the patterns ;)
Well, I do. I've seen the pattern of me reacting to events I don't anticipate. While the corporate ninja expects the unexpected, I also find that with a little anticipation, a stitch in time saves nine. If I make project plans, and there's a major event I didn't account for, I shouldn't be surprised when suddenly nobody's around. At the same time, I'm sure I can find a way to leverage the sudden spurt of energy some folks have right after mid-year discussion.
This a practice I learned long ago and it's actually helpful whether it's day to day or building software. It's doing worst things first.
It's human nature to move away from pain. Sometimes I have a meeting or a conversation or even just a task for the day that I'm not looking forward to. I'm not talking about the stuff I can ignore forever. I'm talking about stuff that needs to happen sooner rather than later, that I won't enjoy doing.
If I push those things to the end of the day or the end of the week, they loom. Why loom longer than necessary? That's draining. Somebody long ago gave me the tip worst things first and I didn't realize it's actually become one of my most effective habbits.
One of my mentees is going to combine worst things first with a 30 day improvement sprint to see how much energy they get back and how much more they get done. I think this is a great experiment and I look forward to their results.
It's amazing how much the metaphors we use can be enabling or disabling. For example, I used to think "in life there are no second chances" or "you never get a second chance at first impressions." Once I adopted, "life's an experiment", it was much more enabling. It means, changing from getting everything right up front to boxing my risks, trying more, and learning and adapting as I go.
My manager is very much into experiments around impact and improvement. He's got a research background, but he's into applied research. That works great for me because I'm a fan of learning what works over theorizing endless possibilities.
For me, the keys to metaphors are knowing which ones I use, and which ones are limiting. I always need to ask, what's the most enabling metaphor for the situation I'm in. What will make me more resourceful? For example, in a group like patterns & practices, experimenting and continuous improvement come with the job.
I'll have more to say on metaphors another day, but in the meantime, I'll leave you with this ... do you know your 3 most enabling metaphors? ... do you know your 3 most limiting? (hint - limits and opportunities are in the eye of the beholder ... whether you think you can or can't, you're right)
I like Hacking Web Applications Exposed, second edition. I really do. Here's the foreword I wrote:
"Reveals the magic behind the attacks that are so pervasive on the Web today. Knowing the attacks is a first step towards figuring out effective countermeasures. The authors's style makes the information real and practical, while sharing their real-life experience."
Joel Scambrary, Mike Shema, and Caleb Sima are the authors. What you might know about Joel Scambrary is his previous Hacking Exposed books. What you might not know about him is that he ran the security operations for MSN. I worked closely with Joel, during our Improving Web Application Security:Threats and Countermeasures days. He shared my passion for chunking up information to deal with tough problems. We had lots of deep conversations about using buckets to break security down into manageable chunks and driving action. I miss our talks.
I first got to see Caleb Sima in action at one of our Microsoft hosted security events. He's one of the most entertaining presenters I've seen. He walked through a Web attack weaving a story of suspense and drama, full of amusing twists and turns.
Bottom line - the book is insightful, practical, and the authors do a great job of interspersing actionable nuggets throughout.
This conversation (er, debate) comes up a lot. What's the difference between performance, load and stress testing? I'm sure there's tons of *official* definitions. At the end of the day, I think about them like this:
I could say more, but sometimes less is better. If you want to read more, check out our patterns & practices Performance Testing Guidance Project on CodePle or browse through Scott Barber's exhaustive collection of performance testing articles.
The Team Foundation Server Branching Guidance whitepaper is now available! It's a comprehensive whitepaper that covers strategies, patterns and anti-patterns for branching and merging with TFS. You can view the branching guidance online or you can download the PDF version.
Branching Guidance Index
My team works closely with Graham and Mario of the Branching Guidance team as we build out our patterns & practices VSTS Guidance Project. We're sharing learnings and synchronizing recommendations as we go along. We'll be adding more cross-references to the Branching Guidance Project and VSTS product documentation on MSDN from our guidance so you can easily hop for more information.
Here's some quick blogging tips I shared with a colleague, that they found helpful:
Today I was reminded of the powerful scenario for building a custom set of guidance on the fly using Guidance Explorer. One of the scenarios for Guidance Explorer that's probably not well known, is the ability to generate MS Word documents. You can also save to HTML or export to XML. The idea was that you could build a custom set of guidance by grabbing the guidance modules you wanted.
In my case, I needed to quickly create two documents -- a set of ASP.NET 2.0 security guidelines and a set of ASP.NET 2.0 security checklist items. To do this using Guidance Explorer, I took the following steps:
This gave me a single Word document of the ASP.NET 2.0 security guidelines with an index up front and the details in the doc. I repeated the steps to create a set of ASP.NET 2.0 security checklist items.
If necessary, I could have tailored the guidance before creating the document. Another feature that's not well known is that you can use Guidance Explorer as an authoring tool. You can quickly modify the content of guidance modules and then save to one of your read-write libraries.
IT Security posted their list of The 59 Top Influencers in IT Security. They say their list includes "...most influential security experts of 2007 - from corporate tech officers and government security types, to white hat hackers and bloggers." I don't get caught up in whether it's the right list or complete list. Instead, I use the list to look for names that I don't recognize to see who might have new ideas or thoughts I should explore.
On the Microsoft side, I like to browse the following lists to see what our security-minded community is up to: