Preparing canned explanations

As a developer, I spent a lot of time explaining things to computers (in other words, coding). Starting as a graduate student, and now as a program manager, I spend a lot of time explaining things to people. Turns out that's often harder.

It's particularly hard with canned explanations, such as presentations and specs, where you prepare the explanation in advance. If your audience doesn't understand something, you may lose them; you may not get the chance to try another tack.

Preparing canned explanations is an art, and I know just enough to realize I know almost nothing. Due to the patient mentoring of a great explainer, and through watching several others, I've managed to learn a few pointers. The most important is to tell a story. This is very broad, and includes:

• Start with what they know. Don't throw your audience in the deep end. Start with common knowledge, then build to new things.
  
• Give an intuitive overview. Tell the audience where you're headed. Suspense and surprise work sometimes, but don't keep them guessing about your point. A rule of thumb is "tell them what you'll tell them, then tell them, then tell them what you told them."
  
• Flow is everything. Top down, bottom up, temporally, procedurally (first, then, next, finally)...however you do it, make points flow from one to another. If you break the flow, or have none, it's easy to lose your audience.
  
• Make every word count. Be brief. Try to make one point at a time. Then, drop unnecessary points.
  
• Be concrete. Define nouns, quantify adjectives, and favor processes over vague verbs. Numbers, anecdotes, and examples go a long way.
  
• Use the conclusion. The audience may skip everything else, but they'll usually wake up for the conclusion. At minimum, reiterate your story outline and emphasis your main points.

Apart from telling a story, I've learned a couple tips about polishing explanations:

• Get feedback on your drafts. Give practice presentations, ask peers to review your specs, etc. Feedback from first-timers is invaluable, so don't waste fresh eyes: have some people review your first draft, others your second, and so forth. It also helps if someone reads multiple drafts, but make sure they're either very patient, or owe you a favor.
  
• Insist on criticism. Ask what you could have done better. Insist people tell you something. There's always something to improve, and people can be surprisingly reluctant to give criticism face-to-face.

I'm always looking for new tips, so if anyone has a good one, please share!

Read more... Collapse post...

Nice thing about PMing at SQL Server

Fair warning: shameless plug ahead.

Groups within Microsoft vary widely, including everything from the culture, to the engineering process...even the acronyms. Makes it hard to paint the whole company with one brush.

For instance, take SQL Server. We're not the 500lb gorilla; that's Oracle. In the database arena, we're one of the scrappy underdogs, and it shows in the culture. At the same time, our division is one of Microsoft's established workhorses; we're not an experimental foray into a new business. That also shows in the culture.

It's an interesting combination. It gives us constant drive and motivation, but directed by a maturity that comes from knowing we impact the company's bottom line. As a PM, I really feel both of these factors. I'm always encouraged to think about differentiating, and solving the biggest customer pain points. At the same time, I know we're working on cool stuff that will actually make a difference.

Read more... Collapse post...

Defining Program Management

I joined Microsoft SQL Server as a Program Manager in January. Before then, my direct PM experience was herding 20 undergraduates into developing a video game for a class, reading parts of "The Art of Project Management", and preparing for the Microsoft interview. In other words, I'm still very new at this.

About the first thing I learned is that the PM role is hard to define (which is part of what makes it fun).

I've heard developers describe their role as "we fix bugs", and testers as "we find bugs". Oversimplified, but, given a broad enough definition of "bugs", mostly accurate. It's harder for PMs. "We write specs" fits the pattern, but no definition of "spec" covers most of what we do. Scott Burken renamed his book "Making Thing Happen", but that's not really concrete. A developer friend suggested "we schedule meetings", which, while funny, isn't very specific.

In an effort to understand and communicate the role, here's a list of what I think it means to be a PM (which, by the way, is a very PM-ish thing to do). The goal is to keep it updated over time, and to track the changes.

What do you think? Anything I should add to or take off the list?

So, what do Program Managers do? I (currently) think

• We make things easier: for customers, by designing good features; for engineers, by getting stuff out of their way; for managers, by abstracting away the project's day-to-day; for sales, by differentiating and evangelizing.
• We (try to) understand customers: listen to them, shadow them, think like them, and champion them.
• We drive consensus: get stakeholders to agree on a vision.
• We champion the vision: keep the project on-target.
• We understand the business: how do we differentiate? What's the next big thing?
• We design the functionality: specify what the feature does, and help developers design how it does it.
• We project manage: plan the project, track progress, and manage risks.
• We explain things: communicate between engineering, customer, and business worlds, through presentations and writing.
• We evangelize: get people excited about the project.

Read more... Collapse post...